Release Schedule issues and doubts

Release Schedule issues and doubts

[Andrew Pinski]

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

Re: Release Schedule issues and doubts

[Richard Sandiford]

Andrew Pinski <pinskia@physics.uc.edu> writes:
> 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.
>
> [snip]
>
> 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.

I think the two issues are closely related though.  One of the reasons
that it's difficult to get a patch reviewed is that, to be really
confident in a patch, a reviewer has to understand what every line does,
and be fairly sure that it's doing it in the right way.  Some of the
"new feature" patches that have been posted recently have been very big,
and must have taken the reviewers a long time to review.

Even if it's not intended that way, your proposal is probably going to
be interpreted at some stage as a way of punishing maintainers.  If by
accepting a patch, you take on the responsibility of organising fixes
for every problem that gets traced to that patch, there's going to be
even less incentive to review the thing in the first place.

Richard

Re: Release Schedule issues and doubts

[Steven Bosscher]

On 6/4/06, Richard Sandiford <richard@codesourcery.com> wrote:
> Even if it's not intended that way, your proposal is probably going to
> be interpreted at some stage as a way of punishing maintainers.

And what is wrong with that?  Maybe it would help clean up the long
list of maintainers who don't actually do any maintenance.  Then, at
last, you get a more fair picture of the number of
reviewers&maintainers that we really have. Maybe it turns out that
patches don't get reviewed not because there are not enough
maintainers, but not enough _active_ maintainers.

>  If by
> accepting a patch, you take on the responsibility of organising fixes
> for every problem that gets traced to that patch, there's going to be
> even less incentive to review the thing in the first place.

With power comes responsibility.  If you can't handle the
responsibility, you shouldn't accept the power.  Being a maintainer of
some part of the compiler should be more than just being listed in
MAINTAINERS.

Gr.
Steven

Re: Release Schedule issues and doubts

[Gerald Pfeifer]

On Sun, 4 Jun 2006, Steven Bosscher wrote:
> Maybe it would help clean up the long list of maintainers who don't 
> actually do any maintenance.  Then, at last, you get a more fair
> picture of the number of reviewers&maintainers that we really have.

Agreed.  It will provide a clearer picture at least, though it won't
solve the problem per se.

(Among maintainers of specific parts, I think there aren't too many
not doing anything about those parts.  Write after approval is another
story -- I guess we have at least a dozen of nominal members -- and
global write does not necessarily reflect reality, either.)

> With power comes responsibility.  If you can't handle the 
> responsibility, you shouldn't accept the power.  Being a maintainer
> of some part of the compiler should be more than just being listed
> in MAINTAINERS.

If think nobody will disagree with the second sentence.

However, we should account for periods of inactivity and reduced
activity caused by personal issues, employer changes, illness,
whatever.

Other projects have a certain period of time (one year, eighteen months)
after which inactive contributors are contacted and eventually purged,
and I think we should do something similar.


Also, when we talk about responsibility, let's be careful not to demand
too much: just because someone is listed as a maintainer for foo, does
not means her or she shall be responsible for each and every patch or
bug in that area.  

Even fixing one bug a month and reviewing one patch a month is an
important contribution.  If this is not sufficient in a specific
area, we need to try and get additional maintainers, not alienate
existing ones.

Gerald

Re: Release Schedule issues and doubts

[Mike Stump]

On Jun 4, 2006, at 2:08 AM, Steven Bosscher wrote:
> On 6/4/06, Richard Sandiford <richard@codesourcery.com> wrote:
>> Even if it's not intended that way, your proposal is probably  
>> going to
>> be interpreted at some stage as a way of punishing maintainers.
>
> And what is wrong with that?

I have a different take...  I think people should be responsible for  
the patches they put in, and that means that in general, they should  
work on bugs and regressions in those patches before going off on fun  
new work.  This, if we wanted, could be enforced by accepting patches  
to fix regressions before accepting (any) other work by that person.   
This transfers responsibility from the person that approved the work,  
which, I'd rather not see in general, as it can discourage patch  
review, to the person doing the work.  We can also have this as an  
optional sign me up for more responsibility type of declaration by  
patch submitters.  I'm happy to fix regressions my patches cause, I  
consider it my obligation.

With regressions fixed sooner, we then might be able to engineer a  
situation in which Mark isn't saddled with hundreds of bug fixes for  
regressions, well, unless he caused them all.  :-)  Maybe we could  
even ditch some of the stageness we presently do.

This employs the standard motivation for work, the acceptance of a  
patch or not, instead of trying to use bullying tactics, we're gonna  
revoke your privilege, or other such mechanisms, which, I don't think  
increases the fun.

Re: Release Schedule issues and doubts

[Richard Sandiford]

Mike Stump <mrs@apple.com> writes:
> On Jun 4, 2006, at 2:08 AM, Steven Bosscher wrote:
>> On 6/4/06, Richard Sandiford <richard@codesourcery.com> wrote:
>>> Even if it's not intended that way, your proposal is probably  
>>> going to
>>> be interpreted at some stage as a way of punishing maintainers.
>>
>> And what is wrong with that?
>
> I have a different take...  I think people should be responsible for  
> the patches they put in, and that means that in general, they should  
> work on bugs and regressions in those patches before going off on fun  
> new work.  This, if we wanted, could be enforced by accepting patches  
> to fix regressions before accepting (any) other work by that person.   
> This transfers responsibility from the person that approved the work,  
> which, I'd rather not see in general, as it can discourage patch  
> review, to the person doing the work.

I agree.  And I don't think a new gcc by-law is needed here (we seem so
many of those already).  Maintainers can already refuse to review a "fun
new feature" patch until the submitter has fixed some problem with one
of the submitter's earlier patches (if the maintainer thinks that's
appropriate).  I remember at least one case where it has already
happened.

Richard

Re: Release Schedule issues and doubts

[Andrew Pinski]

On Jun 4, 2006, at 1:03 PM, Richard Sandiford wrote:
>
> I agree.  And I don't think a new gcc by-law is needed here (we  
> seem so
> many of those already).  Maintainers can already refuse to review a  
> "fun
> new feature" patch until the submitter has fixed some problem with one
> of the submitter's earlier patches (if the maintainer thinks that's
> appropriate).  I remember at least one case where it has already
> happened.

Yes but that is not all the problem because a lot of the time
the maintainer is also the submitter.  There is no way to discourage
the behavior of the maintainer on going on to other stuff while there
are known regressions to fix.

-- Pinski

Re: Release Schedule issues and doubts

[Richard Sandiford]

Gerald Pfeifer <gerald@pfeifer.com> writes:
> However, we should account for periods of inactivity and reduced
> activity caused by personal issues, employer changes, illness,
> whatever.

Agreed.

> Other projects have a certain period of time (one year, eighteen months)
> after which inactive contributors are contacted and eventually purged,
> and I think we should do something similar.

I don't really see what we gain by having a fixed limit (and another
rule ;)).  The SC have removed people in the past in cases where it
was "obvious" that they were no longer active.  That's really just a
house-cleaning exercise, though; I don't think we gain anything other
than cleanliness.

Like you said, there are good reasons why people might not be able
to review patches for a while.  But (as you also said) if someone in
MAINTAINERS manages to review an average one patch every two months,
say, that's still better than nothing!  Even if those patches come
after a long period of inactivity.  Some maintainers with a lot of
experience don't review patches as often as they used to, but they
still provide good reviews when they do.  I think a system of
punishing maintainers is going to make it less attractive for
less active maintainers to do anything at all.

It's not like we have a fixed limit on the number of active maintainers.
At the end of the day, if the SC think that someone would make a good
maintainer for a particular part of the compiler, they should just go
ahead and approach them.  Obviously having more maintainers introduces
more risk of disagreement, but (a) folks have generally seemed to work
through such disagreements in the past (b) I think any judgement about
whether the risk is too high is more likely to be based on the way recent
development has been going, _not_ on a count of the number of people
in MAINTAINERS.

Richard

Re: Release Schedule issues and doubts

[Andrew Pinski]

On Jun 4, 2006, at 1:19 PM, Richard Sandiford wrote:
> I think a system of
> punishing maintainers is going to make it less attractive for
> less active maintainers to do anything at all.

You are not punishing the good maintainers, just not so good
ones.  The idea is keep maintainers active in GCC and not just
sit in the side lines while their code gets bitrotten (which
happens too much in GCC already).  We can have a reward system
for good maintainers in that they get first priority for committing
in stage 1 and maybe allowing them to decide what is the best way
to do something.  In the sense they are can override the other
maintainers in that same area.

Thanks,
Andrew Pinski

Re: Release Schedule issues and doubts

[Gabriel Dos Reis]

Andrew Pinski <pinskia@physics.uc.edu> writes:

| On Jun 4, 2006, at 1:19 PM, Richard Sandiford wrote:
| > I think a system of
| > punishing maintainers is going to make it less attractive for
| > less active maintainers to do anything at all.
| 
| You are not punishing the good maintainers, just not so good
| ones.  

The trouble is there does not seem to be a clear gain in your
punishment system.  At best it may just discourage people.
In a commercial organization, that might be a good system.  For a free
project like GCC, it is not obvious where the long-term benefits for
the project are, given its "unconventional" way of "hiring" people.

People get inactive for some period of time for various reasons, some
of whichg are not subject of public debate.

-- Gaby

-- 
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
	Texas A&M University -- Department of Computer Science
	301, Bright Building -- College Station, TX 77843-3112

Re: Release Schedule issues and doubts

[Mike Stump]

On Jun 4, 2006, at 1:11 PM, Andrew Pinski wrote:
> Yes but that is not all the problem because a lot of the time
> the maintainer is also the submitter.  There is no way to discourage
> the behavior of the maintainer on going on to other stuff while there
> are known regressions to fix.

A wiki page of top regressions we care about?  We could politely  
request general agreement that the ones listed be given priority.

Re: Release Schedule issues and doubts

[Andrew Pinski]

On Jun 4, 2006, at 1:52 PM, Mike Stump wrote:
> A wiki page of top regressions we care about?  We could politely  
> request general agreement that the ones listed be given priority.

There is already a link from the main page of GCC to the regressions
and they are given priorities by the release manager already.

-- Pinski

Re: Release Schedule issues and doubts

[Andrew Pinski]

On Jun 4, 2006, at 1:43 PM, Gabriel Dos Reis wrote:
>
> The trouble is there does not seem to be a clear gain in your
> punishment system.  At best it may just discourage people.
> In a commercial organization, that might be a good system.  For a free
> project like GCC, it is not obvious where the long-term benefits for
> the project are, given its "unconventional" way of "hiring" people.

Which is why in my previous message, I proposed in giving rewards to
ones which stick around and maintain.  Do we want positive or negative
reenforcement?

> People get inactive for some period of time for various reasons, some
> of whichg are not subject of public debate.

My system said nothing about inactive people, only the active ones.
The way I consider a person active maintainer is approving patches/ 
creating
patches.  If a person cannot follow up on the approval and/or creation,
then why should we take the contribution if it causes problems?

2 months after the regression was found seems like a good time frame for
figuring if the maintainer could handle the work load.  Maybe we  
should have
a time limit on how far after the patch went in, we should consider  
the regression
significant to worry to give a punishment out.

-- Pinski