Re: Fixes for 2.15.1

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Thu, 23 Feb 2012, David Miller wrote:

> > Fedora/RHEL have reverted the specific commit for handling EAGAIN.
> > It's caused more problems than it fixed.
> 
> I think we should be more pragmatic about changes that introduce
> regressions.
> 
> If we can't figure out the cause or nobody is spending the time to
> investigate, just simply revert the change, and revert it immediately.
> 
> In fact I think we should revert regression causing changes very
> aggressively.

Without commenting on this particular patch (I haven't studied the issues 
around it), in general I think this is a good idea and goes along with 
putting in changes quickly, which I also want.

For a large proportion of changes I think it would be fine for them to be 
committed either before posting, or soon after posting if problems weren't 
pointed out quickly - and I think we should have a healthily sized 
(probably ten or more) group of active contributors trusted to do this 
with many of their patches - along with some guidelines about when not to 
do this (if uncomfortable with the area of the library in question, or 
shortly before a release, or if introducing new public interfaces, for 
example).  And I think this would result in faster development and a 
better library.  But the other side of this is that if a change does 
introduce problems (including going against the desired coding style, or 
lacking a testcase that should have been added to the testsuite, or other 
internal matters) - found in testing, or pointed out in post-commit review 
- then there is responsibility to fix or revert quickly.  (This also 
implies it's a bad idea to commit risky changes - even reviewed pre-commit 
- shortly before you know you'll be away for a while.)

Obviously if a patch is reverted then any associated bug must be reopened.

GCC policy for reversion of regression-causing patches says:

   If a patch is committed which introduces a regression on any target
   which the Steering Committee considers to be important and if:
     * the problem is reported to the original poster;
     * 48 hours pass without the original poster or any other party
       indicating that a fix will be forthcoming in the very near future;
     * two people with write privileges to the affected area of the
       compiler determine that the best course of action is to revert the
       patch;

   then they may revert the patch.

-- 
Joseph S. Myers
joseph@codesourcery.com