This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Release Schedule issues and doubts


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]