* 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 external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.