Re: MAINTAINERS file and .el files?

[Eli Zaretskii]

> From: address@hidden (Pavel =?iso-8859-2?q?Jan=EDk?=)
> Date: Sun, 25 Nov 2001 13:42:34 +0100
> 
>    > AFAIU, Stefan wanted only those files to be listed whose Maintainer 
>    > headers says "FSF".  In that case, it's not redundant: no one says that 
>    > the original author must be a maintainer.
> 
> So why e.g. hexl.el doesn't contain:
> 
> Maintainer: Eli Zaretskii <address@hidden>

Because I'm not going to appoint myself a maintainer of hexl.el.

> The current state contains one indirect reference. If I'm looking for the
> maintainer of e.g. hexl.el I will look into its header. It contains FSF so
> I must look into MAINTAINERS (which, BTW, is not included in make-dist
> output right now. Does this mean that this file is only for developers and
> we do not want non-developers to send fixes directly to the maintainer?

Relax, this issue is still in transition; we are finalizing it as we
go.  The original intent was to define some procedures to go with that
file, but it's up to Richard when to make them effective, and frankly,
unless more people come aboard and start working seriously on fixing
bugs and adding features, IMHO we can hardly hope to get off the
ground.

That's why MAINTAINERS is not yet copied by make-dist: it's work in
progress, and it isn't anywhere near being finished.  If it confuses
you, simply ignore it.

My personal view is that putting my name into a file as its maintainer
means a long-term committment.  It means I don't want anyone to change
that file without my say-so (unless I'm dead).  By contrast, listing
my name in MAINTAINERS simply means that you can talk to me about
issues relevant to that file, or ask for approval if you are unsure
whether a change you have in mind would be a good one.  It also means
that if a problem pops up with that file, it is by default in my
backyard, and should go onto my TODO if no one else volunteers.

In other words, if someone wants to know who to bug about unresolved
issues with a certain file, MAINTAINERS is their friend.

> Before MAINTAINERS, I'd go ahead and simply commit it.

Personally, I don't like this development paradigm.  I think it
doesn't fit a situation where half a dozen or more people make
changes without talking to each other.  I'm afraid it will lead to a
need to back out changes, which I think does a lot of harm to the
relations among developers.

So, MAINTAINERS or no MAINTAINERS, I'd prefer that people talked
before they commit changes.  But that's just me.

MAINTAINERS was supposed to give you more information to whom you
should consider talking.  Where all this will evolve is anybody's
guess.