FYI: Committing to trunk

Hi guys,
  This year there have been some changes to the fine details about
committing to trunk. I think it's time for a reminder about some of the
checklist to be done before committing. This covers just the bits where
we have all been making mistakes (me too) which impact the records.
Forcing me to manually tweak the visible changesets and/or touch your
commit messages on backports.

1)

You will be familiar with the initial Author: line.

   !! It is now multiple lines !!

When there are multiple authors. Each person who contributed code gets
their own individual "Author: " line.

These are used to auto-generate the CONTRIBUTORS.txt content and will be
used as contact with copyright holders when we need them.

  NP: The author may and sometimes does request omission of their
contact email details. This if fine, even retro-actively.

2)

The patch title.

  * These may be cut-n-pasted straight into the ChangeLog and the
release announcement, make it simple and clear please.

  * Brief. Somewhere around 80 char. I've found bzr displays a line of
"---" which can be used as a rough guide to aim for length.

  * please take some time to **thoroughly** check bugzilla for bugs
which you might be fixing or affecting. A lot of what we are changing
either fixes or obsoletes some bugs. Or makes some others need
re-testing for new details.

  * please only mention "bug" if there is an attributable number to
reference. Otherwise it is just a fix. We have a lot of those not
formally in bugzilla.

  * don't forget the new bzr "--fixes squid:NN" parameter. For every
single bug, even if you are closing half the open entries in bugzilla at
once.

  * If you do have a bug number please syntax the first bytes are "Bug
N: " not "bug fix N", "fix bug N:" etc
   - multiple bugs would be "Bug NN, Bug MMM: " from what I can see of
the scripts. Hopefully we don't have a lot of those.
   - Followed by the text of the bugzila title, if that bug title was
not clearly descriptive of the problem, please make it so as well.
   - It is assumed (by me and by changesets) to be a full fix unless
there is something like "partial" or "pt1" etc is mentioned.

  * If you are merging a larger feature which fixes a bunch of problems
in one sweeping. Please mention the bug numbers in the text even if you
decide its too many for the title.

3)

Sort of related, I've been watching launchpad slowly gather a long list
of branches which are not touched for very long times. Similar to what
happened on the CVS devel.* server.

Several of these are for features which have been merged already!
  I believe LP has a removal system for merged branches but have found
nothing helpful about it. At present it seems up to the branch owner to
mark the branch as finished with and schedule removal/deletion.

  Can you guys please check your branches there and drop the dead ones?

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.9
   Beta testers wanted for 3.2.0.3