Re: [HACKERS] 8.5 development schedule
Peter Eisentraut wrote: > Well, in the past the commit fest manager has usually written an > email, "The commit fest is now closed". With the new commitfest software, as the last patch is moved out of "pending" and the commitfest moved to "closed" status -- I can practically hear the bang of the gavel. :-) -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On mån, 2009-08-17 at 10:22 -0400, Robert Haas wrote: > On Mon, Aug 17, 2009 at 8:43 AM, Peter Eisentraut wrote: > > On Mon, 2009-08-17 at 08:04 -0400, Robert Haas wrote: > >> Now that the first CommitFest is over and done with, > > > > I think you forgot the part where you tell everyone that it is in fact > > done. I'm waiting on you before I get the alpha release rolling. > > Hmm, it's sort of out of my hands at this point. There are three > patches left, all of which have been claimed by committers, one of > whom is you. I don't have any magical powers to control the timing of > committer activity. Well, in the past the commit fest manager has usually written an email, "The commit fest is now closed". Which, as you write, doesn't really strictly mean anything, just as much as the commit first itself doesn't really need to mean anything, but appeared to give everyone a sense of direction and a fuzzy feeling. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Mon, Aug 17, 2009 at 8:43 AM, Peter Eisentraut wrote: > On Mon, 2009-08-17 at 08:04 -0400, Robert Haas wrote: >> Now that the first CommitFest is over and done with, > > I think you forgot the part where you tell everyone that it is in fact > done. I'm waiting on you before I get the alpha release rolling. Hmm, it's sort of out of my hands at this point. There are three patches left, all of which have been claimed by committers, one of whom is you. I don't have any magical powers to control the timing of committer activity. But if you're waiting (sorry, didn't realize that), then I think what we should do is just move those three patches to the next CommitFest. Then this one will really be done. I'll go do that now. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Mon, 2009-08-17 at 08:04 -0400, Robert Haas wrote: > Now that the first CommitFest is over and done with, I think you forgot the part where you tell everyone that it is in fact done. I'm waiting on you before I get the alpha release rolling. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Tue, Jun 30, 2009 at 1:33 AM, Peter Eisentraut wrote:
> Now that 8.4.0 is out the door, development for 8.5devel will be opened any
> day now. But we haven't discussed the development timeline so far. The core
> team has several proposals:
>
> CommitFest Alpha
> Aug. 1 Sept. 1
> Oct. 1 Nov. 1
> Dec. 1 Jan ~~ 5
> Feb. 1 March 4
>
> Release ~ May 2010
>
> This puts us on track for a release at the same time next year, maybe a little
> earlier.
>
> ("Alpha" is a semiformal snapshot release at the end of the commitfest, for
> those who haven't heard yet. Details later.)
>
> If we want to avoid a commitfest in December, then this:
>
> CommitFest Alpha
> Sept. 1 Oct. 1
> Nov. 1 Dec. 1
> Jan. 1 Feb 1
> March 1 April 2
>
> Release ~ June 2010
>
> But this has the drawback of waiting an extra month for the first commit fest,
> for no particularly good reason. (Check the current list, if you are
> curious.)
>
> Or, one more commitfest:
>
> CommitFest Alpha
> Aug. 1 Sept. 1
> Oct. 1 Nov. 1
> Dec. 1 Jan ~~ 5
> Feb. 1 March 3
> April 3 May 3
>
> Release ~ July 2010
>
> But that gets 8.5 out even later than this year, and past PGCon.
>
> Comments?
Now that the first CommitFest is over and done with, it's probably
time to revive this discussion. If we want people to get big patches
in prior to the last CommitFest, we'd better give the ample warning of
when the penultimate CommitFest is likely to start.
Since we started the first CommitFest on July 15th, and assuming we
want to stick with the timing of one CommitFest every 2 months, a
four-CommitFest cycle would look like this: July 15th, September 15th,
November 15th, January 15th. A five-CommitFest cycle would add an
additional CommitFest starting March 15th, but I think the last time
we had this discussion, most people were in favor of trying to get 8.5
out the door before PGCon.
I want to point out that if we want to have 8.4 be released at the
same time that 8.5 was, or maybe even a bit earlier in the year so
that it actually is before PGCon, then the right number of CommitFests
is THREE. Last time, we started the last CommitFest on November 1st.
With a three-CommitFest release, our final CommitFest will begin two
weeks later than it did last year; with a four-CommitFest release, it
will begin a month and a half later. Even if we assume we'll do a
better job with release management this time, it doesn't seem very
realistic to think that we're going to start the final CommitFest a
month and a half later and get the release out a month sooner.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Robert Haas wrote: > On Fri, Jul 3, 2009 at 1:16 PM, Tom Lane wrote: >> Heikki Linnakangas writes: >>> Robert Haas wrote: What I've seen of Heikki's work thus far has led me to believe that his reasons for rejecting the patch were good ones, but I don't specifically what they were. It would be helpful, I think, to reiterate them or repost links to the relevant messages in the archives; it would also be great if we could get an estimate of how close the patch is to being committable. Does it still need massive work, or is it getting fairly close, or what? Are the issues code cleanliness/maintainability, bugs, missing functionality? >>> This is where we left off: >>> http://archives.postgresql.org/message-id/49a64d16.8010...@enterprisedb.com >> There were adjacent remarks suggesting that large other parts of the >> patch remained to be reviewed, as well. >> http://archives.postgresql.org/pgsql-hackers/2009-02/msg01268.php > > Thanks to both of you, this is very helpful. Two other questions: > > 1. Are there any chunks of this functionality in this patch that seem > like they might be able to be severed and committed separately? I don't think so. > 2. Was the latest version of this patch posted to the mailing list, > and if so can you provide a link? Yes: http://archives.postgresql.org/message-id/49a64d73.6090...@enterprisedb.com -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Fri, Jul 3, 2009 at 1:16 PM, Tom Lane wrote: > Heikki Linnakangas writes: >> Robert Haas wrote: >>> What I've seen of Heikki's work thus far has led me to believe that >>> his reasons for rejecting the patch were good ones, but I don't >>> specifically what they were. It would be helpful, I think, to >>> reiterate them or repost links to the relevant messages in the >>> archives; it would also be great if we could get an estimate of how >>> close the patch is to being committable. Does it still need massive >>> work, or is it getting fairly close, or what? Are the issues code >>> cleanliness/maintainability, bugs, missing functionality? > >> This is where we left off: >> http://archives.postgresql.org/message-id/49a64d16.8010...@enterprisedb.com > > There were adjacent remarks suggesting that large other parts of the > patch remained to be reviewed, as well. > http://archives.postgresql.org/pgsql-hackers/2009-02/msg01268.php Thanks to both of you, this is very helpful. Two other questions: 1. Are there any chunks of this functionality in this patch that seem like they might be able to be severed and committed separately? 2. Was the latest version of this patch posted to the mailing list, and if so can you provide a link? Thanks, ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Heikki Linnakangas writes: > Robert Haas wrote: >> What I've seen of Heikki's work thus far has led me to believe that >> his reasons for rejecting the patch were good ones, but I don't >> specifically what they were. It would be helpful, I think, to >> reiterate them or repost links to the relevant messages in the >> archives; it would also be great if we could get an estimate of how >> close the patch is to being committable. Does it still need massive >> work, or is it getting fairly close, or what? Are the issues code >> cleanliness/maintainability, bugs, missing functionality? > This is where we left off: > http://archives.postgresql.org/message-id/49a64d16.8010...@enterprisedb.com There were adjacent remarks suggesting that large other parts of the patch remained to be reviewed, as well. http://archives.postgresql.org/pgsql-hackers/2009-02/msg01268.php regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Robert Haas wrote: > What I've seen of Heikki's work thus far has led me to believe that > his reasons for rejecting the patch were good ones, but I don't > specifically what they were. It would be helpful, I think, to > reiterate them or repost links to the relevant messages in the > archives; it would also be great if we could get an estimate of how > close the patch is to being committable. Does it still need massive > work, or is it getting fairly close, or what? Are the issues code > cleanliness/maintainability, bugs, missing functionality? This is where we left off: http://archives.postgresql.org/message-id/49a64d16.8010...@enterprisedb.com I was in the process of simplifying Simon's last patch, by removing the concept of "recovery procs", and simplifying the association between subxids and top xids is communicated to the slave. The above link contains an experimental patch for that. The simplifications probably left behind some more crud that can now be removed, or things that were broken. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
gsst...@mit.edu (Greg Stark) writes: > I would like to propose a different strategy. Instead of always > tackling all the smaller patches and leaving the big patches for last, > I would suggest we start with Hot Standby. > > In fact I would suggest as Hot Standby has already gotten a first pass > review that we consider applying it on day 1. That gets it into > everyone's development trees so they can see any suspicious code or > effects it has in their peculiar environments. It may not be perfect > but if we apply it now there's plenty of time to make improvements. > > Then we can have a regular commitfest a month or so later. Hopefully > any followon changes to Hot Standby would actually get into that > commitfest if they're relatively minor. I could see going either way on this, either: a) Doing an as-early-as-possible CommitFest to knock off easy items that have been waiting a while, and having the *second* Fest be the one where we expect all the large, controversial items to get added (e.g. - stuff like hot standby, SEPostgreSQL), or b) Focusing on the likely-hard ones (hot standby, SE PostgreSQL) first, and deferring others to Fest #2. -- select 'cbbrowne' || '@' || 'acm.org'; http://cbbrowne.com/info/linuxdistributions.html "Everything should be built top-down, except the first time." -- Alan J. Perlis -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, Jul 1, 2009 at 11:42 PM, Andrew Dunstan wrote: > You have correctly identified the requirement in the sentence quoted above. > I for one am quite prepared to support core or some person designated by > core having such authority. I agree with you that without something like > that not much will improve. That's the role of a release manager. Perhaps it's time to think about designating one for each release to endorse this responsability. -- Guillaume -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Tom Lane wrote: Ron Mayer writes: Bruce Momjian wrote: Where did you see 8.4 was scheduled to be released around the start of the year? I never never seen that and would have disputed anyone saying it publicly. I think people carefully avoided the word "scheduled", but the press FAQ on www.postgresql.org did say to expect it in Q4 08. http://archives.postgresql.org/pgsql-general/2009-02/msg01265.php http://www.postgresql.org/about/press/faq Q: When will 8.4 come out? A: Historically, PostgreSQL has released approximately every 12 months and there is no desire in the community to change from that pattern. So expect 8.4 sometime in the fourth quarter of 2008. Whoever wrote that certainly didn't ask any of the core hackers about the phrasing. Thtat change was done as part of the website changes for the 8.3 release which we usually get through Josh(who is usually creating the presskits).The relevant commit message would be: https://pgweb.postgresql.org/changeset/1888. Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> Bruce Momjian writes: > >>> If we review patches as soon as they appear, and give rapid feedback, we > >>> can easily reject patches that take more than a few days for the patch > >>> author to resolve, and there would be little slippage; the same goes > >>> for dealing with known bugs. I know it can be done, but I don't promise > >>> it would be pleasant. > >> > >> In other words, you propose dropping the idea of commitfests, and > >> expecting committers to spend *all* their time reviewing? Tain't > >> happening. > > > "I don't promise it would be pleasant." > > I'm not sure which part of "no" you didn't understand, but this > committer is not buying into that proposal. Again, I am pointing out it could be done, but it would be unpleasant, as you mentioned. We can't move make progress unless we understand the underlying causes of our delays. I am not suggesting we adopt it for reasons you mentioned. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian writes: > Tom Lane wrote: >> Bruce Momjian writes: >>> If we review patches as soon as they appear, and give rapid feedback, we >>> can easily reject patches that take more than a few days for the patch >>> author to resolve, and there would be little slippage; the same goes >>> for dealing with known bugs. I know it can be done, but I don't promise >>> it would be pleasant. >> >> In other words, you propose dropping the idea of commitfests, and >> expecting committers to spend *all* their time reviewing? Tain't >> happening. > "I don't promise it would be pleasant." I'm not sure which part of "no" you didn't understand, but this committer is not buying into that proposal. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, Jul 1, 2009 at 7:00 PM, Tom Lane wrote: > Greg Stark writes: >> On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane wrote: >>> I'm also not prepared to push a large and unstable feature into the tree >>> on the hope that it will get fixed. > >> I didn't have the impression it had any known problems, Simon and >> others spent a lot of time testing it already. > > If it didn't have known problems it would have been committed in 8.4. What I've seen of Heikki's work thus far has led me to believe that his reasons for rejecting the patch were good ones, but I don't specifically what they were. It would be helpful, I think, to reiterate them or repost links to the relevant messages in the archives; it would also be great if we could get an estimate of how close the patch is to being committable. Does it still need massive work, or is it getting fairly close, or what? Are the issues code cleanliness/maintainability, bugs, missing functionality? >From our conversations at the PGcon development meeting it seems as though there are a lot of people for whom this is a high-priority feature. Perhaps some of them will be willing to help if we give them enough information to work with. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Tom Lane wrote: > Bruce Momjian writes: > > There has been discussion about how to be more hard-nosed about > > rejecting patches. I think it has to start with us being more > > hard-nosed about giving patches feedback --- the very idea we had to > > create commit-fests reflects that we historically have not done an > > organized job of processing patches. > > > If we review patches as soon as they appear, and give rapid feedback, we > > can easily reject patches that take more than a few days for the patch > > author to resolve, and there would be little slippage; the same goes > > for dealing with known bugs. I know it can be done, but I don't promise > > it would be pleasant. > > In other words, you propose dropping the idea of commitfests, and > expecting committers to spend *all* their time reviewing? Tain't > happening. "I don't promise it would be pleasant." -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Robert Haas wrote: > > If we review patches as soon as they appear, and give rapid feedback, we > > can easily reject patches that take more than a few days for the patch > > author to resolve, and there would be little slippage; ?the same goes > > for dealing with known bugs. ?I know it can be done, but I don't promise > > it would be pleasant. > > Also agreed. It's never pleasant to have a patch rejected/postponed, > but it's tolerable if you've gotten some feedback and understand the > reasons why. Of course there is no guarantee that you will agree with > those reasons, but that's life. Some day you may be the committer and > have your turn to irritate patch submitters. :-) Our only limitation is our own sense that we have been fair to patch authors, i.e. there is no external restriction on how we handle things. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian writes: > There has been discussion about how to be more hard-nosed about > rejecting patches. I think it has to start with us being more > hard-nosed about giving patches feedback --- the very idea we had to > create commit-fests reflects that we historically have not done an > organized job of processing patches. > If we review patches as soon as they appear, and give rapid feedback, we > can easily reject patches that take more than a few days for the patch > author to resolve, and there would be little slippage; the same goes > for dealing with known bugs. I know it can be done, but I don't promise > it would be pleasant. In other words, you propose dropping the idea of commitfests, and expecting committers to spend *all* their time reviewing? Tain't happening. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, Jul 1, 2009 at 6:55 PM, Bruce Momjian wrote: > bruce wrote: >> I realize there is the perception that the large patches that were >> eventually rejected held up the release, but for all the patches I can >> think of, they were not rejected immediately _because_ we had other >> valid patches to work on. Once all valid patches were applied, we were >> quickly able to reject the large unready patches. >> >> So, rejecting the large patches early would not have significantly >> moved the release date earlier. > > I see no one agrees with my analysis --- no matter; if I unreservedly > agreed with others, I wouldn't be here. ;-) > > There has been discussion about how to be more hard-nosed about > rejecting patches. I think it has to start with us being more > hard-nosed about giving patches feedback --- the very idea we had to > create commit-fests reflects that we historically have not done an > organized job of processing patches. Agreed. > If we review patches as soon as they appear, and give rapid feedback, we > can easily reject patches that take more than a few days for the patch > author to resolve, and there would be little slippage; the same goes > for dealing with known bugs. I know it can be done, but I don't promise > it would be pleasant. Also agreed. It's never pleasant to have a patch rejected/postponed, but it's tolerable if you've gotten some feedback and understand the reasons why. Of course there is no guarantee that you will agree with those reasons, but that's life. Some day you may be the committer and have your turn to irritate patch submitters. :-) ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, Jul 1, 2009 at 6:53 PM, Kevin Grittner wrote: > Bruce Momjian wrote: > >> The problem is that the committers control the commit date, but the >> one seen as punished for a rejected patch is not the committers but >> the submitter. > > Well, it would seem odd for anyone to feel "punished". Depends on who the patch submitter thinks is at fault. Sometimes, patches legitimately don't get reviewed as much as would be good. Other times, the submitter just thinks the committer is nitpicking. I think Bruce summarized it pretty well. Really, when you get right down to it, you can guarantee that all patches get a certain amount of review, or you can guarantee that the CommitFest ends by a certain date, but not both, because you can't force other people to spend more time on PostgreSQL than they have to spend. At best, you can get them to spend the time that they do have on the right sort of things (e.g. reviewing rather than developing new patches during CommitFest). Of course, since you want both of those things to happen, it's a balancing act. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Greg Stark writes: > On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane wrote: >> I'm also not prepared to push a large and unstable feature into the tree >> on the hope that it will get fixed. > I didn't have the impression it had any known problems, Simon and > others spent a lot of time testing it already. If it didn't have known problems it would have been committed in 8.4. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Greg Stark wrote: > On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane wrote: > > > I'm also not prepared to push a large and unstable feature into the tree > > on the hope that it will get fixed. > > I didn't have the impression it had any known problems, Simon and > others spent a lot of time testing it already. The improvements Heikki > was asking for were simplifications or cleanup type changes and every > time he asked for something Simon had it done within a day or two. > > The problem is I think this will *always* be a "large unstable > feature" just because it's large. If we aren't happy having it in the > tree for alpha releases then there's no circumstance we'll ever be > happy having it in a real release. I think it's a *lot* better having > it in the alpha releases when if we find problems we can revert it or > fix the problems than dropping it at the last second before the betas > when it has to be perfect and there's no second chances. By that logic we would never have accepted large patches, but we have, often. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
bruce wrote: > I realize there is the perception that the large patches that were > eventually rejected held up the release, but for all the patches I can > think of, they were not rejected immediately _because_ we had other > valid patches to work on. Once all valid patches were applied, we were > quickly able to reject the large unready patches. > > So, rejecting the large patches early would not have significantly > moved the release date earlier. I see no one agrees with my analysis --- no matter; if I unreservedly agreed with others, I wouldn't be here. ;-) There has been discussion about how to be more hard-nosed about rejecting patches. I think it has to start with us being more hard-nosed about giving patches feedback --- the very idea we had to create commit-fests reflects that we historically have not done an organized job of processing patches. If we review patches as soon as they appear, and give rapid feedback, we can easily reject patches that take more than a few days for the patch author to resolve, and there would be little slippage; the same goes for dealing with known bugs. I know it can be done, but I don't promise it would be pleasant. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian wrote: > The problem is that the committers control the commit date, but the > one seen as punished for a rejected patch is not the committers but > the submitter. Well, it would seem odd for anyone to feel "punished". If the patch isn't submitted in good form with the issues hashed out in prior discussion, and the reviewer(s) and committer(s) can't resolve the issues prior to the cutoff -- well, try to address those issues for the next release. Maybe submit with a bit more lead time next time around. As is often pointed out here, nothing stops you from using your own patch if you need to. We did so here, for example, with the standard character string literals. Had that patch never been accepted, we'd still be patching new releases. I'm sure that's not always an option, but I'll bet it often is. If the submitter is anxious to make a particular release, they should be motivated to submit early, turn around quickly, and raise a fuss if the patch seems to be wanting for attention. One possible solution would be to have trains leaving the station more often. I know that the idea of more frequent releases has been proposed and rejected before, but that option is sort of screaming to be considered again in all of this. Are the mentions of alpha releases a way to edge into this area -- a feature which misses a major release could be available to the intrepid within a month or two, should it then be finished and committed, in a semi-formal way? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Tue, Jun 30, 2009 at 5:11 PM, Tom Lane wrote: > I'm also not prepared to push a large and unstable feature into the tree > on the hope that it will get fixed. I didn't have the impression it had any known problems, Simon and others spent a lot of time testing it already. The improvements Heikki was asking for were simplifications or cleanup type changes and every time he asked for something Simon had it done within a day or two. The problem is I think this will *always* be a "large unstable feature" just because it's large. If we aren't happy having it in the tree for alpha releases then there's no circumstance we'll ever be happy having it in a real release. I think it's a *lot* better having it in the alpha releases when if we find problems we can revert it or fix the problems than dropping it at the last second before the betas when it has to be perfect and there's no second chances. -- greg http://mit.edu/~gsstark/resume.pdf -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Kevin Grittner wrote: > Bruce Momjian wrote: > > > Define "make that date"? That is the problem. > > Not committed by that date. I guess that leaves the issue of picking > a particular time in a particular time zone, but it doesn't otherwise > seem ambiguous. > > Picture the New York Subway system. You're coming down the stairs and > the train is in sight. You either make it through the doors before > they close, or you don't. If you don't, you wait for the next train. > The system would never work if they held up the train for everyone in > sight of the train who hoped to get on to avoid the wait. Nobody is > throwing their weight around when those doors close; it's just how the > system works. The problem is that the committers control the commit date, but the one seen as punished for a rejected patch is not the committers but the submitter. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian wrote: > Define "make that date"? That is the problem. Not committed by that date. I guess that leaves the issue of picking a particular time in a particular time zone, but it doesn't otherwise seem ambiguous. Picture the New York Subway system. You're coming down the stairs and the train is in sight. You either make it through the doors before they close, or you don't. If you don't, you wait for the next train. The system would never work if they held up the train for everyone in sight of the train who hoped to get on to avoid the wait. Nobody is throwing their weight around when those doors close; it's just how the system works. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, Jul 1, 2009 at 5:01 PM, Tom Lane wrote: > Bruce Momjian writes: >> Kevin Grittner wrote: >>> However, even the *possibility* that this could be true is pretty >>> scary. If we need to effectively shut down new development for seven >>> months at the end of a release, in addition to the interim commit >>> fests, we'd better get a handle on why, so that can change. To what >>> do you attribute the extended time needed to handle the final CF? >>> How can that be made better? > >> We had many patches that had been through previous commit-fests with >> minor adjustments and we had to finalize them before we could close the >> final commit-fest. To be clear I am talking about patches that were >> eventually applied in 8.4, not patches that were rejected for 8.4. > > I think this is simply not in agreement with the facts. The patches > that caused the greatest amount of delay for 8.4 were the ones that > ultimately got rejected --- notably hot standby, sync rep, and > sepostgres. Now the fact that everybody knew they would take awhile This is also how I remember it. > provided some "cover" for other patches that weren't quite ready. > If we had bounced those three on Nov. 1 the commit fest would've been > a lot shorter. Probably some other things that did get in would've > gotten bounced too, but on the whole I think the project would have been > better off. It wasn't just the big patches that dragged on forever: for example, updateable views got submitted literally hours before the start of the CommitFest in a state where it did not even pass regression tests, I reviewed it, there was a lng delay before resubmit, then it got committed, then it got reverted. If we had ejected that patch from the queue (for non-resubmission, if nothing else) early on in the process, it would have freed up at least three people's time (Tom's, mine, Peter's) to work on other patches that were in better shape and submitted sooner. One of the WORST mistakes that we made with the November CommitFest was to only assign reviewers to the small patches, figuring that the committers would look at the big ones. SE-PostgreSQL was not given a reasonable review for a very long time. What we need to do this time is start with the biggest patches and assign the most capable reviewers (committers, preferably) to those patches and then work down the list. This is another example of the uncomfortable dynamic between committers and everyone else: non-committers don't feel comfortable assigning committers to review patches, because who are we to tell the commiters what to do? But when the committers are the only ones competent to do that review, the result is a huge vacuum. We need to put some structure around this that works. I do agree, however, that rejecting more patches sooner (in particular, the ones that had been reviewed and found wanting) would have been the way to go and good for the project. > The long and the short of it is that there is always tremendous pressure > to include patches that are on the edge of being ready, because we all > know that bouncing them to the next release cycle will mean an extra > year before they're available in production. The dynamic in 8.4 was > exactly the same as it's been in the prior release cycles: we keep > slipping the possible release date and trying to get those patches > ready, and we don't give up until everyone agrees the release is just > hopelessly late. As long as we keep behaving that way, no amount of > schedule-setting or rule-making is going to change anything. Yep. > It comes down to somebody having the willingness to say "no" and the > authority to make it stick. Robert mentioned upthread that the > committers don't want to be seen as throwing their weight around, > which is quite true, but I have also noticed in the past that saying > "no" does not convince whoever is arguing that "this release will suck > if it doesn't have this feature". And there's always somebody arguing > that side --- usually several people. Yep. But having a review that clearly enumerates the reasons WHY the patch needs to be rejected is certainly more compelling than a blanket statement that the patch is big and invasive and therefore must have bugs, even if we haven't looked at it enough to find them. The blanket statement may be quite true, but it doesn't provide feedback to the patch author and so fails to accomplish one of the main purposes of the CommitFests, at least IMO. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Tom Lane wrote: "Joshua D. Drake" writes: On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote: It comes down to somebody having the willingness to say "no" and the authority to make it stick. Robert mentioned upthread that the committers don't want to be seen as throwing their weight around, Is that the purpose of core? To make exactly those decisions? Core has never seen itself as intended to make feature-by-feature decisions. People seem to be willing to defer to us on release schedule-setting, but it's not clear to me that the community has delegated us more authority than that. You have correctly identified the requirement in the sentence quoted above. I for one am quite prepared to support core or some person designated by core having such authority. I agree with you that without something like that not much will improve. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Joshua D. Drake wrote: > On Wed, 2009-07-01 at 17:13 -0400, Tom Lane wrote: > > "Joshua D. Drake" writes: > > > On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote: > > >> It comes down to somebody having the willingness to say "no" and the > > >> authority to make it stick. Robert mentioned upthread that the > > >> committers don't want to be seen as throwing their weight around, > > > > > Is that the purpose of core? To make exactly those decisions? > > > > Core has never seen itself as intended to make feature-by-feature > > decisions. People seem to be willing to defer to us on release > > schedule-setting, but it's not clear to me that the community has > > delegated us more authority than that. > > I would agree that having core decide on specific features is probably a > stretch but having core set a cut date to which *all* patches that don't > make that date? That seems within purview. Define "make that date"? That is the problem. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, 2009-07-01 at 17:13 -0400, Tom Lane wrote: > "Joshua D. Drake" writes: > > On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote: > >> It comes down to somebody having the willingness to say "no" and the > >> authority to make it stick. Robert mentioned upthread that the > >> committers don't want to be seen as throwing their weight around, > > > Is that the purpose of core? To make exactly those decisions? > > Core has never seen itself as intended to make feature-by-feature > decisions. People seem to be willing to defer to us on release > schedule-setting, but it's not clear to me that the community has > delegated us more authority than that. I would agree that having core decide on specific features is probably a stretch but having core set a cut date to which *all* patches that don't make that date? That seems within purview. Sincerely, Joshua D. Drake -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
"Joshua D. Drake" writes: > On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote: >> It comes down to somebody having the willingness to say "no" and the >> authority to make it stick. Robert mentioned upthread that the >> committers don't want to be seen as throwing their weight around, > Is that the purpose of core? To make exactly those decisions? Core has never seen itself as intended to make feature-by-feature decisions. People seem to be willing to defer to us on release schedule-setting, but it's not clear to me that the community has delegated us more authority than that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, 2009-07-01 at 17:01 -0400, Tom Lane wrote: > It comes down to somebody having the willingness to say "no" and the > authority to make it stick. Robert mentioned upthread that the > committers don't want to be seen as throwing their weight around, Is that the purpose of core? To make exactly those decisions? Sincerely, Joshua D. Drake -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian writes: > Kevin Grittner wrote: >> However, even the *possibility* that this could be true is pretty >> scary. If we need to effectively shut down new development for seven >> months at the end of a release, in addition to the interim commit >> fests, we'd better get a handle on why, so that can change. To what >> do you attribute the extended time needed to handle the final CF? >> How can that be made better? > We had many patches that had been through previous commit-fests with > minor adjustments and we had to finalize them before we could close the > final commit-fest. To be clear I am talking about patches that were > eventually applied in 8.4, not patches that were rejected for 8.4. I think this is simply not in agreement with the facts. The patches that caused the greatest amount of delay for 8.4 were the ones that ultimately got rejected --- notably hot standby, sync rep, and sepostgres. Now the fact that everybody knew they would take awhile provided some "cover" for other patches that weren't quite ready. If we had bounced those three on Nov. 1 the commit fest would've been a lot shorter. Probably some other things that did get in would've gotten bounced too, but on the whole I think the project would have been better off. The long and the short of it is that there is always tremendous pressure to include patches that are on the edge of being ready, because we all know that bouncing them to the next release cycle will mean an extra year before they're available in production. The dynamic in 8.4 was exactly the same as it's been in the prior release cycles: we keep slipping the possible release date and trying to get those patches ready, and we don't give up until everyone agrees the release is just hopelessly late. As long as we keep behaving that way, no amount of schedule-setting or rule-making is going to change anything. It comes down to somebody having the willingness to say "no" and the authority to make it stick. Robert mentioned upthread that the committers don't want to be seen as throwing their weight around, which is quite true, but I have also noticed in the past that saying "no" does not convince whoever is arguing that "this release will suck if it doesn't have this feature". And there's always somebody arguing that side --- usually several people. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Kevin Grittner wrote: > Bruce Momjian wrote: > > The beta preparation is dealing with all open issues, which is > > different than the focus of the commit-fest. Ideally we would be > > addressing those open/bug issues during normal development, but for > > the hard problems seem to linger and then we have to deal with them > > during beta preparation, which can take 1-2 months. > > Is there any way to move some of that work up into the earlier commit > fests? (I'm afraid I still don't have my head around exactly what > sorts of issues are addressed in this phase.) Basically when someone reports a bug against CVS HEAD we try to fix it but if the fix is complex, we usually just leave it for later, hence the beta preparation time. I think we assume some ideal fix will occur to us but once we are near beta, we have no more time so we fix it as best we can. > By the way, I hope that nobody is taking any of my observations or > questions as criticism or complaint. It seems pretty obvious that the > process currently involves a fair amount of frustration and pain for > all involved, and I'm trying to brainstorm to help. Don't think for a > minute that I forget or fail to appreciate the tremendous work you do, > along with that done by everyone else. We understand your motivation. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian wrote: > The beta preparation is dealing with all open issues, which is > different than the focus of the commit-fest. Ideally we would be > addressing those open/bug issues during normal development, but for > the hard problems seem to linger and then we have to deal with them > during beta preparation, which can take 1-2 months. Is there any way to move some of that work up into the earlier commit fests? (I'm afraid I still don't have my head around exactly what sorts of issues are addressed in this phase.) By the way, I hope that nobody is taking any of my observations or questions as criticism or complaint. It seems pretty obvious that the process currently involves a fair amount of frustration and pain for all involved, and I'm trying to brainstorm to help. Don't think for a minute that I forget or fail to appreciate the tremendous work you do, along with that done by everyone else. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Tom Lane wrote: > Bruce Momjian writes: > > Tom Lane wrote: > >> In retrospect, the CF idea took some of the edge off the problem of > >> lots of large patches arriving at the feature freeze deadline, but it > >> is far from having eliminated the problem. > > > The beta preparation is dealing with all open issues, which is different > > than the focus of the commit-fest. Ideally we would be addressing those > > open/bug issues during normal development, but for the hard problems > > seem to linger and then we have to deal with them during beta > > preparation, which can take 1-2 months. > > We've never scheduled a "beta preparation" phase like that before, > and I don't recall you complaining about the lack of one in the 8.4 > schedule. Personally I think the slip is entirely due to the final > CF taking five months (we closed it 25-March) where we'd expected > something closer to one month. I didn't bring it up because the schedule was kind of a first attempt and it didn't make sense to try and tune it at that point. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Kevin Grittner wrote: > Bruce Momjian wrote: > > > How could we have possibly completed the last commit-fest and gotten > > ready for beta in two months --- that is just not realistic. I > > think we anticipated a 2x longer final commit-fest, two months, but > > there was no time scheduled for actual beta preparation. > > For my edification, could you point me at something which identifies > the work needed after everything is committed and before the first > beta is released? (I can't remember reading anything like that, but > it may have fallen through the cracks.) > > If no such page exists, could you sketch out a brief outline? I just posted on this, but the answer is that commit-fest is for getting patches applied --- it does not address open bugs that have to be addressed before we can go to beta. Those bugs could be new or could be related to previously-applied patches. That process can take 1-2 months. > > > I think there was some ideal that we wouldn't need any time to > > prepare for beta and that we would have dealt with all bugs by the > > time the last commit-fest is complete, but that is illusory. > > I thought one of the purposes of the two-month beta testing phase on > the calendar was to find and fix bugs. That was in addition to the > two month final commit-fest. But usually by the time we finish the last commit-fest, we already have lots of bugs we know about (usually hard to fix), and it doesn't make sense to go into beta with known bugs. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian writes: > Tom Lane wrote: >> In retrospect, the CF idea took some of the edge off the problem of >> lots of large patches arriving at the feature freeze deadline, but it >> is far from having eliminated the problem. > The beta preparation is dealing with all open issues, which is different > than the focus of the commit-fest. Ideally we would be addressing those > open/bug issues during normal development, but for the hard problems > seem to linger and then we have to deal with them during beta > preparation, which can take 1-2 months. We've never scheduled a "beta preparation" phase like that before, and I don't recall you complaining about the lack of one in the 8.4 schedule. Personally I think the slip is entirely due to the final CF taking five months (we closed it 25-March) where we'd expected something closer to one month. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Tom Lane wrote: > Bruce Momjian writes: > > OK, that is more accurate, but looking at the schedule: > > > 1st November 2008 - final commit fest begins > > 1st January 2009 - beta 1 > > 1st March 2009 - 8.4.0 release > > > How could we have possibly completed the last commit-fest and gotten > > ready for beta in two months --- that is just not realistic. > > We didn't know that at the time, though. We thought the last CF would > take a month plus. And up till November the CFs *were* getting done > in about a month. > > In retrospect, the CF idea took some of the edge off the problem of > lots of large patches arriving at the feature freeze deadline, but it > is far from having eliminated the problem. The beta preparation is dealing with all open issues, which is different than the focus of the commit-fest. Ideally we would be addressing those open/bug issues during normal development, but for the hard problems seem to linger and then we have to deal with them during beta preparation, which can take 1-2 months. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Ron Mayer writes: > Bruce Momjian wrote: >> Where did you see 8.4 was scheduled to be released around the start of >> the year? I never never seen that and would have disputed anyone saying >> it publicly. > I think people carefully avoided the word "scheduled", but the > press FAQ on www.postgresql.org did say to expect it in Q4 08. > http://archives.postgresql.org/pgsql-general/2009-02/msg01265.php > http://www.postgresql.org/about/press/faq >Q: When will 8.4 come out? >A: Historically, PostgreSQL has released approximately > every 12 months and there is no desire in the community > to change from that pattern. So expect 8.4 sometime in > the fourth quarter of 2008. Whoever wrote that certainly didn't ask any of the core hackers about the phrasing. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian wrote: > How could we have possibly completed the last commit-fest and gotten > ready for beta in two months --- that is just not realistic. I > think we anticipated a 2x longer final commit-fest, two months, but > there was no time scheduled for actual beta preparation. For my edification, could you point me at something which identifies the work needed after everything is committed and before the first beta is released? (I can't remember reading anything like that, but it may have fallen through the cracks.) If no such page exists, could you sketch out a brief outline? > I think there was some ideal that we wouldn't need any time to > prepare for beta and that we would have dealt with all bugs by the > time the last commit-fest is complete, but that is illusory. I thought one of the purposes of the two-month beta testing phase on the calendar was to find and fix bugs. That was in addition to the two month final commit-fest. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Ron Mayer wrote: > Bruce Momjian wrote: > > Where did you see 8.4 was scheduled to be released around the start of > > the year? I never never seen that and would have disputed anyone saying > > it publicly. > > I think people carefully avoided the word "scheduled", but the > press FAQ on www.postgresql.org did say to expect it in Q4 08. > > > http://archives.postgresql.org/pgsql-general/2009-02/msg01265.php > http://www.postgresql.org/about/press/faq >Q: When will 8.4 come out? >A: Historically, PostgreSQL has released approximately > every 12 months and there is no desire in the community > to change from that pattern. So expect 8.4 sometime in > the fourth quarter of 2008. OK, now that someone has brought it up --- I have been disappointed with the anticipated release dates we broadcast to the press --- without community approval or oversight. This is not the first time, but hopefully it is the last. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian writes: > OK, that is more accurate, but looking at the schedule: > 1st November 2008 - final commit fest begins > 1st January 2009 - beta 1 > 1st March 2009 - 8.4.0 release > How could we have possibly completed the last commit-fest and gotten > ready for beta in two months --- that is just not realistic. We didn't know that at the time, though. We thought the last CF would take a month plus. And up till November the CFs *were* getting done in about a month. In retrospect, the CF idea took some of the edge off the problem of lots of large patches arriving at the feature freeze deadline, but it is far from having eliminated the problem. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian wrote: Where did you see 8.4 was scheduled to be released around the start of the year? I never never seen that and would have disputed anyone saying it publicly. I think people carefully avoided the word "scheduled", but the press FAQ on www.postgresql.org did say to expect it in Q4 08. http://archives.postgresql.org/pgsql-general/2009-02/msg01265.php http://www.postgresql.org/about/press/faq Q: When will 8.4 come out? A: Historically, PostgreSQL has released approximately every 12 months and there is no desire in the community to change from that pattern. So expect 8.4 sometime in the fourth quarter of 2008. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Kevin Grittner wrote: > Tom Lane wrote: > > "Kevin Grittner" writes: > >> That showed a January 1 beta release and a March 1 production > >> release. > > > > Terminological problem. Around here, "release" *always* means > > production release. We don't expect end users to be very interested > > in pre-production versions. > > Well, I actually phrased it with managers here that 8.4 was scheduled > to go to beta on January 1st, but that the actual release date was > less predictable because the PostgreSQL community worries more about > having a solid release than hitting a release date. Based on > discussions on the hackers list, I actually had the impression that > there would be a concerted effort to hit the beta date. > > But, yeah -- on this thread I got the dates confused a bit. I'm happy > to see that the slippage was less severe than I had got myself > thinking it was. A third of a year, rather than half. And I have just posted that a lack of scheduled time for beta preparation was one reason for the slippage. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Kevin Grittner wrote: > "Joshua D. Drake" wrote: > > On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote: > > >> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php > >> > >> That showed a January 1 beta release and a March 1 production > >> release. > > > > Right that would be the expectation I had. > > The first of March is still well into the first quarter; but I was > getting confused about beta versus production release schedules when I > said the release was six months late; it was four months late -- to > the day. OK, that is more accurate, but looking at the schedule: 1st November 2008 - final commit fest begins 1st January 2009 - beta 1 1st March 2009 - 8.4.0 release How could we have possibly completed the last commit-fest and gotten ready for beta in two months --- that is just not realistic. I think we anticipated a 2x longer final commit-fest, two months, but there was no time scheduled for actual beta preparation. I think there was some ideal that we wouldn't need any time to prepare for beta and that we would have dealt with all bugs by the time the last commit-fest is complete, but that is illusory. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Tom Lane wrote: > "Kevin Grittner" writes: >> That showed a January 1 beta release and a March 1 production >> release. > > Terminological problem. Around here, "release" *always* means > production release. We don't expect end users to be very interested > in pre-production versions. Well, I actually phrased it with managers here that 8.4 was scheduled to go to beta on January 1st, but that the actual release date was less predictable because the PostgreSQL community worries more about having a solid release than hitting a release date. Based on discussions on the hackers list, I actually had the impression that there would be a concerted effort to hit the beta date. But, yeah -- on this thread I got the dates confused a bit. I'm happy to see that the slippage was less severe than I had got myself thinking it was. A third of a year, rather than half. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
"Kevin Grittner" writes: > Bruce Momjian wrote: >> Where did you see 8.4 was scheduled to be released around the start of >> the year? > http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php > That showed a January 1 beta release and a March 1 production release. Terminological problem. Around here, "release" *always* means production release. We don't expect end users to be very interested in pre-production versions. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
"Joshua D. Drake" wrote: > On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote: >> http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php >> >> That showed a January 1 beta release and a March 1 production >> release. > > Right that would be the expectation I had. The first of March is still well into the first quarter; but I was getting confused about beta versus production release schedules when I said the release was six months late; it was four months late -- to the day. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, 2009-07-01 at 12:47 -0500, Kevin Grittner wrote: > Bruce Momjian wrote: > > Where did you see 8.4 was scheduled to be released around the start > of > > the year? I never never seen that and would have disputed anyone > saying > > it publicly. > > http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php > > That showed a January 1 beta release and a March 1 production release. Right that would be the expectation I had. Joshua D. Drake -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian wrote: > Where did you see 8.4 was scheduled to be released around the start of > the year? I never never seen that and would have disputed anyone saying > it publicly. http://archives.postgresql.org/pgsql-hackers/2008-02/msg00193.php That showed a January 1 beta release and a March 1 production release. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, 2009-07-01 at 13:39 -0400, Bruce Momjian wrote: > Where did you see 8.4 was scheduled to be released around the start of > the year? I never never seen that and would have disputed anyone saying > it publicly. As I understood it, 8.4 was supposed to released at the beginning of Q2. I never heard or read beginning of the year either. Joshua D. Drake -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Kevin Grittner wrote: > Ron Mayer wrote: > > > I could imagine an enterprise plan that says "we'll upgrade to > > the current production release in January [after christmas sales]"; > > or "we'll begin to upgrade the January after [feature-x] is in > > production". > > > > But in neither case does it help my long term planning to know if > > the current version January release is scheduled to be called 8.4 > > or 8.5 or 9.1 (which is really all that the current system helps > > me predict). > > It would help with that if you didn't plan on features which had not > been committed, and the release date didn't slip. It's been a little > embarrassing at times to have told people not to try to mitigate > performance problems on the application side because I've confirmed > that the semijoin / antijoin code already committed to the 8.4 release > solves the problem, and the release was expected around the start of > the year. Where did you see 8.4 was scheduled to be released around the start of the year? I never never seen that and would have disputed anyone saying it publicly. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Ron Mayer writes: > Tom Lane wrote: >> I think we used to do it more or less like that, but people didn't like >> it because they couldn't do any long-range planning. > Does the current system help long-range planning? > I could imagine an enterprise plan that says "we'll upgrade to > the current production release in January [after christmas sales]"; > or "we'll begin to upgrade the January after [feature-x] is in > production". You have forgotten the context. This discussion is not about end-user planning, it is about developer planning. The issue is whether a developer should work on feature A that he thinks will take about X months to finish, or feature B that he thinks will take Y months. For this purpose it is useful to have an idea of how long it will be until the next feature freeze. How long after that the release will actually hit the street is interesting, but not directly relevant to whether he's got a chance to get the feature in. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian wrote: > Kevin Grittner wrote: >> To what do you attribute the extended time needed to handle the >> final CF? How can that be made better? > > We had many patches that had been through previous commit-fests with > minor adjustments and we had to finalize them before we could close > the final commit-fest. To be clear I am talking about patches that > were eventually applied in 8.4, not patches that were rejected for > 8.4. Thanks. That answers the first question. I guess it suggests that the second question could be refined to: What could have been done to finalize these patches in earlier commit-fests or bump them to 8.5 before they dragged the process of wrapping the release by half a year? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Kevin Grittner wrote: > Bruce Momjian wrote: > > > I realize there is the perception that the large patches that were > > eventually rejected held up the release, but for all the patches I > > can think of, they were not rejected immediately _because_ we had > > other valid patches to work on. Once all valid patches were > > applied, we were quickly able to reject the large unready patches. > > > > So, rejecting the large patches earily would not have significantly > > moved the release date earlier. > > Like Robert, I'm extremely skeptical of this claim, for the same > reasons. > > However, even the *possibility* that this could be true is pretty > scary. If we need to effectively shut down new development for seven > months at the end of a release, in addition to the interim commit > fests, we'd better get a handle on why, so that can change. To what > do you attribute the extended time needed to handle the final CF? > How can that be made better? We had many patches that had been through previous commit-fests with minor adjustments and we had to finalize them before we could close the final commit-fest. To be clear I am talking about patches that were eventually applied in 8.4, not patches that were rejected for 8.4. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Ron Mayer wrote: > But in neither case does it help my long term planning to know if > the current version January release is scheduled to be called 8.4 > or 8.5 or 9.1 (which is really all that the current system helps > me predict). The numbering is typically decided near the end of the devel cycle; it's not set in stone from the beginning. Witness how 8.0 was slated to be called 7.5 until it was almost ready ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Ron Mayer wrote: > I could imagine an enterprise plan that says "we'll upgrade to > the current production release in January [after christmas sales]"; > or "we'll begin to upgrade the January after [feature-x] is in > production". > > But in neither case does it help my long term planning to know if > the current version January release is scheduled to be called 8.4 > or 8.5 or 9.1 (which is really all that the current system helps > me predict). It would help with that if you didn't plan on features which had not been committed, and the release date didn't slip. It's been a little embarrassing at times to have told people not to try to mitigate performance problems on the application side because I've confirmed that the semijoin / antijoin code already committed to the 8.4 release solves the problem, and the release was expected around the start of the year. Ultimately, I don't know that it makes sense to plan on any feature until its patch is accepted, so the best you can do is try to plan on when the accepted patches will become available. Almost by definition, if you want a guarantee that the feature will be in some release, the date of the release becomes unknowable in advance. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, Jul 01, 2009 at 11:51:28AM -0400, Robert Haas wrote: > Tom wrote upthread: > # If you find yourself with nothing else to do except review a new patch > # during beta, then sure, go do it. But is there *really* nothing you > # could be doing to help expedite the beta? > > My honest answer to this question is that I have no idea. It was > pretty clear to me what I was supposed to be doing during CommitFest > (reviewing patches) but a lot less clear to me what I should be doing > during beta. I know that there was an open items list, but it was > never really clear to me how I should help with that. My feelings as well. During beta, there was clearly work for those with experience in the areas with open items, and probably for committers generally, but each time I reviewed the open items list I found little I could do to help. If there's something I should have found, I'd love for someone to point it out; in the meantime I tested betas and release candidates in situtations common to my use of PostgreSQL, and found that it worked to my satisfaction, after which I was left trying to figure out what to do, and started dabbling in a patch or two that interested me. > If a hamster > and an elephant are trying to sit on the same bench, the hamster does > not want the elephant to assert that he is a hamster; he wants the > elephant to announce his choice of seat prior to putting his bottom in Thanks, Robert -- this made me giggle :) -- Joshua Tolley / eggyknap End Point Corporation http://www.endpoint.com signature.asc Description: Digital signature
Re: [HACKERS] 8.5 development schedule
Tom Lane wrote: "Joshua D. Drake" writes: We already push and pull our release dates based are what in the queue, we just do so informally. Why not just make it part of the process? I think we used to do it more or less like that, but people didn't like it because they couldn't do any long-range planning. Does the current system help long-range planning? I could imagine an enterprise plan that says "we'll upgrade to the current production release in January [after christmas sales]"; or "we'll begin to upgrade the January after [feature-x] is in production". But in neither case does it help my long term planning to know if the current version January release is scheduled to be called 8.4 or 8.5 or 9.1 (which is really all that the current system helps me predict). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, Jul 1, 2009 at 10:30 AM, Kevin Grittner wrote: > Bruce Momjian wrote: >> I realize there is the perception that the large patches that were >> eventually rejected held up the release, but for all the patches I >> can think of, they were not rejected immediately _because_ we had >> other valid patches to work on. Once all valid patches were >> applied, we were quickly able to reject the large unready patches. >> >> So, rejecting the large patches earily would not have significantly >> moved the release date earlier. > > Like Robert, I'm extremely skeptical of this claim, for the same > reasons. > > However, even the *possibility* that this could be true is pretty > scary. If we need to effectively shut down new development for seven > months at the end of a release, in addition to the interim commit > fests, we'd better get a handle on why, so that can change. To what > do you attribute the extended time needed to handle the final CF? > How can that be made better? Hear, hear! Tom wrote upthread: # If you find yourself with nothing else to do except review a new patch # during beta, then sure, go do it. But is there *really* nothing you # could be doing to help expedite the beta? My honest answer to this question is that I have no idea. It was pretty clear to me what I was supposed to be doing during CommitFest (reviewing patches) but a lot less clear to me what I should be doing during beta. I know that there was an open items list, but it was never really clear to me how I should help with that. A lot of the open items were pretty mushy, subjective issues, or that was how they seemed to me - not so much "How are we going to fix this?" but "Is this worth fixing?" and "What kind of fix is appropriate?". IOW, what they needed before any useful technical work could be done was consensus. Of course, both committers and non-committers need consensus to make changes, but committers need a lot less consensus. If no one strongly objects, they just apply. Non-committers, on the other hand, need the affirmative support of a committer to actually perform the commit. It's a lot easier to get to "no one things this is a really bad idea" than it is to get to "one of these six people thinks this is a good idea and that person is willing to devote an hour of their day (or more) to making it happen". It seems to me that the solution to this problem is pretty simple. Committers need to say exactly what kind of help they want; they need to affirmatively tell other people what to do. If Tom wants someone to develop a patch for bug XYZ, he should say that he is prepared to apply such a patch and ask for volunteers. That helps path authors in three ways: 1. Prospective patch authors know that Tom thinks this is important and that it could hold up the release. 2. Prospective patch authors know that this isn't something that Tom is already working on. 3. Prospective path authors know that they have a good chance of getting something applied quickly, without waiting 1-7 months for the next CommitFest. I think committers are reluctant to do this for fear of being seen as pushy, or for fear of being seen to use their status as committers as way to throw their weight around. In fact, I've heard more than one committer make statements of the form, well, we don't really have any more weight to throw around than anyone else. The problem with this is that it's blatantly false, and no non-committer who has taken the time to write a patch is under any contrary illusion. If a hamster and an elephant are trying to sit on the same bench, the hamster does not want the elephant to assert that he is a hamster; he wants the elephant to announce his choice of seat prior to putting his bottom in it. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Ugh, I disagree. I agree that we were too generous with letting people rework patches while the CommitFest was in progress (mostly, we let people drop off the map for 3 weeks and then come back and say, oh, here's my revised version). But you have to allow a certain amount of reworking as the CommitFest progresses, I think. Otherwise, it just takes way too long to get anything done. Sure. The key is "a *certain amount* of reworking". Not failing to respond to review for 3 weeks at a time. Not introducing APIs or syntax extensions which have never been discussed on -hackers before. Not extensive performance testing. Not saying "here's 3 parts out of 5 of the patch, I'll have the other two by the 15th". Not sumbitting a patch with no written specification or (for user-facing features) documentation. That is, the *submitter* should at least think the patch is ready to go. If people are submitting stuff they *know* isn't ready to commit, it should be with a "WIP" flag, which to the reviewers says "review this last, or not at all if we run out of time". And, even if the submitter is being responsive, if we've spent 30 days being back-and-forth with the patch, it's just not ready. Dragging that out to 60 days doesn't, according to our history, help. > I also believe, although I cannot prove it, that it would have > increased the pressure to get the remaining items dealt with. When > there are 100 patches, everyone can say "oh, well it doesn't matter > whether I get this taken care of today, because there will still be 99 > other patches". When there are 3 patches, that argument doesn't hold > water. I agree. Closing out 11/08 accelerated once we were down to the last 5 patches. > If we need to effectively shut down new development for seven > months at the end of a release, in addition to the interim commit > fests, we'd better get a handle on why, so that can change. To what > do you attribute the extended time needed to handle the final CF? > How can that be made better? Exactly. What I think we should be moving towards is the idea that *any* commitfest could, with another 30 days of housekeeping, become a final release. The only way to release in a timely fashion is to always be ready to release -- this is not just my opinion, but the experience of the Ubuntu, Parrot, and several other projects. Let me point out a worrisome trend: 7.2: 10 months 7.3: 9 months 7.4: 12 months 8.0: 13 months 8.1: 11 months 8.2: 13 months 8.3: 14 months 8.4: 16 months That's a dangerous-looking progression. What's worse is that the increasing time has always been associated with post feature-freeze; i.e. the not-fun post-development period. Until we embrace the idea that patches will get integrated or rejected in a timely fashion, and that we *can* make a target release date, we won't. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Bruce Momjian wrote: > I realize there is the perception that the large patches that were > eventually rejected held up the release, but for all the patches I > can think of, they were not rejected immediately _because_ we had > other valid patches to work on. Once all valid patches were > applied, we were quickly able to reject the large unready patches. > > So, rejecting the large patches earily would not have significantly > moved the release date earlier. Like Robert, I'm extremely skeptical of this claim, for the same reasons. However, even the *possibility* that this could be true is pretty scary. If we need to effectively shut down new development for seven months at the end of a release, in addition to the interim commit fests, we'd better get a handle on why, so that can change. To what do you attribute the extended time needed to handle the final CF? How can that be made better? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, 2009-07-01 at 02:14 -0400, Robert Haas wrote: > Basically, if we're too quick to bump patches to the next CommitFest, > there will be only moderate resistance for the first N-1 CommitFests, > but then for the last CommitFest people won't want to be bumped by a > whole major release for what are basically minor issues. That is an important point. Remember we are talking about non-committers here. Each commitfest needs to be about wrangling in the patches that are exact or nearly there. Nothing is perfect, especially when the definition of perfection is not controlled by the patch author. How can anybody know what will or will not be objected to until the patch is reviewed? Committers don't submit perfect patches, they apply them piece by piece, with comments about "I'll get back to that" or "still thinking of best way to do it.". Look at the way FOREIGN DATA WRAPPERS got in. Half a feature, piece by piece (I have zero objection to that, just an example). Saying that non-committers need to submit perfect patches or we reject them just ends up with a pile up. Expecting people that haven't passed a the bar exam to provide a higher standard of code than those that have passed the test is obviously not going to work. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Tue, 2009-06-30 at 08:33 +0300, Peter Eisentraut wrote: > Now that 8.4.0 is out the door, development for 8.5devel will be > opened any day now. But we haven't discussed the development timeline > so far. This is a wonderful thing. Development opening quickly and the idea of a discussed and explicit dev schedule are both good news. The differences between proposed schedules seems fairly small, so I have no comment on them other than expressing happiness that they exist. Thanks. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Tue, 2009-06-30 at 09:35 -0400, Robert Haas wrote: > In any case, we probably need some weigh-in from Heikki and Simon on > their plans for Hot Standby before we make any decisions... We discussed this at the developer meeting in May. I gave a clear commitment to getting Hot Standby into Postgres, and a wish to see it in 8.5. I'm going to attempt to get Sync Rep into core first, then Hot Standby. There are not too many people that have good insight in these areas and I think we need them all working together to successfully commit anything to Postgres core that we all agree with. I believe its possible that individuals may produce working solutions on their own, though I also believe that constructive teamwork can produce better solutions. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Tue, 2009-06-30 at 21:04 +0300, Heikki Linnakangas wrote: > Merlin Moncure wrote: > > Given that there is also a lot of work on synchronous replication, is > > it better to get the HS in so the SR stuff can use that as a baseline, > > or to triage in both patches together? > > Whichever finishes first. Although they're very useful together, there > is little if any code-level dependency between them. It would be > dangerous to have one wait for the other, as one or the other could well > be delayed for some reason. We can't even be sure that both are finished > in time for 8.5. Code dependency is not the main worry. Developer and committer time and attention is our scarcest resource and I expect it to remain so. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Wed, Jul 1, 2009 at 1:16 AM, Josh Berkus wrote: > Hmmm ... actually, I think Andrew's right that we don't need a specific > "last commitfest" rule which is special. Really, any patch which gets > submitted to any commitfest gets returned if it's not ready to be committed > immediately after review. The only way the last CF is special is that > anything bounced goes to the next version. > > We forgot that with the November CF, which is why it dragged on for 3.5 > months and burned a lot of people out. Let's just stick to that this time > and we don't need any new rules. Ugh, I disagree. I agree that we were too generous with letting people rework patches while the CommitFest was in progress (mostly, we let people drop off the map for 3 weeks and then come back and say, oh, here's my revised version). But you have to allow a certain amount of reworking as the CommitFest progresses, I think. Otherwise, it just takes way too long to get anything done. Suppose someone submits a patch that has minor issues to the first CommitFest. The reviewer points the issues he sees, so the author fixes the patch up and resubmits to the second CommitFest. The patch is now assigned for review again (possibly to a different reviewer), and one more minor issue is discovered, so the author fixes up the patch again and resubmits to the third CommitFest. Upon third review, it's discovered that one of the comments is poorly written, so the author fixes it up again and resubmits to the final CommitFest, whereupon it is committed. That's about 7 months to get that patch committed, and it would be twice that if the initial commitfest was to the SECOND commitfest rather than the first, since the release cycle would intervene. What should actually happen is that the whole thing should be handled by a single reviewer during one CommitFest. It's much easier to re-review a patch that you've read through just a few days prior than it is to review a whole new patch from scratch, so I don't think it's imposing an undue burden on the reviewers; in fact it should produce a net REDUCTION in work by concentrating all the work for a particular patch into a relatively compact period of time. What WAS a big problem during the last CommitFest, at least for me, was resubmits that didn't happen promptly. I couldn't decide whether I should continue starting to review new patches, or whether that would lead to chaos when all the resubmits from the ones I'd previously reviewed came back around, leaving me with 4 or 5 patches that all needed to be reviewed at the same time. So I'm strongly in favor of a very firm deadline for resubmits: except for very large patches like HS, resubmits should be required within, say, 96 hours of the time the review hits the list; otherwise, we bump it. Basically, if we're too quick to bump patches to the next CommitFest, there will be only moderate resistance for the first N-1 CommitFests, but then for the last CommitFest people won't want to be bumped by a whole major release for what are basically minor issues. So we'll be back in a situation where the last CommitFest is the pits. We have to find a middle ground where we're bumping things that are truly holding things up (tying up reviewer resources or unduly lengthening the CommitFest) but at the same time avoid bumping things so quickly that we don't really provide a patch authors with a fair shake at getting something committed in a reasonable period of time. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Andrew, I thought we discussed that at pgCon in May and rejected it. That's not what we have in my notes: http://wiki.postgresql.org/wiki/PgCon_2009_Developer_Meeting#CommitFests Of course, I may have missed some options, a lot of people were talking. I have very, very serious reservations about it. I think we need to get better about proper triage, especially on the final commitfest, rather than moving the effective feature freeze back a whole commitfest. Thing is, if we're getting 15,000 lines of code we've never seen before (collectively) at the final commitfest, there's simply no way we're getting a release out within 3 months of that. ISTM we're in danger of becoming dominated by procedures. Let's keep it light and loose. Hmmm ... actually, I think Andrew's right that we don't need a specific "last commitfest" rule which is special. Really, any patch which gets submitted to any commitfest gets returned if it's not ready to be committed immediately after review. The only way the last CF is special is that anything bounced goes to the next version. We forgot that with the November CF, which is why it dragged on for 3.5 months and burned a lot of people out. Let's just stick to that this time and we don't need any new rules. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Tue, Jun 30, 2009 at 11:18 PM, Bruce Momjian wrote: > Tom Lane wrote: >> > As for thresholds, I'd propose that we measure the size of patches >> > using "diff -u | diffstat". If the number of insertions plus the >> > number of deletions is >= 1000, then the patch is not eligible for the >> > final CommitFest unless it was submitted for the penultimate >> > CommitFest. This obvious discriminates against patches with a large >> > footprint that are not very invasive and in favor of those with a >> > small footprint that are more destabilizing, but it's a clean line in >> > the sand, and I think having such a line is better than trying to >> > apply human judgment to every case. >> >> Well, in the end it will come down to committers' judgements anyway; >> if someone thinks a patch is ready it will probably go in, regardless >> of size. But this gives us another tool for saying "no", so I'm >> agreeable ;-) > > I realize there is the perception that the large patches that were > eventually rejected held up the release, but for all the patches I can > think of, they were not rejected immediately _because_ we had other > valid patches to work on. Once all valid patches were applied, we were > quickly able to reject the large unready patches. > > So, rejecting the large patches earily would not have significantly > moved the release date earlier. I don't believe it. :-) If the large patches had been rejected earlier, the reviewers and committers who were spending time on them could have started spending time on other things sooner. I also believe, although I cannot prove it, that it would have increased the pressure to get the remaining items dealt with. When there are 100 patches, everyone can say "oh, well it doesn't matter whether I get this taken care of today, because there will still be 99 other patches". When there are 3 patches, that argument doesn't hold water. Another thing I'd like to improve for the next CommitFest is the communication between reviewers and committers. In the November CommitFest, I, and I think others, assumed that the committers were reading all of the review threads in detail throughout the process and that they would jump in when things got close to being done, or maybe when things got marked as Ready for Committer on the Wiki. That worked OK, but there were rough patches where things bogged down. As much as we may express opinions on the merits of certain patches, I think all of us non-committers are (certainly I am) loathe to avoid the perception that we're telling the committers what to do. But, I think it would be helpful to have periodic updates on what the different committers are currently focused on, how long they intend to be focused on that, and what they intend to focus on next; and I think it would be helpful for the CF mgmt team to make suggestions as to what patches we think are the closest to being ready to go or most in need of committer-level input. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Tom Lane wrote: > > As for thresholds, I'd propose that we measure the size of patches > > using "diff -u | diffstat". If the number of insertions plus the > > number of deletions is >= 1000, then the patch is not eligible for the > > final CommitFest unless it was submitted for the penultimate > > CommitFest. This obvious discriminates against patches with a large > > footprint that are not very invasive and in favor of those with a > > small footprint that are more destabilizing, but it's a clean line in > > the sand, and I think having such a line is better than trying to > > apply human judgment to every case. > > Well, in the end it will come down to committers' judgements anyway; > if someone thinks a patch is ready it will probably go in, regardless > of size. But this gives us another tool for saying "no", so I'm > agreeable ;-) I realize there is the perception that the large patches that were eventually rejected held up the release, but for all the patches I can think of, they were not rejected immediately _because_ we had other valid patches to work on. Once all valid patches were applied, we were quickly able to reject the large unready patches. So, rejecting the large patches earily would not have significantly moved the release date earlier. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > I'm in agreement that we should try to provide feedback (in general, to > > be honest) on patches/suggestions/ideas/designs/etc as quickly as > > possible. The commitfest approach is good for this when it's "in > > motion", but it's been stale for months. +1 from me for starting early. > > > To flip it around a bit, I don't know that there's actually a moratorium > > on providing feedback? > > Well, I wouldn't put it as strongly as "moratorium", but ... the point > of having a release cycle is that at certain times people are supposed > to focus on stabilizing and testing a release, not on working on new > development. I certainly agree with this. I tried to qualify my comment above in the sentence which followed it, but apparently I didn't do a good job. - This only applies before feature freeze (eg: right after 8.4 is out) - No work being done on a current patch (eg: waiting for feedback) - Have cycles to spare Our current arrangment is based on a premise that a given person will have X cycles in a month to work on PG, and that they have >=X amount of work to do on developing their patch(s) that month. I feel like there are a number of patch submitters who have X cycles to work on PG, and If, at any time in the past six months, I were to have > gone off and reviewed a patch that's clearly 8.5 material, that's > man-hours taken directly away from getting a solid 8.4 release out the > door. Which means that much longer until 8.4 does get out, which hurts > everybody including the submitter of the premature patch. So in general > I agree with the viewpoint Peter outlined that working on new > development during beta period is not really playing by the rules, and > that people who expect feedback for new development during beta period > simply don't understand how the project is supposed to work. It wasn't my intent to imply this would be done during feature-freeze, or beta, but rather something to be done during development. Perhaps I should have phrased it as "the moratorium on looking at patches can end when 8.4 is released, and not be fully reinstated until 8.5 beta". > Anyway, as of now that's all moot until next spring. But it's still > true that people want time to work on their own patches, which is why > we came up with the commitfests. It's so you can get some time to work > without feeling guilty about not reviewing other people's work instead. I definitely think that's good, and to be honest I don't think my suggestion would apply to core much at all (they've always got >=X work to do on patches :), but as we saw during the commitfests in 8.4, there's a number of non-core folks out there volunteering to review. If they're willing and able to spend cycles reviewing other patches rather than twiddling their thumbs waiting for feedback, let's encourage that. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] 8.5 development schedule
Josh Berkus wrote: One thing Peter forgot to mention here is that the next-to-last commitfest is the *last* commitfest for new major features. For the *last* commitfest, any patch introduced either has to be a resubmission of something we've seen at a prior CF, or has to be very "small" (i.e. not many lines/files, no side effects, no API or defined standard API). This makes the next-to-last CF our "biggest" CF. I thought we discussed that at pgCon in May and rejected it. I have very, very serious reservations about it. I think we need to get better about proper triage, especially on the final commitfest, rather than moving the effective feature freeze back a whole commitfest. ISTM we're in danger of becoming dominated by procedures. Let's keep it light and loose. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Yeah. In core's private discussion of this, I too was arguing for >> running a CommitFest ASAP, in order to have some motion on the existing >> patch backlog. I don't know that we'd actually end up committing many, >> but we need to provide feedback so people can take the next steps. > I'm in agreement that we should try to provide feedback (in general, to > be honest) on patches/suggestions/ideas/designs/etc as quickly as > possible. The commitfest approach is good for this when it's "in > motion", but it's been stale for months. +1 from me for starting early. > To flip it around a bit, I don't know that there's actually a moratorium > on providing feedback? Well, I wouldn't put it as strongly as "moratorium", but ... the point of having a release cycle is that at certain times people are supposed to focus on stabilizing and testing a release, not on working on new development. If, at any time in the past six months, I were to have gone off and reviewed a patch that's clearly 8.5 material, that's man-hours taken directly away from getting a solid 8.4 release out the door. Which means that much longer until 8.4 does get out, which hurts everybody including the submitter of the premature patch. So in general I agree with the viewpoint Peter outlined that working on new development during beta period is not really playing by the rules, and that people who expect feedback for new development during beta period simply don't understand how the project is supposed to work. If you find yourself with nothing else to do except review a new patch during beta, then sure, go do it. But is there *really* nothing you could be doing to help expedite the beta? Anyway, as of now that's all moot until next spring. But it's still true that people want time to work on their own patches, which is why we came up with the commitfests. It's so you can get some time to work without feeling guilty about not reviewing other people's work instead. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Tue, Jun 30, 2009 at 9:17 PM, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> As I mentioned in the core discussion, I'm a bit concerned that this >> would have the effect of choking off development too soon. We could >> have a situation where nothing major is supposed to be getting worked >> on from Nov 15 to mid-May, which seems much too long. So "very small" >> seems too strict. Robert's suggestion of a 1000-line cutoff might be >> workable though. > > Maybe we should have a hard rule now, but then leave ourselves the > option to relax it (perhaps not publically) once we actually get to the > last CF? I dunno, just a thought. I do share your concern about not > choking off development for too long, but it sure seems like we've > always got a big patch or two that we're trying to get into the next > release near the end.. With all due respect, you guys are worrying about the wrong problem. I suspect it's much more likely that we're going to want to postpone 900-line patches than it is that you're going to want to not postpone 1100-line patches. If by some chance Tom wants to commit an 1100-line patch submitted three weeks after the start of the last CommitFest, he'll explain why he wants to do it and in all likelihood the rest of us will shrug our shoulders and say "OK, do it". But I seriously doubt that's gonna happen. What's a lot more likely is that Tom will look at a 900-line patch submitted three weeks BEFORE the start of the last CommitFest and say "this is going to break a lot of stuff, we should bounce this to 8.6", and everyone will say "no, it's a great feature, commit the broken code now! now, we say!". ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
* Tom Lane (t...@sss.pgh.pa.us) wrote: > As I mentioned in the core discussion, I'm a bit concerned that this > would have the effect of choking off development too soon. We could > have a situation where nothing major is supposed to be getting worked > on from Nov 15 to mid-May, which seems much too long. So "very small" > seems too strict. Robert's suggestion of a 1000-line cutoff might be > workable though. Maybe we should have a hard rule now, but then leave ourselves the option to relax it (perhaps not publically) once we actually get to the last CF? I dunno, just a thought. I do share your concern about not choking off development for too long, but it sure seems like we've always got a big patch or two that we're trying to get into the next release near the end.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] 8.5 development schedule
* Tom Lane (t...@sss.pgh.pa.us) wrote: > I would like to propose aiming for a release around April/May 2010 ... > "in time for PGCon" if you like, but the main point is to have it out > before people start disappearing for summer break. We've already run > into problems with scheduling the 8.4 release because of that. Big +1 from me for having it in time for PGCon. > Or we could slide the target release date into the fall, but it seemed > to me that the spring release timeframe worked better (or would have if > we'd been able to meet it fully). Agreed. > Of the schedules Peter mentioned, the only one that has a realistic > chance of releasing before June is the one with the final commitfest > starting Feb 1. Even then, we need to do something to prevent that > fest from expanding the way the last 8.4 fest did. The core committee > speculated a bit about instituting a rule like "major patches must > be submitted into a CF before the last one; the last one will only > accept resubmissions and small patches". But then you have to draw > the line between major and minor patches. I liked the general idea of only accepting "already been seen patches" or "bug-fix only" patches in the last commitfest. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] 8.5 development schedule
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas writes: > > What I think we have is a lot of people who are waiting > > for feedback, and we should try to give them some. I also know that > > reviewing 60 patches for the November CommitFest was a ton of work, > > and the reviewers (including the committers) ran out of steam well > > before we got done. That, and not any desire to jump the queue, is > > the reason why I would like to get the reviewing process started > > before the patch list grows unmanageably large. > > Yeah. In core's private discussion of this, I too was arguing for > running a CommitFest ASAP, in order to have some motion on the existing > patch backlog. I don't know that we'd actually end up committing many, > but we need to provide feedback so people can take the next steps. I'm in agreement that we should try to provide feedback (in general, to be honest) on patches/suggestions/ideas/designs/etc as quickly as possible. The commitfest approach is good for this when it's "in motion", but it's been stale for months. +1 from me for starting early. To flip it around a bit, I don't know that there's actually a moratorium on providing feedback? If people aren't busy working on 8.4 (I hope not at this point, except testing.. :), have patches that they've submitted and are waiting for feedback on, or aren't otherwise busy.. I say feel free to pull patches and review/comment on. As I like to tell the people who work with me- being proactive and self-starting is almost always looked on favorably. I'm like to encourage the above for the entire development cycle, for that matter. Perhaps it won't change much (I'm confident we'll still need a "commitfest mom", etc) but I don't see why we should actively prevent it. > People who *were* following the project calendar (like me for instance) > have been largely ignoring the 8.5 queue, so many of those patches are > just sitting out there without any substantive comment. Certainly following the calendar is a good thing, it's just that we're about to pass a milestone on the project calendar and need to decide what we're gonna do next and when. > Right at the moment I imagine a large fraction of those patches are > broken anyway by the recent pgindent run --- has anyone checked? I havn't yet, but it certainly sounds like a great idea. Maybe we could even have a "mini-fix-pgindent" commitfest in the last 2 weeks of July.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] 8.5 development schedule
Kevin Grittner wrote: Tom Lane wrote: I think we used to do it more or less like that, but people didn't like it because they couldn't do any long-range planning. Well, obviously the 8.4 release cycle did little to help them. As has already been observed, there is a crying need to say "no" at some point to get a release out. It might actually help to do that on big patches if we don't let too many tiny ones accumulate. I seem to remember the argument being tossed about that "we might as well keep working on this one because there's all these others to wrap up." Have you chaps considered a simple points system? Every patch would need five minutes attention to triage it into one of: small (1 point), medium (2), large (10), huge (50 points - Sync Repl etc). First CF gets (say) 200 points, next 150, next 100, next 75. First-come, first-served - if your patch goes over the limit it goes in the next commit-fest. -- Richard Huxton Archonet Ltd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Josh Berkus writes: > One thing Peter forgot to mention here is that the next-to-last > commitfest is the *last* commitfest for new major features. For the > *last* commitfest, any patch introduced either has to be a resubmission > of something we've seen at a prior CF, or has to be very "small" (i.e. > not many lines/files, no side effects, no API or defined standard API). We've been kicking around variations of that idea already. As I mentioned in the core discussion, I'm a bit concerned that this would have the effect of choking off development too soon. We could have a situation where nothing major is supposed to be getting worked on from Nov 15 to mid-May, which seems much too long. So "very small" seems too strict. Robert's suggestion of a 1000-line cutoff might be workable though. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Josh Berkus writes: >> I would propose to start CommitFests July 15th, September 15th, >> November 15th, and January 15th, planning all but the last to be one >> month long. The last CommitFest I would plan on closing up by March >> 1st, with release hopefully by June 1st. > This sounds good to me. Anyone object? I'd like to set the target before PGCon not after; so May 1 or May 15. Otherwise +1. > The deciding people on "big patches" for the final commitfest should be > a combination of the commitfest managers and the core team. And we > should weed out the disqualified before January 15. As you say, we should reject outright (at the start of the final CF) anything that's clearly too big. But in the final 8.4 CF it didn't really become clear until later on that some things were not ready or were too big to deal with. We need to be more willing to swing the axe later in the fest, rather than allowing it to drag on "just a bit more" in the hopes of getting big feature X in. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On 6/29/09 10:33 PM, Peter Eisentraut wrote: Now that 8.4.0 is out the door, development for 8.5devel will be opened any day now. But we haven't discussed the development timeline so far. The core team has several proposals: CommitFest Alpha Aug. 1 Sept. 1 Oct. 1 Nov. 1 Dec. 1 Jan ~~ 5 Feb. 1 March 4 Release ~ May 2010 This puts us on track for a release at the same time next year, maybe a little earlier. One thing Peter forgot to mention here is that the next-to-last commitfest is the *last* commitfest for new major features. For the *last* commitfest, any patch introduced either has to be a resubmission of something we've seen at a prior CF, or has to be very "small" (i.e. not many lines/files, no side effects, no API or defined standard API). This makes the next-to-last CF our "biggest" CF. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
I would propose to start CommitFests July 15th, September 15th, November 15th, and January 15th, planning all but the last to be one month long. The last CommitFest I would plan on closing up by March 1st, with release hopefully by June 1st. This sounds good to me. Anyone object? As for thresholds, I'd propose that we measure the size of patches using "diff -u | diffstat". If the number of insertions plus the number of deletions is>= 1000, then the patch is not eligible for the final CommitFest unless it was submitted for the penultimate CommitFest. This obvious discriminates against patches with a large footprint that are not very invasive and in favor of those with a small footprint that are more destabilizing, but it's a clean line in the sand, and I think having such a line is better than trying to apply human judgment to every case. I think we need human judgement. You could easily make a 4-line change to a macro or one of the planner files which would require endless debugging. The deciding people on "big patches" for the final commitfest should be a combination of the commitfest managers and the core team. And we should weed out the disqualified before January 15. -- Josh Berkus PostgreSQL Experts Inc. www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Kevin Grittner wrote: > It might actually help to do that on big patches if we don't let too > many tiny ones accumulate. I seem to remember the argument being tossed > about that "we might as well keep working on this one because there's > all these others to wrap up." Yeah, and the people who was able to work on the small patches was too busy helping on the bigger items. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Merlin Moncure wrote: > Given that there is also a lot of work on synchronous replication, is > it better to get the HS in so the SR stuff can use that as a baseline, > or to triage in both patches together? Whichever finishes first. Although they're very useful together, there is little if any code-level dependency between them. It would be dangerous to have one wait for the other, as one or the other could well be delayed for some reason. We can't even be sure that both are finished in time for 8.5. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Robert Haas wrote: > In any case, we probably need some weigh-in from Heikki and Simon on > their plans for Hot Standby before we make any decisions... I'm planning to spend considerable amount of time reviewing and helping with hot standby and synchronous replication, but someone else will have to take the lead. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Tom Lane wrote: > I think we used to do it more or less like that, but people > didn't like it because they couldn't do any long-range planning. Well, obviously the 8.4 release cycle did little to help them. As has already been observed, there is a crying need to say "no" at some point to get a release out. It might actually help to do that on big patches if we don't let too many tiny ones accumulate. I seem to remember the argument being tossed about that "we might as well keep working on this one because there's all these others to wrap up." -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Robert Haas writes: > I agree. On the other hand, I think all of the proposed schedules are > somewhat optimistic about how long the final release will take. We > started the final CommitFest for 8.4 on November 1st and are set to > release July 1st. The proposed schedule for next time involves > starting the final CommitFest three months later and releasing two > months earlier. I'd like to think that with a little more discipline > around CommitFests we can tighten things up a little, but it seems > excessively optimistic to think that we're going to cut down from > seven months to two. Yeah. What I think the 8.4 cycle taught us is that commitfests are a good thing but they won't magically eliminate the need to say "no" at the end. If we are willing to be sufficiently hardnosed about saying "no", we can make the final commitfest short. Otherwise it's going to drag on just like this one did. Keeping the final-CF-to-release period short is desirable for the reasons already mentioned --- we don't want to shut down development for a long period. So even if it's optimistic, I think we should write the schedule that way. We can be certain that the period won't last *less* time than scheduled :-( > I would propose to start CommitFests July 15th, September 15th, > November 15th, and January 15th, planning all but the last to be one > month long. The last CommitFest I would plan on closing up by March > 1st, with release hopefully by June 1st. Hmm. If we drop the notion that CFs have to start on month boundaries, that's actually not a bad schedule --- in particular, it keeps us away from expecting much of anything to get done in the last half of December. I'd suggest setting the target release date to May 15 (pre-PGCon), as long as we're working with ides-of-whichever dates. > As for thresholds, I'd propose that we measure the size of patches > using "diff -u | diffstat". If the number of insertions plus the > number of deletions is >= 1000, then the patch is not eligible for the > final CommitFest unless it was submitted for the penultimate > CommitFest. This obvious discriminates against patches with a large > footprint that are not very invasive and in favor of those with a > small footprint that are more destabilizing, but it's a clean line in > the sand, and I think having such a line is better than trying to > apply human judgment to every case. Well, in the end it will come down to committers' judgements anyway; if someone thinks a patch is ready it will probably go in, regardless of size. But this gives us another tool for saying "no", so I'm agreeable ;-) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
"Joshua D. Drake" writes: > We already push and pull our release dates based are what in the queue, > we just do so informally. Why not just make it part of the process? That > way we are being up front and saying, "Yeah, we have no idea. We will > review in 6 months and that is when we decide our target." I think we used to do it more or less like that, but people didn't like it because they couldn't do any long-range planning. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Tue, Jun 30, 2009 at 12:37 PM, Tom Lane wrote: > "Joshua D. Drake" writes: >> On Tue, 2009-06-30 at 12:29 -0400, Tom Lane wrote: >>> I would like to propose aiming for a release around April/May 2010 ... >>> "in time for PGCon" if you like, but the main point is to have it out >>> before people start disappearing for summer break. We've already run >>> into problems with scheduling the 8.4 release because of that. > >> I generally agree with this however why not just have a "When it is >> done?". Let's hit some commitfests and some time near the end of the >> year start discussing Beta and release. > >> We are not a company. We don't have a deadline. Why can't we just >> develop and say, "Yeah, this looks like it would make a substantive >> release."? > > Well, then you might as well not have a schedule at all. The point of > setting up a schedule is not to have a deadline that we must meet or > die trying (and certainly not to ship whether it's ready or not, as > a certain other OS database has been accused of doing). Rather, the > point of this exercise is to give individual developers a framework > to plan in. Without a target date it's tough to decide what is > reasonable to work on for 8.5. I agree. On the other hand, I think all of the proposed schedules are somewhat optimistic about how long the final release will take. We started the final CommitFest for 8.4 on November 1st and are set to release July 1st. The proposed schedule for next time involves starting the final CommitFest three months later and releasing two months earlier. I'd like to think that with a little more discipline around CommitFests we can tighten things up a little, but it seems excessively optimistic to think that we're going to cut down from seven months to two. I would propose to start CommitFests July 15th, September 15th, November 15th, and January 15th, planning all but the last to be one month long. The last CommitFest I would plan on closing up by March 1st, with release hopefully by June 1st. As for thresholds, I'd propose that we measure the size of patches using "diff -u | diffstat". If the number of insertions plus the number of deletions is >= 1000, then the patch is not eligible for the final CommitFest unless it was submitted for the penultimate CommitFest. This obvious discriminates against patches with a large footprint that are not very invasive and in favor of those with a small footprint that are more destabilizing, but it's a clean line in the sand, and I think having such a line is better than trying to apply human judgment to every case. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Tue, 2009-06-30 at 12:37 -0400, Tom Lane wrote: > > We are not a company. We don't have a deadline. Why can't we just > > develop and say, "Yeah, this looks like it would make a substantive > > release."? > > Well, then you might as well not have a schedule at all. The point of > setting up a schedule is not to have a deadline that we must meet or > die trying (and certainly not to ship whether it's ready or not, as > a certain other OS database has been accused of doing). Rather, the > point of this exercise is to give individual developers a framework > to plan in. Without a target date it's tough to decide what is > reasonable to work on for 8.5. Right, I get that. That is why I mentioned the start discussing at the end of the year. The idea being, we really don't know what's going to hit. So we set a review date of work being done. Say December 1st. On December 1st we look at what is in, what appears to be coming and "then" determine a potential release date. We already push and pull our release dates based are what in the queue, we just do so informally. Why not just make it part of the process? That way we are being up front and saying, "Yeah, we have no idea. We will review in 6 months and that is when we decide our target." Shrug... Sincerely, Joshua D. Drake > > regards, tom lane > -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
"Joshua D. Drake" writes: > On Tue, 2009-06-30 at 12:29 -0400, Tom Lane wrote: >> I would like to propose aiming for a release around April/May 2010 ... >> "in time for PGCon" if you like, but the main point is to have it out >> before people start disappearing for summer break. We've already run >> into problems with scheduling the 8.4 release because of that. > I generally agree with this however why not just have a "When it is > done?". Let's hit some commitfests and some time near the end of the > year start discussing Beta and release. > We are not a company. We don't have a deadline. Why can't we just > develop and say, "Yeah, this looks like it would make a substantive > release."? Well, then you might as well not have a schedule at all. The point of setting up a schedule is not to have a deadline that we must meet or die trying (and certainly not to ship whether it's ready or not, as a certain other OS database has been accused of doing). Rather, the point of this exercise is to give individual developers a framework to plan in. Without a target date it's tough to decide what is reasonable to work on for 8.5. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Tue, 2009-06-30 at 12:29 -0400, Tom Lane wrote: > Peter Eisentraut writes: > > Now that 8.4.0 is out the door, development for 8.5devel will be opened any > > day now. But we haven't discussed the development timeline so far. The > > core > > team has several proposals: > > [ details snipped ] > > ISTM there are two critical decisions here: when's the first commitfest, > and when's the target release date? There's already been considerable > chatter about the first decision, but not much about the second. > > I would like to propose aiming for a release around April/May 2010 ... > "in time for PGCon" if you like, but the main point is to have it out > before people start disappearing for summer break. We've already run > into problems with scheduling the 8.4 release because of that. I generally agree with this however why not just have a "When it is done?". Let's hit some commitfests and some time near the end of the year start discussing Beta and release. We are not a company. We don't have a deadline. Why can't we just develop and say, "Yeah, this looks like it would make a substantive release."? Joshua D. Drake -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Tue, 2009-06-30 at 12:11 -0400, Tom Lane wrote: > I'm also not prepared to push a large and unstable feature into the tree > on the hope that it will get fixed. The general consensus among -core, > and I think most of -hackers as well, is that we want to try to keep CVS > HEAD pretty stable, so that developers aren't fighting each others' > bugs. This also ties into the "alpha releases" concept that Peter > mentioned --- if HEAD isn't stable then we can hardly put out a testable > alpha release. +1 Sincerely, Joshua D. Drake -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Peter Eisentraut writes: > Now that 8.4.0 is out the door, development for 8.5devel will be opened any > day now. But we haven't discussed the development timeline so far. The core > team has several proposals: > [ details snipped ] ISTM there are two critical decisions here: when's the first commitfest, and when's the target release date? There's already been considerable chatter about the first decision, but not much about the second. I would like to propose aiming for a release around April/May 2010 ... "in time for PGCon" if you like, but the main point is to have it out before people start disappearing for summer break. We've already run into problems with scheduling the 8.4 release because of that. Or we could slide the target release date into the fall, but it seemed to me that the spring release timeframe worked better (or would have if we'd been able to meet it fully). Of the schedules Peter mentioned, the only one that has a realistic chance of releasing before June is the one with the final commitfest starting Feb 1. Even then, we need to do something to prevent that fest from expanding the way the last 8.4 fest did. The core committee speculated a bit about instituting a rule like "major patches must be submitted into a CF before the last one; the last one will only accept resubmissions and small patches". But then you have to draw the line between major and minor patches. Actually, we did have a rule in the 8.4 cycle specifying that we reserved the right to reject large patches during the final CF. The problem was that in practice we failed to get up the gumption to say "no" and make it stick. This has been a persistent project management failing for many years, and I'm not sure how we change that dynamic. There's always somebody cheerleading for the latest-and-greatest patch... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Greg Stark writes: > I would like to propose a different strategy. Instead of always > tackling all the smaller patches and leaving the big patches for last, > I would suggest we start with Hot Standby. > In fact I would suggest as Hot Standby has already gotten a first pass > review that we consider applying it on day 1. Hot Standby wasn't ready for 8.4, and it's not any more ready now, because nothing has been done on it since then. What Simon told us at the developers' meeting is that he needs to find someone who will bankroll further work on it. I hope that will happen, but we can't design the 8.5 schedule around the assumption that it will. I'm also not prepared to push a large and unstable feature into the tree on the hope that it will get fixed. The general consensus among -core, and I think most of -hackers as well, is that we want to try to keep CVS HEAD pretty stable, so that developers aren't fighting each others' bugs. This also ties into the "alpha releases" concept that Peter mentioned --- if HEAD isn't stable then we can hardly put out a testable alpha release. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Robert Haas writes: > What I think we have is a lot of people who are waiting > for feedback, and we should try to give them some. I also know that > reviewing 60 patches for the November CommitFest was a ton of work, > and the reviewers (including the committers) ran out of steam well > before we got done. That, and not any desire to jump the queue, is > the reason why I would like to get the reviewing process started > before the patch list grows unmanageably large. Yeah. In core's private discussion of this, I too was arguing for running a CommitFest ASAP, in order to have some motion on the existing patch backlog. I don't know that we'd actually end up committing many, but we need to provide feedback so people can take the next steps. People who *were* following the project calendar (like me for instance) have been largely ignoring the 8.5 queue, so many of those patches are just sitting out there without any substantive comment. Right at the moment I imagine a large fraction of those patches are broken anyway by the recent pgindent run --- has anyone checked? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
On Tue, Jun 30, 2009 at 10:11 AM, Peter Eisentraut wrote: > On Tuesday 30 June 2009 16:50:55 Kevin Grittner wrote: >> > However, if anything, I think if anything we should go the other way >> > and start the first CommitFest July 15th. >> >> I'm curious what the counter-arguments to this are. Is it >> review-fatigue from getting the release out, or is there an economy of >> scale to building up a 100 patches before starting to review? Would >> reviewing these get some contributors moving again, thus boosting the >> total work hours available for the 8.5 release? Would it pull people >> off of WIP? > > Well, think about what could happen if we go this way. What you basically > have here are people who have essentially ignored the commitfest and beta > mandates and worked on new patches. Well, the only person who has proposed this so far is me, and I don't think there can be more than three or four people who are not committers who put in as much work into the November CommitFest as I did, and I've already volunteered to do more work for the next CommitFest. I'm not exactly sure what the beta mandate is, and I admit that I haven't done much beta-testing, but even just in the course of developing the patches I've submitted recently I've found several bugs which were fixed for 8.4 (try searching your -committers email for "Robert Haas"). I probably would not have found those bugs if I had just set out to "test 8.4", because I wouldn't have thought of those things, so I really feel that I have done as well as I can. If you disagree, we should discuss, perhaps off-list. At any rate, the idea that nobody is should do any development during the seven months for which the tree has been in feature freeze doesn't seem like a very good one. If we accept that proposition, then presumably nobody should also do any development during August, October, or December, since those months are set aside for CommitFests. Therefore, during calendar year 2009, there will be a total of 91 days during which people are allowed to work on their own patches, specifically July 1-July 31, September 1-September 30, and November 1-30. How are we going to move this project forward by telling people that they're only allowed to do development 25% of the days out of the year? And even if we do accept that proposition, my proposal to back everything up 15 days wouldn't change the total number of development days: it would add the second half of December at the expense of the second half of July. I'm of the opinion that the way that we should be striving to maximize the amount of useful development that gets done, and I think the way to do that is to give people prompt feedback on their patches. A lot of the people who have submitted patches for the next CommitFest are first-time or occasional contributors who may already have lost interest in the project; waiting longer to review those patches is not going to increase the chances that those people will eventually get more involved, either as patch authors or as patch reviewers. Others are people like Fujii Masao, Kevin Grittner, and Pavan Deolasee who, I venture to say, have done enough work on this project to deserve having their contributions reviewed in a timely fashion, regardless of exactly when they choose to do their development. There may be a few people who aren't carrying the burden of contributing back to the community, but I don't think it's anything like a majority. > And they now get to say, because we > already have enough patches, let's start the commit fest early. And then the > same people might ignore the commitfest mandate again and produce another 100 > patches by the time this commit fest ends. So let's start the next commit > fest right after this one. I don't think we have "enough" patches; I'm not sure what that means. Enough for what? It would be great if we had more patches, assuming that they were of good quality and did useful things to advance PostgreSQL. What I think we have is a lot of people who are waiting for feedback, and we should try to give them some. I also know that reviewing 60 patches for the November CommitFest was a ton of work, and the reviewers (including the committers) ran out of steam well before we got done. That, and not any desire to jump the queue, is the reason why I would like to get the reviewing process started before the patch list grows unmanageably large. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.5 development schedule
Peter Eisentraut wrote: > Well, think about what could happen if we go this way. What you > basically have here are people who have essentially ignored the > commitfest and beta mandates and worked on new patches. And they > now get to say, because we already have enough patches, let's start > the commit fest early. Well, patches started going onto the wiki page for this commit fest over seven months ago. Early review takes on a different meaning in this context. I think the basic problem with the schedule at this point is that we're releasing six months past the planned date; kinda throws things off. The question is how to get back on track and avoid that for 8.5. You probably have a point in that some of the patches came from people who might have been able to help more in the review and commit process, but I think some people lack the confidence to take on that role; and with the features that dragged out the release half-way to what would have been our next release date, there probably aren't many who could have made useful contributions to the review process. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
