Re: Release Schedule issues and doubts

[Richard Sandiford <richard at codesourcery dot com>]

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