Restore-reliability mode - Mailing list pgsql-hackers

From Noah Misch
Subject Restore-reliability mode
Date
Msg-id 20150603135049.GA74753@tornado.leadboat.com
Whole thread Raw
In response to Re: [CORE] postpone next week's release  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Restore-reliability mode  (Geoff Winkless <pgsqladmin@geoff.dj>)
Re: Restore-reliability mode  (Andres Freund <andres@anarazel.de>)
Re: Restore-reliability mode  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Subject changed from "Re: [CORE] postpone next week's release".

On Sat, May 30, 2015 at 10:48:45PM -0400, Bruce Momjian wrote:
> Well, I think we stop what we are doing, focus on restructuring,
> testing, and reviewing areas that historically have had problems, and
> when we are done, we can look to go to 9.5 beta.  What we don't want to
> do is to push out more code and get back into a
> wack-a-bug-as-they-are-found mode, which obviously did not serve us well
> for multi-xact, and which is what releasing a beta will do, and of
> course, more commit-fests, and more features.  
> 
> If we have to totally stop feature development until we are all happy
> with the code we have, so be it.  If people feel they have to get into
> cleanup mode or they will never get to add a feature to Postgres again,
> so be it.  If people say, heh, I am not going to do anything and just
> come back when cleanup is done (by someone else), then we will end up
> with a smaller but more dedicated development team, and I am fine with
> that too.  I am suggesting that until everyone is happy with the code we
> have, we should not move forward.

I like the essence of this proposal.  Two suggestions.  We can't achieve or
even robustly measure "everyone is happy with the code," so let's pick
concrete exit criteria.  Given criteria framed like "Files A,B,C and patches
X,Y,Z have a sign-off from a committer other than their original committer."
anyone can monitor progress and find specific ways to contribute.  Second, I
would define the subject matter as "bug fixes, testing and review", not
"restructuring, testing and review."  Different code structures are clearest
to different hackers.  Restructuring, on average, adds bugs even more quickly
than feature development adds them.

Thanks,
nm



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: auto_explain sample rate
Next
From: Geoff Winkless
Date:
Subject: Re: Restore-reliability mode