UCD problem in SSA/SpectrumDM

[Christophe Arviset]

Bob


Robert Hanisch wrote:
> On 11/24/09 5:48 AM, "Keith Noddle" <ktn at star.le.ac.uk> wrote:
>
>   
>>> Indeed, as stated by Ray, even "minor" revisions should go through the
>>> recommendation process.
>>>       
>> I wish to point out that I did also state this in my reply to Doug on
>> 20th; there never was any doubt that even the most minor of changes
>> requires full approval - I was trying to suggest that the extent of the
>> change will be proportional to the time approval takes, that's all.
>>
>> What doesn't seem clear to me is whether the IVOA has mandated that
>> minor revisions MUST be backwards compatible with previous revisions of
>> the current document (i.e. V1.6 MUST be backwards compatible with V1.1
>> etc). Maybe I've missed it somewhere, but if it isn't explicitly stated
>> then IMHO it should be.
>>     
> Hi Keith.  This is stated explicitly in Section 1.2 of the standards process
> document:
>
> " After a document reaches Recommendation status, subsequent revisions
> retrace the promotion process.  Changes that are backward compatible result
> in increments in the number to the right of the decimal place (1.1, 1.2,
> ...).  Changes that are not backward compatible require an increment of the
> number of the left of the decimal place (2.0), with subsequent backward
> compatible revisions following the same pattern (2.1, 2.2, ...)."
>
> Having been one of the architects of this review and promotion process, this
> discussion makes me wonder whether we need a more expedient way to deal with
> legitimate mistakes.  At the level of typos I would hope we could agree that
> these could simply be fixed, e.g., with the oversight of the standing
> committee on process.  A new version of the document (with date of issuance
> revised) would replace the previous one and changes duly noted in the change
> log part of the paper.
>
> For mistakes such as the incorrect UCD that led to this discussion the
> situation is not black-and-white.  Such a mistake causes changes to code,
> which invokes the "new version" rule, but hardly seems to require engaging
> the entire review machinery.  Of course, allowing things into this gray area
> becomes a matter of judgment (by whom?), and risks a foray into
> arbitrariness.  Maybe we need a lightweight "re-review" process for such
> situations.  In any case, let's try to not get out of control with rule
> making, lest we have to start hiring legal counsel into all of our teams!
>   
I agree with you that it is better not to enter this "gray area". We've 
already have enough difficulty to agree on the process, have it 
understood and respected that I believe we should stick to it.
I (naively!) believe that if the changes are really minor, the review 
process should be straightforward and we should get little comments and 
fast approval.
If people believe they are not that "minor", discussion / comments / 
answers take place as per the normal process.


Cheers

Christophe
> Your approach of gathering things together makes sense to me.
>
> cheers,
> Bob
>
>
>   

-- 
Thanks in advance

Cheers

Christophe


-------------------------------------------------------------------
Christophe ARVISET                       Christophe.Arviset at esa.int

European Space Agency (ESA)
European Space Astronomy Centre (ESAC)
Science Operations Department
Science Archives and Computer Support Engineering Unit

P.O. Box 78
28691 Villanueva de la Canada                 Tel: +34 91 813 12 78
Madrid - SPAIN                                Fax: +34 91 813 13 08
------------------------------------------------------------------- 


================================================================================================
This message and any attachments are intended for the use of the addressee or addressees only. The
unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content
is prohibited. If you received this message in error, please delete it from your system and notify
the sender. E-mails can be altered and their integrity cannot be guaranteed. ESA shall not be liable
for any e-mail if modified.
=================================================================================================