a few thoughts on the schedule
Hi,
It's pretty clear that the impending feature freeze proposed by core
has spurred a lot of activity. This is both good and bad. On the
good side, we're getting a bunch of stuff done. On the bad side,
there is inevitably going to be a temptation to rush things in that
are really not quite fully-baked just yet. If we fail to resist that
temptation, we WILL pay the consequences. Those consequences may
include overt bugs (as per the recent discussion on what went wrong
with multi-xacts) or bad design decisions from which we will not
easily be able to disentangle ourselves.
I am already concerned about some of the commits that have gone in
very recently, particularly these:
- Map basebackup tablespaces using a tablespace_map file - Discussion
on pgsql-committers suggests that this may have some scary problems.
Maybe I just don't understand the situation.
- Allow on-the-fly capture of DDL event details - This looks really
half-baked to me. At the least, the documentation expresses an
optimism about what can be done with a pg_ddl_command that isn't
realized by the code.
- Code review for foreign/custom join pushdown patch - Whacks around
my earlier commit without agreement or adequate discussion, apparently
on the theory that Tom always knows best.
- Add support for INSERT ... ON CONFLICT DO NOTHING/UPDATE - Huge
feature introducing novel infrastructure.
We also need to start thinking about what happens after feature
freeze. The CommitFest application currently lists a 2015-06
CommitFest which, according to previous practice, would be expected to
start on the 15th of the month. Given where we are now, that seems
entirely unrealistic. I am doubtful that we will be ready to ship a
beta by mid-June, let alone begin a new development cycle.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
It's pretty clear that the impending feature freeze proposed by core
has spurred a lot of activity. This is both good and bad. On the
good side, we're getting a bunch of stuff done. On the bad side,
there is inevitably going to be a temptation to rush things in that
are really not quite fully-baked just yet. If we fail to resist that
temptation, we WILL pay the consequences.
Yeah. At this point I think it's clear that only a minority of the
remaining commitfest items can get into 9.5; we're going to have to
punt many of them to next time. I'll post some thoughts about specific
patches separately, but let's keep this thread for discussion of the
overall situation.
I am already concerned about some of the commits that have gone in
very recently, particularly these:
There is going to need to be a mop-up period, and we ought to be willing
to revert anything we feel wasn't really ready. I don't feel that those
decisions need to be made in a hurry though. I'm envisioning taking about
a month to look more closely at committed patches and see what needs to be
cleaned up or undone altogether.
- Code review for foreign/custom join pushdown patch - Whacks around
my earlier commit without agreement or adequate discussion, apparently
on the theory that Tom always knows best.
As far as that goes, obviously I've got strong opinions on what the FDW
APIs ought to look like, and I'm happy to discuss this issue further ---
but I think that's a topic for the mop-up period, not for this week.
What I think we need to be doing this week is triage. Commit what's
ready, punt what's not. I'll post a separate list about that.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 13, 2015 at 11:09 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
- Code review for foreign/custom join pushdown patch - Whacks around
my earlier commit without agreement or adequate discussion, apparently
on the theory that Tom always knows best.As far as that goes, obviously I've got strong opinions on what the FDW
APIs ought to look like, and I'm happy to discuss this issue further ---
but I think that's a topic for the mop-up period, not for this week.What I think we need to be doing this week is triage. Commit what's
ready, punt what's not. I'll post a separate list about that.
That sounds like a fine plan. Thanks for responding.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 13, 2015 at 10:32:03AM -0400, Robert Haas wrote:
We also need to start thinking about what happens after feature
freeze. The CommitFest application currently lists a 2015-06
CommitFest which, according to previous practice, would be expected to
start on the 15th of the month. Given where we are now, that seems
entirely unrealistic. I am doubtful that we will be ready to ship a
beta by mid-June, let alone begin a new development cycle.
This is a very good analysis. I have been holding back my trivial new
patches for 9.6 in hopes of setting a good example. However, all my
stuff is new, while many of these other patches have waited their turn
for review, and we are going to be unfair to submitters if we don't give
them the attention they deserve --- that is always the tension we have
at this time.
We have three days left so I think we need committers to devote serious
time, if possible, to helping us resolve as much as we can. If we start
thinking about this on Friday, it is too late.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 13, 2015 at 11:19:29AM -0400, Bruce Momjian wrote:
On Wed, May 13, 2015 at 10:32:03AM -0400, Robert Haas wrote:
We also need to start thinking about what happens after feature
freeze. The CommitFest application currently lists a 2015-06
CommitFest which, according to previous practice, would be expected to
start on the 15th of the month. Given where we are now, that seems
entirely unrealistic. I am doubtful that we will be ready to ship a
beta by mid-June, let alone begin a new development cycle.This is a very good analysis. I have been holding back my trivial new
patches for 9.6 in hopes of setting a good example. However, all my
stuff is new, while many of these other patches have waited their turn
for review, and we are going to be unfair to submitters if we don't give
them the attention they deserve --- that is always the tension we have
at this time.We have three days left so I think we need committers to devote serious
time, if possible, to helping us resolve as much as we can. If we start
thinking about this on Friday, it is too late.
Let me put a finer point on this --- whatever gets pushed to 9.6
unreasonably will be a feature we don't have in 9.5 and will discourage
future development. I know we can't do magic, but now is the time to
try.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
* Bruce Momjian (bruce@momjian.us) wrote:
On Wed, May 13, 2015 at 11:19:29AM -0400, Bruce Momjian wrote:
On Wed, May 13, 2015 at 10:32:03AM -0400, Robert Haas wrote:
We also need to start thinking about what happens after feature
freeze. The CommitFest application currently lists a 2015-06
CommitFest which, according to previous practice, would be expected to
start on the 15th of the month. Given where we are now, that seems
entirely unrealistic. I am doubtful that we will be ready to ship a
beta by mid-June, let alone begin a new development cycle.This is a very good analysis. I have been holding back my trivial new
patches for 9.6 in hopes of setting a good example. However, all my
stuff is new, while many of these other patches have waited their turn
for review, and we are going to be unfair to submitters if we don't give
them the attention they deserve --- that is always the tension we have
at this time.We have three days left so I think we need committers to devote serious
time, if possible, to helping us resolve as much as we can. If we start
thinking about this on Friday, it is too late.Let me put a finer point on this --- whatever gets pushed to 9.6
unreasonably will be a feature we don't have in 9.5 and will discourage
future development. I know we can't do magic, but now is the time to
try.
I certainly agree with this and have been putting a fair bit of effort
into it over the past week. :/
More help would absolutely be appreciated.
Thanks!
Stephen
On Wed, May 13, 2015 at 11:40 AM, Bruce Momjian <bruce@momjian.us> wrote:
We have three days left so I think we need committers to devote serious
time, if possible, to helping us resolve as much as we can. If we start
thinking about this on Friday, it is too late.Let me put a finer point on this --- whatever gets pushed to 9.6
unreasonably will be a feature we don't have in 9.5 and will discourage
future development. I know we can't do magic, but now is the time to
try.
And on the flip side, whatever is pushed to 9.6 will not create a
stability issue in 9.5.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
Let me put a finer point on this --- whatever gets pushed to 9.6
unreasonably will be a feature we don't have in 9.5 and will discourage
future development. I know we can't do magic, but now is the time to
try.
The other side of that coin is that the stuff that ends up getting pushed
will, in many cases, be stuff that nobody cared a whole lot about.
One thing that continues to bother me about the commitfest process is that
it's created a default expectation that things get committed eventually.
But many new ideas are just plain bad, and others are things that nobody
but the author cares about. We need to remember that every new feature
we add creates an ongoing maintenance burden, and might foreclose better
ideas later. I'd like to see a higher threshold for accepting feature
patches than we seem to have applied of late.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 13, 2015 at 11:52:40AM -0400, Tom Lane wrote:
Bruce Momjian <bruce@momjian.us> writes:
Let me put a finer point on this --- whatever gets pushed to 9.6
unreasonably will be a feature we don't have in 9.5 and will discourage
future development. I know we can't do magic, but now is the time to
try.The other side of that coin is that the stuff that ends up getting pushed
will, in many cases, be stuff that nobody cared a whole lot about.One thing that continues to bother me about the commitfest process is that
it's created a default expectation that things get committed eventually.
But many new ideas are just plain bad, and others are things that nobody
but the author cares about. We need to remember that every new feature
we add creates an ongoing maintenance burden, and might foreclose better
ideas later. I'd like to see a higher threshold for accepting feature
patches than we seem to have applied of late.
Agreed. If the idea is good someone else will pick it up.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2015-05-13 11:49:45 -0400, Robert Haas wrote:
On Wed, May 13, 2015 at 11:40 AM, Bruce Momjian <bruce@momjian.us> wrote:
Let me put a finer point on this --- whatever gets pushed to 9.6
unreasonably will be a feature we don't have in 9.5 and will discourage
future development. I know we can't do magic, but now is the time to
try.And on the flip side, whatever is pushed to 9.6 will not create a
stability issue in 9.5.
I'm not sure it's that simple. For one I think patches don't age that
well. Often enough patches don't really get significantly more review
when they're delayed, and at the same time the understanding of the
innards reduces again. But more importantly not integrating things that
are either ready or nearly ready and that have been waiting for a long
while, might be better for stability short term. But I think in the
mid/long term it creates a lack of reviewers, contributors and
eventually committers.
Obviously that's *not* meant as a call to just commit everything
pending.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 05/13/2015 08:09 AM, Tom Lane wrote:
What I think we need to be doing this week is triage. Commit what's
ready, punt what's not. I'll post a separate list about that.regards, tom lane
+1
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
On 2015-05-13 11:52:40 -0400, Tom Lane wrote:
One thing that continues to bother me about the commitfest process is that
it's created a default expectation that things get committed eventually.
But many new ideas are just plain bad, and others are things that nobody
but the author cares about. We need to remember that every new feature
we add creates an ongoing maintenance burden, and might foreclose better
ideas later. I'd like to see a higher threshold for accepting feature
patches than we seem to have applied of late.
Agreed that this is a problem. I think we need to work on giving that
feedback rather sooner than later. It's one thing to be given a -1 a
week or two after a patch gets proposed, another being given it 10
revisions and half a year later.
How about we really try to triage the patches a) before the CF starts,
b) half into the CF?
I guess we'd have to somebody making a summary of each patch, and their
own opinion. Then that list can be discussed. I don't really like that,
because it involves a fair amount of work and has a good bit of
potential for personal preferences to creep in. But I don't have a
better idea.
If necessary I'll do that for the first CF.
Greetings,
Andres Freund
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
On 2015-05-13 11:52:40 -0400, Tom Lane wrote:
One thing that continues to bother me about the commitfest process is that
it's created a default expectation that things get committed eventually.
Agreed that this is a problem. I think we need to work on giving that
feedback rather sooner than later. It's one thing to be given a -1 a
week or two after a patch gets proposed, another being given it 10
revisions and half a year later.
How about we really try to triage the patches a) before the CF starts,
b) half into the CF?
We keep talking about doing something like that (I remember it's come up
several times in the annual developer meetings), and then not actually
doing it. But I agree it seems like a good idea.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 05/13/2015 09:27 AM, Tom Lane wrote:
Andres Freund <andres@anarazel.de> writes:
On 2015-05-13 11:52:40 -0400, Tom Lane wrote:
One thing that continues to bother me about the commitfest process is that
it's created a default expectation that things get committed eventually.Agreed that this is a problem. I think we need to work on giving that
feedback rather sooner than later. It's one thing to be given a -1 a
week or two after a patch gets proposed, another being given it 10
revisions and half a year later.How about we really try to triage the patches a) before the CF starts,
b) half into the CF?We keep talking about doing something like that (I remember it's come up
several times in the annual developer meetings), and then not actually
doing it. But I agree it seems like a good idea.
What if:
* Commitfest starts at branch.
* Accept new patches for 9.6 until X date
* At X date, tree is closed and patch review begins
* Patch review continues until all patches are committed, kicked or Y
date is met.
* At Y date, we go to Alpha
* At Z date, we go to Beta
Well crap, I ran out of sequence letters but you get the idea. In short,
no more ethereal "We kind of do this on this date sort of". Stick to it,
it may suck sometimes but it is really the only reasonable way to do it
anymore.
JD
regards, tom lane
--
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
On Wed, May 13, 2015 at 8:39 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
I am already concerned about some of the commits that have gone in
very recently, particularly these:There is going to need to be a mop-up period, and we ought to be willing
to revert anything we feel wasn't really ready. I don't feel that those
decisions need to be made in a hurry though. I'm envisioning taking about
a month to look more closely at committed patches and see what needs to be
cleaned up or undone altogether.
I think doing post-commit review is really a good thing especially for
the patches which have more impact. One way to achieve could be
that we can identify all the patches that can have high impact (at least
feature patches, it shouldn't be difficult to identify such patches) and
some of the senior members like you can review them thoroughly after
the feature freeze (at end of development cycle), ofcourse it is better
if that can be done during development, but it seems that doesn't happen
many of the times. So if we add a phase after feature freeze and before
first release of the version, that can avoid some serious problems that
the project faces during beta or post release.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
On Wed, May 13, 2015 at 10:32:03AM -0400, Robert Haas wrote:
We also need to start thinking about what happens after feature
freeze. The CommitFest application currently lists a 2015-06
CommitFest which, according to previous practice, would be expected to
start on the 15th of the month. Given where we are now, that seems
entirely unrealistic. I am doubtful that we will be ready to ship a
beta by mid-June, let alone begin a new development cycle.
+1 for not starting a CommitFest on 2015-06-15. If we're going to take 9.5
from feature freeze to general availability in four months, we won't get there
by diving into 9.6 development in the first of those months.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2015-05-18 22:05:47 -0400, Noah Misch wrote:
+1 for not starting a CommitFest on 2015-06-15. If we're going to take 9.5
from feature freeze to general availability in four months, we won't get there
by diving into 9.6 development in the first of those months.
We could rechristen it a 'reviewfest', which is only targeted at
external reviewers. But given the low turnout of those lately, I doubt
it's worthwhile. It's probably also frustrating if there's no actual
commit progress.
So +1 to moving it.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, May 18, 2015 at 7:10 PM, Andres Freund <andres@anarazel.de> wrote:
So +1 to moving it.
+1
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, May 19, 2015 at 11:10 AM, Andres Freund <andres@anarazel.de> wrote:
On 2015-05-18 22:05:47 -0400, Noah Misch wrote:
+1 for not starting a CommitFest on 2015-06-15. If we're going to take 9.5
from feature freeze to general availability in four months, we won't get there
by diving into 9.6 development in the first of those months.We could rechristen it a 'reviewfest', which is only targeted at
external reviewers. But given the low turnout of those lately, I doubt
it's worthwhile. It's probably also frustrating if there's no actual
commit progress.So +1 to moving it.
+1 for moving it at least 1 month. There are many remaining open items.
--
Michael--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 05/18/2015 07:21 PM, Peter Geoghegan wrote:
On Mon, May 18, 2015 at 7:10 PM, Andres Freund <andres@anarazel.de> wrote:
So +1 to moving it.
+1
I for one would love to see a nice and solid focus on what we have now
for a little while versus diverting resources yet again to new development.
+1
--
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
