Less radical proposal (was Re: Radical proposal: skip 3.4)

[Phil Edwards <phil at codesourcery dot com>]

On Fri, Jan 09, 2004 at 08:27:01PM -0500, Nathanael Nerode wrote:
> [...] it's probably worth 
> completely avoiding new development work until this gets cut down 
> somewhat.  On the other hand, if the new development work is going to 
> incidentally fix these bugs, it's probably worth going with it rather 
> than trying to come up with temporary fixes.
> 
> So I think people doing development work should identify which 
> regressions are already fixed by their development work.  This would 
> help identify which regressions are going to be "incidentally" fixed in 
> 3.5, and which aren't.  If lots of bugs will be incidentally fixed, 
> we're in one situation; otherwise we're in quite a different situation.

I was about to post a, "hey, this is a very good idea and I strongly agree
with it" message, then I realized that these are precisely the guidelines
we're already supposed to be following.

So, here's a suggestion:  during stage 3, this rule should be more
vigourously ... eh, "enforced" isn't quite the word I want, but it's close.
For those two months, we really should be seeing more bugs fixed than
new code committed.  Yah, I know fixing bugs isn't sexy, but getting our
collective ass whomped by commercial compilers is even less sexy.  Yah, I
know nobody here wants to be the unpopular bully who vetos perfectly good
new dev work during those two months, but I think it'll still be needed.

(This assumes that future stages really are held to 2 months or so... and
if we restrict stage 3 to just bugfixing, I'm betting that 2 months will
be plenty of time.)

-- 
LUKE:  Is Perl better than Python?
YODA:  No... no... no.  Quicker, easier, more seductive.
LUKE:  But how will I know why Python is better than Perl?
YODA:  You will know.  When your code you try to read six months from now.