Maintainer overview

Maintainer overview

[Lars Magne Ingebrigtsen]

Emacs has more than a few bits and pieces that some specific people feel
ownership to.  However, we don't really seem to have a mechanism for
notifying these people when bugs that affect their packages show up in
the Emacs bug tracker.

I think it would be very nice if we had such a list of
packages/maintainers -- that was up-to-date.

Now, some of the .el files themselves do have Maintainer: lines, but you
really have to root around, and know that you're supposed to root
around, to find them.

What I'd ideally like to see is to be able to say `C package TAB' (in
debbugs-gnu mode, of course) and see what packages a bug report can be
assigned to, and have the maintainer(s) Cc'd on the existence of the bug
report.

I think the most pleasant way to do this would be to add a slightly more
formal Maintainer: syntax.  Grepping though the sources, we find stuff
like:

vt-control.el:6:;; Maintainer: Rob Riepel <riepel@networking.stanford.edu>
whitespace.el:6:;; Maintainer: Vinicius Jose Latorre <viniciusjl@ig.com.br>
wid-edit.el:6:;; Maintainer: FSF
window.el:6:;; Maintainer: FSF
woman.el:6:;; Maintainer: FSF
x-dnd.el:6:;; Maintainer: FSF
xml.el:6:;; Maintainer: Mark A. Hershberger <mah@everybody.org>
calc/calc-aent.el:6:;; Maintainer: Jay Belanger <jay.p.belanger@gmail.com>
calc/calcalg2.el:6:;; Maintainer: Jay Belanger <jay.p.belanger@gmail.com>
calc/calcalg3.el:6:;; Maintainer: Jay Belanger <jay.p.belanger@gmail.com>
calc/calc-alg.el:6:;; Maintainer: Jay Belanger  <jay.p.belanger@gmail.com>
calc/calc-arith.el:6:;; Maintainer: Jay Belanger <jay.p.belanger@gmail.com>
calc/calc-bin.el:6:;; Maintainer: Jay Belanger <jay.p.belanger@gmail.com>

My suggestion would be to change this to

;; Package-maintainer: calc:Jay Belanger <jay.p.belanger@gmail.com>

The `C package' command could then go through all the .el files, gather
the package names, and allow TAB-ing over them.

Alternatively, we could just put a new file into etc that lists all the
packages and their maintainers, which would, of course, be a lot more
efficient.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Maintainer overview

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 28 Jul 2011 00:48:16 +0200
> 
> I think it would be very nice if we had such a list of
> packages/maintainers -- that was up-to-date.

We have something in admin/MAINTAINERS.

> What I'd ideally like to see is to be able to say `C package TAB' (in
> debbugs-gnu mode, of course) and see what packages a bug report can be
> assigned to, and have the maintainer(s) Cc'd on the existence of the bug
> report.

What about source files that are not packages, like code written in C,
or issues that are not confined to a single file/package?

Re: Maintainer overview

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I think it would be very nice if we had such a list of
>> packages/maintainers -- that was up-to-date.
>
> We have something in admin/MAINTAINERS.

It's a starting point.

>> What I'd ideally like to see is to be able to say `C package TAB' (in
>> debbugs-gnu mode, of course) and see what packages a bug report can be
>> assigned to, and have the maintainer(s) Cc'd on the existence of the bug
>> report.
>
> What about source files that are not packages, like code written in C,
> or issues that are not confined to a single file/package?

Perhaps "area" is a better concept than "package".  I mean, Ted and
Juanma would probably appreciate being notified on gnutls issues, and
you would like (or "like" :-)) to get bidi notifications.

However, areas that are mostly covered by people who are participating
actively on emacs-devel already don't really need to get these
notifications, since we all read emacs-bugs already, don't we?  :-)

So, while nice, it's probably more useful for packages maintained by
people who don't read these lists regularly.

So, yes, "area".  And I'd suggest a file format like

bidi: Eli Zaretskii <eliz@gnu.org>

gnutls: Ted Zlatanov <tzz@lifelogs.com>
 Juanma Barranquero <lekktu@gmail.com>

gnus,message: Lars Magne Ingebrigtsen <larsi@gnus.org>
 
Easy to parse and edit.
 
-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Maintainer overview

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 28 Jul 2011 09:35:46 +0200
> 
> > What about source files that are not packages, like code written in C,
> > or issues that are not confined to a single file/package?
> 
> Perhaps "area" is a better concept than "package".  I mean, Ted and
> Juanma would probably appreciate being notified on gnutls issues, and
> you would like (or "like" :-)) to get bidi notifications.
> 
> However, areas that are mostly covered by people who are participating
> actively on emacs-devel already don't really need to get these
> notifications, since we all read emacs-bugs already, don't we?  :-)
> 
> So, while nice, it's probably more useful for packages maintained by
> people who don't read these lists regularly.

Maybe we should take a step back and talk about the goals of this
feature.  Is this just to be nice to those who don't read
bug-gnu-emacs and send them a notification?  Or do we want to make
sure every bug is assigned to some "victim"?  These are different
goals, and the solutions are likely to be different.

Re: Maintainer overview

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Maybe we should take a step back and talk about the goals of this
> feature.  Is this just to be nice to those who don't read
> bug-gnu-emacs and send them a notification?  Or do we want to make
> sure every bug is assigned to some "victim"?  These are different
> goals, and the solutions are likely to be different.

I was thinking only of the former.  In particular, when doing bug triage
it would be nice if debbugs-gnu knew that cperl and org and etc were
primarily handled by people who don't necessarily read emacs-bugs
religiously.  I mean, I know the first two, but I don't know "etc".  So
having that knowledge in a machine-parseable form would aid bringing a
bug report to the attention of people who knows how to fix the bug.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Maintainer overview

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 28 Jul 2011 10:09:11 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Maybe we should take a step back and talk about the goals of this
> > feature.  Is this just to be nice to those who don't read
> > bug-gnu-emacs and send them a notification?  Or do we want to make
> > sure every bug is assigned to some "victim"?  These are different
> > goals, and the solutions are likely to be different.
> 
> I was thinking only of the former.

Then it's easy, but I think most of Emacs isn't maintained by such
individuals.  So you will have covered only a small part of the code.

Re: Maintainer overview

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Then it's easy, but I think most of Emacs isn't maintained by such
> individuals.  So you will have covered only a small part of the code.

I think that's OK.  The main issue, as I see it, is to be able to notify
(sort-of "external") maintainers that an issue has appeared.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Maintainer overview

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Maybe we should take a step back and talk about the goals of this
 > feature.  Is this just to be nice to those who don't read
 > bug-gnu-emacs and send them a notification?

The situation of Emacs (whose goal is to incorporate all the elisp
that's fit to execute[1]) is somewhat different -- always using
bug-gnu-emacs makes quite a bit of sense -- but XEmacs packages have
had their own bug addresses for over a decade.  The following use
cases are seen, from more common to less (in my recollection, I could
check if anybody cares):

1) Redirect to xemacs-beta (the closest we have to bug-gnu-emacs).
2) Redirect to an @xemacs.org alias of the package maintainer.  These
   are practically public as they are easy to guess.
3) Redirect to a public email address of the package maintainer.
4) Redirect to a mailing list dedicated to the package.
5) Redirect to a private email address of the package maintainer.

(Here "public" means an address the user is willing to have exposed in
ML archives and the like.  "Private" means the user expects the
address to be known only to specified correspondents and their MTAs.)

The maintenance burden is small (for us; we own the alias file for
xemacs.org, I don't know if that would be the same in GNU or if you'd
have to ask for service from Savannah); about an hour to set up and
test example aliases, another two hours to create the original list of
about 200 aliases for 50 or so packages (we actually have 4 aliases
per package, but that's probably overkill), including gathering
information from about 25 package maintainers about their preferences
(some do prefer to read about their packages on xemacs-beta); and
about 1 minute per new package or change of package maintainer, of
which there have probably been about 50 over the decade.

We do occasionally get complaints about stale aliases, but the former
maintainers are usually pretty sympathetic and relieved that the
change is done immediately.  Mostly stale aliases just revert to
"xemacs-beta", it's not difficult.

AFAIK most never got used very much, but a few were quite active
(mostly those that had courtesy @xemacs.org addresses before we
systematized the package addresses).  Given the low maintenance
burden, I think it is well worth it.  YMMV of course.

Footnotes: 
[1]  Don't take that too seriously, Eli, it's a play on The New York
Times's motto.

Re: Maintainer overview

[Detlev Zundel]

Hi,

>>> I think it would be very nice if we had such a list of
>>> packages/maintainers -- that was up-to-date.
>>
>> We have something in admin/MAINTAINERS.
>
> It's a starting point.

Just as a hint - the Linux kernel has a pretty good grasp on this topic
with the MAINTAINERS[1] file.  There's a script alongside it[2] which
can find maintainers even for a presented patch.  That helps _a lot_ to
automatically find the responsible people.

Of course in Emacs we could integrate that better, but comparable
functionality would be nice to have ;)

Cheers
  Detlev

[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=MAINTAINERS
[2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=scripts/get_maintainer.pl

-- 
There are two hard things in computer science: cache invalidation,
naming things, and off-by-one errors.

Re: Maintainer overview

[Juanma Barranquero]

On Thu, Jul 28, 2011 at 09:35, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:

> Perhaps "area" is a better concept than "package".  I mean, Ted and
> Juanma would probably appreciate being notified on gnutls issues

[ Just a side comment: You just overestimated my knowledge of GnuTLS
by an order of magnitude or two. I'm the guy who likes to delay
loading DLLs, not a GnuTLS expert :-) ]

    Juanma

Re: Maintainer overview

[Jambunathan K]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Emacs has more than a few bits and pieces that some specific people feel
> ownership to.  However, we don't really seem to have a mechanism for
> notifying these people when bugs that affect their packages show up in
> the Emacs bug tracker.
>
> I think it would be very nice if we had such a list of
> packages/maintainers -- that was up-to-date.
>
> Now, some of the .el files themselves do have Maintainer: lines, but you
> really have to root around, and know that you're supposed to root
> around, to find them.
>
> What I'd ideally like to see is to be able to say `C package TAB' (in
> debbugs-gnu mode, of course) and see what packages a bug report can be
> assigned to, and have the maintainer(s) Cc'd on the existence of the bug
> report.
>
> I think the most pleasant way to do this would be to add a slightly more
> formal Maintainer: syntax.  Grepping though the sources, we find stuff
> like:
>
> vt-control.el:6:;; Maintainer: Rob Riepel <riepel@networking.stanford.edu>
> whitespace.el:6:;; Maintainer: Vinicius Jose Latorre <viniciusjl@ig.com.br>
> wid-edit.el:6:;; Maintainer: FSF
> window.el:6:;; Maintainer: FSF
> woman.el:6:;; Maintainer: FSF
> x-dnd.el:6:;; Maintainer: FSF
> xml.el:6:;; Maintainer: Mark A. Hershberger <mah@everybody.org>
> calc/calc-aent.el:6:;; Maintainer: Jay Belanger <jay.p.belanger@gmail.com>
> calc/calcalg2.el:6:;; Maintainer: Jay Belanger <jay.p.belanger@gmail.com>
> calc/calcalg3.el:6:;; Maintainer: Jay Belanger <jay.p.belanger@gmail.com>
> calc/calc-alg.el:6:;; Maintainer: Jay Belanger  <jay.p.belanger@gmail.com>
> calc/calc-arith.el:6:;; Maintainer: Jay Belanger <jay.p.belanger@gmail.com>
> calc/calc-bin.el:6:;; Maintainer: Jay Belanger <jay.p.belanger@gmail.com>
>
> My suggestion would be to change this to
>
> ;; Package-maintainer: calc:Jay Belanger <jay.p.belanger@gmail.com>
>
> The `C package' command could then go through all the .el files, gather
> the package names, and allow TAB-ing over them.
>
> Alternatively, we could just put a new file into etc that lists all the
> packages and their maintainers, which would, of course, be a lot more
> efficient.

A package's maintainer is well a meta info about the package (package as
defined in ELPA sense) - whether built in or not.

I wonder whether there is an interface to inspect the meta information
about a package file.

Jambunathan K.
-- 

Re: Maintainer overview

[Tim Cross]

On Thu, Jul 28, 2011 at 8:48 AM, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> Emacs has more than a few bits and pieces that some specific people feel
> ownership to.  However, we don't really seem to have a mechanism for
> notifying these people when bugs that affect their packages show up in
> the Emacs bug tracker.
>
> I think it would be very nice if we had such a list of
> packages/maintainers -- that was up-to-date.
>
> Now, some of the .el files themselves do have Maintainer: lines, but you
> really have to root around, and know that you're supposed to root
> around, to find them.
>
> What I'd ideally like to see is to be able to say `C package TAB' (in
> debbugs-gnu mode, of course) and see what packages a bug report can be
> assigned to, and have the maintainer(s) Cc'd on the existence of the bug
> report.
>
> I think the most pleasant way to do this would be to add a slightly more
> formal Maintainer: syntax.  Grepping though the sources, we find stuff
> like:
>
> vt-control.el:6:;; Maintainer: Rob Riepel <riepel@networking.stanford.edu>
> whitespace.el:6:;; Maintainer: Vinicius Jose Latorre <viniciusjl@ig.com.br>
> wid-edit.el:6:;; Maintainer: FSF
> window.el:6:;; Maintainer: FSF
> woman.el:6:;; Maintainer: FSF
> x-dnd.el:6:;; Maintainer: FSF
> xml.el:6:;; Maintainer: Mark A. Hershberger <mah@everybody.org>
> calc/calc-aent.el:6:;; Maintainer: Jay Belanger <jay.p.belanger@gmail.com>
> calc/calcalg2.el:6:;; Maintainer: Jay Belanger <jay.p.belanger@gmail.com>
> calc/calcalg3.el:6:;; Maintainer: Jay Belanger <jay.p.belanger@gmail.com>
> calc/calc-alg.el:6:;; Maintainer: Jay Belanger  <jay.p.belanger@gmail.com>
> calc/calc-arith.el:6:;; Maintainer: Jay Belanger <jay.p.belanger@gmail.com>
> calc/calc-bin.el:6:;; Maintainer: Jay Belanger <jay.p.belanger@gmail.com>
>
> My suggestion would be to change this to
>
> ;; Package-maintainer: calc:Jay Belanger <jay.p.belanger@gmail.com>
>
> The `C package' command could then go through all the .el files, gather
> the package names, and allow TAB-ing over them.
>
> Alternatively, we could just put a new file into etc that lists all the
> packages and their maintainers, which would, of course, be a lot more
> efficient.
>
> --
> (domestic pets only, the antidote for overdose, milk.)
>  bloggy blog http://lars.ingebrigtsen.no/
>
>
>


That sounds like useful improvements. However, can I suggest
abstracting the contact details another layer. Some maintainers may
not like their email being distributed inside emacs source files and
when that maintainer leaves or someone else takes over maintenance,
the information becomes outdated.

Perhaps we could use a emacs-package@gnu.org address which is
redirected to the real address of the person currently maintaining the
package or something similar. This would allow the user to control
distribution of their email address and ensure the most current or
best address is used

Tim

Re: Maintainer overview

[Jambunathan K]

> Perhaps we could use a emacs-package@gnu.org address which is
> redirected to the real address of the person currently maintaining the
> package or something similar. This would allow the user to control
> distribution of their email address and ensure the most current or
> best address is used

+1. I stopped short of saying it.

The above proposal can be supplemented with M-x report-package-bug etc
etc.

>
> Tim
>
>

-- 

Re: Maintainer overview

[Lars Magne Ingebrigtsen]

Tim Cross <theophilusx@gmail.com> writes:

> That sounds like useful improvements. However, can I suggest
> abstracting the contact details another layer. Some maintainers may
> not like their email being distributed inside emacs source files and
> when that maintainer leaves or someone else takes over maintenance,
> the information becomes outdated.

If your email address is secret, then you can't participate in Emacs
development.  So I think the first consideration is irrelevant.

The second is true, but this information is for Emacs developers who
want to know where bugs should be reassigned.  These people presumably
have an updated Emacs, so it isn't particularly relevant for them,
either. 

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Maintainer overview

[Tim Cross]

On Thu, Jul 28, 2011 at 5:37 PM, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> Tim Cross <theophilusx@gmail.com> writes:
>
>> That sounds like useful improvements. However, can I suggest
>> abstracting the contact details another layer. Some maintainers may
>> not like their email being distributed inside emacs source files and
>> when that maintainer leaves or someone else takes over maintenance,
>> the information becomes outdated.
>
> If your email address is secret, then you can't participate in Emacs
> development.  So I think the first consideration is irrelevant.
>

There is a big difference between not wanting your email address
distributed in every copy of emacs and wanting it secret. Obviously, a
secret email address is not much use to anyone.

> The second is true, but this information is for Emacs developers who
> want to know where bugs should be reassigned.  These people presumably
> have an updated Emacs, so it isn't particularly relevant for them,
> either.
>

Why should this information be only relevant to emacs maintainers? If
that is the case, then why have it in the files at all - the
maintainers could just have a private list they use.

Perhaps more importantly, why put this additional bit of work on the
maintainers if it isn't necessary - if we can define an effective
meta-data framework, then this sort of grunt work (i.e. re-assigning
bug reports) could be automated, leaving maintainers more time to deal
with issues that benefit more from their abilities.

Tim

Re: Maintainer overview

[Eli Zaretskii]

> Date: Thu, 28 Jul 2011 18:23:08 +1000
> From: Tim Cross <theophilusx@gmail.com>
> 
> On Thu, Jul 28, 2011 at 5:37 PM, Lars Magne Ingebrigtsen <larsi@gnus.org> wrote:
> > If your email address is secret, then you can't participate in Emacs
> > development.  So I think the first consideration is irrelevant.
> >
> 
> There is a big difference between not wanting your email address
> distributed in every copy of emacs and wanting it secret.

No, there isn't any difference, because the addresses are spelled out
in ChangeLog files that are shipped with every release.

Re: Maintainer overview

[Bastien]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I think it would be very nice if we had such a list of
> packages/maintainers -- that was up-to-date.

Whatever the way this can be achieved (and the proposed way looks 
fine to me), I would welcome such an improvement.

Eli Zaretskii <eliz@gnu.org> writes:

> We have something in admin/MAINTAINERS.

I'll add myself as the Org maintainer, thanks for the pointer.

-- 
 Bastien

Re: Maintainer overview

[Chong Yidong]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> However, we don't really seem to have a mechanism for notifying these
> people when bugs that affect their packages show up in the Emacs bug
> tracker.

IIUC, Debbugs already does this for some packages ("packages" meaning
Debbugs packages, not ELPA packages).  For example, bugs for "org-mode"
are forwarded to emacs-orgmode@gnu.org, and bugs for "cc-mode" are sent
to bug-cc-mode@gnu.org.

This is set up by hand, in the /etc/debbugs/Maintainers config file, and
we can easily add more maintainer addresses for other Debbugs
pseudo-packages as necessary.

Re: Maintainer overview

[Lars Magne Ingebrigtsen]

Chong Yidong <cyd@stupidchicken.com> writes:

> IIUC, Debbugs already does this for some packages ("packages" meaning
> Debbugs packages, not ELPA packages).  For example, bugs for "org-mode"
> are forwarded to emacs-orgmode@gnu.org, and bugs for "cc-mode" are sent
> to bug-cc-mode@gnu.org.
>
> This is set up by hand, in the /etc/debbugs/Maintainers config file, and
> we can easily add more maintainer addresses for other Debbugs
> pseudo-packages as necessary.

This doesn't allow TAB-completion over what areas are (currently) valid.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Maintainer overview

[Stefan Monnier]

> I think the most pleasant way to do this would be to add a slightly more
> formal Maintainer: syntax.  Grepping though the sources, we find stuff
> like:

> vt-control.el:6:;; Maintainer: Rob Riepel <riepel@networking.stanford.edu>
> whitespace.el:6:;; Maintainer: Vinicius Jose Latorre <viniciusjl@ig.com.br>
> wid-edit.el:6:;; Maintainer: FSF
> window.el:6:;; Maintainer: FSF
> woman.el:6:;; Maintainer: FSF
> x-dnd.el:6:;; Maintainer: FSF
> xml.el:6:;; Maintainer: Mark A. Hershberger <mah@everybody.org>
> calc/calc-aent.el:6:;; Maintainer: Jay Belanger <jay.p.belanger@gmail.com>
> calc/calcalg2.el:6:;; Maintainer: Jay Belanger <jay.p.belanger@gmail.com>
> calc/calcalg3.el:6:;; Maintainer: Jay Belanger <jay.p.belanger@gmail.com>
> calc/calc-alg.el:6:;; Maintainer: Jay Belanger  <jay.p.belanger@gmail.com>
> calc/calc-arith.el:6:;; Maintainer: Jay Belanger <jay.p.belanger@gmail.com>
> calc/calc-bin.el:6:;; Maintainer: Jay Belanger <jay.p.belanger@gmail.com>

> My suggestion would be to change this to

> ;; Package-maintainer: calc:Jay Belanger <jay.p.belanger@gmail.com>

I don't think we need a new syntax.

We do need to improve the values we set there.  But basically "FSF"
means that the maintainer reads bug-gnu-emacs, and anything else should
mean "I want to receive notifications about commits and pending bugs".

We could add some way to put the email address while at the same time
requesting "please don't auto-send notifications" (for those who
already read bug-gnu-emacs but don't want to mark their package as
maintained by "FSF").

If file foo-bar.el has no Maintainer, then we should defer to the
maintainer of the file foo.el.

If someone could set this up for commits in trunk and in ELPA (where
the Maintainer field should always be provided).


        Stefan