gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] [MERGE REQUEST] get-changeset with no default archi


From: Tom Lord
Subject: Re: [Gnu-arch-users] [MERGE REQUEST] get-changeset with no default archive
Date: Thu, 23 Sep 2004 15:01:07 -0700 (PDT)

    > From: David Allouche <address@hidden>

    > On Thu, 2004-09-23 at 10:30 -0700, Tom Lord wrote:
    > > In other words: I don't personally have an opinion at the moment about
    > > whether the "'changes' input validation speedup" should go in or not.
    > > I do have a meta-opinion that it might very well be reasonable to
    > > include that --- we don't have to go into a strict "bug-fix-only" mode
    > > when the clock is reset.

    > IMHO that is a thin rope to walk on. 

Oh, I completely agree with that.   But we're all on dozens of such
thin ropes anyway and (resource-wise) unavoidably..... it isn't a
question of avoiding such thin ropes --- it's a question of picking
which ones to live with for now.



    > Regular releases should be a
    > priority. 

Clearly I disagree.  Regular _release_candidates_, on the other hand
... now that's a great idea.  Especially if adventerous
user/contributors like yourself make sure to try them out and test
them.


    > Introducing changes, however harmless-looking, always risks
    > introducing new regressions, as we have just seen.

Right.


    > If I were the release manager, I would not accept any additional
    > "improvements" in a RC-frozen version unless there is a clear and
    > _urgent_ need.

    > But, then, I'm not the release manager.

I think that your attitude about the issue is right -- but we don't
have the luxury of turning that attitude into strict policy and
_therefore_, it is a matter of judgment when, upon the failure of a
candidate to be promoted to release, what else can be "snuck in" so
that the release candidates don't lag unreasonably far behind
submissions.

Never let it be said, in any case, that the rate of submissions should
govern the rate of releases.  That way lies madness.  Some submissions
will inevitably languish out of inescapable logical necessity given
the overarching goal of quality.

-t






reply via email to

[Prev in Thread] Current Thread [Next in Thread]