On 5/3/10 1:02 AM, "David Kastrup" <d...@gnu.org> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
