From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: bruce.connor.am@gmail.com, emacs-devel@gnu.org
Subject: Re: Emacs release and bundling GNU Elpa
Date: Mon, 22 Jun 2015 18:33:33 +0300 [thread overview]
Message-ID: <83si9jhi5u.fsf@gnu.org> (raw)
In-Reply-To: <jwvioag4m2x.fsf-monnier+emacs@gnu.org>
Fair disclosure: I don't like this "move to ELPA" attitude. I think
the net result will be more bugs because of unsynchronized development
and less exposure of packages to people who track development on
master, and more hassle due to the need to work with more than one Git
repository, multiple development philosophies, etc.
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 21 Jun 2015 20:45:36 -0400
> Cc: emacs-devel <emacs-devel@gnu.org>
>
> step-1: we change the tarball-building script so as to pull some
> packages from elpa.git and include them somewhere under the `lisp'
> directory (for example) in the tarballs we distribute.
> step-2: we change the build scripts used from a Git checkout so they can
> also use those packages from elpa.git.
> step-3: we change the build scripts again so they always use those
> packages from elpa.git.
>
> At step 3, we'd have the following novelties:
> - the end user has to checkout both emacs.git and elpa.git before she
> can build Emacs (I suspect there will be some resistance, here).
> - packages in emacs/lisp can start to depend on packages from elpa.git.
> - we could even include preload some elpa.git packages (i.e. from loadup.el).
>
> I'm not exactly sure we'll ever get to step 3.
At step 1, we'd have the following novelties:
. Package developers will have to abide by some of the core's
development methodology, like freezing development when core does
so, perhaps using release branches, timely fixing of critical or
blocking bugs during pretests, etc., let alone abiding by style and
documentation guidelines.
. Core maintainers will probably start pushing more changes to the
packages, something I'm not sure package developers will like.
Alternatively, we will have to develop procedures and protocols we
don't currently have for having the package developers themselves
expedite fixing of certain problems deemed urgent.
. We'd need to find a way of providing ChangeLogs for the packages,
either by merging their Git logs somehow, or by keeping their
ChangeLogs in separate directories (which would mean each package
will have its own directory, making load-path longer).
. We'd need to produce NEWS entries for the packages, which will
probably mean the packages will have to maintain their own NEWS
files, using the same methodology and style as in core development.
. If any of the packages have manuals, or are mentioned in the Emacs
manuals, changes there will have to be merged as well, and we will
have to track those updates, e.g. like we do in NEWS.
. Our defcustom's have a ':version' tag, which is useful for quickly
examining new options since some release -- how will this work in
packages whose release cycle is not synchronized with Emacs? At
the very least, some changes to support that in
customize-changed-options will be needed. Similarly with
make-obsolete: we will need at least some standardized wording for
the WHEN argument, to avoid confusion between versions of Emacs and
the packages.
(I'm sure I'm missing some more fun.)
next prev parent reply other threads:[~2015-06-22 15:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-21 9:59 Emacs release and bundling GNU Elpa Artur Malabarba
2015-06-22 0:45 ` Stefan Monnier
2015-06-22 11:20 ` Phillip Lord
2015-06-22 13:27 ` Artur Malabarba
2015-06-22 13:30 ` Artur Malabarba
2015-06-22 13:30 ` Artur Malabarba
2015-06-22 15:22 ` Phillip Lord
2015-06-22 15:33 ` Stefan Monnier
2015-06-22 15:33 ` Eli Zaretskii [this message]
2015-06-22 16:50 ` Stephen Leake
2015-06-22 17:16 ` Stefan Monnier
2015-06-22 17:45 ` Artur Malabarba
2015-06-22 18:49 ` Eli Zaretskii
2015-06-23 10:55 ` Artur Malabarba
2015-06-23 13:20 ` Stefan Monnier
-- strict thread matches above, loose matches on Subject: below --
2015-06-24 8:12 Barry
2015-06-24 14:04 ` Stefan Monnier
2015-06-24 15:01 ` Eli Zaretskii
2015-06-24 15:44 ` Phillip Lord
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83si9jhi5u.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=bruce.connor.am@gmail.com \
--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 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.