admin/MAINTAINER edits

admin/MAINTAINER edits

[Glenn Morris]

What's going on with all these pointless (IMO) admin/MAINTAINER edits?

Section 3 "the list of areas for which no maintainer has been found so far"
has recently been filled out with a huge dump of files. Eg

lisp/calendar/*
lisp/gnus/*
lisp/progmodes/f90.el
etc etc

These things are not unmaintained.
Nor are the vast majority of items in that section.

IMO MAINTAINERS, which was neglected for years, isn't very important.
I was hoping to just see it go away, not get revived. It just sits
around duplicating information, getting outdated, and not being used.

If someone is listed in an individual file's header, listing them again
in this file is just pointless duplication.
(And the presumption is that the Author is the Maintainer if none is
explicitly listed.)

IMO the MAINTAINERS files was only every really "useful" for abstract
things like

Jason Rumney
      W32

(BTW, that entry is fairly obviously no longer appropriate, as are some
others.)

Re: admin/MAINTAINER edits

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 30 Sep 2015 16:00:50 -0400
> 
> What's going on with all these pointless (IMO) admin/MAINTAINER edits?

They aren't pointless.  I asked for them.

> Section 3 "the list of areas for which no maintainer has been found so far"
> has recently been filled out with a huge dump of files. Eg
> 
> lisp/calendar/*
> lisp/gnus/*
> lisp/progmodes/f90.el
> etc etc
> 
> These things are not unmaintained.
> Nor are the vast majority of items in that section.

Then let's remove the files that are not unmaintained.  In fact, the
entire section 3 could go away, as it doesn't provide any useful
information, IMO.

> IMO MAINTAINERS, which was neglected for years, isn't very important.
> I was hoping to just see it go away, not get revived. It just sits
> around duplicating information, getting outdated, and not being used.

Many/most our files say the maintainer is FSF, which is not very
useful.  MAINTAINERS fills that gap.  It's a single file that needs to
be consulted, so I don't see a problem if it repeats what some files
already say.

> If someone is listed in an individual file's header, listing them again
> in this file is just pointless duplication.

I don't think this duplication is something we should worry about.

> (And the presumption is that the Author is the Maintainer if none is
> explicitly listed.)

That assumption is incorrect in many cases.  The original authors are
long gone or lost interest or no longer work on Emacs.

We are going to a period of time where maintenance is scattered
between many more people than it was before.  It's quite possible that
this period will last forever.  How else could I or you or someone
else know whom to ask to look into some specific problem that was
reported and not handled soon enough?  The current situation with
timely handling bug reports and other problems is IMO intolerable, and
we must somehow make it better.  I think when someone declares his/her
interests in public, that will cause them feel more responsible for
those parts, and will allow us to ping them when they miss the
original reports for some reason.

So I think on balance this file is helpful.

> IMO the MAINTAINERS files was only every really "useful" for abstract
> things like
> 
> Jason Rumney
>       W32
> 
> (BTW, that entry is fairly obviously no longer appropriate, as are some
> others.)

Feel free to delete those you know are no longer appropriate.

Re: admin/MAINTAINER edits

[Paul Eggert]

Glenn Morris wrote:
> IMO MAINTAINERS, which was neglected for years, isn't very important.
> I was hoping to just see it go away, not get revived. It just sits
> around duplicating information, getting outdated, and not being used.

That would be fine with me.  One less thing to maintain.  I edited 
admin/MAINTAINERS only because Eli asked.

Re: admin/MAINTAINER edits

[Paul Eggert]

Eli Zaretskii wrote:
> How else could I or you or someone
> else know whom to ask to look into some specific problem that was
> reported and not handled soon enough?

When this happens in other projects, I look at the commit logs and see who has 
updated the file recently and why.  This sounds more reliable (and easier to 
maintain) than a separate MAINTAINERS file.

I agree that our bug-report response is bad, but admin/MAINTAINERS won't 
appreciably help with that.

Re: admin/MAINTAINER edits

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 1 Oct 2015 07:47:36 -0700
> 
> Eli Zaretskii wrote:
> > How else could I or you or someone
> > else know whom to ask to look into some specific problem that was
> > reported and not handled soon enough?
> 
> When this happens in other projects, I look at the commit logs and see who has 
> updated the file recently and why.

That could take a while, so is less convenient.

> I agree that our bug-report response is bad, but admin/MAINTAINERS won't 
> appreciably help with that.

It's a small step, and by itself will not help in any significant
way.  But let's not dismiss every idea too quickly, okay?

Re: admin/MAINTAINER edits

[Glenn Morris]

Eli Zaretskii wrote:

>> What's going on with all these pointless (IMO) admin/MAINTAINER edits?
>
> They aren't pointless.  I asked for them.

I obviously disagree. :)

If you look at the VCS history of the file, then in the past decade you
are almost the only person who ever edited it. Everything else (bar ~ 2
commits) is just the slow deletion of obsolete information.
It was on the way out.

I could critique ever entry in the file, but will just pick one example.
The reftex additions are pointless, because every one of those files
already listed auctex-devel as the maintainer. It's just make-work and
duplication.

If someone wants to maintain foo.el, they should put their name in the
Maintainer field in foo.el.

(I'll leave aside the broader concept of whether "ownership" of files in
this way is useful; eg
http://producingoss.com/en/managing-participants.html#territoriality )

> In fact, the entire section 3 could go away, as it doesn't provide any
> useful information, IMO.

At least we agree on that much. :)

> Many/most our files say the maintainer is FSF, which is not very
> useful.

Zero files say that the maintainer is FSF.
(I know because I removed such statements some time ago.)

>> (And the presumption is that the Author is the Maintainer if none is
>> explicitly listed.)
>
> That assumption is incorrect in many cases.  The original authors are
> long gone or lost interest or no longer work on Emacs.

Indeed true.

Re: admin/MAINTAINER edits

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Thu, 01 Oct 2015 13:33:54 -0400
> 
> Eli Zaretskii wrote:
> 
> >> What's going on with all these pointless (IMO) admin/MAINTAINER edits?
> >
> > They aren't pointless.  I asked for them.
> 
> I obviously disagree. :)

Judging by the positive reaction to my request, it looks like you and
Paul are the minority here.

> If you look at the VCS history of the file, then in the past decade you
> are almost the only person who ever edited it. Everything else (bar ~ 2
> commits) is just the slow deletion of obsolete information.
> It was on the way out.

I thought we should revive it.  And I still think so.  Let's give this
more than 5 day's grace, before we decide who is right, OK?

Re: admin/MAINTAINER edits

[Dmitry Gutov]

On 10/01/2015 08:33 PM, Glenn Morris wrote:

> If someone wants to maintain foo.el, they should put their name in the
> Maintainer field in foo.el.

As a counter-example, I wouldn't put my name on any of vc/vc-*.el files 
except for vc-git.el, but I don't really mind taking care of bugs in any 
of the backends. Putting lisp/vc/* under my name inside the second part 
of MAINTAINERS feels about right.

> (I'll leave aside the broader concept of whether "ownership" of files in
> this way is useful; eg
> http://producingoss.com/en/managing-participants.html#territoriality )

"Cookie licking" is neat phrase. :)