Re: Schedule for 8.5 Development

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.

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

On Sep 2, 2009, at 4:42 PM, Josh Berkus wrote:

> CF3 11/15 to 12/14
> Alpha3 by 11/20

12/20?

David

On Wed, Sep 2, 2009 at 7:42 PM, Josh Berkus<josh(at)agliodbs(dot)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

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

On Wed, Sep 2, 2009 at 9:31 PM, Josh Berkus<josh(at)agliodbs(dot)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

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

On Wed, Sep 2, 2009 at 10:22 PM, Josh Berkus<josh(at)agliodbs(dot)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

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

I think that June release date is realistic.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

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

--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com

Josh Berkus wrote:
> 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
> >> 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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

On Fri, 2009-09-18 at 10:22 -0700, Josh Berkus wrote:
> 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
> >> 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.