[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs release and bundling GNU Elpa
Re: Emacs release and bundling GNU Elpa
Mon, 22 Jun 2015 11:50:06 -0500
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt)
Eli Zaretskii <address@hidden> writes:
> 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 <address@hidden>
>> Date: Sun, 21 Jun 2015 20:45:36 -0400
>> Cc: emacs-devel <address@hidden>
>> 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.
Only for ELPA pacakges that will be included in the Emacs tarball. These
are the same requirements as on packages that are in emacs git, so it's
> . Core maintainers will probably start pushing more changes to the
> packages, something I'm not sure package developers will like.
That is a requirement of including a package in the tarball. Again,
> . 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.
That should be the case for ELPA packages anyway.
> . 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 suggest :version contain the package version. To correlate that with
an Emacs version, the NEWS entry for the package release date should be
Re: Emacs release and bundling GNU Elpa, Eli Zaretskii, 2015/06/22
- Re: Emacs release and bundling GNU Elpa,
Stephen Leake <=
- Re: Emacs release and bundling GNU Elpa, Stefan Monnier, 2015/06/22
- Re: Emacs release and bundling GNU Elpa, Artur Malabarba, 2015/06/22
- Re: Emacs release and bundling GNU Elpa, Eli Zaretskii, 2015/06/22
- Re: Emacs release and bundling GNU Elpa, Artur Malabarba, 2015/06/23
- Re: Emacs release and bundling GNU Elpa, Stefan Monnier, 2015/06/23