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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
