This is the mail archive of the
mailing list for the GCC project.
Re: GCC 4.0 Status Report (2005-02-03)
- From: Zack Weinberg <zack at codesourcery dot com>
- To: gcc at gcc dot gnu dot org
- Date: Sun, 06 Feb 2005 01:41:05 -0800
- Subject: Re: GCC 4.0 Status Report (2005-02-03)
- Organization: CodeSourcery, LLC
- References: <200502031949.j13JnNNp008162@sirius.codesourcery.com>
On Thu, 2005-02-03 at 11:49 -0800, Mark Mitchell wrote:
> However, before that happens, it is important that we have a coherent
> strategy for GCC 4.1. There are a number of major branches (and
> perhaps done on work that is not on a branch) that people will want to
> integrate, and we must do that in an orderly fashion.
> Therefore, we will use the same proposal-based procedure that we used
> (late) in the GCC 4.0 timeframe.
I would like to make two suggestions for additions to this procedure.
First, I think it would be a good move to file tracker bugs in Bugzilla
for each proposal, possibly with dependent bugs for subtasks. A similar
procedure seems to work very well for the Mozilla folks.
Second, I'd like to point out that the current three-phase development
cycle creates a strong perverse incentive for people not to fix bugs.
In phases 1 and 2, everyone is frantically trying to get their new
features coded and committed before the deadline, so they don't touch
their bug list. In phase 3, the only thing anyone is allowed to do is
fix bugs, so we all get tired and frustrated and lose momentum. To
counter this tendency I suggest that people ought to be allowed to
propose, and then follow through on, will-be-committed-by dates for
their projects that are as late as the day before the branch date for
4.1. This should have the effect that people are motivated to fix bugs
in phase 1/2, since it's not going to cause them to miss the deadline
for features, and at the same time, they may have feature work to work
on in phase 3 (if it made the list) which takes away the tedium of doing
nothing but bug fixing. The exact procedure here probably needs
tweaking, but I think it is important that we do something along these
lines in order to eliminate the perverse incentive.
(I should say that idea #2 above comes from a much more coherent essay
on the subject of deadlines and getting people to fix bugs promptly, by
Joel Spolsky, which I cannot now find.)