Thread: 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 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
>
> 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.
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 18 May 2015 at 23:34, Robert Haas <robertmhaas@gmail.com> wrote:
+1 to 2015-07-15 and then the same schedule as this release. Constant fine tuning the dates doesn't really help, it just creates the impression that discussion might make the dates flexible which works against us, even though I might otherwise agree with them.
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.
We have this discussion every year, but I would like to skip that.
That allows us to release in Sept, without conflicting with CFs.
I suggest we go Beta1 on June 1, so we can discuss any problems arising in person in Ottawa. It's quicker than normal, but if we've lost a month or two we should just skip the usual "open items" chase, which can be done in parallel with users finding and reporting real bugs.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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 20 May 2015 at 03:13, Noah Misch <noah@leadboat.com> wrote:
--
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.
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.
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.
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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. +