Re: Rietveld workflow problems

[David Kastrup]

"address@hidden" <address@hidden> writes:

> On Sep 21, 2011, at 10:27 AM, David Kastrup wrote:
>
>> Just wanted to throw this observation out: the current work on optional
>> arguments is one area where working with Rietveld is getting really
>> strained.  The reason is that Rietveld just supports discussing and
>> improving a single patch/commit.
>> 
>> The current patch series consists of one infrastructure patch (allowing
>> pushing tokens with values) and "the rest".
>> 
>> But there are about five different other (co-developed) infrastructure
>> patches that the whole depends on.  Making those independent issues
>> would mean that you could not apply the main Rietveld patch to
>> origin/master and check it out.
>> 
>> So my workflow when on a larger Rietveld-reviewed patch like this
>> consists of silently pushing required infrastructure/cleanup patches
>> without discussion or review in order to keep origin/master in a state
>> where one can meaningfully discuss the large single patch on top without
>> getting side-tracked in unrelated issues.
>> 
>> That's not really pretty.
>
> For what it's worth, I run into the same problem from time to time - I
> recently sent an e-mail to the list about a 1-line patch to fix kneed
> beams that I needed to apply for other work.  Ditto for a
> variable-name changing patch.  I think that if it is really
> infrastructure / clean-up / small, then if you send an e-mail to the
> list with a heads up and nobody complains within 12ish hours (and/or
> if you get a "LGTM"), then it is OK to push.  The definition of
> infrastructure / clean-up / small is, of course, up for debate, but I
> think that people have a pretty good sense of what needs review and
> what doesn't.

It decouples the large patch from master/discussion for 12ish hours.
Per small change.  That breaks the stride.  Now the usual function of
review is a byproduct: it should not brake the usually sole developer
from continuing work on the functionality, but keep others informed and
able to check out his work and contribute.  Review procedures should
never block development, it should aid it.  The only blockage that is
acceptable is the decision about when to merge the completed work into
master.

"I can't do anything until" is bad.  "This depends on x" also is bad.
What we want, I think, is being able to pull a branch, or at least apply
a patch _series_ (in a manner where already applied patches in the right
order will get skipped, like git am does IIRC).

Perhaps it would be nice if we found a way to play with "Gerrit",
supposedly a git-based system similar to Rietveld.

-- 
David Kastrup