On Sat, Feb 28, 2009 at 04:56:55PM -0600, Chris Dolan wrote: > On Feb 28, 2009, at 11:07 AM, Patrick R. Michaud wrote: >> On Sat, Feb 28, 2009 at 10:46:10AM -0600, Andy Lester wrote: >>> On Feb 28, 2009, at 10:29 AM, Patrick R. Michaud wrote: >>>> So, for the time being Rakudo's official policy will be to >>>> accept patch submissions via RT. I've now cleared the fork queue >>>> on GitHub; any patches that were previously there need to be >>>> resubmitted. >>> >>> My understanding is that this is bad for everyone else, because it >>> loses the changeset history by making your committed patch >>> different than the accumulated changesets that you're applying. >>> [...] > > Based on my experience watching the Linux kernel development process via > git, I think both Andy and Patrick are partially right. An important > point is that git optimizes for scalability of the project leadership.
Agreed; this was one of the (many) reasons I also decided to make the jump to git. > [...] reviewing false starts is an big waste of time > for project leaders, who may already be bottlenecks for a project. The > Linux dev process insists that submitters do this: > 1) fork a trunk point > 2) do work on a branch, which may include false starts > 3) if the work is more than one commit: > a) make a new clean branch > b) manually rebuild the patch as a series of commits handling > separate concerns > c) ask upstream to pull that optimized branch > 4) submitter deletes dev branch which included the false starts > > This process means the submitted branch/patches represents a fictitious > optimal development, as if the programmer were perfect and made no false > starts along the way. That means more work for the submitter of a > complicated patch, but sometimes raising the bar is not a bad thing. Agreed. And I don't think it's important that Rakudo's patch history contain _all_ of the false starts made and subsequently corrected by an individual developer. I'd much prefer to see it as fictitious optimal development. So, I think what we really need is a good guide describing how submitters can create the "optimized" branches for the maintainers to pull from. > On the other hand, if the submitter thinks the patch is awesome but the > reviewer thinks it needs a little work, that's a bit harder because the > reviewer needs to do one of the following: > 1) branch and fix > a) make a branch > b) pull the submission > c) edit > d) commit > 2) edit the patch as text and commit > 3) reject the patch back to the submitter > Option #2 is the easiest but the worst because it loses attribution. #3 > happens the quite often in the Linux kernel process. We should not view > rejection as rude, but as necessary for a good code base. In general I'm in favor of #3 as well; I think that rejecting patches (with explanation and suggestions for improvement) is another really good mechanism for raising the quality of code and process. I don't find #1 to be too much work either, since it's easy to do local edits and commits before pushing them to rakudo/master. > All that said, I have not studied the git best practices for reviewing > submissions. I strongly suspect that there's lots more we can learn > from Linux. Agreed. And thank you very much for this thoughtful and helpful message, it really helps to clarify some of my thinking on the topic. Pm
