Re: 9.5 release scheduling (was Re: logical column ordering)

On Thu, Dec 11, 2014 at 2:05 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:

> On Thu, Dec 11, 2014 at 10:04:43AM -0700, David G Johnston wrote:
> > Tom Lane-2 wrote
> > > Robert Haas &lt;
> >
> > > robertmhaas@
> >
> > > &gt; writes:
> > >> On Thu, Dec 11, 2014 at 1:18 AM, Josh Berkus &lt;
> >
> > > josh@
> >
> > > &gt; wrote:
> > >>> While there were technical
> > >>> issues, 9.4 dragged a considerable amount because most people were
> > >>> ignoring it in favor of 9.5 development.
> > >
> > >> I think 9.4 dragged almost entirely because of one issue: the
> > >> compressibility of JSONB.
> > >
> > > 2. The amount of pre-release testing we get from people outside the
> > > hard-core development crowd seems to be continuing to decrease.
> > > We were fortunate that somebody found the JSONB issue before it was
> > > too late to do anything about it. Personally, I'm very worried that
> > > there are other such bugs in 9.4. But I've given up hoping that any
> > > more testing will happen until we put out something that calls itself
> > > 9.4.0, which is why I voted to release in the core discussion about it.
> >
> > The compressibility properties of a new type seem like something that
> should
> > be mandated before it is committed - it shouldn't require good fortune
> that
>
> Odd are the next problem will have nothing to do with compressibility
> --- we can't assume old failure will repeat themselves.
>

​tl;dr: assign two people, a manager/curator and a lead reviewer​. Give
the curator better tools and the responsibility to engage the community.
If the primary reviewer cannot review a patch in the current commitfest it
can be marked "awaiting reviewer" and moved to the next CF for evaluation
by the next pair of individuals. At minimum, though, if it does get moved
the manager AND reviewer need to comment on why it was not handled during
their CF. Also, formalize documentation targeting developers and reviewers
just like the documentation for users has been formalized and committed to
the repository. That knowledge and history is probably more important that
source code commit log and definitely should be more accessible to
newcomers.

​While true a checklist of things to look for and evaluate when adding a
new type to the system still has value. How new types interact, if at all,
with TOAST seems like something that warrants explicit attention before
commit, and there are probably others (e.g., OIDs, input/output function
volatility and configuration, etc...)​. Maybe this exists somewhere but it
you are considering improvements to the commitfest application having an
top-of-page & always-visible checklist that can bootstrapped based upon the
patch/feature type and modified for specific nuances for the item in
question seems like it would be valuable.

If this was in place before 9.3 then the whatever category the multi-xact
patches fall into would want to have their template modified to incorporate
the various research and testing - along with links to the discussions -
the resulted from the various bug reports that were submitted. It could
even be structured to both be an interactive checklist as well as acting as
curated documentation for developers and reviewers. The wiki has some of
this but if the goal is to encourage people to learn how to contribute to
PostgreSQL it should receive a similar level of attention and quality
control that our documentation for people wanting to learn how to use
PostgreSQL receive. But that is above and beyond the simple goal of having
meaningful checklists attached to each of the major commit-fest items whose
TODO items can be commented upon and serve as a reference for how close to
commit a feature may be. Comments can be as simple as a place for people
to upload a psql script and say "this is what I did and everything seemed
to work/fail in the way I expected - on this platform".

Curation is hard though so I get why easier - just provide links to the
mailing list mainly - actions are what is currently being used. Instead of
the CF manager being a reviewer (which is a valid approach) having them be
a curator and providing better tools geared toward that role (both to do
the work and to share the results) seem like a better ideal. Having that
role a CF reviewer should maybe also be assigned. The two people -
reviewer and manager - would then be responsible for ensuring that reviews
are happening and that the communication to and recruitment from the
community is being handled - respectively.

Just some off-the-cuff thoughts...

David J.