Rietveld review (was: markup-command and markup-command-list signatures)

[Carl Sorensen]

On 5/3/10 1:02 AM, "David Kastrup" <address@hidden> wrote:

> 
> I don't see that you stand a chance with the standard processes here.
> You don't have commit access.  The gold standard here (to the exclusion
> of all other workflows) is a patch review on Rietveld.  That basically
> limits feedback to persons with a Google developer account.

I don't have a Google developer account.  I did need to use a gmail account.
So yes, if you want to comment, you need to have some kind of google
account.  But I didn't find it difficult to establish a gmail account and
have that account forward mail to my standard email address.

> At the
> point of acceptance, the change is pulled in as a single commit touching
> lots of areas simultanously.  Since mainline development continues,
> there is no sensible strategy for merging/rebasing for anybody without a
> branch history.  So the only person able to work on this will be
> yourself.  People will be able to check your work only when the patch
> set applies.  But that means that mainline changes in the same areas
> need to be tracked by you and will also pollute the Rietveld review
> area.

Mainline changes don't need to pollute the Rietveld review area.  The post
to Rietveld is in the form of a git diff, and you are free to specify any
commit as the head point for the diff.  It's pretty simple to do the work in
git, and merge/rebase with the main tree as necessary, and use git-cl to
upload the diff of where your branch diverges from the main branch.  I
haven't had problems with this is the past.  I'm not saying they don't exist
(it's impossible to prove a negative), but in my experience the system works
pretty well.

> 
> I don't see that a task like this can be sensibly done except in a
> separate branch.  But working like that is a git workflow rather than a
> Subversion one, and does not fit with the Rietveld processes.  Of course
> you can set up your own Lilypond repository for pulling, but the way I
> see it, the relevant developers would refuse to participate in
> "non-standard" processes like that.

In the past we have had developers with an individual branch hosted on
Savannah that were not part of the main tree; we didn't find them useful.
Why do you need to "set up your own Lilypond repository for pulling"?  Why
not just create a branch in your local repository and go ahead and do the
rebase/merge as necessary?

> 
> I don't see that humongous changes like that can be usefully integrated
> in a single non-merge commit.

I don't understand this emphasis on "a single non-merge commit".  If you
want to propose a patch set that requires multiple commits, you can do so.
It won't show up on Rietveld that way, but you can email a patch as a series
of commits leading of the main trunk.

> There must be infrastructure changes and
> so on, and you'll need to set up reviews for each of them, without an
> apparent goal being accomplished before the last commits make it.
> 

I agree that this can be an issue.  Infrastructure changes that are not
needed are asked to be postponed until the need is apparent.  But they're
not rejected.


> Basically you'll be on your own going against the tide until you are
> finished.  The work flows here are designed to achieve code quality by
> making it harder for a would-be contributor to get sub-par code through,
> not by making others participate with the work.

I think this is an interesting comment.  Do you believe that it would be
preferable to let sub-par code through?  Or do you believe that there are
other workflows that would be as effective at blocking sub-par code but
would be more inviting to a new contributor?

This is a serious question I'd like to ask you.  If you were the king of
LilyPond, what would you establish as the workflow?  I'd really like to hear
your opinion.

Thanks,

Carl