Re: gerrit - does it allow writing commits using a web interface?

[Graham Percival]

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