Re: [jgit-dev] submitting jgit proposals (too) fast

[Shawn Pearce <spearce@xxxxxxxxxxx>]

On Fri, Mar 11, 2011 at 07:46, Christian Halstrick
<christian.halstrick@xxxxxxxxx> wrote:
> I see that it happened now multiple times (e.g.
> http://egit.eclipse.org/r/#change,2635 or ...,2564) to multiple
> developers that proposals in jgit/egit have been merged sooner as the
> author expected it. It happens quite seldom, but sometimes proposals
> get submitted before everybody hat a chance to react on them
> ("reviewers are not fast enough"). And in other occasions a developer
> really wants and expects some comments but the proposal gets too early
> submitted ("developer couldn't express that he needs feedback"). Don't
> get me wrong: I really like that somebody looks at our open proposals
> and submits what's good enough - that's good for some/most of our
> proposals and increases our overall speed.
>
> But I think we need some rules to allow that
> a) everybody get's a chance to do a review in time and
> b) a developer can express that he expects comments
>
> Are there any best practices of other projects which solve this? Some
> kind of minimum time a non-trivial proposals should stay in review
> (or: before I submit a proposal where there is already another
> reviewer I wait at lest 24hours after the last patchset).

I think this is reasonable, given the timezone differences between all
contributors, you really need to let something stand for *at least* 24
hours in order to ensure everyone had a chance to see their email
during normal waking hours in their timezone.

But worse, I don't check email on the weekends. So if a change comes
in mid-day Friday PST time, odds are I won't see it for about 3 days
until Monday morning PST time. It slows down the project's progress,
sure, but it would be nice if I have a chance to see some changes
before they go in. All too often I'm commenting *after* the change was
already submitted, and then we're playing catch-up in another change.

24 hours might be sufficient during the work-week for most people. But
I really need 3 days on the weekends. FWIW, I think C Git tends to let
patches exist on the list for about 2 days before it merges down to
"next", where it lives for about 2 weeks before it merges to "master".
This is a harder workflow to manage with Gerrit Code Review, the tool
wasn't built for that sort of workflow. But it does give the
distributed community a longer time to review and provide useful
comments.

> Or a rule
> that authors should vote (-2) on their proposals if they are not sure
> whether they are ready for submit.

Yes.

IMHO, if an author wants feedback but doesn't want it submitted yet,
upload with "RFC" as the start of the subject. Such changes are
clearly not submittable, the commit message is useless. This style
does require a final amend to strip out the RFC tag, but this should
be easy for a reviewer to re-review on the final patch set, as there
would be likely no differences relative to the prior patch set, except
the update of the commit message.

If the author really doesn't want to submit the change, they should
use -2 to block it. That way only the author can release the change by
rescoring it with a non-negative score.

-- 
Shawn.