Getting start on Emacs 25.2

Getting start on Emacs 25.2

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

Hi all,

Congratulations to everyone on getting 25.1 released and out the door! This
involved a lot of hard work by many people, and I appreciate all the lost
evenings spent coding, reviewing bugs, writing documentation, and improving
our testing framework.

Now that 25.1 is out the door, it's time to begin work on 25.2. I'd like to
ask those who are aware of patches that might have been applied to 25.1, but
weren't due to time pressure, to review those patches and consider
cherry-picking them to the emacs-25 branch, which is now open to such changes.

New feature work should continue on 'master', toward the 26.1 release.

Speaking of whiche, one the first things I'd like to achieve toward 26.1 is
the new ELPA infrastructure we've discussed in the past -- the ability to
designate ELPA packages as (1) "usable by core" (2) "included in the
distribution tarball" and (3) "installed using package.el". I've been calling
these "core ELPA", "tarball ELPA" and "package ELPA", respectively.

Phil Lord has already done some further investigations down this road, so soon
we'll have an open discussion on how best to achieve this technically.

Again, many thanks to everyone,
-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Getting start on Emacs 25.2

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, Richard Stallman <rms@gnu.org>
> Date: Sat, 17 Sep 2016 19:45:55 -0700
> 
> Now that 25.1 is out the door, it's time to begin work on 25.2. I'd like to
> ask those who are aware of patches that might have been applied to 25.1, but
> weren't due to time pressure, to review those patches and consider
> cherry-picking them to the emacs-25 branch, which is now open to such changes.

My gut feeling is that everything on master is relevant to Emacs 25.2,
and therefore we should probably start a new branch, called emacs-25.2
or some such, forking it off master.  Trying to go through the changes
deciding which ones are worthy of cherry-picking is IMO a waster of
our time, as no AFAIR major features were pushed to master that would
be inappropriate for 25.2.

Alternatively, we could decide that 25.2 will be a bugfix only
release, in which case none of the changes on master should be in it,
only bugs that will be reported hence about the released version.

My $0.20, anyway.

Re: Getting start on Emacs 25.2

[Stefan Monnier]

>> Now that 25.1 is out the door, it's time to begin work on 25.2. I'd
>> like to ask those who are aware of patches that might have been
>> applied to 25.1, but weren't due to time pressure, to review those
>> patches and consider cherry-picking them to the emacs-25 branch,
>> which is now open to such changes.

Maybe a good start is to look at those commits on master whose commit
message refers to a bug#.

> My gut feeling is that everything on master is relevant to Emacs 25.2,
> and therefore we should probably start a new branch, called Emacs-25.2
> or some such, forking it off master.

Master includes a fairly large number of changes already, so it's
clearly not fit for a quick bug-fix-only release.

IOW what you're suggesting is to forgo bug-fix releases and go straight
to the next "feature" release (maybe with fairly few features).

I'm fine with it, but I'd call it Emacs-26, then ;-)

> Alternatively, we could decide that 25.2 will be a bugfix only
> release, in which case none of the changes on master should be in it,
> only bugs that will be reported hence about the released version.

I'd vote for that option (but accepting some cherrypicks from master
from those people who care enough to take the time to do that).
[ Of course, nobody should be surprised at this point: back in the
  time of 24.5 I made it clear that I think the ".MM" part should be
  used exclusively for bugfix-only releases, so Emacs-24.3 should have
  been called Emacs-25.1.  ]


        Stefan

Re: Getting start on Emacs 25.2

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> Alternatively, we could decide that 25.2 will be a bugfix only
> release, in which case none of the changes on master should be in it,
> only bugs that will be reported hence about the released version.

I think 25.2 should be a bugfix only release, happening very soon. What's in
'master' should become 26, and I'd be happy with releasing that even in just a
few months. I'm OK with picking up the pace of our major releases, if you are.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: Getting start on Emacs 25.2

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 358 bytes --]

John Wiegley <jwiegley@gmail.com> writes:

> I think 25.2 should be a bugfix only release, happening very soon. What's in
> 'master' should become 26, and I'd be happy with releasing that even in just a
> few months. I'm OK with picking up the pace of our major releases, if
> you are.

I would really like to have more regular major releases.

Cheers,
Nico

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: Getting start on Emacs 25.2

[Andreas Röhler]

On 18.09.2016 23:23, Nicolas Petton wrote:
> John Wiegley <jwiegley@gmail.com> writes:
>
>> I think 25.2 should be a bugfix only release, happening very soon. What's in
>> 'master' should become 26, and I'd be happy with releasing that even in just a
>> few months. I'm OK with picking up the pace of our major releases, if
>> you are.
> I would really like to have more regular major releases.
>
> Cheers,
> Nico

Hi John and all,

thanks a lot for all your work!
IIUC siding here with Eli and Nicolas: care for bugs with priority, but 
don't waste release-efforts with it.

Cheers,
Andreas

Re: Getting start on Emacs 25.2

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: emacs-devel@gnu.org,  rms@gnu.org
> Date: Sun, 18 Sep 2016 12:41:44 -0700
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Alternatively, we could decide that 25.2 will be a bugfix only
> > release, in which case none of the changes on master should be in it,
> > only bugs that will be reported hence about the released version.
> 
> I think 25.2 should be a bugfix only release, happening very soon.

Then we'd need a good definition of what changes constitute a
"bugfix".

Re: Getting start on Emacs 25.2

[Phillip Lord]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: John Wiegley <jwiegley@gmail.com>
>> Cc: emacs-devel@gnu.org,  rms@gnu.org
>> Date: Sun, 18 Sep 2016 12:41:44 -0700
>> 
>> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Alternatively, we could decide that 25.2 will be a bugfix only
>> > release, in which case none of the changes on master should be in it,
>> > only bugs that will be reported hence about the released version.
>> 
>> I think 25.2 should be a bugfix only release, happening very soon.
>
> Then we'd need a good definition of what changes constitute a
> "bugfix".

I don't think anyone has managed that for any form of software. A
working rule of thumb is the best we are likely to get, but that should
be enough.

Phil

Re: Getting start on Emacs 25.2

[Eli Zaretskii]

> From: phillip.lord@russet.org.uk (Phillip Lord)
> Cc: John Wiegley <jwiegley@gmail.com>,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Thu, 22 Sep 2016 13:57:02 +0100
> 
> >> I think 25.2 should be a bugfix only release, happening very soon.
> >
> > Then we'd need a good definition of what changes constitute a
> > "bugfix".
> 
> I don't think anyone has managed that for any form of software. A
> working rule of thumb is the best we are likely to get, but that should
> be enough.

There's no differences between the two, for our purposes in this
case.  Rule of thumb is the same as definition in this context, and
both need to be good.  Otherwise, we will either release 25.2 that
won't be an improvement wrt 25.1, or will waste a lot of time and
energy arguing just what changes to commit to the release branch.

Re: Getting start on Emacs 25.2

[Phillip Lord]

John Wiegley <jwiegley@gmail.com> writes:
> Speaking of whiche, one the first things I'd like to achieve toward 26.1 is
> the new ELPA infrastructure we've discussed in the past -- the ability to
> designate ELPA packages as (1) "usable by core" (2) "included in the
> distribution tarball" and (3) "installed using package.el". I've been calling
> these "core ELPA", "tarball ELPA" and "package ELPA", respectively.

I'm still slightly confused by this, so let me have a go at
clarification. First some terminology, because I think things are
getting confusing with the term "package":

 - package -- a set of lisp files, `provide`ing a co-ordinated set of
   features. Examples: gnus, seq.el, vc

 - Core format -- a package laid out according to current core
   directories -- i.e. source in a (nested) dir in the lisp dir, test in
   another. Examples: gnus, org
   
 - package.el format -- a package with headers, and directories laid out
   for package.el. Examples: gnus and org (again!)

 - ELPA -- the set of package.el format packages available on the web,
   with associated repo.

Currently, we have

 - packages in core format in Emacs Git and build
 - packages in package.el format in ELPA git and build
 - a few packages in both (org and seq I think)

In the future I see:

 - packages in core format in Emacs git and build. Those packages
   involved in bootstrap, startup and package.el itself have to remain
   in this state. Everything else can, but need not.
 - packages in package.el format that are guaranteed to be present in
   any Emacs download.
 - packages in package.el format that are present in any download and
   also available on ELPA.
 - packages in package.el format that are available only on ELPA.

My belief is that most packages would be better in package.el format,
although I don't see an immediate case for re-formatting them wholesale.

I'm not sure I understand your distinction between "core ELPA" and
"tarball ELPA".

> Phil Lord has already done some further investigations down this road, so soon
> we'll have an open discussion on how best to achieve this technically.

So far, I've added the ability to (partial) support for packages in
package.el format directly to the Emacs build, which seems the obvious
way to support points 2 and 3 from above.

Phil

Re: Getting start on Emacs 25.2

[Michael Albinus]

phillip.lord@russet.org.uk (Phillip Lord) writes:

>  - Core format -- a package laid out according to current core
>    directories -- i.e. source in a (nested) dir in the lisp dir, test in
>    another. Examples: gnus, org

A "core" package isn't located in its own subdirectory mandatorily. I would
call tramp a package in core Emacs, but its files are distributed over
doc/misc, lisp/net and test/lisp/net.

> Phil

Best regards, Michael.

Re: Getting start on Emacs 25.2

[Phillip Lord]

Michael Albinus <michael.albinus@gmx.de> writes:

> phillip.lord@russet.org.uk (Phillip Lord) writes:
>
>>  - Core format -- a package laid out according to current core
>>    directories -- i.e. source in a (nested) dir in the lisp dir, test in
>>    another. Examples: gnus, org
>
> A "core" package isn't located in its own subdirectory mandatorily. I would
> call tramp a package in core Emacs, but its files are distributed over
> doc/misc, lisp/net and test/lisp/net.


Indeed, no. That would be the main difference between core and
package.el format.

Phil

Re: Getting start on Emacs 25.2

[John Wiegley]

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

>>>>> "PL" == Phillip Lord <phillip.lord@russet.org.uk> writes:

PL> My belief is that most packages would be better in package.el format,
PL> although I don't see an immediate case for re-formatting them wholesale.

I'm not entirely sure that this is better. For the immediate future, I'd like
us to have a way of "viewing ELPA" from Emacs.git, such that there's nothing
special we need to do in Emacs.git in order to include or rely on ELPA
packages (such as requiring the use of package.el structure).

I see incorporating package.el as a separate issue, and one that we should
solve after we mechanize inclusion of ELPA packages into Emacs core or the
distribution.  Because we're already doing the latter, just manually. So let's
automate that, get it working smoothly, and then after we can have a separate
discussion about whether we should be relying on package.el more than we are.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]