Guilhem Bichot a écrit, Le 29.07.2010 16:23:
> Hello,
>
> I'd like to do a poll:
> do you think the post-push emails (automatically sent to
> commits@stripped when you do "bzr push") should be disabled
> for Server trees?
Some people replied that the push-mail was useless.
Some noted that such mail is useful to follow what is actually pushed,
or to verify what they pushed. Some noted that subscribing to Launchpad
notifications allowed to follow pushes.
What takes time, in the post-push trigger, is generating the "bundle"
(the attachment of the mail, which contains all info to recreate the
revision; it's more powerful than the diff which has problems with file
renames).
So the latest proposal, which is easy to implement, is:
- we keep sending post-push mails
- we don't include any bundle in the post-push mail; a bundle is not
needed, as the revision was just made available in the tree
- we limit the diff's size to 10,000 (no reason to generate huge diffs
which the mailing list will reject anyway, and which no one will read).
There is also a proposal for commit mails, which have the same slowness
problem:
- same diff size limit as above
- keep including a bundle, because it has proven to help complex reviews
(when files have been renamed and the diff doesn't apply), but include
it only if it won't contain more than 10 revisions (so that it's
guaranteed to not take long to generate). The idea is that when there is
a review, it's often a single revision which is committed. Reviewing a
merge is rare. In the event where developer A should review a huge merge
of developer B, A and B can always communicate so that B would
explicitely generate the bundle (with "bzr send") or push to a temporary
tree for A to branch.
Unless this meets opposition, I will implement this.
--
Mr. Guilhem Bichot <guilhem.bichot@stripped>
Oracle / MySQL / Optimizer team, Lead Software Engineer
Bordeaux, France
www.oracle.com / www.mysql.com
