unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: emacs-devel@gnu.org
Subject: Re: GNU ELPA package for CC-mode
Date: Thu, 23 Aug 2018 21:34:18 +0000	[thread overview]
Message-ID: <20180823213418.GA32596@ACM> (raw)
In-Reply-To: <jwvefephd7n.fsf-monnier+emacs@gnu.org>

Hello, Stefan.

On Thu, Aug 23, 2018 at 01:25:00 -0400, Stefan Monnier wrote:
> >> Search for "5.33" in the cc-mode.el of the master branch.
> > Ah.  So it's metadata written into a source file.  I'm against this.
> > Would it not be possible to store the version number elsewhere?
> > Metadata in ordinary files is ugly and causes problems.  A significant
> > one being that VCS logs get polluted by updates of metadata, making it
> > unpleasant, or even difficult, to use a log display.

> Not sure I understand:

You don't understand the notion of the VCS logs becoming polluted?
Let's try again, then.  At the moment, if you do

    git log -- lisp/progmodes/cc-mode.el

, you get back details of changes to cc-mode.el which are all about the
development of CC Mode.  There's, however, one exception, your latest
change, which has nothing to do with the development of CC Mode.

What you're proposing may lead to these undesirable "exceptions", log
entries which have nothing to do with the development of CC Mode,
becoming common and swamping the substantive entries.  Were this to
happen, it would be unpleasant to scan a git log of cc-mode.el searching
for substantive changes amongst the obtrusive metadata change entries,
or it might possibly even be difficult.

There must surely be a better way of triggering ELPA releases which
doesn't involve this type of pollution.

> .... we currently have

>     (defconst c-version "5.33.1"

> in cc-defs.el.  In which way is this different?

In every possible way, bar the superficial.  c-version is an essential
part of CC Mode, and is THE version of CC Mode.  The proposed VERSION:
header is not a part of CC Mode, it is part of ELPA, recording the
number of the ELPA release only.

> > This "Version:" header certainly has no place in master, though I can
> > see an argument being made for it being included in an ELPA version of
> > CC Mode.

> The purpose of this "Version:" header is to document for package.el
> ....

Yes.  It's essentially part of package.el, not part of CC Mode or of
master.

> .... which version of the cc-mode package is bundled with Emacs so
> that it ....

"It" being what?  Emacs?  package.el?

> .... can decide whether some other cc-mode ELPA package is more or
> less recent (and hence whether to activate that other package or not).

Sorry, I don't follow that bit.  Something's deciding something about
dates, and there are several CC Mode ELPA packages around.  Or
something.

> So it very much belongs in `master`.

I can't follow your arguments, sorry.  Your conclusion doesn't appear to
follow from the arguments.  This proposed "Version:" header has no
purpose in master, only in package.el, isn't that right?

"Version:" in master would be pollution, which we want to avoid.  There
surely must be a better way.  How about putting it in a separate file,
called something like elpa-cc.el, or elpa-versions.el, or leaving it out
altogether?  Can ELPA releases be triggered by some mechanism which
doesn't involve changing a library's .el files?

> >> The generation of the new package happens when the "Version:" header
> >> changes, so I don't think we want this header to be auto-generated on
> >> every commit.
> > "Changes" is a verb with an agent.  Under what scenario do you envisage
> > this version number being changed?

> Someone pushed a commit which changes that part of the file.

That wasn't the question I was attempting to ask; I wanted you to tell
me about the schedule for changing the version number, the criterion for
doing so, the frequency with which it will be done, things like that.

> > Automatically upon a CC Mode commit to master is what I thought you
> > had in mind.  Are you suggesting doing this by hand when it takes
> > somebody's fancy?

> Right: when you decide the code deserves a new GNU ELPA release.

It seems to make sense to make such a release on each CC Mode commit to
master.  I thought that was the idea - to keep the ELPA release
synchronised with master.  However, if we end up keeping this obtrusive
"Version:" in cc-mode.el, I would say do it on every tenth commit that
changes the substance of cc-mode.el, thus keeping the aforementioned
pollution within reasonable bounds.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).



  reply	other threads:[~2018-08-23 21:34 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-19 13:24 GNU ELPA package for CC-mode Stefan Monnier
2018-08-19 20:49 ` Alan Mackenzie
2018-08-19 23:45   ` Stefan Monnier
2018-08-20  8:24     ` Jostein Kjønigsen
2018-08-20 14:06       ` Stefan Monnier
2018-08-20 17:58         ` Jostein Kjønigsen
2018-08-21 13:30           ` Stefan Monnier
2018-08-21 16:20     ` Alan Mackenzie
2018-08-23  5:25       ` Stefan Monnier
2018-08-23 21:34         ` Alan Mackenzie [this message]
2018-08-23 22:17           ` Stefan Monnier
2018-08-24  8:43             ` Eli Zaretskii
2018-08-24 11:56               ` Michael Albinus
2018-08-24 22:21                 ` Stefan Monnier
2018-08-25  8:43                   ` Tramp as ELPA package (was: GNU ELPA package for CC-mode) Michael Albinus
2018-08-25 18:04                     ` Tramp as ELPA package Stefan Monnier
2018-08-25 21:04                       ` Stefan Monnier
2018-08-26  6:39                         ` Andreas Schwab
2018-08-26 10:48                           ` Michael Albinus
2018-08-26 11:09                         ` Michael Albinus
2018-08-26 15:21                           ` Stefan Monnier
2018-08-26 18:04                             ` Michael Albinus
2018-08-26 18:27                               ` Eli Zaretskii
2018-08-26 18:34                                 ` Michael Albinus
2018-08-26 19:03                                   ` Eli Zaretskii
2018-08-27  7:12                                     ` Michael Albinus
2018-08-27 13:33                                       ` Stefan Monnier
2018-08-27 13:41                                         ` Michael Albinus
2018-08-27 13:44                                           ` Stefan Monnier
2018-08-27 15:22                                             ` Michael Albinus
2018-08-27 15:09                                       ` Eli Zaretskii
2018-08-27 15:21                                         ` Michael Albinus
2018-08-26 15:30                           ` Tom Tromey
2018-08-26 16:26                             ` Stefan Monnier
2018-08-26 17:46                             ` Michael Albinus
2019-04-04 12:41                           ` Michael Albinus
2019-04-04 15:48                             ` Stefan Monnier
2019-04-04 16:07                               ` Michael Albinus
2019-04-05 14:43                               ` Michael Albinus
2019-04-05 15:07                                 ` Dmitry Gutov
2019-04-05 16:19                                   ` Michael Albinus
2019-04-16  7:53                                     ` Steinar Bang
2019-04-05 18:14                                 ` Stephen Leake
2019-04-05 18:20                                   ` Stephen Leake
2019-04-05 22:18                                     ` Michael Albinus
2019-04-07  0:17                                       ` Stephen Leake
2019-04-07  7:41                                         ` Michael Albinus
2019-04-06 12:42                                 ` Stefan Monnier
2019-04-08 12:37                                   ` Michael Albinus
2019-04-08 13:07                                     ` Stefan Monnier
2019-04-08 13:31                                       ` Michael Albinus
2019-04-08 16:43                                         ` Stefan Monnier
2019-05-20 13:05                                       ` Michael Albinus
2019-06-30 19:20                                         ` Michael Albinus
2019-04-05 18:55                               ` Achim Gratz
2019-04-06 22:25                                 ` GNU ELPA and package.el (was: Tramp as ELPA package) Stefan Monnier
2019-04-07  7:17                                   ` GNU ELPA and package.el Achim Gratz
2019-04-07 14:07                                     ` Stefan Monnier
2019-04-07 17:37                                       ` Achim Gratz
2019-04-07 20:31                                         ` Stefan Monnier
2019-04-08 17:55                                           ` Achim Gratz
2019-04-08 19:01                                             ` Stefan Monnier
2019-04-08 20:24                                               ` Achim Gratz
2019-04-09  1:39                                                 ` Stefan Monnier
2018-08-25 19:15                   ` GNU ELPA package for CC-mode Clément Pit-Claudel
2018-08-25 20:17                     ` Stefan Monnier
2018-08-25 21:17                       ` Tom Tromey
2018-08-25 23:28                         ` Kyle Andrews
2018-08-24 15:48               ` Stefan Monnier
2018-08-24 19:21                 ` Eli Zaretskii
2018-08-24 22:17               ` Stefan Monnier
2018-08-25  7:02                 ` Eli Zaretskii
2018-08-25  8:51                 ` Alan Mackenzie
2018-08-25 10:15                   ` Michael Albinus
2018-08-25 18:07                   ` Stefan Monnier
2018-08-25 18:27                     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180823213418.GA32596@ACM \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).