Sending diffs of `elpa' to the respective maintainers

Sending diffs of `elpa' to the respective maintainers

[Stefan Monnier]

A while ago I mentioned that I think it's important to setup some email
filter that will automatically send a copy of the emacs-elpa-diffs email
to the maintainer of the corresponding package.

Has anyone had time to look into that?  If not, could someone take on
that task?

It shouldn't be that hard: maintain a small table matching files to
maintainer's email addresses, and then filter the email from
emacs-elpa-diffs and redirect them as appropriate.

The same could be done for Emacs's bundled packages, but the
maintainership there is often a mot more murky, so I'd rather limit it
to `elpa' for now (where we should enforce that every package comes with
a "maintainer email address").


        Stefan

Re: Sending diffs of `elpa' to the respective maintainers

[Stefan Monnier]

> It shouldn't be that hard: maintain a small table matching files to
> maintainer's email addresses, and then filter the email from
> emacs-elpa-diffs and redirect them as appropriate.

BTW, the same script could probably detect when a new package is
installed and post a corresponding announcement on gnu.emacs.sources.


        Stefan

Re: Sending diffs of `elpa' to the respective maintainers

[Stefan Monnier]

> Has anyone had time to look into that?  If not, could someone take on
> that task?

Ping!


        Stefan

Re: Sending diffs of `elpa' to the respective maintainers

[Bastien]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> Has anyone had time to look into that?  If not, could someone take on
>> that task?
>
> Ping!

Double-ping!  

See my not-so-different request in my last email: sending diffs 
related to a module (say, Org) to the maintainer of the module.

-- 
 Bastien

Re: Sending diffs of `elpa' to the respective maintainers

[Glenn Morris]

Stefan Monnier wrote:

> Ping!

Just in case you think no-one is listening, I might look at this after
24.1 is released. But the latter seems more important to me.

(A python fan could probably write a bzr plugin for this.)

Re: Sending diffs of `elpa' to the respective maintainers

[Glenn Morris]

Glenn Morris wrote:

> (A python fan could probably write a bzr plugin for this.)

For more details, see
http://doc.bazaar.canonical.com/development/en/user-guide/hooks.html

I was thinking of a post_pull hook. Presumably (...) these can access
the list of modified files brought in by a pull, compare the file names
against an external file that maps elpa packages to maintainers, and
send out a "your file has changed" notice. Then someone with a checkout
of the Emacs elpo repo could run bzr pull via cron.

An alternative is to write something that parses the "modified" section
of an emacs-diffs email to extract the file names, then does the same
thing. Invoked via procmail or whatever.

Re: Sending diffs of `elpa' to the respective maintainers

[Glenn Morris]

I added something for this to the elpa admin/ directory; have a look.
I could easily run it from my procmailrc on fencepost, but perhaps it
would be better to use a dedicated account on elpa.gnu.org.
It needs to be subscribed to the elpa-diffs mailing list, and to have a
procmailrc of the form given in the script's commentary. Also, you
probably want to add more lines to maintainers.txt (don't know if you
want it to be opt-in or opt-out).

Re: Sending diffs of `elpa' to the respective maintainers

[Stefan Monnier]

> I added something for this to the elpa admin/ directory; have a look.

Thanks.  Sounds like a good start.  It would be good to change it so it
manages the maintfile itself.  Or else couple it with a cron job that
builds the maintfile.

> I could easily run it from my procmailrc on fencepost, but perhaps it
> would be better to use a dedicated account on elpa.gnu.org.

elpa.gnu.org sounds like a natural choice, indeed.

> Also, you probably want to add more lines to maintainers.txt (don't
> know if you want it to be opt-in or opt-out).

Definitely "opt-out".  And a missing maintainer data should be treated
as an error (i.e. tho I guess it would be the cron job's duty to
detect/handle it).  I.e. we need to distinguish "missing maintainer
data" from "maintainer decided not to want it".
I'd guess the "opt-out" would be a separate list of "opt-out email
addresses".


        Stefan

Re: Sending diffs of `elpa' to the respective maintainers

[Glenn Morris]

Stefan Monnier wrote:

> It would be good to change it so it manages the maintfile itself. Or
> else couple it with a cron job that builds the maintfile.

That's easily done. Just need a thing that parses packages/*.el for
"Maintainer" or "Author" headers. I suggest doing it via cron, so that
it is not necessary to scan all packages on every commit. Need to watch
for changed addresses though, and need to undo any address munging
people might have used (or require them not to do so). The only issuse I
see is if a new package is installed and then a change is committed very
soon after, before the maintfile gets updated. Maybe updating the
maintfile should be part of the process of installing a new package.

Maybe someone on this list will feel inspired to write this piece...

> as an error (i.e. tho I guess it would be the cron job's duty to
> detect/handle it).  I.e. we need to distinguish "missing maintainer
> data" from "maintainer decided not to want it".
> I'd guess the "opt-out" would be a separate list of "opt-out email
> addresses".

I'd suggest just commenting out the relevant line in the maintainers
file.

Re: Sending diffs of `elpa' to the respective maintainers

[Stefan Monnier]

>> It would be good to change it so it manages the maintfile itself.
>> Or else couple it with a cron job that builds the maintfile.
> That's easily done. Just need a thing that parses packages/*.el for
> "Maintainer" or "Author" headers.  I suggest doing it via cron, so that
> it is not necessary to scan all packages on every commit.  Need to watch
> for changed addresses though, and need to undo any address munging
> people might have used (or require them not to do so).

No need: just rebuild the file from scratch each time.

> The only issuse I see is if a new package is installed and then
> a change is committed very soon after, before the maintfile gets
> updated. Maybe updating the maintfile should be part of the process of
> installing a new package.

Maybe if the maintainer address is not found, the forwarding script
should trigger a refresh of the maintainer list.

> Maybe someone on this list will feel inspired to write this piece...

Hopefully.

>> as an error (i.e. tho I guess it would be the cron job's duty to
>> detect/handle it).  I.e. we need to distinguish "missing maintainer
>> data" from "maintainer decided not to want it".
>> I'd guess the "opt-out" would be a separate list of "opt-out email
>> addresses".
> I'd suggest just commenting out the relevant line in the maintainers
> file.

Not sure what you mean, but in any case, we can hope that noone will
want to opt-out, so we may never need to solve this problem.


        Stefan

Re: Sending diffs of `elpa' to the respective maintainers

[Glenn Morris]

Stefan Monnier wrote:

>> Maybe someone on this list will feel inspired to write this piece...
>
> Hopefully.

Apparently not.

I implemented:

1) --create; to scan the packages directory and write all recognizable
   maintainers to a file. Eg in the admin/ directory, try:

./forward-diffs.py --create -p ../packages -m maint.txt

No need to keep maint.txt in version control.

2) If a changed file has an unknown maintainer, it will scan the file
for the maintainer and if found add it to the maintainer file.
(So the maintainer file isn't really needed, but it makes things a
little faster.)


3) opt-out through an override file, overmaint.txt, where you can use
"nomail" for maintainer.


"Someone" needs to actually put it into use.

I suggest running --create once an hour or somesuch from cron, and the
normal mode of operation from procmail as previously suggested.

"Someone" also needs to ensure all packages have recognizable maintainer
emails. (DOT AT obfuscation is handled.) Several do not (eg company).

Re: Sending diffs of `elpa' to the respective maintainers

[Stefan Monnier]

> 2) If a changed file has an unknown maintainer, it will scan the file
> for the maintainer and if found add it to the maintainer file.
> (So the maintainer file isn't really needed, but it makes things a
> little faster.)
> 3) opt-out through an override file, overmaint.txt, where you can use
> "nomail" for maintainer.

Thank you very much.

> "Someone" needs to actually put it into use.

Aha!


        Stefan

Re: Sending diffs of `elpa' to the respective maintainers

[Glenn Morris]

Other things I should add:

Allow directories to have maintainers, which will be used if there is no
maintainer listed for a particular file in said directory.

Optional --prefix ... argument, defaulting to "packages/". Changing this
would allow it to be used with non-elpa branches.

Re: Sending diffs of `elpa' to the respective maintainers

[Glenn Morris]

Glenn Morris wrote:

> Allow directories to have maintainers, which will be used if there is no
> maintainer listed for a particular file in said directory.
>
> Optional --prefix ... argument, defaulting to "packages/". Changing this
> would allow it to be used with non-elpa branches.

Implemented. Should be usable for emacs-diffs mails as well now.
Something like:

forward-diffs.py -p /path/to/trunk -m maints.txt --no-scan --prefix ""

where maints.txt contains eg:

lisp/org     foo@example.com