Re: Releasing in September - Mailing list pgsql-hackers

On Wed, Jan 20, 2016 at 12:03 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> But I'm not very sure that we're talking about the same set of people
>> here.  If we're going to go to a system where nobody's allowed to
>> commit anything for the next release until the current release is
>> finalized, then we'd better have some procedure for making sure that
>> happens relatively quickly.  And the procedure can't be that the
>> people who are hot to get started on the next release have to bat
>> cleanup for the people who don't have time to fix the bugs they
>> introduced previously.  Because *that* would be manifestly unfair.
>
> You're assuming that the people who are hot to get started on the next
> release are different from the people who don't have time to fix the bugs
> they introduced previously.  IME it's mostly the same people.

The last common commit between master and REL9_5_STABLE is dated June
30th.  Here is the open items list as of that date:

https://wiki.postgresql.org/index.php?title=PostgreSQL_9.5_Open_Items&oldid=25373

The only thing on that list that I had anything to do with is "Foreign
join pushdown vs EvalPlanQual".  And that only would have mattered to
people who want to do out-of-core FDW join pushdown against 9.5 and
aren't comfortable restricting the feature to queries without
rowmarks, which is probably nobody, and "PGXS "check" target forcing
an install ?", which was a very minor issue that I didn't create but
did help fix.  Similarly, I see nothing on that list that could be
attributed to, say, you.

I hate to name names, but it seems to me that where things came off
the rails for 9.5 is that (1) the row-level security feature was
absolutely riddled with bugs and that those bugs were not fixed in
anything like timely fashion; (2) the commit timestamp stuff was
pretty badly broken, too; and (3) Andres's multixact reworks landed
quite late and IMHO were not safe enough to back-patch, yet they
needed to be in the release.  In my view, the last major fix for (1)
was in 7d8db3e8f37aec9d252353904e77381a18a2fa9f on September 30th, for
(2) was in commit 69e7235c93e2965cc0e17186bd044e4c54997c19 on December
11th, and for (3) was in aa29c1ccd9f785f9365809f5133e5491acc7ae53 on
September 26th.  I think the row-security stuff is particularly bad
because that feature was originally committed on September 19, *2014*.
It's not good when you commit a security feature and are still
redefining the way that the privilege system interacts with that
feature a year later.

Also note the dates.  We put out beta1 in the beginning of October,
right after those major fixes for (1) and (3) in late September.  And
we put out rc1 just after (2) got patched up.  There is of course a
chicken and egg problem here, because it's unclear to what degree the
commits drove the wrap date and to what degree the wrap date drove the
commits, but if we can't get fixes for those kinds of issues into the
tree on time, we are not going to release on time.  Now maybe if we
refuse to branch until we get these kinds of issues fixed, we'll fix
them sooner (or revert the patches that caused the problems in the
first place, which is another way to go).  That would be a positive
development.  But if we end up waiting just as long but with nothing
substantial getting committed in the meantime, that will be awful.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company