Mercurial mail flood

[Mark Wielaard]

Hi all,

That mercurial mail flood on distro-pkg-dev was the result of Andrew's
hard work merging all the icedtea6 changes into icedtea[7] and upgrading
to openjdk b26. Apologies for not realizing in time that this would
replay all of the history (since February!) and generated 287 emails
(urgh). [*]

I'll try and change the scripts so they bundle the commits of one push.
This is what some other openjdk mailinglists seem to do. Although the
actual patches are lost then from the email. Are the mercurial scripts
for those other lists available somewhere?

Thanks and sorry for the spamming,

Mark

[*] Currently we use:

[hooks]
incoming.notify = python:hgext.notify.hook

[notify]
sources = serve push pull bundle
test = False
maxdiff = 500

[usersubs]
## key is subscriber email, value is comma-separated list of glob patterns
# We don't want notification of /hg/testrepo, so not included. openjdk
# overrides maxdiff to not send any diffs. The others use the default above.
distro-pkg-dev@... = /hg/fedora,/hg/icedtea,/hg/icedtea6,/hg/openjdk,/hg/icepick,/hg/brandweg

[Mark Reinhold]

> Date: Thu, 29 May 2008 23:31:46 +0200
> From: Mark Wielaard <mark@...>

> That mercurial mail flood on distro-pkg-dev was the result of Andrew's
> hard work merging all the icedtea6 changes into icedtea[7] and upgrading
> to openjdk b26. Apologies for not realizing in time that this would
> replay all of the history (since February!) and generated 287 emails
> (urgh). [*]

Nice work, but yeah -- that was an awful lot of email ...

> I'll try and change the scripts so they bundle the commits of one push.
> This is what some other openjdk mailinglists seem to do. Although the
> actual patches are lost then from the email. Are the mercurial scripts
> for those other lists available somewhere?

We're using a custom notify script for the OpenJDK repositories.  We
can't publish it just yet -- it's in the same lawyer-wait state as the
jcheck extension.  (I expect that to be resolved in, at most, the next
six weeks.)

Personally I view the inclusion of patches in Mercurial notifications as
a distraction unless they're very short, but I know that opinions differ
on this.

- Mark

[Matthias Klose-6]

Andrew John Hughes schrieb:

> 2008/5/30 Mark Reinhold <mr@...>:
>> Personally I view the inclusion of patches in Mercurial notifications as
>> a distraction unless they're very short, but I know that opinions differ
>> on this.
>>
>> - Mark
>>
>
> Well, for me, it depends on whether the patches have been published on
> a list prior to the commit.
> With Classpath, we've never had patches in the mails; the commit
> message and links to the diffs
> on CVS appears.  The patches are posted separately to a separate list.
>  In contrast, I've found some
> of the icedtea commits useful to read, because that's the only place
> I've seen the change.  But these
> seem to be truncated if they go over a certain length and generated
> files in the repository isn't helping
> this.  So I'd tend to agree that very short easily digestable ones are
> fine in the commits (see Lillian's recent minor
> IcedTea changes for the release) but that larger patches should be
> attached in a separate mail and (dare I say it) on a
> separate list.

Could we establish a policy not to redirect the commit messages to the ML, but
instead require a manual posting of a patch (excluding generated files),
together with a short rationale why the patch is applied and what it is supposed
to fix? Should make it easier to track the history of patches. This information
might be in some bug tracker, but probably not in the IcedTea tracker. Having
this information in one place on the ML would be helpful.

  Matthias

[Roman Kennke-2]

Hi there,

> Could we establish a policy not to redirect the commit messages to the
> ML,

My point of view is that none of these should be sent to the lists, who
is interested in reading all the commit messages can subscribe to the
RSS feed, for example:

http://icedtea.classpath.org/hg/icedtea/rss-log

Same for the other -dev lists (althougt, they don't have so much HG
related traffic, probably because they don't post single commits, but
aggregate everything from a push (or so).

/Roman

--
http://kennke.org/blog/

[gnu_andrew]

2008/5/30 Matthias Klose <doko@...>:

> Andrew John Hughes schrieb:
>> 2008/5/30 Mark Reinhold <mr@...>:
>>> Personally I view the inclusion of patches in Mercurial notifications as
>>> a distraction unless they're very short, but I know that opinions differ
>>> on this.
>>>
>>> - Mark
>>>
>>
>> Well, for me, it depends on whether the patches have been published on
>> a list prior to the commit.
>> With Classpath, we've never had patches in the mails; the commit
>> message and links to the diffs
>> on CVS appears.  The patches are posted separately to a separate list.
>>  In contrast, I've found some
>> of the icedtea commits useful to read, because that's the only place
>> I've seen the change.  But these
>> seem to be truncated if they go over a certain length and generated
>> files in the repository isn't helping
>> this.  So I'd tend to agree that very short easily digestable ones are
>> fine in the commits (see Lillian's recent minor
>> IcedTea changes for the release) but that larger patches should be
>> attached in a separate mail and (dare I say it) on a
>> separate list.
>
> Could we establish a policy not to redirect the commit messages to the ML, but
> instead require a manual posting of a patch (excluding generated files),
> together with a short rationale why the patch is applied and what it is supposed
> to fix? Should make it easier to track the history of patches. This information
> might be in some bug tracker, but probably not in the IcedTea tracker. Having
> this information in one place on the ML would be helpful.
>
>  Matthias
>

+1
--
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

[Mark Wielaard]

Hi,

On Fri, 2008-05-30 at 12:43 +0100, Andrew John Hughes wrote:

> 2008/5/30 Matthias Klose <doko@...>:
> >
> > Could we establish a policy not to redirect the commit messages to the ML, but
> > instead require a manual posting of a patch (excluding generated files),
> > together with a short rationale why the patch is applied and what it is supposed
> > to fix? Should make it easier to track the history of patches. This information
> > might be in some bug tracker, but probably not in the IcedTea tracker. Having
> > this information in one place on the ML would be helpful.
>
> +1

It seems a good policy (especially the excluding generated files part)
IF this is done for all patches/commits, even those which some might
find trivial.

The reason I like having the commit messages including the actual
patches is because only then do I really have a good overview of what is
going into the tree. If people would actually post each and every patch
that they commit then that would obviously be enough.

And we could then use the rss feed to track and match posted patches to
what actually goes in. For those hating rss and having to be always
online (like me) we could install rss2email.

Cheers,

Mark

[jonathan.gibbons]

For my part, I dislike the messages going to all the -dev aliases for  
an integration area
if only because it clogs up the mail archives. When I put back changes  
to TL, the same
announcement goes to 4 separate mailing lists, including 3 -dev  
aliases, and is archived
in each of those mail archives. I know disk is cheap, but ....

I still think that this would be better with either RSS or mail to a  
list that is specific to an
integration area.

-- Jon

On May 30, 2008, at 5:06 AM, Mark Wielaard wrote:

> Hi,
>
> On Fri, 2008-05-30 at 12:43 +0100, Andrew John Hughes wrote:
>> 2008/5/30 Matthias Klose <doko@...>:
>>>
>>> Could we establish a policy not to redirect the commit messages to  
>>> the ML, but
>>> instead require a manual posting of a patch (excluding generated  
>>> files),
>>> together with a short rationale why the patch is applied and what  
>>> it is supposed
>>> to fix? Should make it easier to track the history of patches.  
>>> This information
>>> might be in some bug tracker, but probably not in the IcedTea  
>>> tracker. Having
>>> this information in one place on the ML would be helpful.
>>
>> +1
>
> It seems a good policy (especially the excluding generated files part)
> IF this is done for all patches/commits, even those which some might
> find trivial.
>
> The reason I like having the commit messages including the actual
> patches is because only then do I really have a good overview of  
> what is
> going into the tree. If people would actually post each and every  
> patch
> that they commit then that would obviously be enough.
>
> And we could then use the rss feed to track and match posted patches  
> to
> what actually goes in. For those hating rss and having to be always
> online (like me) we could install rss2email.
>
> Cheers,
>
> Mark
>