* Re: master bef1be8: Fixes for "Maintainer:" and related lines
[not found] ` <20190520043437.4F9A82068F@vcs0.savannah.gnu.org>
@ 2019-05-20 14:40 ` Glenn Morris
2019-05-20 15:39 ` Paul Eggert
0 siblings, 1 reply; 4+ messages in thread
From: Glenn Morris @ 2019-05-20 14:40 UTC (permalink / raw)
To: emacs-devel; +Cc: Paul Eggert
Paul Eggert wrote:
> branch: master
> commit bef1be873009d6e9f5a097396179f63a565bb6fd
[...]
> Mostly, this just removes "Maintainer: emacs-devel@gnu.org" lines,
> which are not that useful.
They are useful. It is long-standing Emacs convention that if there is
no Maintainer header, the Author is the maintainer. See elisp node
"Conventional Headers for Emacs Libraries". So this change isn't
correct, since it implies someone is the maintainer when they are not.
> ;; Author: Gerd Moellmann <gerd@gnu.org>
> -;; Maintainer: emacs-devel@gnu.org
etc.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: master bef1be8: Fixes for "Maintainer:" and related lines
2019-05-20 14:40 ` master bef1be8: Fixes for "Maintainer:" and related lines Glenn Morris
@ 2019-05-20 15:39 ` Paul Eggert
2019-05-22 22:19 ` Glenn Morris
0 siblings, 1 reply; 4+ messages in thread
From: Paul Eggert @ 2019-05-20 15:39 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
[-- Attachment #1: Type: text/plain, Size: 1862 bytes --]
On 5/20/19 7:40 AM, Glenn Morris wrote:
> It is long-standing Emacs convention that if there is
> no Maintainer header, the Author is the maintainer. See elisp node
> "Conventional Headers for Emacs Libraries".
I didn't know that. However, that node doesn't match existing practice
as it goes on to say, "Some files in Emacs use ‘FSF’ for the
maintainer. This means that the original author is no longer
responsible for the file, and that it is maintained as part of Emacs"
despite the fact that no files in the Emacs source code use "FSF" for
the maintainer (either before or after my recent patch).
Also, it appears that many (most?) people didn't know about and didn't
follow the convention. Not only did the convention not come up in
discussion until now, it's quite common to see comment pairs like the
following, which are the first five remaining instances of "Maintainer:"
lines in Emacs's .el files (sorted by file name):
;; Author: Markus Rost <markus.rost@mathematik.uni-regensburg.de>
;; Maintainer: Markus Rost <rost@math.ohio-state.edu>
;; Author: David Ponce <david@dponce.com>
;; Maintainer: David Ponce <david@dponce.com>
;; Author: David Ponce <david@dponce.com>
;; Maintainer: David Ponce <david@dponce.com>
;; Author: Richard Kim <ryk@dspwiz.com>
;; Maintainer: Richard Kim <ryk@dspwiz.com>
;; Author: Kevin Gallagher <kevin.gal@verizon.net>
;; Maintainer: Kevin Gallagher <kevin.gal@verizon.net>
and this indicates the authors were following the opposite convention
that a file without a listed maintainer is being maintained collectively.
All in all I think it'd lessen confusion and simplify maintenance if we
used "Maintainer:" for contacting current maintainers who aren't authors
and don't normally read bug reports. Something like the attached
proposed patch, say?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Adjust-Maintainer-doc.patch --]
[-- Type: text/x-patch; name="0001-Adjust-Maintainer-doc.patch", Size: 1389 bytes --]
From c18d6f7f7c18f5d2ef3a221242146ea2c7acbb5f Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Mon, 20 May 2019 08:35:53 -0700
Subject: [PROPOSED] Adjust Maintainer: doc
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* doc/lispref/tips.texi (Library Headers): Don’t say that
a missing Maintainer: header means the authors are maintainers.
---
doc/lispref/tips.texi | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/doc/lispref/tips.texi b/doc/lispref/tips.texi
index d41fe82572..c46e3a0f6c 100644
--- a/doc/lispref/tips.texi
+++ b/doc/lispref/tips.texi
@@ -1011,11 +1011,9 @@ Library Headers
person(s) who currently maintain(s) the file (respond to bug reports,
etc.).
-If there is no maintainer line, the person(s) in the Author field
-is/are presumed to be the maintainers. Some files in Emacs use
-@samp{FSF} for the maintainer. This means that the original author is
-no longer responsible for the file, and that it is maintained as part
-of Emacs.
+If there is no maintainer line, nobody in particular (other than
+perhaps the authors) has volunteered to maintain the file, or an
+ordinary Emacs bug report is a good way to contact the maintainers.
@item Created
This optional line gives the original creation date of the file, and
--
2.21.0
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: master bef1be8: Fixes for "Maintainer:" and related lines
2019-05-20 15:39 ` Paul Eggert
@ 2019-05-22 22:19 ` Glenn Morris
2019-05-25 21:34 ` Paul Eggert
0 siblings, 1 reply; 4+ messages in thread
From: Glenn Morris @ 2019-05-22 22:19 UTC (permalink / raw)
To: Paul Eggert; +Cc: emacs-devel
Paul Eggert wrote:
> However, that node doesn't match existing practice as it goes on to
> say, "Some files in Emacs use 'FSF' for the maintainer. This means
> that the original author is no longer responsible for the file, and
> that it is maintained as part of Emacs" despite the fact that no files
> in the Emacs source code use "FSF" for the maintainer (either before
> or after my recent patch).
I changed it to use a real email address in 34dc21d.
It seemed harmless to leave the explanation of FSF, for older files
people might encounter. (Or more likely I forgot to remove it.)
> it's quite common to see comment pairs like the following, which are
> the first five remaining instances of "Maintainer:" lines in Emacs's
> .el files (sorted by file name):
>
> ;; Author: Markus Rost <markus.rost@mathematik.uni-regensburg.de>
> ;; Maintainer: Markus Rost <rost@math.ohio-state.edu>
Harmless duplication that does not contravene the convention.
> All in all I think it'd lessen confusion and simplify maintenance if
> we used "Maintainer:" for contacting current maintainers who aren't
> authors and don't normally read bug reports. Something like the
> attached proposed patch, say?
That's an incompatible change. If I see a file with only an Author
header, I can't tell whether it follows the old convention (author is
the maintainer), or the new one (emacs-devel is the maintainer).
My counter suggestion is to revert bef1be8.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: master bef1be8: Fixes for "Maintainer:" and related lines
2019-05-22 22:19 ` Glenn Morris
@ 2019-05-25 21:34 ` Paul Eggert
0 siblings, 0 replies; 4+ messages in thread
From: Paul Eggert @ 2019-05-25 21:34 UTC (permalink / raw)
To: Glenn Morris; +Cc: emacs-devel
On 5/22/19 3:19 PM, Glenn Morris wrote:
> I changed it to use a real email address in 34dc21d.
> It seemed harmless to leave the explanation of FSF, for older files
> people might encounter. (Or more likely I forgot to remove it.)
OK, but it's better to have the documentation match the current behavior.
> My counter suggestion is to revert bef1be8.
OK, I did that and also updated the documentation to match the current
behavior of listing "Maintainer: emacs-devel@gnu.org" when there is no
particular maintainer. I'm not a fan of this convention and others in
this thread agreed, but we don't seem to have a consensus to change it.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-05-25 21:34 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20190520043434.1198.8439@vcs0.savannah.gnu.org>
[not found] ` <20190520043437.4F9A82068F@vcs0.savannah.gnu.org>
2019-05-20 14:40 ` master bef1be8: Fixes for "Maintainer:" and related lines Glenn Morris
2019-05-20 15:39 ` Paul Eggert
2019-05-22 22:19 ` Glenn Morris
2019-05-25 21:34 ` Paul Eggert
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).