gerrit [was: minutes of ESC call ...]

On Thu, Jul 12, 2012 at 04:55:50PM +0100, Michael Meeks wrote:

> * gerrit update (David / Bjoern)
>       + can we have the patch in the 'new change' mail (Lionel)
>               + would be nice !
>       + two ways to do mailing - better to move to using stream object
>         and generate our own mails (Bjoern)
>               + change templates on server-side; would affect all
>                 subscribing to a watched project.

This was said in the context of "can we have the patch in the 'new
change' mail". Frankly, if I subscribe to a watched project, I'd like
to get the patch in my personal email, too; not only in the dev ML
mail.

So personally, we can change the templates server-side, wouldn't
bother me, quite the contrary.

>       + lots of supposed / bogus patch inter-dependency
>               + multiple commits when pushed are marked dependent,
>                 even if they are not etc.

I kinda understand where that's coming from, but frankly I find that
too strict / restrictive from gerrit's part; if the patches commute
purely on basis of "do not touch the same lines" (one applies cleanly
without the other), then just make them "independent". Yes, might miss
"semantic dependencies" like "added a function in a .hxx" in one
commit and "use that function" in another commit. But in case of
doubt, err on the side of *not* annoying the user.

>               + please use the './logerrit nextchange' tool to ensure
>                 separate patches stay separate.

This "resets --hard" my local branch. Bleh. My local branch should be
treated as a "queue" of patches I want to have in this branch, and
that are not there yet. Don't force me to meddle with my local queue,
just handle it reasonably:

 1) Easy way to push just _one_ commit (from the middle of the queue,
    obviously, else where's the fun) to gerrit.

 2) Also an easy way to push my whole queue. (That's what gerrit does
    now when I push my top ref.)

 3) When I repush my queue, recognise that I didn't change anything
    (except rebasing with changes that came in since then, thus new
    commit timestamp) and don't create a new patch set, and don't
    respam the reviewers.

    If I changed one or several of the commits, *then*, OK, do the
    "new patch set, mail reviewers" thing.

-- 
Lionel