Re: [HACKERS] Schedule for 8.5 Development
On Fri, 2009-09-18 at 10:22 -0700, Josh Berkus wrote: Bruce, CF17/15 to 8/14 Alpha1 by 8/20 CF29/15 to 10/14 Alpha2 by 10/20 CF311/15 to 12/14 Alpha3 by 11/20 CF41/15 to 2/14 Alpha4 by 2/20 Beta1 est. 3/1 to 3/7 Release June, depending on bugs I think that June release date is realistic. Are we ready to put this up on /developer then and make it real? Please use a less confusing date notation if you do. -- 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] Schedule for 8.5 Development
Bruce, CF1 7/15 to 8/14 Alpha1 by 8/20 CF2 9/15 to 10/14 Alpha2 by 10/20 CF3 11/15 to 12/14 Alpha3 by 11/20 CF4 1/15 to 2/14 Alpha4 by 2/20 Beta1est. 3/1 to 3/7 Release June, depending on bugs I think that June release date is realistic. Are we ready to put this up on /developer then and make it real? -- 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] Schedule for 8.5 Development
Josh Berkus wrote: Bruce, CF17/15 to 8/14 Alpha1 by 8/20 CF29/15 to 10/14 Alpha2 by 10/20 CF311/15 to 12/14 Alpha3 by 11/20 CF41/15 to 2/14 Alpha4 by 2/20 Beta1 est. 3/1 to 3/7 Release June, depending on bugs I think that June release date is realistic. Are we ready to put this up on /developer then and make it real? Sure. -- Bruce Momjian br...@momjian.ushttp://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] Schedule for 8.5 Development
Josh Berkus wrote: Hackers, Per discussions on two other threads on this list which have apparently reached consensus, we will be going with the following schedule: CF1 7/15 to 8/14 Alpha1by 8/20 CF2 9/15 to 10/14 Alpha2by 10/20 CF3 11/15 to 12/14 Alpha3by 11/20 CF4 1/15 to 2/14 Alpha4 by 2/20 Beta1 est. 3/1 to 3/7 Release June, depending on bugs I think that June release date is realistic. -- Bruce Momjian br...@momjian.ushttp://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] Schedule for 8.5 Development
On Sep 2, 2009, at 4:42 PM, Josh Berkus wrote: CF3 11/15 to 12/14 Alpha3 by 11/20 12/20? David -- 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] Schedule for 8.5 Development
On Wed, Sep 2, 2009 at 7:42 PM, Josh Berkusj...@agliodbs.com wrote: Hackers, Per discussions on two other threads on this list which have apparently reached consensus, we will be going with the following schedule: CF1 7/15 to 8/14 Alpha1 by 8/20 CF2 9/15 to 10/14 Alpha2 by 10/20 CF3 11/15 to 12/14 Alpha3 by 11/20 CF4 1/15 to 2/14 Alpha4 by 2/20 Beta1 est. 3/1 to 3/7 Release June, depending on bugs The corollary to the above is that CF4 will end on Valentine's Day even if we have to reject patches to do it. I would like to propose an additional stipulation on CF4 - namely, that we will reject out of hand any large patches that were not submitted to CF3. For the sake of definiteness, let's say that a large patch is anything whether diffstat run against the unified diff shows lines added + lines removed = 1000. I think this is important both for making sure that CF4 ends on time and also for making sure that we don't destabilize the tree too much late in the development cycle. Going further with that theme, I think that we should further agree that if, in the judgement of the relevant reviewers/committers, any given patch submitted for CF4 seems as though it may destabilize the tree in a way that will significantly prolong beta, or if the patch as submitted seems likely to need follow-on patches before the feature is release-worthy, we will punt it to 8.6. Obviously, these will be judgement calls, but I think it will be easier to make them if we state the ground rules and expectations up front. I'd also like to add that the decision should be made based on *having read the patch* rather than any theory about the relative value of the feature. We seem to have consensus on a time-based release, so let's try to release on time. I'd also like to propose that we schedule an open-items-fest for 3/15-4/14. My vision is that we'll try to make sure that we have a complete list of open items, including any that are lurking in the mailboxes of Tom, Bruce, or others, by 3/15. We'll ask for volunteers to address those open items. Then on 3/15 we'll dole them out and ask each person to come up with a proposed plan of action for the open item assigned to them and post it to -hackers. In some cases, closing the item may mean writing a patch, which we'll ask the volunteers to help with when possible (but sometimes it won't be), but at a minimum, the volunteers need to make sure that consensus on how to handle the item is reached, so that when someone who has the necessary coding-fu has time to put into it, they know what code they're supposed to be writing. Thoughts? ...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] Schedule for 8.5 Development
Robert, I would like to propose an additional stipulation on CF4 - namely, that we will reject out of hand any large patches that were not submitted to CF3. For the sake of definiteness, let's say that a large patch is anything whether diffstat run against the unified diff shows lines added + lines removed = 1000. I thought that we agreed it would be better just to give the CFM the authority to decide the too big issue, rather than a specific count of rows. Going further with that theme, I think that we should further agree that if, in the judgement of the relevant reviewers/committers, any given patch submitted for CF4 seems as though it may destabilize the tree in a way that will significantly prolong beta, or if the patch as submitted seems likely to need follow-on patches before the feature is release-worthy, we will punt it to 8.6. Obviously, these will be judgement calls, but I think it will be easier to make them if we state the ground rules and expectations up front. I'd also like to add that the decision should be made based on *having read the patch* rather than any theory about the relative value of the feature. We seem to have consensus on a time-based release, so let's try to release on time. Yes. I'd also like to propose that we schedule an open-items-fest for 3/15-4/14. Ok, great. That sounds terrific. BTW, it was my thought that we'd have more than one CFM for CF4. We'll need it. -- 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] Schedule for 8.5 Development
On Wed, Sep 2, 2009 at 9:31 PM, Josh Berkusj...@agliodbs.com wrote: Robert, I would like to propose an additional stipulation on CF4 - namely, that we will reject out of hand any large patches that were not submitted to CF3. For the sake of definiteness, let's say that a large patch is anything whether diffstat run against the unified diff shows lines added + lines removed = 1000. I thought that we agreed it would be better just to give the CFM the authority to decide the too big issue, rather than a specific count of rows. Hmm, I'm not aware that we have consensus on that particular issue. I feel that a cutoff is useful because introspecting the mind of the CFM can be difficult, but running diffstat is easy. I feel that we owe patch authors some kind of guidance so that, when they're thinking about developing a patch over their Christmas vacation, they have some idea whether it's likely to be unceremoniously punted. I do not like it when my patches are unceremoniously punted for any reason, and I think I'd be pretty peeved it if happened because someone felt that my patch was too big, without having first provided any guidance at all on what the definition of too big was. The rule I'm proposing may not be the right guidance, but I don't think it's good for our definition of a too-large patch to resemble Potter Stewart's definition of pornography. Going further with that theme, I think that we should further agree that if, in the judgement of the relevant reviewers/committers, any given patch submitted for CF4 seems as though it may destabilize the tree in a way that will significantly prolong beta, or if the patch as submitted seems likely to need follow-on patches before the feature is release-worthy, we will punt it to 8.6. Obviously, these will be judgement calls, but I think it will be easier to make them if we state the ground rules and expectations up front. I'd also like to add that the decision should be made based on *having read the patch* rather than any theory about the relative value of the feature. We seem to have consensus on a time-based release, so let's try to release on time. Yes. I'd also like to propose that we schedule an open-items-fest for 3/15-4/14. Ok, great. That sounds terrific. BTW, it was my thought that we'd have more than one CFM for CF4. We'll need it. It's not obvious to me why CF4 should require more CommitFest managers than any other CommitFest. But, by the same token, I am completely in favor of trying to better distribute the work associated with managing the CommitFests. We need to think about how to do that. In managing the July CommitFest, I found that the work divided itself up into two main phases. During the first phase, from approximately a week before the start of the CommitFest to about 5 days after the start, the activities were largely sequential, like this: 1. Sign up reviewers. 2. Make sure all patches were on the wiki. 3. Set reviewer expectations. 4. Assign initial patches for review. 5. Follow up with reviewers who failed to review. After that, there was a set of tasks that had to be continuously done in a loop: A. Update the status of patches on the wiki (because the patch authors and reviewers often didn't). B. Poke reviewers or patch authors who didn't respond in a timely fashion and/or move to Returned with Feedback. C. Assign new patches to reviewers who requested them. D. Send occasional status updates to -hackers. I think that the burden on the CM could be greatly reduced if patch authors and reviewers could try to make sure to do (A) and (B) themselves as much as possible. (C) and (D) are really not much work. ...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] Schedule for 8.5 Development
Robert, A. Update the status of patches on the wiki (because the patch authors and reviewers often didn't). B. Poke reviewers or patch authors who didn't respond in a timely fashion and/or move to Returned with Feedback. C. Assign new patches to reviewers who requested them. D. Send occasional status updates to -hackers. I think that the burden on the CM could be greatly reduced if patch authors and reviewers could try to make sure to do (A) and (B) themselves as much as possible. (C) and (D) are really not much work. Couldn't (B) be done by the app? If you recall, I suggested a while ago that the app ought to auto-email reviewers and authors after a few days of inactivity, and then alert you if they don't respond after a couple days more. Anyway, I can easily see dividing the duties of assigning patches to reviewers and keeping status updated. -- 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] Schedule for 8.5 Development
On Wed, Sep 2, 2009 at 10:22 PM, Josh Berkusj...@agliodbs.com wrote: Robert, A. Update the status of patches on the wiki (because the patch authors and reviewers often didn't). B. Poke reviewers or patch authors who didn't respond in a timely fashion and/or move to Returned with Feedback. C. Assign new patches to reviewers who requested them. D. Send occasional status updates to -hackers. I think that the burden on the CM could be greatly reduced if patch authors and reviewers could try to make sure to do (A) and (B) themselves as much as possible. (C) and (D) are really not much work. Couldn't (B) be done by the app? If you recall, I suggested a while ago that the app ought to auto-email reviewers and authors after a few days of inactivity, and then alert you if they don't respond after a couple days more. I think it needs a little more of a human touch than that. Beyond the fact that people tend to pay more attention to an email from a person than an automatically generated one, there's value in giving voice to the specific issues with that particular patch... It sounds like this needs too much reworking for this CF is different from Are you planning to update this patch based on so-and-so's review? which in turn is different from So-and-so, are you planning to do any additional review of this patch?. Anyway, I can easily see dividing the duties of assigning patches to reviewers and keeping status updated. I think it would be more valuable to divide up the task of keeping status updated, maybe by CommitFest topic. Assigning the patches is not very time-consuming. But on that note, one thing I tried to do (not sure how well I succeeded) last time is tried to match patches with reviewers both by patch topic and level of experience, with a bias toward getting large patches reviewed early. I found this to be one of the trickier parts of the whole project, because I obviously had to assign reviewers without having read most of the patches or with only limited knowledge of the capabilities and interests of the reviewers. Still, I must have done OK, because it worked out. What's unclear to me is how much value I added in the process, and how much better or worse things could have gone had I made different decisions. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
