Обсуждение: 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

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

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

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. +

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. +

* 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

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

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. +

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

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.

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

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

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.

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.

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.

On Mon, May 18, 2015 at 7:10 PM, Andres Freund <andres@anarazel.de> wrote:
> So +1 to moving it.

+1

-- 
Peter Geoghegan

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

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.

On 2015-05-19 11:34:49 +0900, Michael Paquier wrote:
> +1 for moving it at least 1 month.

2015-06-15 also collides with pgcon, which probably isn't the best
idea. I do think we should try hard doing a triage at the start of a CF
and not many with experience in the project are going to have time
around then.

So, to where do we move it? We probably need to schedule at least the
first CF now. Just to 2015-07-15? That'd leave us enough room to
schedule the rest at pgcon.

> There are many remaining open items.

At least on https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items
there not really that many?

On Tue, May 19, 2015 at 11:41 AM, Andres Freund <andres@anarazel.de> wrote:
> On 2015-05-19 11:34:49 +0900, Michael Paquier wrote:
>> +1 for moving it at least 1 month.
>
> 2015-06-15 also collides with pgcon, which probably isn't the best
> idea. I do think we should try hard doing a triage at the start of a CF
> and not many with experience in the project are going to have time
> around then.
>
> So, to where do we move it? We probably need to schedule at least the
> first CF now. Just to 2015-07-15? That'd leave us enough room to
> schedule the rest at pgcon.

That's in line with what I got in mind.

>> There are many remaining open items.
>
> At least on https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items
> there not really that many?

On top of those items, many patches and features (I mean a lot!) have
been committed just before the feature freeze deadline. I would think
that those things should be looked at a second time by extra eyes.
--
Michael

Michael Paquier <michael.paquier@gmail.com> writes:
> On Tue, May 19, 2015 at 11:41 AM, Andres Freund <andres@anarazel.de> wrote:
>> On 2015-05-19 11:34:49 +0900, Michael Paquier wrote:
>>> There are many remaining open items.

>> At least on https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items
>> there not really that many?

> On top of those items, many patches and features (I mean a lot!) have
> been committed just before the feature freeze deadline. I would think
> that those things should be looked at a second time by extra eyes.

Yes.  We desperately need to spend time on reviewing the stuff that got
crammed in at the last minute --- I think we'd be fools to assume that
there aren't a lot of bugs there.

I think if we spend the next month reviewing what's already in, we could
ship a credible beta before PGCon.  And then maybe we could start 9.6
development on 1 July, only a couple weeks late.  But if we start focusing
on 9.6 development right now, which is what some current threads seem to
be after, 9.5 is going to be a disaster.
        regards, tom lane

On May 18, 2015, at 10:41 PM, Andres Freund <andres@anarazel.de> wrote:
>> On 2015-05-19 11:34:49 +0900, Michael Paquier wrote:
>> +1 for moving it at least 1 month.
>
> 2015-06-15 also collides with pgcon, which probably isn't the best
> idea. I do think we should try hard doing a triage at the start of a CF
> and not many with experience in the project are going to have time
> around then.
>
> So, to where do we move it? We probably need to schedule at least the
> first CF now. Just to 2015-07-15? That'd leave us enough room to
> schedule the rest at pgcon.

Honestly, that seems awful soon.  I would have thought maybe August 15th.

I am inclined to think the 5-CommitFest thing we did this time did not work out. It might've been fine if feature
freezehad been a month earlier, but by freezing in May we've pretty clearly stolen at least a month, if not two, from
thenext cycle. 

...Robert

On 2015-05-18 23:30:20 -0400, Tom Lane wrote:
> Michael Paquier <michael.paquier@gmail.com> writes:
> > On Tue, May 19, 2015 at 11:41 AM, Andres Freund <andres@anarazel.de> wrote:
> >> On 2015-05-19 11:34:49 +0900, Michael Paquier wrote:
> >>> There are many remaining open items.
> 
> >> At least on https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items
> >> there not really that many?
> 
> > On top of those items, many patches and features (I mean a lot!) have
> > been committed just before the feature freeze deadline. I would think
> > that those things should be looked at a second time by extra eyes.

Completely agreed that there's a lot of need for review and testing. I
just wondered because of the reference to the open item list whether you
were potentially thinking about something else.

> I think if we spend the next month reviewing what's already in, we could
> ship a credible beta before PGCon.  And then maybe we could start 9.6
> development on 1 July, only a couple weeks late.

1st of July doesn't seem to leave much room to me. Even if we ship Beta1
before pgcon, the work doesn't stop there. At least I hope so, because
if it does it will mean that nobody is testing beta 1.

> But if we start focusing
> on 9.6 development right now, which is what some current threads seem to
> be after, 9.5 is going to be a disaster.

FWIW, I personally don't intend to start actual significant new
development till early/mid June. I think I, and probably some others,
will have to have a couple design discussions until then though. For one
it'll be hard to discuss things effectively at pgcon without that.

Greetings,

Andres Freund

On 2015-05-18 23:34:16 -0400, Robert Haas wrote:
> On May 18, 2015, at 10:41 PM, Andres Freund <andres@anarazel.de> wrote:

> > [first 9.6 CF around 2015-07-15]

> Honestly, that seems awful soon.  I would have thought maybe August 15th.

Maybe we should just rename it to 9.6-1 for now? And then look how
things look around pgcon?

> I am inclined to think the 5-CommitFest thing we did this time did not
> work out. It might've been fine if feature freeze had been a month
> earlier, but by freezing in May we've pretty clearly stolen at least a
> month, if not two, from the next cycle.

I personally think the late close of the 9.4 cycle has alone thrings far
enough off track that we can't fairly evaluate a 5 CF schedule.



Personally I'm coming more and more to the conclusion that CFs just
don't work [anymore]. I think the *tracking* itself is rather important
and has a worthwhile role. But it seems to me that what CFs have lately
essentially ended up being, is closer to a cycle long review queue than
anything else.

ISTM that the CF scheduling right now does more harm than good.
* They seem to frustrate a lot of the people doing a lot of reviews.
* Evidently they don't very well prevent individual patches from just slipping through and through.
* They lead to completely uninteresting patches being reviewed before
others.
* The contribution experience is still pretty painful and takes ages

Maybe we should forget them and just have monthly 'judgefests' where
some poor sod summarizes the current state and direction, and we then
collaboratively discuss whether we see things going anywhere and if not,
what would need to happen that they do.  And have a policy that "older"
patches should be preferred over newer ones; but at the same time cull
patches continually sitting at the tail end as 'not interesting'.

On Mon, May 18, 2015 at 11:52 PM, Andres Freund <andres@anarazel.de> wrote:
>> > [first 9.6 CF around 2015-07-15]
>
>> Honestly, that seems awful soon.  I would have thought maybe August 15th.
>
> Maybe we should just rename it to 9.6-1 for now? And then look how
> things look around pgcon?

I'd rather agree on a date.  People need to plan their schedules.

>> I am inclined to think the 5-CommitFest thing we did this time did not
>> work out. It might've been fine if feature freeze had been a month
>> earlier, but by freezing in May we've pretty clearly stolen at least a
>> month, if not two, from the next cycle.
>
> I personally think the late close of the 9.4 cycle has alone thrings far
> enough off track that we can't fairly evaluate a 5 CF schedule.

Oh, I agree with that.  I'm certainly not saying we shouldn't do it
again.  But I don't see a practical way to do 5 CFs again for 9.6 and
also release it in September of 2016.  I don't think it would be a
good idea to open the tree for 9.6 development in three weeks, or even
in time for a July 1st CommitFest.  The vary earliest time frame that
would make sense to me is to branch July 1st and start a CF on July
15th.  If we schedule four more CommitFests after that at two month
intervals, they would start on September 15th, November 15th, January
15th, and March 15th, putting us a month behind where we were this
time.  That's not going to work.

So I think the options are:

- Do 4 CommitFests as we have for past releases.  We could do July
15th, September 15th, November 15th, and January 15th; or we could do
August 1st, October 1st, December 1st, and February 1st; or we could
do August 15th, October 15th, December 15th, and February 15th.
Probably, that last one isn't so good: starting on December 15th is
going to suck.

- Do 5 or more CommitFests and accept that the release cycle is going
to be more than a year.  Personally, given where we're at right now, I
don't think an early fall release of 9.5 is going to be remotely
practical.  I think we're going to end up releasing in late fall or
early in the new year.  So I'd be completely fine with a schedule that
aims for 9.6 to get released around March-May of 2017, so the last
CommitFest would start in August or September of 2016.  I expect that
to be unpopular, which is fine, but then I think we have to limit
ourselves to 4 CFs this time through.

> Personally I'm coming more and more to the conclusion that CFs just
> don't work [anymore]. I think the *tracking* itself is rather important
> and has a worthwhile role. But it seems to me that what CFs have lately
> essentially ended up being, is closer to a cycle long review queue than
> anything else.

I mostly agree with that.

> ISTM that the CF scheduling right now does more harm than good.
> * They seem to frustrate a lot of the people doing a lot of
>   reviews.
> * Evidently they don't very well prevent individual patches from
>   just slipping through and through.
> * They lead to completely uninteresting patches being reviewed before
> others.
> * The contribution experience is still pretty painful and takes ages

Those are legitimate issues.

> Maybe we should forget them and just have monthly 'judgefests' where
> some poor sod summarizes the current state and direction, and we then
> collaboratively discuss whether we see things going anywhere and if not,
> what would need to happen that they do.  And have a policy that "older"
> patches should be preferred over newer ones; but at the same time cull
> patches continually sitting at the tail end as 'not interesting'.

I think we need to start by understanding that we need the
contribution experience to be good for both patch authors and also for
reviewers (including reviewers who are commiters).   We very much need
to give new contributors a good experience of submitting patches and
getting useful feedback and getting stuff committed.  I think it's
clear that we could do a much better job at that, and the project
would benefit enormously.  However, doing a better job means spending
more time on it, and we can't just demand that senior reviewers or
contributors spend more time on it.  I mean, we can, I guess, but it
will only breed frustration and resentment.  I'm not sure what the
solution is here, but if it boils down to telling people who have put
a lot of effort into the project over a long period of time that they
are not doing enough, I'm here to say that won't work.

So one problem that comes up in the context of your proposal is that
it's likely to be hard to find the "poor sod" whose existence you
hypothecate.  Maybe there is someone who will do that once or twice,
but I think it'll be hard to keep that position filled over the long
term.

Unfortunately, I don't have a lot of good ideas here.  I know that I
spend as much time reviewing other people's patches as I can manage to
find in my schedule, and I know a lot of people would probably like to
see me do more of that.  I'm sure there are also some people who would
like to see me do less of that, and at least a few who would like to
see me die in a fire.  Ultimately, this is about money.  I have a job
where I can devote some time to reviewing other people's patches,
which is great: many people aren't that lucky.  Nobody has offered me
a job where I can spend a higher percentage of my time doing that than
I spend now.  Unless talented reviewers can get such job offers, we
are going to continue to have trouble making ends meet.

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

On 05/18/2015 08:52 PM, Andres Freund wrote:

> Maybe we should forget them and just have monthly 'judgefests' where
> some poor sod summarizes the current state and direction, and we then
> collaboratively discuss whether we see things going anywhere and if not,
> what would need to happen that they do.  And have a policy that "older"
> patches should be preferred over newer ones; but at the same time cull
> patches continually sitting at the tail end as 'not interesting'.
>

I don't think this will be a productive solution. I would argue that any 
solution we come up with, somebody is going to think they got the short 
end of the stick. There will be someone that thinks it is inefficient, 
that it doesn't suit their needs or that it doesn't work in their 
paradigm. That is why we don't have a proper issue/bug tracker. That is 
why we are constantly "inventing here" instead of relying on the work of 
others (when it comes to this particular problem).

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.

I don't care about 9.6 at this point. 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.

Consider that yes, we have a ton of people that migrated to 9.4 but 
those generally aren't people running the 24x7 enterprise class database.

It will not hurt us, and will only help us to slow down for this 
release. If 9.6 gets pushed until Winter 2017, so what.

Let's release Alpha1, start promoting the heck out of it amongst the 
community and early adopting (for NON PRODUCTION) developers. Let's make 
it easy as snot dripping from a toddlers nose to submit bug reports. 
Let's verify those things and let's produce the most solid, reliable and 
bug free PostgreSQL version, ever.

The summer is nigh and it is going to be slow going anyway.


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.

On 2015-05-19 10:25:49 -0400, Robert Haas wrote:
> On Mon, May 18, 2015 at 11:52 PM, Andres Freund <andres@anarazel.de> wrote:
> > I personally think the late close of the 9.4 cycle has alone thrings far
> > enough off track that we can't fairly evaluate a 5 CF schedule.
> 
> Oh, I agree with that.

Ah, ok.

> The vary earliest time frame that would make sense to me is to branch
> July 1st and start a CF on July 15th.

I'm wondering why the CF has to start after branching? Or is that just
two independent dates? The first week or so of the first CF won't have
much stuff ready for commit.

> Personally, given where we're at right now, I don't think an early
> fall release of 9.5 is going to be remotely practical.

Why? To me the last few beta periods were pretty drawn out affairs,
without much happening. Yes, there was the jsonb stuff in 9.4 delaying
the release, but that wasn't waiting for work, but a decision.  But most
of the time everyone was developing their stuff for the next cycle,
waiting for beta testers to come forward with bugs. Not very much of
that happened.

I think a shorter schedule might actually help us to both, get the open
issues closed sooner, and get more actual testing. Most people seem to
work with a "Oh, there's time left, I can do that later" attitude.

I mean if there'd actually be lots of people busy testing, sure, a long
beta makes sense for postgres (complex, contains critical data). But I
don't think that's happening.

> - Do 4 CommitFests as we have for past releases.  We could do July
> 15th, September 15th, November 15th, and January 15th; or we could do
> August 1st, October 1st, December 1st, and February 1st; or we could
> do August 15th, October 15th, December 15th, and February 15th.
> Probably, that last one isn't so good: starting on December 15th is
> going to suck.

I tend to agree that Dec 15 is a bad idea.

> > Maybe we should forget them and just have monthly 'judgefests' where
> > some poor sod summarizes the current state and direction, and we then
> > collaboratively discuss whether we see things going anywhere and if not,
> > what would need to happen that they do.  And have a policy that "older"
> > patches should be preferred over newer ones; but at the same time cull
> > patches continually sitting at the tail end as 'not interesting'.
> 
> I think we need to start by understanding that we need the
> contribution experience to be good for both patch authors and also for
> reviewers (including reviewers who are commiters).   We very much need
> to give new contributors a good experience of submitting patches and
> getting useful feedback and getting stuff committed.  I think it's
> clear that we could do a much better job at that, and the project
> would benefit enormously.

Agreed.  I think right now to succeed in the project you need to be
extraordinarily stubborn or patient. Which in turn comes with its own
set of problems in the long term, besides lower participation. The set
of qualities needed to succeed aren't the same that I see needed in the
project.

> However, doing a better job means spending more time on it, and we
> can't just demand that senior reviewers or contributors spend more
> time on it.  I mean, we can, I guess, but it will only breed
> frustration and resentment.  I'm not sure what the solution is here,
> but if it boils down to telling people who have put a lot of effort
> into the project over a long period of time that they are not doing
> enough, I'm here to say that won't work.

Agreed, that we can't just demand it. But I think without changing
anything the situation will just get worse and worse, because there'll
be few new senior people.

I think part of that is saying "no" more efficiently, upfront. Which is
why I really want the triage step.
a) It's much better for the project to not have several "junior" reviewers  first spend time on a patch, then have a
smallflamefest, and then  have somebody "senior" reject a patch in its entirety. That's a waste  of everyone's effort
andfrustrating.
 
b) It's not that bad to hear a "no" as a new contributor soon after  submission. It's something entirely different to
gothrough a long  bikeshedding, several revisions of reworking, just to be told in the  end that it was a bad idea from
theget go.
 

> So one problem that comes up in the context of your proposal is that
> it's likely to be hard to find the "poor sod" whose existence you
> hypothecate.  Maybe there is someone who will do that once or twice,
> but I think it'll be hard to keep that position filled over the long
> term.

I'm not sure. ISTM that a painfull couple hours every now and then are
much less bad than the continuous CF we had lately. I personally also
find it frustrating to go through the CF and see a good portion of
things that I never can see going anywhere, but that still suck up
resources.

I'd actually be willing to do triage every now and then; but I don't
think it should always be the same person. For one it does come with
power, for another it's nice to now always be the person having to tell
people that their stuff isn't relevant/good/whatever enough. It's also
not good to needlessly build up SPOFs.

> Unless talented reviewers can get such job offers, we are going to
> continue to have trouble making ends meet.

Hasn't every talented reviewer gotten job offers shortly afterwards in
the last few years?  The ones that accept don't necessarily work that
much in the community, but several seem to. And I think in the case of
several people the reason they don't, is less the company, but that it's
emotionally draining.

Greetings,

Andres Freund

On 2015-05-19 09:43:54 -0700, Joshua D. Drake wrote:
> 
> On 05/18/2015 08:52 PM, Andres Freund wrote:
> 
> >Maybe we should forget them and just have monthly 'judgefests' where
> >some poor sod summarizes the current state and direction, and we then
> >collaboratively discuss whether we see things going anywhere and if not,
> >what would need to happen that they do.  And have a policy that "older"
> >patches should be preferred over newer ones; but at the same time cull
> >patches continually sitting at the tail end as 'not interesting'.
> >
> 
> I don't think this will be a productive solution. I would argue that any
> solution we come up with, somebody is going to think they got the short end
> of the stick. There will be someone that thinks it is inefficient, that it
> doesn't suit their needs or that it doesn't work in their paradigm. That is
> why we don't have a proper issue/bug tracker. That is why we are constantly
> "inventing here" instead of relying on the work of others (when it comes to
> this particular problem).

What does that have to do with the suggestion above? That seems entirely
unrelated to changing CFs to a different format.

> 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?


> 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
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.

> 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.

Greetings,

Andres Freund

On Tue, May 19, 2015 at 10:35 AM, Andres Freund <andres@anarazel.de> wrote:
> I'm not sure. ISTM that a painfull couple hours every now and then are
> much less bad than the continuous CF we had lately. I personally also
> find it frustrating to go through the CF and see a good portion of
> things that I never can see going anywhere, but that still suck up
> resources.
>
> I'd actually be willing to do triage every now and then; but I don't
> think it should always be the same person. For one it does come with
> power, for another it's nice to now always be the person having to tell
> people that their stuff isn't relevant/good/whatever enough. It's also
> not good to needlessly build up SPOFs.

It's pretty hard to tell someone that they're working on something
that doesn't matter to us. That's why it happens comparatively rarely.
If I told some new contributor that their patch was not worth our
time, I'd fully expect some other experienced hacker to show up 5
minutes later and tell me I'm wrong, unless perhaps the idea was
shockingly bad, which is rare.

>> Unless talented reviewers can get such job offers, we are going to
>> continue to have trouble making ends meet.
>
> Hasn't every talented reviewer gotten job offers shortly afterwards in
> the last few years?  The ones that accept don't necessarily work that
> much in the community, but several seem to. And I think in the case of
> several people the reason they don't, is less the company, but that it's
> emotionally draining.

I think that's very true, and often unacknowledged. Reviewing other
people's work can be very difficult. I do not enjoy conflict with
other people on this mailing list one bit, and that's getting harder
to deal with on a personal level over time, not easier.

-- 
Peter Geoghegan

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.

On 05/19/2015 11:02 AM, Peter Geoghegan wrote:

>> Hasn't every talented reviewer gotten job offers shortly afterwards in
>> the last few years?  The ones that accept don't necessarily work that
>> much in the community, but several seem to. And I think in the case of
>> several people the reason they don't, is less the company, but that it's
>> emotionally draining.
>
> I think that's very true, and often unacknowledged. Reviewing other
> people's work can be very difficult. I do not enjoy conflict with
> other people on this mailing list one bit, and that's getting harder
> to deal with on a personal level over time, not easier.

Although I certainly understand your sentiment. It isn't personal. It is 
professional. If people are taking personally (and I certainly have), 
they need to step the heck back, take a breath and ask themselves what 
their problem is.

If they won't, then someone in the community needs to step up and help 
them do that. The more we remove the ID, the more productive we will become.

Sincerely,


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.

On Tue, May 19, 2015 at 1:35 PM, Andres Freund <andres@anarazel.de> wrote:
>> The vary earliest time frame that would make sense to me is to branch
>> July 1st and start a CF on July 15th.
>
> I'm wondering why the CF has to start after branching? Or is that just
> two independent dates? The first week or so of the first CF won't have
> much stuff ready for commit.

Well, if there is something ready to commit, I'd like to be able to commit it.

>> Personally, given where we're at right now, I don't think an early
>> fall release of 9.5 is going to be remotely practical.
>
> Why? To me the last few beta periods were pretty drawn out affairs,
> without much happening. Yes, there was the jsonb stuff in 9.4 delaying
> the release, but that wasn't waiting for work, but a decision.  But most
> of the time everyone was developing their stuff for the next cycle,
> waiting for beta testers to come forward with bugs. Not very much of
> that happened.
>
> I think a shorter schedule might actually help us to both, get the open
> issues closed sooner, and get more actual testing. Most people seem to
> work with a "Oh, there's time left, I can do that later" attitude.

There's something to that theory.  I'm just worried all of those last
minute commits are hiding a bunch of bugs.

> I think part of that is saying "no" more efficiently, upfront. Which is
> why I really want the triage step.
> a) It's much better for the project to not have several "junior" reviewers
>    first spend time on a patch, then have a small flamefest, and then
>    have somebody "senior" reject a patch in its entirety. That's a waste
>    of everyone's effort and frustrating.
> b) It's not that bad to hear a "no" as a new contributor soon after
>    submission. It's something entirely different to go through a long
>    bikeshedding, several revisions of reworking, just to be told in the
>    end that it was a bad idea from the get go.

I agree this would help.  Figuring out how to do it in a reasonable
way would help a lot.  If we could get say 4 committers to go through
at the start of each CommitFest and each comment very briefly on 25%
of the patches each (yes, no, or maybe, and a bit of justification), I
bet that would streamline things considerably.  If we could get each
committer to go through 50% of the patches and do this, then each
patch would get a quick opinion from two committers right at the
outset.  That would be even nicer.

>> Unless talented reviewers can get such job offers, we are going to
>> continue to have trouble making ends meet.
>
> Hasn't every talented reviewer gotten job offers shortly afterwards in
> the last few years?  The ones that accept don't necessarily work that
> much in the community, but several seem to. And I think in the case of
> several people the reason they don't, is less the company, but that it's
> emotionally draining.

Agreed, lots of people get job offers.  But somehow we're still short
of reviewers, so something's not working the way it needs to.  Maybe
that's for the reason you postulate, or maybe it's for the reason I
postulate, or maybe there is some other reason.

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

On Tue, May 19, 2015 at 04:55:11PM -0400, Robert Haas wrote:
> On Tue, May 19, 2015 at 1:35 PM, Andres Freund <andres@anarazel.de> wrote:
> > I think part of that is saying "no" more efficiently, upfront. Which is
> > why I really want the triage step.
> > a) It's much better for the project to not have several "junior" reviewers
> >    first spend time on a patch, then have a small flamefest, and then
> >    have somebody "senior" reject a patch in its entirety. That's a waste
> >    of everyone's effort and frustrating.
> > b) It's not that bad to hear a "no" as a new contributor soon after
> >    submission. It's something entirely different to go through a long
> >    bikeshedding, several revisions of reworking, just to be told in the
> >    end that it was a bad idea from the get go.
> 
> I agree this would help.  Figuring out how to do it in a reasonable
> way would help a lot.  If we could get say 4 committers to go through
> at the start of each CommitFest and each comment very briefly on 25%
> of the patches each (yes, no, or maybe, and a bit of justification), I
> bet that would streamline things considerably.  If we could get each
> committer to go through 50% of the patches and do this, then each
> patch would get a quick opinion from two committers right at the
> outset.  That would be even nicer.

Brief committer appraisals are unhelpful individually, but patterns matter.  I
would make the questionnaire as simple as necessary to get 4-7 committer
evaluations per patch.  Prefer 30-second analyses from each of five
committers, not 30-minute analyses from two.  Starting point:

Q: How much effort would it take to write, from scratch, a committable patch for this feature?
A: Small | Medium | Large

Q: Relative to the that effort level, how valuable is this feature once committed?
A: Negative | Low | Medium | High

Q: How suitable is the chosen design?
A: Wrong | Inconclusive | Right

That should suffice to highlight doomed patches.  With great submission notes,
one can answer all three questions without opening the diff itself.  Each
appraiser could cover every patch of a CommitFest in an hour or two.

On Wed, May 20, 2015 at 09:15:14AM -0400, Simon Riggs wrote:
> On 20 May 2015 at 03:13, Noah Misch <noah@leadboat.com> wrote:
> > Brief committer appraisals are unhelpful individually, but patterns
> > matter.  I
> > would make the questionnaire as simple as necessary to get 4-7 committer
> > evaluations per patch.  Prefer 30-second analyses from each of five
> > committers, not 30-minute analyses from two.

> I'm happy to participate as a "triager" and will follow whatever process we
> decide.
> 
> I would very much like to make this something we do via the CF app.

Good place for it.

> I believe we should include in our thinking how we nurture and grow
> reviewers, contributors and committers. I am more likely to treat a
> low-value patch seriously if it is an early contribution from someone, for
> example.

Absolutely, though I am unsure how to specifically account for that in
community processes.

On Tue, May 19, 2015 at 10:25:49AM -0400, Robert Haas wrote:
> Unfortunately, I don't have a lot of good ideas here.  I know that I
> spend as much time reviewing other people's patches as I can manage to
> find in my schedule, and I know a lot of people would probably like to
> see me do more of that.  I'm sure there are also some people who would
> like to see me do less of that, and at least a few who would like to
> see me die in a fire.  Ultimately, this is about money.  I have a job
> where I can devote some time to reviewing other people's patches,
> which is great: many people aren't that lucky.  Nobody has offered me
> a job where I can spend a higher percentage of my time doing that than
> I spend now.  Unless talented reviewers can get such job offers, we
> are going to continue to have trouble making ends meet.

I think this comes down to how many companies care about the health of
the community vs. how many care about getting their specific patches
committed.  In some sense this is the free rider problem:
http://en.wikipedia.org/wiki/Free_rider_problem

Historically employees who are Postgres community members have been good
at telling employers that they cannot be free riders, but there has been
some diminishment of that as Postgres has figured more prominently in
company success.  However, I have also heard that there is increased
concern among employers that the free rider problem is causing
structural problems in the community, which might lend support to free
rider-resisting employees.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +