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
