On Fri, Sep 07, 2012 at 02:47:49PM +0200, Jan Nieuwenhuizen wrote: > Graham Percival writes: > > > Because this empirically did not work in the past for us. > > Possibly we can identify why and fix it.
Yes, hopefully. I apologize for the tone of my earlier email; I should have been more polite. > Did we ever have Git style patches sent to the mailing list as > official procedure? There is quite a difference between > attaching a patch to a mail with a dubious subject, or using a > Git patch with beautiful commit message one-liner directly as > email. Minor point here: the subject line of Reitveld messages is git one-line summary (issue 123456789) I agree that the Rietveld issue number is irrelevant, but the current "dubious subjects" come from the patches themselves, Random sample: Creates getter and setter functions for buildings bar-line interface part 2/2 Adds octavation-eight-interface to the Beam_collision_engraver Add support for Cyrillic in Texinfo/TeX Some of those are good; other subjects could use a bit of reworking to become "beautiful". :) This is something which we could (and should) improve regardless of the review tool -- any "dubious" messages will otherwise get into our git history. > > - patches get lost, especially from new contributors > > This is bad; however, with Git patches and an email client it is > > * easy to identify which are patches from the subject line > * easy to see whether a patch/email has gotten a reply Hmm. One of the things which I'm most proud of in the current setup is that there's a single place to see patches "in danger" of being pushed and which therefore require reviews within a day or two: http://code.google.com/p/lilypond/issues/list?can=2&q=patch%3Dcountdown As long as a reviewer checks that link 3 times a week, nothing will "slip past" them. There's also an email notification whenever that list changes. By contrast, lilypond-devel gets dozens of emails every day; it's easier for miss a patch email. Granted, additional features of an email client (be they filtering, automatically adding colour to emails beginning with [PATCH], etc) could help here. > We now have quite a system for contributing. Probably it fixes some > things. However, your survey found out that this is one of the major > sources of developer discouragement. Yes. We could really use an improved system. I'm hoping to improve the developer/git side of things (i.e. extending lily-git.tcl to handle multiple branches since new contributors and even some experienced developers are empirically not comfortable with git), but of course we should also discuss how we could improve the reviewer side of things as well. > What if, when adopting a linux kernel style email-patch strategy, > we add some guidelines (we have enough of them right now anyway) -snip list- That would place additional burden on patch submitters. This isn't necessarily a bad thing, particularly if we clearly documented the responsibilities. New contributors always get confused with our current system anyway, so we need to improve this part of the CG anyway. > This is all we need*, and much, much easier and friendlier than what we > have now. Indiscriptive, automatic emails with urls in them, that > you cannot reply to. Useless. Minor point: you _can_ reply to the Rietveld emails. For example, http://codereview.appspot.com/6501096/#msg3 was sent from email (mutt+vim+msmtp). Granted, the emails do not contain the actual diffs, but if you have a comment based on the patch description or based on the other comments+discussion, just hit "reply to all" in your email client. Cheers, - Graham _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
