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 10:30:45 -0700 (PDT)

    > Date: Thu, 23 Sep 2004 10:19:38 -0700 (PDT)
    > From: Tom Lord <address@hidden>
    > CC: address@hidden

    >     > From: Aaron Bentley <address@hidden>

    >     > I would think so.  I'd like to also stick that 'changes' input 
    >     > validation speedup into the next candidate, now that we have to 
make one 
    >     > anyhow.  Thoughts?

    > I'm with you.   And we can leverage that to even better effect if,
    > over the next few days, I can cons up a (possibly empty :-) "hit list"
    > of issues with the last release candidate.

    > Our goal should be unambiguous, monotonically increasing quality of
    > GNU Arch releases;  a good *approximation* of that with release
    > candidates;  encouragement of users who can to help test release
    > candidates;  and a complete cessation of the supposed "power politics"
    > crap that I keep trying to put down.

    > My gosh, if we muster ourselves in that direction, the project might
    > even start to look a bit .... dare i say it .... professional.


Oops: I should qualify my "I'm with you" a bit.

I do not mean that all of the subsequent integration work that was
done on the presumption that 1.2.2 was done should now be pulled into
the 1.2.2 line --- that would be disasterous.

I do mean that I think, given that we don't have (and probably don't
want, yet) to develop formal release goals for every release, there
*is* room for collective judgement about what can and should be "snuck
in" when the clock gets reset this way to fix a bug.   

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.

-t





reply via email to

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