How I Patch Piloted lately and some tricks about merge proposals

[Vincent Ladeuil]

Hi all,

I've been the patch pilot for this ending week and caught up the
week before... after we realize we were missing a pilot ;)

The good news is that no plane crash were reported.
The bad news is that our queue grew a bit.

It is now under control again and quite short. Congratulations to
all parties involved !

  https://code.edge.launchpad.net/bzr/+activereviews

I had the pleasure to see several new contributors while old
contributors have kept sending merge proposals.

The flight was even more enjoyable than the previous one thanks
to a larger participation of other reviewers on many proposals.

I also had a look on the hidden part of the merge proposals (the
ones that has been reviewed but still need to be worked on):

  https://code.edge.launchpad.net/bzr/+merges?field.status=WORK_IN_PROGRESS&field.status-empty-marker=1

While not as short as our activereviews page, it's nice to see
that many subjects will still be landed soon.

I encourage all people mentioned there to update their proposals
if only to ask for more help.

Martin mentioned in another mail 'bugs with patches', again, if
you attached a patch to a bug, please turn it into a real branch
and do a merge proposal, it's too easy for such patches to get
lost and far easier to get feedback by the patch pilot via the
merge proposals.

And while I'm on asking favors, doc/developers/HACKING.txt has
been updated to give some clues about branch names (see Making a
Merge Proposal). It's lovely to see people willing to give back
and follow the (old) advice to name their branch 'giveback', but
more and more people are doing it and while we fully appreciate
the intent, using a name giving an hint on the submission content
doesn't hurt. Also, many people agree that, when the branch is
fixing a bug, this bug number must be part of the branch
name. The important bit here is *part*, please add a very succinct
description of the content too, who (except John but he's
cheating) can remember what a bug is about from the number only ?
Whether you put the bug number at the beginning or at the end is
still open :-)

But think a bit about it when you submit a merge proposal, that
branch name will be mentioned again and again in discussions and
it really helps everybody involved to understand what it's about.

And remember that bzr will... remember that push location so if
you need to amend your proposal you'll only have to use 'bzr
push'. 

Also, keep in mind that you don't need to make a new merge
proposal when you take review comments into account. Pushing your
new revisions to the same branch will both update the diff
associated to the proposal *and* insert a comment containing your
commit message(s). In addition, clicking on the revision number
in these comments gives access to the diff of this revision, so
there is no need to put incremental diffs in the comments either.

         Vincent