Release Schedule issues and doubts

[Andrew Pinski <pinskia@physics.uc.edu>]

Hi,
   First if anyone has a problem with this email please tell me  
instead of just hating me,
this email is not to make anyone hate me worse but instead try get  
some attention to the
problem with our current planned release schedule [1].

The current release plan as I understand it (please correct me if I  
am wrong):
stage 1: 2 months to get big (infrastructure) changes in
stage 2: 2 months to get smaller (non-infrastructure) in
stage 3: 2 months to get other bug fixes (and maybe add new ports) in
branch: release once regressions are fixed

Now once the branch is created, there is nothing in the release  
schedule what happens
so I am going on past experiences (though this is were the problem is).
Once either stage 3 happens and then again once the branch happens,  
the development
of regression and bug fixes go down and people start working on their  
own projects again.

Now at this point, we could say this because we are all volunteers  
working on GCC which
has happened when someone reports a regression and figures out who  
caused it and the person
who caused it goes and basically says that.  Now we have a policy for  
regression causing
patches but it does not get followed for regressions that don't show  
up in the testsuite.
The rationale of this policy is keep the release schedule on track.

Now for the fix I have in mind (which might or might not work):
If you are a maintainer of an area and you approve a patch which  
causes a regression in that new
code, you have to fix it or have the person whos patch it was fix it  
or face losing your
maintainer-ship if it is not handled 2 months after the regression  
was (openly) reported
(which means either to the gcc email lists or to bugzilla).

If the patch exposes a latent bug in some other code, the person who  
approved the code
is let off the hook and maintainers of that area would be required to  
look into the problem
if the patch's own is not able to figure out the fix.
---------------------------------

The rational behind this proposal is to make the release schedule of  
GCC faster and less
plain-full at the end when all the regressions have piled up.  Also  
it keeps GCC maintainership
more of alive value rather than just sitting back and not fixing  
problems.

We have currently at least 10 regressions which have been reported  
and publicly mentioned
which patch caused the regression for at least 2 months.  Yes getting  
these fix will not
allow us to branch 4.2 but a lot more regressions are already  
publicly mentioned which patch
caused it.

I know this is a tough problem to deal with but we need to try to  
solve this even
if that means not doing any more releases.

The other problem I see currently is not getting patches reviewed in  
a timely fashion but
that is for a different email and it looks like it is getting fixed.


Thanks,
Andrew Pinski

[1] http://gcc.gnu.org/develop.html