All in one ...

[Peter Simons]

Guido, I will answer the multiple postings of yours in one reply for
the sake of limiting the number of articles posted on the list. So
don't be astonished when I jump from topic to topic in this article!

You wrote:

 > Peter, you are still working on the (frontend) engine parts of the
 > gnu system, actually? That wouldn't be a problem for me right now
 > ;-) ....

I suspended all activities on the software until we have the policy
for the "new archive" defined to a degree that makes radical changes
unlikely. I am currently gathering the points we discussed in a single
document, which I will post here ASAP. Currently, I have difficulties
typing, because my hands are still shaking from one-too-many beers on
the weekend, so don't expect any results before Tuesday or Wednesday.
:-)


 > thanks. I'm quieted (what was the english word again?).

Reassured? :-)


 > I have a current update submission in my inbox that changes the
 > behaviour slightly of an existing widespread macro - I am willing
 > to accept it, however .... should a notice of such changes be sent
 > to a macro list?

I think that is up to you. In the future, updates that change the
interface should be (publicly) evaluated before they are incorporated
into the archive. But I don't think that we will have the necessary
infrastructure up and running until at least two or three weeks. If
you accept the macro under the same name it has now, I don't see a
problem with it, since it is going to be marked "obsolete" anyway.
(You should tell the submitter, though.)

Accepting the macro under a new name already is not the way to go, I
think, because we don't know yet what rules we will have in place when
the archive is re-launched. And telling the macro author to change the
macro _again_ is IMHO bound to annoy him.


 > Or should acutally every commit be notified on a macro list as
 > well?

I think that Savannah has some mechanism for that in place. I
personally tend to check the diffs when doing a "cvs update" anyway,
so I don't really need commits to be mailed to me, but I am sure other
people will find it useful. It is probably a good idea, however, to
use a separate list for that so that we don't flood the discussion
forum with commit mails.


 > In a way, inconsistent version numbers are not our problem, it is
 > the problem of the author and how to handle bug request.

That is true. We don't _need_ consistent version numbers to run the
archive, and I am willing to let the author use whatever he sees fit.
I just think that this is not how the users of the archive _think_ it
would (or should) be.

Obviously, going from a "send in whatever you like" policy to a
massively fascist one is not desirable :-), but if we _do_ want
consistent macro versions, _now_ is the time to do it. (I also like
the idea of dropping the version tag from the input format, thus
making it easier for authors to send in correct submissions.)


 > "Finalized" means it is not anymore part of the ac-archive, neither
 > its visual or hard-to-reach content pages. An old version can only
 > be extracted from old tarballs [...]

Alright, I got it now. I'll write it up in the policy document ASAP
for you to review.


 > aaaaahm, here's the current example of `changes the behaviour
 > slightly` [...], so I am going to accept it [...].

I agree, that's not an "evil interface change". :-)

Peter