Re: Schedule for 8.5 Development

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