[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.
Thanks,
Carl
- Re: markup-command and markup-command-list signatures, Boris Shingarov, 2010/05/02
- Re: markup-command and markup-command-list signatures, David Kastrup, 2010/05/03
- Rietveld review (was: markup-command and markup-command-list signatures),
Carl Sorensen <=
- Re: Rietveld review, David Kastrup, 2010/05/04
- Re: Rietveld review, Werner LEMBERG, 2010/05/04
- Re: Rietveld review, David Kastrup, 2010/05/04
- Re: Rietveld review, Reinhold Kainhofer, 2010/05/04
- Re: Rietveld review, David Kastrup, 2010/05/04
- Re: Rietveld review, Reinhold Kainhofer, 2010/05/04
- Re: Rietveld review, David Kastrup, 2010/05/04
- Re: Rietveld review, Carl Sorensen, 2010/05/04
- Re: Rietveld review, David Kastrup, 2010/05/04
- Re: Rietveld review, Carl Sorensen, 2010/05/06