Re: [Python-Dev] notifications form Hg to python-checkins
On Wed, Jul 14, 2010 at 5:56 AM, Éric Araujo <merwok@netwok.org> wrote:
I was actually going to suggest something along those lines post transition, since Hg will have an email address for everyone - leave push notifications coming from the bot (so existing filters based on the bot address keep working), but include the push author in the reply-to field.
IIRC, you can’t know who pushed without kludgy hackery. Also, the one to push is not necessarily the author of the commit(s). If that was just a braino and you meant setting the committer as reply-to, it seems a good idea.
No, I meant push. There's a separate discussion where it was pointed out that publishing each commit as a separate email makes python-checkins even chattier than it is already (this point came up after Tarek pushed a distutils2 changeset containing ~100 separate commits), so the suggestion was made to combine all commit notifications for a given push into a single email. However, I don't remember if that idea was suggested specifically to Dirkjan as a change to the notification email. If not, I'm suggesting it now :) Note that the current distutils2 emails to python-checkins already say "Tarek Ziade pushed..." and then include the committer details inside the email, and that's what we want - the developer pushing the change into the central repository is always going to be one of the core devs, but the original creator of the change set could have been anyone. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Tue, Jul 13, 2010 at 23:22, Nick Coghlan <ncoghlan@gmail.com> wrote:
No, I meant push. There's a separate discussion where it was pointed out that publishing each commit as a separate email makes python-checkins even chattier than it is already (this point came up after Tarek pushed a distutils2 changeset containing ~100 separate commits), so the suggestion was made to combine all commit notifications for a given push into a single email. However, I don't remember if that idea was suggested specifically to Dirkjan as a change to the notification email. If not, I'm suggesting it now :)
As I recall, that's what I first implemented, but it was shot down by some of the committers... anyway, I'd be happy to change it back. Cheers, Dirkjan
On Wed, Jul 14, 2010 at 7:45 AM, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
On Tue, Jul 13, 2010 at 23:22, Nick Coghlan <ncoghlan@gmail.com> wrote:
No, I meant push. There's a separate discussion where it was pointed out that publishing each commit as a separate email makes python-checkins even chattier than it is already (this point came up after Tarek pushed a distutils2 changeset containing ~100 separate commits), so the suggestion was made to combine all commit notifications for a given push into a single email. However, I don't remember if that idea was suggested specifically to Dirkjan as a change to the notification email. If not, I'm suggesting it now :)
As I recall, that's what I first implemented, but it was shot down by some of the committers... anyway, I'd be happy to change it back.
Having seen the per-commit approach in action, I'd personally like it changed back to per-push notifications, but you may want to start a thread on python-committers about it (given the number of tangents it has spawned, I wouldn't be surprised if a lot of people have stopped following this discussion by now). My rationale is as follows: - for small changesets with only one or two changes, per-push or per-commit emails don't make much difference - for large changesets, per-commit can be very noisy (as Tarek's 100+ notifications showed) while per-push stays the same I seem to have a vague recollection of the discussion you mention - do you remember if the specific objection was to a lack of a list of filenames affected in the subject line for the old per-push emails? Listing all the files affected by the push in the subject line would definitely still be desirable. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Am 14.07.2010 00:00, schrieb Nick Coghlan:
On Wed, Jul 14, 2010 at 7:45 AM, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
On Tue, Jul 13, 2010 at 23:22, Nick Coghlan <ncoghlan@gmail.com> wrote:
No, I meant push. There's a separate discussion where it was pointed out that publishing each commit as a separate email makes python-checkins even chattier than it is already (this point came up after Tarek pushed a distutils2 changeset containing ~100 separate commits), so the suggestion was made to combine all commit notifications for a given push into a single email. However, I don't remember if that idea was suggested specifically to Dirkjan as a change to the notification email. If not, I'm suggesting it now :)
As I recall, that's what I first implemented, but it was shot down by some of the committers... anyway, I'd be happy to change it back.
I think I was one of the "shooters" :)
Having seen the per-commit approach in action, I'd personally like it changed back to per-push notifications, but you may want to start a thread on python-committers about it (given the number of tangents it has spawned, I wouldn't be surprised if a lot of people have stopped following this discussion by now).
My rationale is as follows: - for small changesets with only one or two changes, per-push or per-commit emails don't make much difference
True.
- for large changesets, per-commit can be very noisy (as Tarek's 100+ notifications showed) while per-push stays the same
I assume you mean large pushes, consisting of tens of changesets? In this case, I see several problems with a single email: * it can get huge, and therefore a pain to load, and view in mail clients * it's needlessly clumsy to reply to single changes, since you have to go and delete the thousands of lines inbetween * there's no indication of what was pushed in the subject I also don't think we will see pushes like Tarek's 100+ one very often for Python. Usually changes will be bug fixes, and unless the committer is offline I expect them to be pushed immediately.
I seem to have a vague recollection of the discussion you mention - do you remember if the specific objection was to a lack of a list of filenames affected in the subject line for the old per-push emails? Listing all the files affected by the push in the subject line would definitely still be desirable.
No, I think we agreed to put the (first line of the) commit message there, which I think tells potential reviewers much better if they want to look at that changeset. Georg
On Wed, Jul 14, 2010 at 10:15, Georg Brandl <g.brandl@gmx.net> wrote:
I also don't think we will see pushes like Tarek's 100+ one very often for Python. Usually changes will be bug fixes, and unless the committer is offline I expect them to be pushed immediately.
Depends. If we do feature branches in separate clones, the merges for those can potentially push large numbers of csets at once. Presumably, we could push some more complexity into the hook, and have it send emails per-group for groups of 5 and larger and per-cset for smaller groups.
No, I think we agreed to put the (first line of the) commit message there, which I think tells potential reviewers much better if they want to look at that changeset.
Not sure there was actual consensus on that, but I still stand behind this point. Cheers, Dirkjan
On 14 July 2010 18:26, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
On Wed, Jul 14, 2010 at 10:15, Georg Brandl <g.brandl@gmx.net> wrote:
I also don't think we will see pushes like Tarek's 100+ one very often for Python. Usually changes will be bug fixes, and unless the committer is offline I expect them to be pushed immediately.
Depends. If we do feature branches in separate clones, the merges for those can potentially push large numbers of csets at once.
Presumably, we could push some more complexity into the hook, and have it send emails per-group for groups of 5 and larger and per-cset for smaller groups.
No, I think we agreed to put the (first line of the) commit message there, which I think tells potential reviewers much better if they want to look at that changeset.
Not sure there was actual consensus on that, but I still stand behind this point.
If development work was done in named branches, the hook could send one email per branch that was delivered, and to be safe, one email per changeset added to a main feature branch.
Tim Delaney
[Nick]
[me]
IIRC, you can’t know who pushed without kludgy hackery.
[...] Note that the current distutils2 emails to python-checkins already say "Tarek Ziade pushed..."
I looked at mail.py in the hooks repository and learned that hooks get an HGPUSHER variable in their environment. Nice! Regards
participants (5)
-
Dirkjan Ochtman -
Georg Brandl -
Nick Coghlan -
Tim Delaney -
Éric Araujo