Re: a few thoughts on the schedule

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: a few thoughts on the schedule
Date: 2015-05-19 18:28:07
Message-ID: 555B80B7.8020008@commandprompt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 05/19/2015 10:44 AM, Andres Freund wrote:

>> I don't know what the solution is but I know I like the idea of a tree
>> freeze except for bug fixes for at least 3 weeks but I would be jumping for
>> joy if we froze the tree except for bug fixes for 6 or 12 weeks.
>
> We've done that for pretty much every release so far?
>

That isn't really my experience at least from perception and I will be
honest and I haven't followed the releases for 9.4 and 9.3 that much but
it used to be:

Branch Tree
Accept patches for new tree and closed tree (bug fixes)

What I am suggesting is that we don't accept ANY patches that are not
directly related to the closed tree that is being prepped for release.

I am not suggesting a shutdown of collaboration or discussion. I am
trying (and perhaps failing) to find a way to steer everyone in a single
direction for this release:

Our focus is the quality of 9.5, nothing else.

>
>> I don't care about 9.6 at this point.
>
> But you don't develop things for it, so you're in a very different
> position. It takes a *lot* of time to come up with a serious proposal

I would argue I develop a lot more than you consider. I have to deal
with the end result that -hackers create on a much wider scale (as do
most other consultants) than most do.

> for a new feature, and then lots more time to come up with a reasonable
> patch. To get a serious feature into 9.6 you pretty much have to already
> have started by now.

Then extend the development time. Instead of 12-15 months, let's make it
18-21 or 21-24 months or again, move to a staggered model (like Ubuntu).

>
>> We move so fast anyway, most people I know haven't even migrated to
>> 9.4.x and even more are happily plugging away on 9.2.
>
> I don't think that's really related to moving fast. It's just that
> existing systems don't necessarily need to move - after all they could
> put the system into production at their respective version. That's
> different to when you consider adopting/extending postgres for a new use
> case/product. And there people quit regularly lament a couple problems
> in postgres. Say if we, and there's been serious talk about that,
> addressed vacuuming being so painful, that'd certainly increase adoption
> in the mid term.

This is true but doesn't negate my argument, it enforces it. Most people
aren't going to be anywhere near disappointed if we slow down and focus
on quality versus innovativeness.

Note: I am not saying we don't try to release quality software, of
course we do.

JD

--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2015-05-19 18:30:51 Re: a few thoughts on the schedule
Previous Message Tom Lane 2015-05-19 18:22:43 Re: Problems with question marks in operators (JDBC, ECPG, ...)