unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Emacs release and bundling GNU Elpa
@ 2015-06-21  9:59 Artur Malabarba
  2015-06-22  0:45 ` Stefan Monnier
  0 siblings, 1 reply; 19+ messages in thread
From: Artur Malabarba @ 2015-06-21  9:59 UTC (permalink / raw)
  To: emacs-devel, Stefan Monnier

I think the ability to specify Elpa packages that should be bundled
with Emacs would be a big improvement.

Stefan, you've mentioned a few times here you'd like some
build-scripts integration between GNU Elpa and the Emacs source at
build time. Could you clarify on what it would take to get that done?

- Is it just a matter of pulling in some extra specified packages when
building the tarball?
- What/where are the files involved in that process?
- How would this work with developers who just clone emacs.git and run
`make bootstrap`? Should the script ask the user to clone GElpa too?


Thanks and cheer
Artur



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Emacs release and bundling GNU Elpa
  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 15:33   ` Eli Zaretskii
  0 siblings, 2 replies; 19+ messages in thread
From: Stefan Monnier @ 2015-06-22  0:45 UTC (permalink / raw)
  To: Artur Malabarba; +Cc: emacs-devel

> Stefan, you've mentioned a few times here you'd like some
> build-scripts integration between GNU Elpa and the Emacs source at
> build time. Could you clarify on what it would take to get that done?

Good question.  It's mostly open.
I see it happening in steps, mostly for historical reasons:

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.

> - Is it just a matter of pulling in some extra specified packages when
> building the tarball?

At first, yes.  Tho the "just" has to be adjusted based on the need to
specify exactly which version of the package to include.

> - What/where are the files involved in that process?

admin/make-tarball.txt should give you all the answers.  But the main
step is clearly to run the `make-dist' script.


        Stefan



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Emacs release and bundling GNU Elpa
  2015-06-22  0:45 ` Stefan Monnier
@ 2015-06-22 11:20   ` Phillip Lord
  2015-06-22 13:27     ` Artur Malabarba
  2015-06-22 15:33     ` Stefan Monnier
  2015-06-22 15:33   ` Eli Zaretskii
  1 sibling, 2 replies; 19+ messages in thread
From: Phillip Lord @ 2015-06-22 11:20 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Artur Malabarba, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 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.


Would it not be possible to put elpa.get into emacs.git as some kind of
subtree?

The reason I ask, is that I try to keep Emacs running somewhere close to
trunk for my daily emacs, but I find that I get mysterious errors in
unrelated packages. These are normally solved by deleting my
.emacs.d/elpa directory and starting from fresh (my config, like many I
am sure, makes this easy).

It would be nice if running make clean on emacs.git checkout would also
do a make clean on its related elpa.git.

Just a thought.

Phil



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Emacs release and bundling GNU Elpa
  2015-06-22 11:20   ` Phillip Lord
@ 2015-06-22 13:27     ` Artur Malabarba
  2015-06-22 13:30       ` Artur Malabarba
  2015-06-22 15:33     ` Stefan Monnier
  1 sibling, 1 reply; 19+ messages in thread
From: Artur Malabarba @ 2015-06-22 13:27 UTC (permalink / raw)
  To: Phillip Lord; +Cc: Stefan Monnier, emacs-devel

2015-06-22 12:20 GMT+01:00 Phillip Lord <phillip.lord@newcastle.ac.uk>:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> 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.
>
>
> Would it not be possible to put elpa.get into emacs.git as some kind of
> subtree?

Or a submodule?

> It would be nice if running make clean on emacs.git checkout would also
> do a make clean on its related elpa.git.

I thinThe elpa.git would not be built. I



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Emacs release and bundling GNU Elpa
  2015-06-22 13:27     ` Artur Malabarba
@ 2015-06-22 13:30       ` Artur Malabarba
  2015-06-22 13:30         ` Artur Malabarba
  0 siblings, 1 reply; 19+ messages in thread
From: Artur Malabarba @ 2015-06-22 13:30 UTC (permalink / raw)
  To: Phillip Lord; +Cc: Stefan Monnier, emacs-devel

>> It would be nice if running make clean on emacs.git checkout would also
>> do a make clean on its related elpa.git.
>
> I thinThe elpa.git would not be built. I

Stupid trackpad... Sent by accident.

I think the elpa.git would be built. Unless we're planning of bundling
the entire GNU Elpa into Emacs, it would only be better to copy those
few desired packages into emacs.git somewhere, and then these packages
would be compiled as part of building emacs.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Emacs release and bundling GNU Elpa
  2015-06-22 13:30       ` Artur Malabarba
@ 2015-06-22 13:30         ` Artur Malabarba
  2015-06-22 15:22           ` Phillip Lord
  0 siblings, 1 reply; 19+ messages in thread
From: Artur Malabarba @ 2015-06-22 13:30 UTC (permalink / raw)
  To: Phillip Lord; +Cc: Stefan Monnier, emacs-devel

2015-06-22 14:30 GMT+01:00 Artur Malabarba <bruce.connor.am@gmail.com>:
>>> It would be nice if running make clean on emacs.git checkout would also
>>> do a make clean on its related elpa.git.
>>
>> I thinThe elpa.git would not be built. I
>
> Stupid trackpad... Sent by accident.
>
> I think the elpa.git would be built.

Gaah!! Sorry again. I meant: Would NOT be build.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Emacs release and bundling GNU Elpa
  2015-06-22 13:30         ` Artur Malabarba
@ 2015-06-22 15:22           ` Phillip Lord
  0 siblings, 0 replies; 19+ messages in thread
From: Phillip Lord @ 2015-06-22 15:22 UTC (permalink / raw)
  To: Artur Malabarba; +Cc: Stefan Monnier, emacs-devel

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> 2015-06-22 14:30 GMT+01:00 Artur Malabarba <bruce.connor.am@gmail.com>:
>>>> It would be nice if running make clean on emacs.git checkout would also
>>>> do a make clean on its related elpa.git.
>>>
>>> I thinThe elpa.git would not be built. I
>>
>> Stupid trackpad... Sent by accident.
>>
>> I think the elpa.git would be built.
>
> Gaah!! Sorry again. I meant: Would NOT be build.



You are having a rough time of it!

So, I think either way could work. Or setting up paths so that only the
desired packages are there, and byte-compiling the relevant bits).

One problem that leaps to mind, BTW, with the current ELPA set up is
that you don't actually get all of ELPA packages at once with a single
clone, since many packages are on branches. So, you'd need to do
multiple clones (depending on how many externals you want). Or something
clever with git-new-workdir. I have little experience with either of
these, I am afraid.

Phil






^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Emacs release and bundling GNU Elpa
  2015-06-22  0:45 ` Stefan Monnier
  2015-06-22 11:20   ` Phillip Lord
@ 2015-06-22 15:33   ` Eli Zaretskii
  2015-06-22 16:50     ` Stephen Leake
                       ` (2 more replies)
  1 sibling, 3 replies; 19+ messages in thread
From: Eli Zaretskii @ 2015-06-22 15:33 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: bruce.connor.am, emacs-devel

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.)



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Emacs release and bundling GNU Elpa
  2015-06-22 11:20   ` Phillip Lord
  2015-06-22 13:27     ` Artur Malabarba
@ 2015-06-22 15:33     ` Stefan Monnier
  1 sibling, 0 replies; 19+ messages in thread
From: Stefan Monnier @ 2015-06-22 15:33 UTC (permalink / raw)
  To: Phillip Lord; +Cc: Artur Malabarba, emacs-devel

> Would it not be possible to put elpa.get into emacs.git as some kind of
> subtree?

"git subtree", no, I don't think that'll fly.

But some of the suggested steps might indeed want to use "git submodule".
This said, that would be just a detail of implementation of those steps.


        Stefan



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Emacs release and bundling GNU Elpa
  2015-06-22 15:33   ` Eli Zaretskii
@ 2015-06-22 16:50     ` Stephen Leake
  2015-06-22 17:16     ` Stefan Monnier
  2015-06-22 17:45     ` Artur Malabarba
  2 siblings, 0 replies; 19+ messages in thread
From: Stephen Leake @ 2015-06-22 16:50 UTC (permalink / raw)
  To: emacs-devel

Eli Zaretskii <eliz@gnu.org> 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 <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.

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
nothing new.

>  . 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,
nothing new.

>  . 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).

Good points.

>  . 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.

yes.

>  . 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
sufficient. 

-- 
-- Stephe



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Emacs release and bundling GNU Elpa
  2015-06-22 15:33   ` Eli Zaretskii
  2015-06-22 16:50     ` Stephen Leake
@ 2015-06-22 17:16     ` Stefan Monnier
  2015-06-22 17:45     ` Artur Malabarba
  2 siblings, 0 replies; 19+ messages in thread
From: Stefan Monnier @ 2015-06-22 17:16 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: bruce.connor.am, emacs-devel

>  . 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.

Yup, no worse than what happens for current bundled packages.
I'm not expecting major issues in this respect.  Furthermore, the
pressure to have the latest&greatest version bundled is less severe
since users can easily install a newer version later on.

>  . Core maintainers will probably start pushing more changes to the
>    packages, something I'm not sure package developers will like.

That's part of deciding which packages get bundled.  Again, that's no
worse than what happens with current bundled packages.

>  . 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).

When installed via package.el, they currently each get their own
directory indeed.  Maybe we could combine some of those directories, but
this decision will probably not be based on minor issues such as where
to put the ChangeLog entries.

>  . 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.

I was thinking of putting the NEWS entries of those packages in the
normal NEWS file.  They'd be updated by hand when we change the version
of this elpa.git package that the emacs.git tree refers to
(remember emacs.git wouldn't just say "bundle company", but "bundle
version <foo> of company").

>  . 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.

package.el already knows how to handle manuals, and while we may decide
to handle it slightly differently, I don't foresee any major issues
there (at least none that are really important to solve).

>  . 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?

Good question.  This one has existed for a long time and is not directly
related to whether ELPA packages get included in Emacs's tarball.

>    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.

No.  We can keep living with these problems unsolved.  Of course, I'd be
happy to see them solved, but bundling ELPA packages doesn't make them
significantly more pressing.


        Stefan



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Emacs release and bundling GNU Elpa
  2015-06-22 15:33   ` Eli Zaretskii
  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
  2 siblings, 1 reply; 19+ messages in thread
From: Artur Malabarba @ 2015-06-22 17:45 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Stefan Monnier, emacs-devel

I was thinking that keep a list somewhere of packages that we want to
pull from elpa. At build time, these will be copied from "./elpa.git/"
(which will probably be a submodule containing the elpa repo) to
"./lisp/from-elpa/" (which will be a .gitignored directory containing
nothing initially). This should also involve copying info manuals from
"./elpa.git/" to the right place.
I see only two differences from the current situation:

1. Instead of the usual `git pull && make bootstrap` the user wil be
expected to do something like `git pull && git submodule update &&
make bootstrap` which should be a no-brainer (maybe there's a hook or
something that can automatically do the update when `pull'ing).

2. To push a change, instead of editing the file inside
lisp/from-elpa/ you have to edit the file in the elpa.git submodule.
This is a relevant difference, but it shouldn't lead to issues. Since
the from-elpa dir is gitignored, there's no way for people to
accidentally commit changes to it. And having to edit on elpa.git is
certainly an improvement over having to edit on both emacs and
elpa.git.

2015-06-22 16:33 GMT+01:00 Eli Zaretskii <eliz@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

Why would it unsynchronise? Everyone who `git pulls` today at 12pm has
the same Emacs. Similarly, under this alternative, everyone who pulls
&& updates today at 12pm will have the same Emacs.

> and less exposure of packages to people who track development on
> master,

These packages will effectively be part of master. Pulling them in
will be a part of the build process, why would there be less exposure?

> and more hassle due to the need to work with more than one Git
> repository, multiple development philosophies, etc.

This is a fine point against moving out of emacs packages that are
only in emacs.
OTOH, we can start with these other two options (a) pull into emacs
packages that are only on Elpa (like company), and (b) move out of
emacs packages that are on both repositories (these are already a
hassle, and the hassle would only be reduced).


> 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.

Yes. This wouldn't be applied to all of elpa.git, only to those
packages that are bundled in.

>  . 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.

Yes, this is something the package developer would have to be aware,
in order for a package to be bundled in. Nobody is forced to bundle a
package in Emacs.
OTOH, for packages that are currently on both repos this already
happens, and it will be much better if for the developer if these
changes are all made to the same place.

>  . 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).

Keep their ChangeLogs in the same place as their source (in the
"./elpa.git/packages/package-name/" directory). This has nothing to do
with the load-path. The load-path will point to "./lisp/from-elpa"
(which is where we copy the sources before compiling).

>  . 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.

Yes. That can sit alongside the ChangeLog.

>  . 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.

As I said at the start. Just like the sources are pulled in at
compiled time, so are their manuals. Changelog entries for edits to
the manual go in the package's ChangeLog.

>  . 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?

They will use the :package-version tag. Like packages have always done.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Emacs release and bundling GNU Elpa
  2015-06-22 17:45     ` Artur Malabarba
@ 2015-06-22 18:49       ` Eli Zaretskii
  2015-06-23 10:55         ` Artur Malabarba
  0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2015-06-22 18:49 UTC (permalink / raw)
  To: bruce.connor.am; +Cc: monnier, emacs-devel

> Date: Mon, 22 Jun 2015 18:45:50 +0100
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel <emacs-devel@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
> 
> Why would it unsynchronise?

Because Emacs development adds new features that the packages may or
may not want to use, and Emacs deprecates obsolete features that the
packages may or may not want to remove.  When a single team handles
that, the policy is always consistent; not so when independent teams
with independent agendas do the same.

> > and less exposure of packages to people who track development on
> > master,
> 
> These packages will effectively be part of master.

Only if one decides to pull them.  Since that's at least a bit of an
additional hassle, one could decide not to bother.

> >  . 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).
> 
> Keep their ChangeLogs in the same place as their source (in the
> "./elpa.git/packages/package-name/" directory). This has nothing to do
> with the load-path. The load-path will point to "./lisp/from-elpa"
> (which is where we copy the sources before compiling).

Aren't you forgetting that ChangeLog files need to be part of the
release tarball?  Or do you mean we will have each package twice in a
tarball, in 2 different directories?



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Emacs release and bundling GNU Elpa
  2015-06-22 18:49       ` Eli Zaretskii
@ 2015-06-23 10:55         ` Artur Malabarba
  2015-06-23 13:20           ` Stefan Monnier
  0 siblings, 1 reply; 19+ messages in thread
From: Artur Malabarba @ 2015-06-23 10:55 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Stefan Monnier, emacs-devel

>> > and less exposure of packages to people who track development on
>> > master,
>>
>> These packages will effectively be part of master.
>
> Only if one decides to pull them.  Since that's at least a bit of an
> additional hassle, one could decide not to bother.

If this is taken forward, copying these packages sources from elpa.git
to emacs not be optional, i.e., it will be a mandatory step in the
make command. This is the only way for other packages in “./lisp/” to
be able to depend on these imported packages.
Updating the submodule will only be necessary once in a while (when
the configuration file specifies a newer version for a package than
the version you have locally, and the makefile will tell you about
that), but it will be necessary.

>> >  . 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).
>>
>> Keep their ChangeLogs in the same place as their source (in the
>> "./elpa.git/packages/package-name/" directory). This has nothing to do
>> with the load-path. The load-path will point to "./lisp/from-elpa"
>> (which is where we copy the sources before compiling).
>
> Aren't you forgetting that ChangeLog files need to be part of the
> release tarball?  Or do you mean we will have each package twice in a
> tarball, in 2 different directories?

Good point. How about, whenever we copy the source to
“./lisp/from-elpa/” we also copy the ChangeLog to the same place, but
rename it to something like ChangeLog-packagename? So they can all
coexist in that directory.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Emacs release and bundling GNU Elpa
  2015-06-23 10:55         ` Artur Malabarba
@ 2015-06-23 13:20           ` Stefan Monnier
  0 siblings, 0 replies; 19+ messages in thread
From: Stefan Monnier @ 2015-06-23 13:20 UTC (permalink / raw)
  To: Artur Malabarba; +Cc: Eli Zaretskii, emacs-devel

> If this is taken forward, copying these packages sources from elpa.git
> to emacs not be optional, i.e., it will be a mandatory step in the
> make command. This is the only way for other packages in “./lisp/” to
> be able to depend on these imported packages.
> Updating the submodule will only be necessary once in a while (when
> the configuration file specifies a newer version for a package than
> the version you have locally, and the makefile will tell you about
> that), but it will be necessary.

I think that for 25.1, we could limit this to step 1 or 2.  I.e. it
should mandatorily be included in the tarball, but when building from
Git it should still be optional (or not supported at all).


        Stefan



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Emacs release and bundling GNU Elpa
@ 2015-06-24  8:12 Barry
  2015-06-24 14:04 ` Stefan Monnier
                   ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: Barry @ 2015-06-24  8:12 UTC (permalink / raw)
  To: monnier, emacs-devel

Stefan:
> step-3: we change the build scripts again so they always use those
> packages from elpa.git.

What are the essential reasons for having two Git repos rather than one?

Stefan:
> - 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).

Is the vision that core Emacs could eventually be reduced to the Elisp engine and other infrastructure, and ELPA constitutes the features? If so, then shouldn't Emacs in principle be buildable and runnable without ELPA packages, with the caveat that commands would be missing?

Eli:
> 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

Right, tracking emacs.git master would hopefully entail tracking elpa.git master.

Eli:
> Core maintainers will probably start pushing more changes to the
> packages, something I'm not sure package developers will like.

This is a virtue. Package maintainers would be involved in the same way as when their package is in emacs.git.

Eli:
> We'd need to find a way of providing ChangeLogs for the packages

Duplicates 'git log PACKAGE-DIR'.




^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Emacs release and bundling GNU Elpa
  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
  2 siblings, 0 replies; 19+ messages in thread
From: Stefan Monnier @ 2015-06-24 14:04 UTC (permalink / raw)
  To: Barry; +Cc: emacs-devel

>> step-3: we change the build scripts again so they always use those
>> packages from elpa.git.
> What are the essential reasons for having two Git repos rather than one?

If you look beyond actual repositories (which are just arbitrary
containers of data), there are more than 2 branches: there's the
emacs.git branch "master", the elpa.git branch "master", and the various
other elpa.git branches of the form "externals/<pkg>".

We want ELPA packages to live their own life, to be released at their
own pace.

> Is the vision that core Emacs could eventually be reduced to the Elisp
> engine and other infrastructure, and ELPA constitutes the features?

No.

>> 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

Yes, there will be more total bugs, simply because the Emacs tarball will
be bigger.  But as long as those "bundled ELPA packages" (BEPs) don't
affect other bundled packages, it's not worse than if the user
had to install those packages by hand.

So all it takes to keep those extra bugs under control is to check the
autoloads of those BEPs.


        Stefan



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Emacs release and bundling GNU Elpa
  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
  2 siblings, 0 replies; 19+ messages in thread
From: Eli Zaretskii @ 2015-06-24 15:01 UTC (permalink / raw)
  To: Barry; +Cc: monnier, emacs-devel

> From: Barry <gundaetiapo@yahoo.com>
> Date: Wed, 24 Jun 2015 01:12:16 -0700
> 
> Eli:
> > We'd need to find a way of providing ChangeLogs for the packages
> 
> Duplicates 'git log PACKAGE-DIR'.

No: I meant provide them in the release tarball.



^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: Emacs release and bundling GNU Elpa
  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
  2 siblings, 0 replies; 19+ messages in thread
From: Phillip Lord @ 2015-06-24 15:44 UTC (permalink / raw)
  To: Barry; +Cc: monnier, emacs-devel

Barry <gundaetiapo@yahoo.com> writes:
>> 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
>
> Right, tracking emacs.git master would hopefully entail tracking
> elpa.git master.


"masters". elpa.git is a multi-headed beast, unfortunately. Many
packages are on branches.

Phil



^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2015-06-24 15:44 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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

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).