Re: 9.5 release scheduling (was Re: logical column ordering) - Mailing list pgsql-hackers
| From | David Johnston |
|---|---|
| Subject | Re: 9.5 release scheduling (was Re: logical column ordering) |
| Date | |
| Msg-id | CAKFQuwZPwBJpoOxWsAN8Zke-Ub4yQd3wTXcn3MdSYq3fZePaSQ@mail.gmail.com Whole thread Raw |
| In response to | Re: 9.5 release scheduling (was Re: logical column ordering) (Bruce Momjian <bruce@momjian.us>) |
| Responses |
Re: 9.5 release scheduling (was Re: logical column
ordering)
(Alvaro Herrera <alvherre@2ndquadrant.com>)
|
| List | pgsql-hackers |
On Thu, Dec 11, 2014 at 10:04:43AM -0700, David G Johnston wrote:
> Tom Lane-2 wrote
> > Robert Haas <
>
> > robertmhaas@
>
> > > writes:
> >> On Thu, Dec 11, 2014 at 1:18 AM, Josh Berkus <
>
> > josh@
>
> > > 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.
pgsql-hackers by date: