[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Carl Sorensen
Subject: Rietveld review (was: markup-command and markup-command-list signatures)
Date: Mon, 3 May 2010 17:29:31 -0600

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]