emacs-25 merge pushed, please confirm

emacs-25 merge pushed, please confirm

[John Wiegley]

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

I just pushed up another emacs-25 -> master merge, this time using gitmerge.
This is just a request to check that everything looks as it should.

-- 
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: emacs-25 merge pushed, please confirm

[Alex Bennée]

John Wiegley <jwiegley@gmail.com> writes:

> I just pushed up another emacs-25 -> master merge, this time using gitmerge.
> This is just a request to check that everything looks as it should.

Just to confirm emacs-25 is the branch to follow for those tracking the
stabilisation of the next release? The merges from emacs-25 to master
are so fixes get merged into what will be mainline development once
emacs-25 is out?

--
Alex Bennée

Re: emacs-25 merge pushed, please confirm

[John Wiegley]

>>>>> Alex Bennée <alex.bennee@linaro.org> writes:

> Just to confirm emacs-25 is the branch to follow for those tracking the
> stabilisation of the next release? The merges from emacs-25 to master are so
> fixes get merged into what will be mainline development once emacs-25 is
> out?

Correct.

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

Next release from master

[Stefan Monnier]

BTW,

I noticed that etc/NEWS on master is setup for "25.2" being the next
release from master.  Is that indeed the intention?

My own conclusion based on how things worked during Emacs-24.N was that
we're better off incrementing the major version every time there are new
features.  IOW the next release form master should be called 26.1 and
25.N should be kept for a bugfix-only releases from the emacs-25 branch.

It's not tremendously important, but the way we've done it in the past
ended up with all kinds of minor inconveniences when we suddenly decide
that we need another bugfix release: e.g. having to update all
"make-obsolete" calls, not to mention all the "will be fixed in (or
added to) Emacs-NN.MM" already posted in debbugs, mailing-lists,
stackoverflow, forums, and newsgroups which suddenly become lies.


        Stefan

Re: Next release from master

[John Wiegley]

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

>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:

> My own conclusion based on how things worked during Emacs-24.N was that
> we're better off incrementing the major version every time there are new
> features. IOW the next release form master should be called 26.1 and 25.N
> should be kept for a bugfix-only releases from the emacs-25 branch.

I think you have a good point, Stefan. master should become emacs-26 at some
point in the future, once it's ready, while emacs-25 should only continue to
improve and stabilize the 25.x series.

I imagine we will be actively working in emacs-25 for at least 25.1 and 25.2,
before shifting attention over to master and leaving emacs-25 only for
maintenance.

-- 
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: Next release from master

[Michael Albinus]

John Wiegley <jwiegley@gmail.com> writes:

>> My own conclusion based on how things worked during Emacs-24.N was that
>> we're better off incrementing the major version every time there are new
>> features. IOW the next release form master should be called 26.1 and 25.N
>> should be kept for a bugfix-only releases from the emacs-25 branch.
>
> I think you have a good point, Stefan. master should become emacs-26 at some
> point in the future, once it's ready, while emacs-25 should only continue to
> improve and stabilize the 25.x series.
>
> I imagine we will be actively working in emacs-25 for at least 25.1 and 25.2,
> before shifting attention over to master and leaving emacs-25 only for
> maintenance.

What release cycles are we're speaking about, in terms of time? Example:
I have committed the first bits to the master branch of what would be
Tramp 2.3. Incompatible (the code, NOT the external interface) to Tramp
2.2.13 in Emacs 25.1. If it takes a long time until Emacs 26 is
released, that code should go to Emacs 25.2, somehow. 

Best regards, Michael.

Re: Next release from master

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Mon, 18 Jan 2016 10:06:14 +0100
> 
> What release cycles are we're speaking about, in terms of time? Example:
> I have committed the first bits to the master branch of what would be
> Tramp 2.3. Incompatible (the code, NOT the external interface) to Tramp
> 2.2.13 in Emacs 25.1. If it takes a long time until Emacs 26 is
> released, that code should go to Emacs 25.2, somehow.

If that's what you want, you will need to lobby for back-porting those
changes after 25.1 is released (assuming 25.2 will be released from
the Emacs-25 branch, that is).

Re: Next release from master

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> If that's what you want, you will need to lobby for back-porting those
> changes after 25.1 is released (assuming 25.2 will be released from
> the Emacs-25 branch, that is).

That's what I've feared. Double work. Hmm, so what ...

Best regards, Michael.

Re: Next release from master

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Mon, 18 Jan 2016 21:06:19 +0100
> Cc: emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If that's what you want, you will need to lobby for back-porting those
> > changes after 25.1 is released (assuming 25.2 will be released from
> > the Emacs-25 branch, that is).
> 
> That's what I've feared. Double work.

Backport boils down to cherry-picking certain commits, so it's hardly
double work.  Or maybe I don't understand what work did you have in
mind.

In any case, this is one reason why maintaining a package outside
Emacs has its downsides.

Re: Next release from master

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Date: Sun, 17 Jan 2016 15:10:13 -0800
> Cc: emacs-devel@gnu.org
> 
> > My own conclusion based on how things worked during Emacs-24.N was that
> > we're better off incrementing the major version every time there are new
> > features. IOW the next release form master should be called 26.1 and 25.N
> > should be kept for a bugfix-only releases from the emacs-25 branch.
> 
> I think you have a good point, Stefan. master should become emacs-26 at some
> point in the future, once it's ready, while emacs-25 should only continue to
> improve and stabilize the 25.x series.

Are you changing your mind? ;-)  You told me something different in
http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01372.html.

> I imagine we will be actively working in emacs-25 for at least 25.1 and 25.2,
> before shifting attention over to master and leaving emacs-25 only for
> maintenance.

You seem to be talking about something that never happened before in
Emacs: we never left any branch "for maintenance", we left it for
good.  Once the decision was made that the next release will be from
master, the branch was abandoned, and never revisited except in
emergency (e.g., if some super-critical bug was reported in the last
release that required an urgent fix).

Re: Next release from master

[John Wiegley]

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

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

>> master should become emacs-26 at some point in the future, once it's ready,
>> while emacs-25 should only continue to improve and stabilize the 25.x
>> series.

> Are you changing your mind? ;-) You told me something different in
> http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01372.html.

Yes, I suppose I am.

'master' should be a place where people can commit API-breaking changes once
they are ready for general consumption; otherwise, such changes would have to
live in feature branches for a very long time, and we'd have little ability to
test them in combination.

However, changes of that magnitude shouldn't happen between 25.1 and 25.2;
that's not what a minor release means to me. When things really start
changing, we should think of them as going into the next major release.

Therefore, the emacs-25 branch will stabilize over time until there's nothing
more to do there. Although many will abandon the branch altogether in favor of
master at some point, there might still be some who wish to fix bugs there and
call for a point release.

I imagine this will lead to more frequent major releases, and fewer point
releases, but that really depends on what we're doing. The more bug work we
do, the more point releases; the more feature work, the more major releases.

I'm not sure that I'm calling for anything radically different than what has
happened before, though.  Are you saying that in the past, what is now master
would become 25.2? What then of features that are destined for 26 and not
future versions of 25.x?

> You seem to be talking about something that never happened before in Emacs:
> we never left any branch "for maintenance", we left it for good. Once the
> decision was made that the next release will be from master, the branch was
> abandoned, and never revisited except in emergency (e.g., if some
> super-critical bug was reported in the last release that required an urgent
> fix).

Yes, I may be talking about something that never happened before in Emacs, but
it's been valuable on other projects, so I thought we might try it here as
well.

That said, if a shift to master means no one ever fixes another bug on
emacs-25, then there will be effectively no change; but the branch can still
hang around for a while, and be available for point releases if necessary.

-- 
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: Next release from master

[Daniel Colascione]

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

On 01/18/2016 01:13 PM, John Wiegley wrote:
>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> master should become emacs-26 at some point in the future, once it's ready,
>>> while emacs-25 should only continue to improve and stabilize the 25.x
>>> series.
> 
>> Are you changing your mind? ;-) You told me something different in
>> http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01372.html.
> 
> Yes, I suppose I am.
> 
> 'master' should be a place where people can commit API-breaking changes once
> they are ready for general consumption; otherwise, such changes would have to
> live in feature branches for a very long time, and we'd have little ability to
> test them in combination.
> 
> However, changes of that magnitude shouldn't happen between 25.1 and 25.2;
> that's not what a minor release means to me. When things really start
> changing, we should think of them as going into the next major release.
> 
> Therefore, the emacs-25 branch will stabilize over time until there's nothing
> more to do there. Although many will abandon the branch altogether in favor of
> master at some point, there might still be some who wish to fix bugs there and
> call for a point release.
> 
> I imagine this will lead to more frequent major releases, and fewer point
> releases, but that really depends on what we're doing. The more bug work we
> do, the more point releases; the more feature work, the more major releases.
> 
> I'm not sure that I'm calling for anything radically different than what has
> happened before, though.  Are you saying that in the past, what is now master
> would become 25.2? What then of features that are destined for 26 and not
> future versions of 25.x?
> 
>> You seem to be talking about something that never happened before in Emacs:
>> we never left any branch "for maintenance", we left it for good. Once the
>> decision was made that the next release will be from master, the branch was
>> abandoned, and never revisited except in emergency (e.g., if some
>> super-critical bug was reported in the last release that required an urgent
>> fix).
> 
> Yes, I may be talking about something that never happened before in Emacs, but
> it's been valuable on other projects, so I thought we might try it here as
> well.
> 
> That said, if a shift to master means no one ever fixes another bug on
> emacs-25, then there will be effectively no change; but the branch can still
> hang around for a while, and be available for point releases if necessary.
> 

I'd be happy with switching to a less-like release scheme and
incrementing a single number. Do minor releases even make sense anymore?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Next release from master

[John Wiegley]

>>>>> Daniel Colascione <dancol@dancol.org> writes:

> I'd be happy with switching to a less-like release scheme and
> incrementing a single number. Do minor releases even make sense anymore?

I think so. If we only increment major numbers, there is no sense of when big
things happen, and or how much one should expect APIs to change between
releases.

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

Re: Next release from master

[Daniel Colascione]

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

On 01/18/2016 01:43 PM, John Wiegley wrote:
>>>>>> Daniel Colascione <dancol@dancol.org> writes:
> 
>> I'd be happy with switching to a less-like release scheme and
>> incrementing a single number. Do minor releases even make sense anymore?
> 
> I think so. If we only increment major numbers, there is no sense of when big
> things happen, and or how much one should expect APIs to change between
> releases.

We try to keep APIs backward-compatible anyway though. In a
single-number, time-based release system, we'd just announce that we're
deprecating some API, and some time later, actually do it.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Next release from master

[John Wiegley]

>>>>> Daniel Colascione <dancol@dancol.org> writes:

> We try to keep APIs backward-compatible anyway though. In a
> single-number, time-based release system, we'd just announce that we're
> deprecating some API, and some time later, actually do it.

Not quite the same, though, since people have to track down and read those
announcements to know what sort of impact release 29 will have on code that
was written again 26. It's fairly easy today to expect that something you
wrote for 24.x should be expected to work over the entire 24.x series; and
equally that you're likely to need to do some work to get it running it on
25.x.

A single increasing number, or a time value, removes all meaningful content
from version numbers. Having x.y at least communicates something about the
relative meanings of x and y.

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

Re: Next release from master

[Stefan Monnier]

> was written again 26. It's fairly easy today to expect that something you
> wrote for 24.x should be expected to work over the entire 24.x series;

Of course, I totally broke that promise with cl-lib first and
nadvice later.


        Stefan

Re: Next release from master

[John Wiegley]

>>>>> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> Of course, I totally broke that promise with cl-lib first and nadvice later.

Yes, those would have definitely fallen into my "major release" category. :)

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

Re: Next release from master

[Eli Zaretskii]

> From: Daniel Colascione <dancol@dancol.org>
> Date: Mon, 18 Jan 2016 13:45:45 -0800
> 
> >> I'd be happy with switching to a less-like release scheme and
> >> incrementing a single number. Do minor releases even make sense anymore?
> > 
> > I think so. If we only increment major numbers, there is no sense of when big
> > things happen, and or how much one should expect APIs to change between
> > releases.
> 
> We try to keep APIs backward-compatible anyway though. In a
> single-number, time-based release system, we'd just announce that we're
> deprecating some API, and some time later, actually do it.

For the developers, the numbering scheme is much less important than
the distinction between a bugfix and a feature releases, IMO.

We should also not forget the users and the downstream package
maintainers, perhaps the numbering scheme means something to them.  We
should consider that if we think to change the numbering.

In any case I think this is a very minor issue, so we should think
twice before starting another bike-shedding thread about that.

Re: Next release from master

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sun, 17 Jan 2016 18:04:17 -0500
> 
> I noticed that etc/NEWS on master is setup for "25.2" being the next
> release from master.  Is that indeed the intention?

I think we don't know yet.

> My own conclusion based on how things worked during Emacs-24.N was that
> we're better off incrementing the major version every time there are new
> features.  IOW the next release form master should be called 26.1 and
> 25.N should be kept for a bugfix-only releases from the emacs-25 branch.

There's a new kid on the block (not me, I'm anything but "new" ;-),
and he needs time to make up his mind about what exactly will be
released, when, and how.  What you see now was asked and answered:

  From http://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01372.html:

  > >>>>> Eli Zaretskii writes:
  > 
  > > We should now change master to identify itself as version 25.1.50 or maybe
  > > even 26.0.50. OK?
  > 
  > Let's go with 25.1.50 for now.

> It's not tremendously important, but the way we've done it in the past
> ended up with all kinds of minor inconveniences when we suddenly decide
> that we need another bugfix release: e.g. having to update all
> "make-obsolete" calls, not to mention all the "will be fixed in (or
> added to) Emacs-NN.MM" already posted in debbugs, mailing-lists,
> stackoverflow, forums, and newsgroups which suddenly become lies.

I don't see any good way around these issues, as long as the decisions
are dynamic and not subject to some fixed deterministic algorithm.
Even if we somehow force ourselves to make the decision now, there
will be similar issues in the other direction, see Michael's email
down-thread.

These issues are not a catastrophe, making those changes (where
necessary) is a simple (though boring and ungrateful) job.

Re: Next release from master

[Glenn Morris]

Stefan Monnier wrote:

> IOW the next release form master should be called 26.1 and 25.N should
> be kept for a bugfix-only releases from the emacs-25 branch.
>
> It's not tremendously important, but the way we've done it in the past
> ended up with all kinds of minor inconveniences when we suddenly decide
> that we need another bugfix release: e.g. having to update all
> "make-obsolete" calls, not to mention all the "will be fixed in (or
> added to) Emacs-NN.MM" already posted in debbugs, mailing-lists,
> stackoverflow, forums, and newsgroups which suddenly become lies.

FWIW, I just want to echo the above (which reiterates the policy from
https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00872.html ,
which was accepted without much debate at the time).

In master, bugs are already being marked as fixed in 25.2, items as
changed in 25.2, etc. If after 25.1 is released, an unexpected rapid
bug-fix 25.2 release is needed from the emacs-25 branch, those
references have to be changed (where possible; obviously references
outside Emacs won't be changeable). The longer master claims to be the
precursor to 25.2, rather than 26.1, the more inconvenient this becomes.

Version numbers need to be expandable (to allow for unexpected bug-fix
releases) and predictable (to avoid having to change references to the
number). The major.minor scheme, where major is bumped every non-bugfix
release, allows for that.

This means that if all goes as planned: 26.1 might not contain any
"major" new features, and 25.2 will never exist. (Unless someone wants
to maintain a bug-fix release branch, but that's a separate topic. This
scheme allows for it, whereas the old one didn't. This scheme probably
also allows for more frequent releases, which is something people have
asked for, since an extra maintenance release can be made at any time
without disruption.) This might take a little bit of getting used to,
but eg the Linux kernel, Firefox, etc, have all stopped being so
conservative with version numbers.


Long story short: if agreed, please renumber master to 26.0.50 asap.

Re: Next release from master

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Thu, 21 Jan 2016 12:35:15 -0500
> 
> FWIW, I just want to echo the above (which reiterates the policy from
> https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00872.html ,
> which was accepted without much debate at the time).

It was "accepted without much debate" because no debate was
acceptable:

  I'll stop listening to this thread starting right about now, but don't
  let that stop you wasting your time debating at length about this boring
  subject,

In any case, we are nowhere near Emacs 25.4, so whatever decision
was obviously correct when we were after 4 24.x releases is not
necessarily TRT now.

And I will echo myself once again: please let John have enough time to
make up his own mind on this.  He deserves that.

> Long story short: if agreed, please renumber master to 26.0.50 asap.

I see no reason to make any such decision ASAP.  (I also don't object
to doing it soon.)

Re: Next release from master

[Glenn Morris]

Eli Zaretskii wrote:

> And I will echo myself once again: please let John have enough time to
> make up his own mind on this.

Two weeks have passed, so I wanted to check what the status of this was.
Perhaps the result was announced and I simply missed it.

>> Long story short: if agreed, please renumber master to 26.0.50 asap.
>
> I see no reason to make any such decision ASAP. 

Because as Stefan and I both tried to explain, the longer you wait to
make a change, the more references have to be changed. And some of them
will be outside our control.

Re: Next release from master

[John Wiegley]

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

>>>>> Glenn Morris <rgm@gnu.org> writes:

> Two weeks have passed, so I wanted to check what the status of this was.
> Perhaps the result was announced and I simply missed it.

The status is that our present course is to keep master as the "next version"
(25.2), while working in emacs-25 as the "upcoming release". When emacs-25 is
ready to release, we will tag it, merge master to it and work toward 25.2.

Features that are intended for 26 should live on a feature branch right now,
since people should mainly be using emacs-25, or if they are doing advance
work for the next release, master.

Whether we need a "third branch" to aggregate features for 26 is an open
question, and one that should only be answered by a feeling of pressing need.
Until then, we'll stick to two branches (25.1, 25.2) as our main areas of
focus.

-- 
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: Next release from master

[Stefan Monnier]

> Features that are intended for 26 should live on a feature branch right now,
> since people should mainly be using emacs-25, or if they are doing advance
> work for the next release, master.

How should we know/decide if something is intended for 26.1 or for 25.2?


        Stefan

Re: Next release from master

[John Wiegley]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Features that are intended for 26 should live on a feature branch right
>> now, since people should mainly be using emacs-25, or if they are doing
>> advance work for the next release, master.

> How should we know/decide if something is intended for 26.1 or for 25.2?

An excellent question. 25.x should not change APIs, without compelling reason;
adding new functionality might be OK, but depends on the scope.  The best rule
of thumb is: when in doubt, ask here.

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

Re: Next release from master

[Dmitry Gutov]

On 02/08/2016 05:54 PM, John Wiegley wrote:

> An excellent question. 25.x should not change APIs, without compelling reason;
> adding new functionality might be OK, but depends on the scope.

Doesn't the current master already contain some breaking changes?

Re: Next release from master

[John Wiegley]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

> Doesn't the current master already contain some breaking changes?

Does it?  Can you tell me which changes have altered APIs?  If so, they do not
belong on master without reason.

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

Re: Next release from master

[Dmitry Gutov]

On 02/09/2016 04:55 PM, John Wiegley wrote:

>> Doesn't the current master already contain some breaking changes?
>
> Does it?  Can you tell me which changes have altered APIs?  If so, they do not
> belong on master without reason.

Wouldn't those be all changes that had to be installed to master, but 
not to emacs-25?

If master is for 25.2, why would someone push changes to master now, but 
not emacs-25?

Re: Next release from master

[Stefan Monnier]

>> How should we know/decide if something is intended for 26.1 or for 25.2?
> An excellent question. 25.x should not change APIs, without compelling reason;
> adding new functionality might be OK, but depends on the scope.  The best rule
> of thumb is: when in doubt, ask here.

IOW, "master" is not really open for changes?


        Stefan

Re: Next release from master

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> How should we know/decide if something is intended for 26.1 or for 25.2?
>> An excellent question. 25.x should not change APIs, without compelling reason;
>> adding new functionality might be OK, but depends on the scope.  The best rule
>> of thumb is: when in doubt, ask here.
>
> IOW, "master" is not really open for changes?

I think this is all kinda confusing.  In the past, we've had one release
branch (currently emacs-25) and one branch for development (of "normal",
uncontroversial features).  I think that worked very well.  If we're now
to be in a tripartite world of
release-branch/kinda-sorta-next-release-branch-which-is-called-master/new-feature-branch
world, that's both unusual and I would give us virtually no testing of
new-feature-branch (since most developers just live on "master").

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Next release from master

[Rasmus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>>>> How should we know/decide if something is intended for 26.1 or for 25.2?
>>> An excellent question. 25.x should not change APIs, without compelling reason;
>>> adding new functionality might be OK, but depends on the scope.  The best rule
>>> of thumb is: when in doubt, ask here.
>>
>> IOW, "master" is not really open for changes?
>
> I think this is all kinda confusing.  In the past, we've had one release
> branch (currently emacs-25) and one branch for development (of "normal",
> uncontroversial features).  I think that worked very well.  If we're now
> to be in a tripartite world of
> release-branch/kinda-sorta-next-release-branch-which-is-called-master/new-feature-branch
> world, that's both unusual and I would give us virtually no testing of
> new-feature-branch (since most developers just live on "master").

I agree.  Feature branches are annoying from a testing point of view.  It
would have to be a very exciting branch before I’d bother to merge it...

Rasmus

-- 
This is the kind of tedious nonsense up with which I will not put

Re: Next release from master

[Kaushal Modi]

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

+1 on adding new features to be tested to the master branch directly.

--
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 125 bytes --]

Re: Next release from master

[Óscar Fuentes]

>> I agree.  Feature branches are annoying from a testing point of view.  It
>> would have to be a very exciting branch before I’d bother to merge it...

You don't need to merge the branch, just do a checkout, build it and
try the feature.

> +1 on adding new features to be tested to the master branch directly.

What does "to be tested" mean here? Does it mean that the feature was
not thoroughly tested by the developer yet? Or is "testing" on the sense
of "let's see if the feature is interesting enough for definitive
inclusion into Emacs but now it is all over the place and removing it
would be a lot of work so it is here to stay"?

I've seen very successful projects that encourage developing features in
the main branch, but those projects have an extensive test suite and a
policy that dictates that any commit that introduces regressions is
fixed or reverted as soon as the regression is observed. Encouraging the
development of intrusive, potentially destabilizing or controversial
features (*) on the master branch of Emacs is a recipe for sinking
quality, hence discouraging people from using the development version,
hence causing the contrary effect of less testing for the whole project.

We have a DVCS. Let's use it for good.

* No problem with features that are mostly independent from the rest of
  the project.

Re: Next release from master

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> What does "to be tested" mean here? Does it mean that the feature was
> not thoroughly tested by the developer yet? Or is "testing" on the sense
> of "let's see if the feature is interesting enough for definitive
> inclusion into Emacs but now it is all over the place and removing it
> would be a lot of work so it is here to stay"?
>
> I've seen very successful projects that encourage developing features in
> the main branch, but those projects have an extensive test suite and a
> policy that dictates that any commit that introduces regressions is
> fixed or reverted as soon as the regression is observed.

Emacs is an editor.  When introducing new features, the trivial thing to
test is whether "it works".  The complicated thing, and that needs many
eyes, is whether something "works right".  Only humans can say whether a
feature feels like it's getting in the way of getting things done, or
whether it feels like the right thing to do.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Next release from master

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Emacs is an editor.  When introducing new features, the trivial thing to
> test is whether "it works".  The complicated thing, and that needs many
> eyes, is whether something "works right".  Only humans can say whether a
> feature feels like it's getting in the way of getting things done, or
> whether it feels like the right thing to do.

Exactly. And developing features on `master' entirely bypasses the "it
works" phase, and that is a recipe for disaster. A dangerous change
should be on a branch until "it works" (*), then merged to see if it
"works right" (**). If the developer recruits some volunteers to see if
it "works right" for them before the merge, that's even better.

* An honest "it works", not a "QA is boring, let others do that."

** Some merges should require an approval by the maintainer. This is no
   different from how things are done now. See the cases of the xwidget
   branch, the ffi branch...

Re: Next release from master

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Exactly. And developing features on `master' entirely bypasses the "it
> works" phase, and that is a recipe for disaster.

Uhm, no?  Presumably everybody tests stuff before they push it.  No
work, no push.  And it's what we've been doing for...  how many decades?
Yet no disaster.

> ** Some merges should require an approval by the maintainer. This is no
>    different from how things are done now. See the cases of the xwidget
>    branch, the ffi branch...

Nobody is arguing against having separate branches for major new
features.  But most features aren't so major.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Next release from master

[Óscar Fuentes]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
>> Exactly. And developing features on `master' entirely bypasses the "it
>> works" phase, and that is a recipe for disaster.
>
> Uhm, no?  Presumably everybody tests stuff before they push it.

Yes, presumably... see my response to Kaushal Modi.

> No work, no push. And it's what we've been doing for... how many
> decades? Yet no disaster.

The Emacs developer community is outstanding by their quality. We also
have a few individuals who are well known for their bug-busting
habilities (and for devoting countless hours to that task.) We also have
looong pre-test and test phases, which acts as some type of hygiene that
prevents the project quality from sinking below certain line.

I'm not proposing a change on how Emacs is developed, I'm opposing the
proposed changed that consists on using `master' for changes that are
multi-commit, potentially destabilizing, and intrusive. That is, changes
that have a serious potential for annoying the community while being
hard to revert at the same time.

>> ** Some merges should require an approval by the maintainer. This is no
>>    different from how things are done now. See the cases of the xwidget
>>    branch, the ffi branch...
>
> Nobody is arguing against having separate branches for major new
> features.  But most features aren't so major.

Nor I'm arguin for having branches for minor changes, neither have I a
problem at all with you developing Gnus in `master' (speaking as a Gnus
user.)

Re: Next release from master

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> I'm not proposing a change on how Emacs is developed, I'm opposing the
> proposed changed that consists on using `master' for changes that are
> multi-commit, potentially destabilizing, and intrusive. That is, changes
> that have a serious potential for annoying the community while being
> hard to revert at the same time.

I don't think anybody is suggesting that.  :-) I think this all started
with "how come we're changing the way we're supposed to develop?"  I.e.,
having three "must have" branches that we're supposed to be working on
instead of two, as we've had for all these years.

(And in addition, there are always feature branches for big, complex,
breaky stuff.  See xwidget, ffi, async-dns, etc.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Next release from master

[Alexis]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Exactly. And developing features on `master' entirely bypasses 
> the "it works" phase, and that is a recipe for disaster. A 
> dangerous change should be on a branch until "it works" (*), 
> then merged to see if it "works right" (**). If the developer 
> recruits some volunteers to see if it "works right" for them 
> before the merge, that's even better.
>
> * An honest "it works", not a "QA is boring, let others do 
> that."
>
> ** Some merges should require an approval by the 
> maintainer. This is no 
>    different from how things are done now. See the cases of the 
>    xwidget branch, the ffi branch...

1+

i would also like to suggest that part of the "it works" phase 
should involve writing (or at least attempting to write) proper 
documentation for the feature(s) involved. Yes, the "works right" 
phase might well involve modifying some of that documentation, but 
proper documentation is important to help people understand how 
the feature is intended to work and/or be used.

Further, it seems to me that Eli is ending up having to write a 
lot of documentation of other people's code, which i feel is 
unfair on him. One of the many things i love about GNU Emacs is 
the comprehensive documentation, which has greatly facilitated my 
ability to customise it and write ELisp packages for use by 
others. If GNU Emacs being "self-documenting" is a headline 
feature, then documentation should be an integral part of code 
development, not Somebody Else's Problem, where "Somebody" is Eli.


Alexis.

Re: Next release from master

[Dmitry Gutov]

On 02/10/2016 05:28 AM, Alexis wrote:

> Further, it seems to me that Eli is ending up having to write a lot of
> documentation of other people's code, which i feel is unfair on him. One
> of the many things i love about GNU Emacs is the comprehensive
> documentation, which has greatly facilitated my ability to customise it
> and write ELisp packages for use by others. If GNU Emacs being
> "self-documenting" is a headline feature, then documentation should be
> an integral part of code development, not Somebody Else's Problem, where
> "Somebody" is Eli.

I'm sure Eli (and the rest of us) would be very happy to see you help 
with documentation.

Re: Next release from master

[Óscar Fuentes]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I'm sure Eli (and the rest of us) would be very happy to see you help
> with documentation.

This response would be very apropos in case Alexis contributed some
feature without documentation.

IMO it is very reasonable to require documenting the contributed
changes. Without that, code reviews and testing are much harder. If the
documentation is not correct English, as long as it is understandable
with some effort, fixing that is easier (*) than reading the code,
understanding its purpose and writing documentation while hoping that
you are describing what the contributor actually intended to implement.

* And something you can expect a bystander to do, hence justifying the
  "patches welcome" standard retort.

Re: Next release from master

[Dmitry Gutov]

On 02/10/2016 06:02 AM, Óscar Fuentes wrote:

> This response would be very apropos in case Alexis contributed some
> feature without documentation.

My sole (admittedly passive-aggressive) point is, if someone's not 
helping with code or documentation, they should get no vote on what the 
process should be.

> IMO it is very reasonable to require documenting the contributed
> changes. Without that, code reviews and testing are much harder.

Not if the feature has appropriate docstrings and header commentary.

As far as I'm concerned, the manual is a separate universe which 
requires additional knowledge to contribute to.

> If the
> documentation is not correct English, as long as it is understandable
> with some effort, fixing that is easier (*) than reading the code,
> understanding its purpose and writing documentation while hoping that
> you are describing what the contributor actually intended to implement.

Hopefully, one doesn't have to read the code to translate the docstrings 
into the manual (AFAICT, Eli tried not to). The person who does the 
documentation also can ask questions.

Re: Next release from master

[Alexis]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 02/10/2016 06:02 AM, Óscar Fuentes wrote:
>
>> This response would be very apropos in case Alexis contributed 
>> some feature without documentation.
>
> My sole (admittedly passive-aggressive) point is, if someone's 
> not  helping with code or documentation, they should get no vote 
> on what the  process should be.

Even if i am affected by the process resulting in poor or no 
documentation, such that it's very difficult for me to actually 
use the (possibly new) feature(s)? (Cf. the documentation for the 
`pcase` features - even people who are far more accomplished 
developers than me have been having trouble understanding what's 
going on, such that they're disinclined to use it.)

i feel that, as both a user of GNU Emacs and a developer of 
packages /for/ GNU Emacs (admittedly not packages currently in 
core), i get to at least voice my opinion about process issues 
that i feel are affecting me. In turn, yes, the people doing the 
work on core GNU Emacs get to say to me "Okay, well, we're not 
going to change the process". i /don't/, however, feel it's 
appropriate to suggest that users and non-core developers aren't 
even allowed to express their concerns. But again, i'll accept 
John's position on this, and won't say anything more for now.


Alexis.

Re: Next release from master

[Dmitry Gutov]

On 02/10/2016 06:51 AM, Alexis wrote:

> Even if i am affected by the process resulting in poor or no
> documentation, such that it's very difficult for me to actually use the
> (possibly new) feature(s)? (Cf. the documentation for the `pcase`
> features - even people who are far more accomplished developers than me
> have been having trouble understanding what's going on, such that
> they're disinclined to use it.)

I'd draw the line between reporting existing problems with documentation 
(like filing bugs "hey, pcase isn't documented!", or "I don't understand 
what the documentation says"), which all users are encouraged to do, 
versus saying how the developers should work.

That's just my standpoint, though.

> i feel that, as both a user of GNU Emacs and a developer of packages
> /for/ GNU Emacs (admittedly not packages currently in core), i get to at
> least voice my opinion about process issues that i feel are affecting
> me.

IMO, process isn't our main problem now.

Re: Next release from master

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 10 Feb 2016 07:28:34 +0200
> Cc: Óscar Fuentes <ofv@wanadoo.es>, jwiegley@gmail.com,
> 	emacs-devel@gnu.org
> 
> IMO, process isn't our main problem now.

Maybe not the main one, but we do have problems there.

Re: Next release from master

[Óscar Fuentes]

Dmitry Gutov <dgutov@yandex.ru> writes:

> My sole (admittedly passive-aggressive) point is, if someone's not
> helping with code or documentation, they should get no vote on what
> the process should be.

Alexis responded to that, and I agree with him.

>> IMO it is very reasonable to require documenting the contributed
>> changes. Without that, code reviews and testing are much harder.
>
> Not if the feature has appropriate docstrings and header commentary.

I was talking about docstrings and, possibly, NEWS too.

> As far as I'm concerned, the manual is a separate universe which
> requires additional knowledge to contribute to.

This is reasonable, as long as we have people willing to work on it and
that doesn't detract them from other more valuable work they would do
instead.

[snip]

Re: Next release from master

[Lars Ingebrigtsen]

Óscar Fuentes <ofv@wanadoo.es> writes:

>> As far as I'm concerned, the manual is a separate universe which
>> requires additional knowledge to contribute to.

Texinfo does take a while to get used to, yes...

> This is reasonable, as long as we have people willing to work on it and
> that doesn't detract them from other more valuable work they would do
> instead.

Yeah.  But I think people should do their best to document any changes
they do, and I kinda sorta feel that "their best" might be at a higher
level than we're observing now.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Next release from master

[Dmitry Gutov]

On 02/10/2016 07:07 AM, Lars Ingebrigtsen wrote:

> Texinfo does take a while to get used to, yes...

Not just Texinfo, but the existing organization and contents of the 
manuals. Not all of us are intimately familiar with them.

> Yeah.  But I think people should do their best to document any changes
> they do, and I kinda sorta feel that "their best" might be at a higher
> level than we're observing now.  :-)

Probably. But I'm sure all of us can point out (different) areas where 
"people" aren't doing their absolute best.

Re: Next release from master

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 10 Feb 2016 07:16:06 +0200
> Cc: emacs-devel@gnu.org
> 
>     Texinfo does take a while to get used to, yes...
> 
> Not just Texinfo, but the existing organization and contents of the manuals. Not all of us are intimately familiar with them.

Again, if those are the problems, I volunteer to solve them for anyone
who has them.  Finding a place where to put new stuff, or any other
such clerical job, takes me a few moments; writing from scratch can
take, and many times does take, much longer.

>     Yeah.  But I think people should do their best to document any changes
>     they do, and I kinda sorta feel that "their best" might be at a higher
>     level than we're observing now.  :-)
> 
> Probably. But I'm sure all of us can point out (different) areas where "people" aren't doing their absolute best. 

We need to strive to be better in all of them, I think.

Re: Next release from master

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 10 Feb 2016 16:07:04 +1100
> Cc: emacs-devel@gnu.org
> 
> Texinfo does take a while to get used to, yes...

I said several time that if Texinfo is a problem for someone, they
don't need to bother.  Adding markup to text that is otherwise ready
is a very simple job that takes a few minutes.  I can volunteer for
doing that service if someone needs it.  I do NOT volunteer to sit for
weeks on end writing documentation from scratch like I did since last
November.

Re: Next release from master

[Alexis]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Alexis responded to that, and I agree with him.

(It's "her", but thanks. :-) )


Alexis.

Re: Next release from master

[Dmitry Gutov]

On 02/10/2016 06:58 AM, Óscar Fuentes wrote:

> I was talking about docstrings and, possibly, NEWS too.

I'm pretty sure Alexis meant the manual. That the place where Eli ended 
up writing documentation for multiple other people's code, including the 
recently-mentioned pcase documentation.

Re: Next release from master

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 10 Feb 2016 05:58:22 +0100
> 
> >> IMO it is very reasonable to require documenting the contributed
> >> changes. Without that, code reviews and testing are much harder.
> >
> > Not if the feature has appropriate docstrings and header commentary.
> 
> I was talking about docstrings and, possibly, NEWS too.

No need, these are already included almost always.  The problem is the
manuals.

> > As far as I'm concerned, the manual is a separate universe which
> > requires additional knowledge to contribute to.
> 
> This is reasonable, as long as we have people willing to work on it and
> that doesn't detract them from other more valuable work they would do
> instead.

We don't have such people, and probably never will.  This is not a
for-profit company which can go out and hire such people.  Our
community is driven by the desire to develop software, so we all quite
naturally don't want to "waste time" on documentation.  But if we
don't work on the documentation, we won't have any, at least not a
good one.

Re: Next release from master

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 10 Feb 2016 06:13:36 +0200
> 
>     IMO it is very reasonable to require documenting the contributed
>     changes. Without that, code reviews and testing are much harder.
> 
> Not if the feature has appropriate docstrings and header commentary.

IME, people who write high-quality doc strings usually also document
the changes in the manual.  So, sadly, going by the doc strings and
the commentary still requires a non-trivial amount of work for many
changes.

> Hopefully, one doesn't have to read the code to translate the docstrings into the manual (AFAICT, Eli tried not to).

This can only be done with user-level documentation, not with stuff in
ELisp manual.  In the latter case, it normally doesn't work.
Especially if the subject matter is something one has little knowledge
about.  E.g., when I worked on cl-generic.el, even reading the code
didn't help enough, because I was not familiar with CLOS before.

> The person who does the documentation also can ask questions.

Yes, but that makes the process much less efficient, even if the
person who wrote the code lives in a close time zone.  A job that
could take several minutes will take hours or days if one must ask
questions to figure things out.  That's what happened with 'pcase',
for example.

Re: Next release from master

[Alexis]

Dmitry Gutov <dgutov@yandex.ru> writes:

> I'm sure Eli (and the rest of us) would be very happy to see you 
> help with documentation.

i'm sorry Dmitry, but i don't agree with the notion that people 
who don't understand the code they're documenting should be the 
first ones to document it. :-P (Though of course, they can 
certainly help clarify things they feel aren't clear in /existing 
documentation.) i don't expect others to document the code of the 
packages i've written, because:

(a) others won't necessarily know what i /intended/ by the code, 
they can only work from what the code /seems/ to do. That makes it 
more difficult for non-me documenters to guess whether something 
is a bug or "working as intended".

(b) i don't assume that my time is much more valuable than other 
people's. i don't think it's a net gain for the Emacs community to 
have somebody else spending, say, an hour or two coming to grips 
with code for the purposes of documenting what they /think/ is 
going on, rather than me spending 5-10 minutes just writing the 
documentation in the first place.

(c) at a basic level, my point was not "i have a problem with Eli 
being the main person writing documentation" so much as "i have a 
problem with the fact that it's /necessary/ for Eli, /or anyone 
else/, to be having to write documentation for code they haven't 
written, because the developers of the code in question have 
treated documentation as Somebody Else's Problem". If you think 
that it's not important to provide documentation for the code you 
write, then okay, but that's not a position i share.

Having said all that, i'd be interested to hear John's thoughts on 
this matter (who i've cc'd), and will follow his lead on this.


Alexis.

Re: Next release from master

[Dmitry Gutov]

On 02/10/2016 06:04 AM, Alexis wrote:

> (c) at a basic level, my point was not "i have a problem with Eli being
> the main person writing documentation" so much as "i have a problem with
> the fact that it's /necessary/ for Eli, /or anyone else/, to be having
> to write documentation for code they haven't written, because the
> developers of the code in question have treated documentation as
> Somebody Else's Problem".

Of course it's a problem. And I would be happy to have to write my own 
documentation, provided nobody is expecting to see the next Emacs 
release anytime soon.

Unfortunately, since there are so few core developers, or people who 
take responsibility for various core packages, some of the time I could 
have used to work on the said documentation, I had to spend on e.g. 
fixing stuff in etags.el, or pieces of VC left broken by ESR's latest 
changes.

> If you think that it's not important to
> provide documentation for the code you write, then okay, but that's not
> a position i share.

Not as important as working code, or fewer bugs in Emacs in general.

Re: Next release from master

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 10 Feb 2016 06:23:03 +0200
> Cc: Óscar Fuentes <ofv@wanadoo.es>, jwiegley@gmail.com,
> 	emacs-devel@gnu.org
> 
> I would be happy to have to write my own documentation, provided nobody is expecting to see the next Emacs release anytime soon.

We need to have both code and documentation for a release, so these
two tasks are not mutually exclusive conditions of releasing a new
Emacs version, they both need to be done.

> Unfortunately, since there are so few core developers, or people who take responsibility for various core packages, some of the time I could have used to work on the said documentation, I had to spend on e.g. fixing stuff in etags.el, or pieces of VC left broken by ESR's latest changes.

Sadly, this is true.  However, we are all in the same boat, since we
don't have on board people who work only on documentation.  Each one
of us, when working on documentation, uses time that could have been
invested in development of code and fixing bugs.  When someone submits
code without proper documentation, eventually Someone Else™ will have
to do that part in their stead.  TANSTAAFL.

>     If you think that it's not important to
>     provide documentation for the code you write, then okay, but that's not
>     a position i share.
> 
> Not as important as working code, or fewer bugs in Emacs in general.

I think both are equally important.  A complex system such as Emacs
without proper documentation will be harder to develop and harder to
attract new contributors.  And if some domain expert steps down,
his/her replacement will have hard time getting up to speed.

I also think that if each one of us invests small efforts on
individual changes to the documentation here and there, it will not
steal any significant amounts of time from our development resources,
because writing documentation, with only very rare exceptions, takes a
small fraction of time needed for design, development, testing, and
debugging.  By contrast, having to wait for weeks for documentation
update, like what happened just now, is bad for frequent releases.

Re: Next release from master

[Eli Zaretskii]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 10 Feb 2016 05:33:13 +0200
> Cc: emacs-devel@gnu.org
> 
> I'm sure Eli (and the rest of us) would be very happy to see you help with documentation.

Indeed; volunteers welcome.

However, the best person to write documentation of a feature is the
one who made the change, and the best time to do that is as part of or
immediately following the development, when all the details are still
fresh in that person's memory.  If Someone Else™ has to do that, that
someone needs to reverse-engineer the changes, look for and browse old
discussions and bug reports, try the new feature to fill the gaps in
the doc strings, etc. etc., just to make sense of what was done and
why, and figure out which parts are important enough to be in the
manuals.  Sometimes, doing all that takes a few moments, but more
often it can take hours or days.

It is much more efficient if the original developer provides some
documentation, even if it's not good English and without Texinfo
markup, because adding markup and rephrasing is a mostly mechanical
process that can be done very quickly and without the need to research
issues closed many moons ago.

Thanks.

Re: Next release from master

[Paul Eggert]

On 02/10/2016 09:58 AM, Eli Zaretskii wrote:
> the best person to write documentation of a feature is the
> one who made the change, and the best time to do that is as part of or
> immediately following the development, when all the details are still
> fresh in that person's memory.

I quite agree with this. The all-too-common habit of "write code first, 
hope somebody else will document later" is a terribly inefficient way 
improve Emacs, and we really should change our collective habits in this 
area. I've been doing my best to document as I go, and find that this is 
much better -- among other things, documenting is a good way to find 
bugs before they're committed to the master branch.

Re: Next release from master

[John Wiegley]

>>>>> Paul Eggert <eggert@cs.ucla.edu> writes:

> On 02/10/2016 09:58 AM, Eli Zaretskii wrote:
>> the best person to write documentation of a feature is the one who made the
>> change, and the best time to do that is as part of or immediately following
>> the development, when all the details are still fresh in that person's
>> memory.

> I quite agree with this. The all-too-common habit of "write code first, hope
> somebody else will document later" is a terribly inefficient way improve
> Emacs, and we really should change our collective habits in this area. I've
> been doing my best to document as I go, and find that this is much better --
> among other things, documenting is a good way to find bugs before they're
> committed to the master branch.

Can we move this discussion to another thread? It is only vaguely related to
deciding what the next release from master will be.

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

Re: Next release from master

[Eli Zaretskii]

> From: Alexis <flexibeast@gmail.com>
> Date: Wed, 10 Feb 2016 14:28:18 +1100
> Cc: emacs-devel@gnu.org
> 
> i would also like to suggest that part of the "it works" phase should involve writing (or at least attempting to write) proper documentation for the feature(s) involved. Yes, the "works right" phase might well involve modifying some of that documentation, but proper documentation is important to help people understand how the feature is intended to work and/or be used.

I think we should indeed move towards requesting that each change in
behavior is accompanied by a suitable change in the documentation.
Other projects (GDB is one example) have such a policy, and it works
well enough, even when the person who submits a patch has difficulty
expressing themselves in English (they are helped to overcome that
difficulty).

> Further, it seems to me that Eli is ending up having to write a lot of documentation of other people's code, which i feel is unfair on him.

Forget about me: it's unfair to all of us.  It took me 2 months to
catch up on all the stuff that should have been documented, which had
to be done before the first pretest could be put out the door.  Two
months of working almost entirely alone on nothing but updates to the
2 main manuals, using up all the time I could afford, doing almost
nothing else for Emacs.  That's 2 months of delay in releasing Emacs.
Do we really want to pay that price each time we are about to make
another release?

> If GNU Emacs being "self-documenting" is a headline feature, then documentation should be an integral part of code development, not Somebody Else's Problem, where "Somebody" is Eli.

Don't count on me being in that role for too long ;-)

Thanks for raising this issue.

Re: Next release from master

[Daniel Colascione]

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

On 02/09/2016 06:42 PM, Óscar Fuentes wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
>> Emacs is an editor.  When introducing new features, the trivial thing to
>> test is whether "it works".  The complicated thing, and that needs many
>> eyes, is whether something "works right".  Only humans can say whether a
>> feature feels like it's getting in the way of getting things done, or
>> whether it feels like the right thing to do.
> 
> Exactly. And developing features on `master' entirely bypasses the "it
> works" phase, and that is a recipe for disaster. A dangerous change
> should be on a branch until "it works" (*), then merged to see if it
> "works right" (**). If the developer recruits some volunteers to see if
> it "works right" for them before the merge, that's even better.

I see no need for such caution on the master branch. It's just as easy
to revert a broken feature as it is to add one in the first place. I'm
in favor of developing directly on master.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Next release from master

[Óscar Fuentes]

Daniel Colascione <dancol@dancol.org> writes:

> I see no need for such caution on the master branch. It's just as easy
> to revert a broken feature as it is to add one in the first place. I'm
> in favor of developing directly on master.

Apparently you skipped a previous message of mine where I mention a case
of a commit that rendered a package useless for many months and was not
possible to revert it.

Mixing unrelated commits on a linear sequence makes difficult to revert
invasive features, review code and pinpoint regressions (bisecting only
tells you that a bug is repeatable starting from certain commit, not
that the commit introduced the bug; having the entire series of commits
that implemented a feature nicely isolated on their own branch of the VC
DAG makes analysis much easier, for all purposes.)

For one-off changes that fits logically on a single commit, yes, master
is fine.

Re: Next release from master

[John Wiegley]

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

It appears that we have several possible scenarios available to us, and each
has its trade-offs.

OPTION #1 (closest to the status quo)

  25.1 is developed on emacs-25
  25.2 is concurrently developed on master
  26.1 is concurrently developed in other branches
  
  LABOR: We need to move 26.1 commits out of master and into some other
  branch. Bugs that were marked "fixed in 25.2" that shouldn't have been, need
  to be updated to say "fixed in 26.1".

OPTION #2

  25.1 is developed on emacs-25
  25.2 is concurrently developed on emacs-25-next
  26.1 is concurrently developed on master

  LABOR: Again, splitting the commits between master and emacs-25-next.  Same
  work as option #1.

  DOWNSIDE: 'master' potentially becomes much more unstable, and yet this is
  the default branch when people pull from Git.  Solution: Change the default
  branch to emacs-XX-next.

OPTION #3

  25.1 is developed on emacs-25
  26.1 is concurrently developed on master

  This means dropping point releases, except for back-patching severe bug
  fixes onto emacs-25.

  DOWNSIDE: Package authors will experience API breakages more often, since
  every release of Emacs is now free to break them. There would be no policy
  of compatibility, as there is now (mostly) between point releases.

  Unless you've managed a large Emacs project used by many, I'm not sure you
  fully understand what is implied by this decision. Someone suggested just
  cutting a new release arbitrarily every X months, but I don't feel that is a
  realistic option.

OPTION #4

  ???

Since the core developers are the ones doing the work, what works for them is
what we should do. If everyone wants API-breaky releases more often, we should
consider that option. However, my preference is option #1, as it is the one
that most emphasizes stability over "new features".

-- 
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: Next release from master

[Mark Oteiza]

John Wiegley <jwiegley@gmail.com> writes:

> It appears that we have several possible scenarios available to us, and each
> has its trade-offs.
>
> OPTION #1 (closest to the status quo)

I have been watching this thread and I still have the question: what is
wrong with the status quo?

AIUI, this is:

- 25.1 lives in emacs-25
- after 25.1 is released, emacs-25 becomes 25.2 and receives bug fixes and
  non-breaking features, either by merging from master or simply being
  applied to emacs-25. Bug fixes applied to emacs-25 periodically get
  merged back into master when appropriate
- 26.1 is master

Re: Next release from master

[Óscar Fuentes]

John Wiegley <jwiegley@gmail.com> writes:

[snip]

> OPTION #3
>
>   25.1 is developed on emacs-25
>   26.1 is concurrently developed on master
>
>   This means dropping point releases, except for back-patching severe bug
>   fixes onto emacs-25.

OPTION #4

emacs-25 is released, the branch remains open for bugfixes. All other
changes go into master. Once emacs-25 has accumulated a reasonable
number of bug fixes, or they are important enough, emacs 25.2 is
released.

I think that this method is easy enough to understand and does not drop
point releases.

OTOH, some people might be upset because new features need to wait for
the next major release, but IMHO point releases should be limited to
quality improvements.

[snip]

Re: Next release from master

[Teemu Likonen]

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

(cl-incf option)

  - master: This is the release branch for versions with new features.
    Releases are Git-tagged: emacs-25.1. After the release new features
    are added or merged here (see feature branches below).

  - maint: When a release happens from master the master branch is
    merged here. Bug fixes are added here (if a bug fix release is
    planned). Releases are Git-tagged: emacs-25.2. This branch is merged
    to master occasionally.

  - next: Wild zone and test branch for new features. Feature branches
    (see below) and the master branch are merged here. This is never
    merged anywhere. Maybe a cleanup sometimes: "git reset --hard
    master".

  - [any feature-specific branch]: There can be any number of
    feature-specific branches for new features. These are merged to next
    when a wider testing is wanted. When feature is ready and the master
    is open these are merged to master (and can be discarded).

From users' and downstream point of view: Those who always want the most
stable version will follow "maint". Those who want the normal next
release branch will follow "master". For testing the latest features one
would use "next" or manually merge any feature branches to one's own.

-- 
/// Teemu Likonen   - .-..   <https://github.com/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

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

Re: Next release from master

[Daniel Colascione]

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

On 02/11/2016 07:24 AM, John Wiegley wrote:
> It appears that we have several possible scenarios available to us, and each
> has its trade-offs.
> 
> OPTION #3
> 
>   25.1 is developed on emacs-25
>   26.1 is concurrently developed on master
> 
>   This means dropping point releases, except for back-patching severe bug
>   fixes onto emacs-25.
> 
>   DOWNSIDE: Package authors will experience API breakages more often, since
>   every release of Emacs is now free to break them. There would be no policy
>   of compatibility, as there is now (mostly) between point releases.

FWIW, I'm not proposing anything as aggressive as breaking compatibility
every release. It's easy enough to maintain API compatibility for a
pre-set number of point releases, and this policy could replace point
release compatibility. A deprecation period of six months to a year is a
reasonable period for expecting external package developers to adapt to
new APIs.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Next release from master

[Kaushal Modi]

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

On Tue, Feb 9, 2016 at 7:38 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:

> What does "to be tested" mean here? Does it mean that the feature was
> not thoroughly tested by the developer yet?
>

I use the dev builds of emacs as my daily driver. I keep the emacs-25 and
master builds ready at all times. For now, I am using emacs-25 as my daily
driver, mainly to test it thoroughly before its public release. But if some
bug creeps in that thwarts my day-job work, then I can report that and
switch to using the master branch build till the bug gets fixed (this is
just an example, I haven't needed to do that yet).

I am able to use the emacs-25/master builds as my daily driver because the
developers are doing a great job of verifying their contributions, and also
because of the feedback for new additions received on this list. But it is
possible that some new addition breaks some arcane inbuilt/external package
I/someone else might be using. It's for that purpose that the more people
use the dev builds as their DD, the better.

Now if there were a separate branch for each new feature, it would cause
the following problems:
- Necessity to keep builds ready for different features to try in addition
to the master/emacs-<VER> branch
- If I stay on a feature branch for too long, I will miss out the fixes,
etc on the master branch. To prevent that, I might need to manually merge
that feature in the master branch locally and then build (that's probably
what Rasmus referred too).
- This results in frequent need to juggle between the feature branch
builds, master build and local merged build.



> Or is "testing" on the sense
> of "let's see if the feature is interesting enough for definitive
> inclusion into Emacs but now it is all over the place and removing it
> would be a lot of work so it is here to stay"?
>

Testing of a feature for its definitive inclusion can still be done on the
master branch (like we did for the multiple dir-locals.el feature). As more
people would be testing the same master branch build (instead of people
being split between master branch and XYZ feature branch), we would get a
better collection of opinions and feedback about that feature.

I am not a software developer. So these viewpoints should be taken as from
someone who simply likes to build and try out the latest emacs builds :)


--
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 3130 bytes --]

Re: Next release from master

[Óscar Fuentes]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> On Tue, Feb 9, 2016 at 7:38 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
>> What does "to be tested" mean here? Does it mean that the feature was
>> not thoroughly tested by the developer yet?
>>
>
> I use the dev builds of emacs as my daily driver. I keep the emacs-25 and
> master builds ready at all times. For now, I am using emacs-25 as my daily
> driver, mainly to test it thoroughly before its public release. But if some
> bug creeps in that thwarts my day-job work, then I can report that and
> switch to using the master branch build till the bug gets fixed (this is
> just an example, I haven't needed to do that yet).

I'm using emacs-dev since many years ago. Given its complexity, it is
one of the most stable and reliable software packages I use. However,
throwing half-working, untested, intrusive changes into master would
change that for sure. For most part of the last year I was forced to use
an old build of emacs-dev because someone changed a package which I
depend on without a cursory testing. When the problem was reported,
there was no positive response from the developer. It was not practical
to revert the change because it was tangled with other unrelated changes
across multiple packages. The problem stayed for months until somebody
else who is familiar with the code fixed it enough to be usable again.
In the meantime, emacs-dev had at least one less tester.

This is a problem typical of projects who use the main branch as a
sandbox.

What keeps voluntary-based projects going is social conventions. Not
stepping onto anybody else's toes is one of the most basic of them. That
is helped by developing features in branches until one is honestly
convinced that merging will not introduce known or suspected problems
that harm other's work, and be quick to revert if some serious
inconvenience cannot be fixed right away (which is facilitated by having
a merge commit instead of multiple commits mixed with the rest of the VC
history.)

[snip]

Re: Next release from master

[Rasmus]

Óscar Fuentes <ofv@wanadoo.es> writes:

>>> I agree.  Feature branches are annoying from a testing point of view.  It
>>> would have to be a very exciting branch before I’d bother to merge it...
>
> You don't need to merge the branch, just do a checkout, build it and
> try the feature.

Unfortunately, I'm not quite ready to adopt your workflow.

I built Emacs with a script and install it to /usr.  I want this to be
based on master.  To test a new feature I’d thus need to merge the feature
branch or forego differences between master and the feature branch in
question.

IOW: Too many branches seems like unnecessary fragmentation.

Rasmus

-- 
Summon the Mothership!

Re: Next release from master

[John Wiegley]

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

>>>>> Lars Ingebrigtsen <larsi@gnus.org> writes:

> I think this is all kinda confusing. In the past, we've had one release
> branch (currently emacs-25) and one branch for development (of "normal",
> uncontroversial features). I think that worked very well. If we're now to be
> in a tripartite world of ... world, that's both unusual and I would give us
> virtually no testing of new-feature-branch (since most developers just live
> on "master").

If we allow committing of "any new code" to master, how do we determine what
should go into 25.2? I think the only reasonable answer to that question would
be that master should become 26, which I'm not ready for yet. 25.x should go
through a few more rounds of stabilization before we jump on 26 features.

Thus, commits on master are commits toward the next release, which in this
case will be 25.2, and so shouldn't change APIs.

I'm fine with the creation of a "next" branch to accumulate 26 features that
either don't deserve a feature branch, or where the committer doesn't want to
create a separate feature branch. However, developers wouldn't focus on that
branch, but rather keep to emacs-25 and master. The majority of us shouldn't
be worrying about 26 yet.

To reiterate:

    emacs-25        pre-release branch for upcoming release (now 25.1)
    master          development branch for next release (now 25.2)
    "next"          general home for breaking, future work (now 26.1)

Having a two branch system means either not having a place for 25.2 work while
we focus on 25.1, or it means not having a place for 26 work other than
separate feature branches. Given that 26 is further away, I'm more concerned
about the stability of the former, rather than the latter. So whether people
want a "next" branch is up to you guys; topic branches are fine too.

To clarify an earlier statement: If there is work presently on master that
breaks APIs, please either provide a justification here on emacs-devel, or
cherry-pick that patch to "next" or some topic branch, and revert it from
master with a note that it doesn't belong in 25.2.

-- 
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: Next release from master

[Dmitry Gutov]

On 02/10/2016 06:40 PM, John Wiegley wrote:

> If we allow committing of "any new code" to master, how do we determine what
> should go into 25.2?

I think I've given a possible answer for that question before: whatever 
we'd have wanted to put into 25.1, but hadn't managed to do so before 
25.1 was released. IOW, the contents of 25.2 would be determined after 
the 25.1 release, and it would be built from the same branch.

> I think the only reasonable answer to that question would
> be that master should become 26

Yes.

> 25.x should go
> through a few more rounds of stabilization before we jump on 26 features.

I think it's an argument in favor of "master is 26", as per above.

Or it's an argument in favor of master having no new features, not 
simply avoiding API breakages, which would strongly conflict with the 
current practice, and the current contents of master.

> To clarify an earlier statement: If there is work presently on master that
> breaks APIs, please either provide a justification here on emacs-devel, or
> cherry-pick that patch to "next" or some topic branch, and revert it from
> master with a note that it doesn't belong in 25.2.

I'm fairly certain that everything in 'git diff emacs-25..master' 
contains either breakages, or new features, or major reorganization 
(like with the test suite).

Or should contain, because everything else could have been backported to 
emacs-25.

Re: Next release from master

[John Wiegley]

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

>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:

> IOW, "master" is not really open for changes?

Not "open open", no.  It's open for features and changes compatible with 25.1,
but too new to be accepted in 25.1. It may also break compatibility with
justification (example: a series bug we introduced that can only be fixed by
an API breakage).

-- 
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: Next release from master

[Dmitry Gutov]

On 02/10/2016 06:41 PM, John Wiegley wrote:

> It may also break compatibility with
> justification (example: a series bug we introduced that can only be fixed by
> an API breakage).

And cannot be fixed with a rollback?

I'd think API breakage = next major version.

Re: Next release from master

[Óscar Fuentes]

John Wiegley <jwiegley@gmail.com> writes:

> Not "open open", no.  It's open for features and changes compatible with 25.1,
> but too new to be accepted in 25.1.

Why the dot releases have new features and non-bug-fixing changes at
all? What's the criteria for putting a new feature on a dot release and
another on a major release?

[snip]

Re: Next release from master

[Daniel Colascione]

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

On 02/10/2016 10:06 AM, Óscar Fuentes wrote:
> John Wiegley <jwiegley@gmail.com> writes:
> 
>> Not "open open", no.  It's open for features and changes compatible with 25.1,
>> but too new to be accepted in 25.1.
> 
> Why the dot releases have new features and non-bug-fixing changes at
> all? What's the criteria for putting a new feature on a dot release and
> another on a major release?

It's partially because of this confusion that I think we should give up
on the major-minor release system entirely. That system made a lot more
sense when bandwidth was scarce, disk space was precious, compilation
glacial, and package management manual. These days, we have ample
computing resources. I'd like to seriously consider time-based releases
of master (say, every six months), with backports of only critical
security fixes to older releases --- with support for a maximum of, say,
three years. This model is becoming increasingly common for OS
distributions and major applications; Mozilla has used it successfully
for years.

While it's true that out-of-tree developers could no longer use version
numbers to understand when APIs might break, I don't think that's really
a problem, since they, too, can distribute their releases continuously.
I seldom bother with releases myself anymore: if I want to use a
package, I just clone the repository. I think a one-major-release
deprecation period for breaking changes would give out-of-tree
developers more than enough time to fix any broken packages.

With a time-based monolithic release system, we wouldn't have to worry
about what features could go in what branch. We'd instead only have to
worry about the length of time for which we would have to support
obsolete APIs, and IMHO, it's much easier to reason about contractual
guarantees at that level.

Quick time-based releases also help get new code in the hands of users
faster, which is not only better for Emacs users, but better for the
future community of Emacs developers, who would find it satisfying to be
able to see code reach production in a relatively short time.

While this scheme does place a greater burden on keeping master stable,
you're _already_ advocating the use of feature branches for potentially
disruptive work, so in theory, master should be stable already. In
practice, I run master synced at irregular intervals and seldom have
problems.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Next release from master

[John Wiegley]

>>>>> Glenn Morris <rgm@gnu.org> writes:

> This means that if all goes as planned: 26.1 might not contain any "major"
> new features, and 25.2 will never exist.

I'm not sure yet what the best "role" for master is. Should it accumulate new
work toward 25.2 while we work on 25.1, or should it accumulate work toward
26.1?

I think that maybe we need three branches: one for current release work (such
as emacs-25); one towards the next release (master); and one towards the next
major release (possible name: "next"?).

When freezing for 25.2, we would merge master into emacs-25 and then work on
25.2 while 'master' becomes the place for future 25.3 changes.

At some point, we'll decide we don't want 25.x, but we really want to cut 26.
At that time 'next' should be merged into 'master', and sanity checked for. If
we are sane, then we cut 'emacs-26', master heads toward 26.2, next heads
toward 27, etc.

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

Re: Next release from master

[Dmitry Gutov]

On 01/22/2016 04:01 AM, John Wiegley wrote:

> I'm not sure yet what the best "role" for master is. Should it accumulate new
> work toward 25.2 while we work on 25.1, or should it accumulate work toward
> 26.1?

Why not get back to the simpler scheme? "New work" will go into the next 
major release (26.1, in this case), into master.

25.2 should only contain the minor tweaks and fixes we would accept into 
25.1 now (with feature freeze in effect), but don't manage to get into 
25.1 because of lack of time, or in case the respective bugs get filed 
too late (after 25.1's release).

So, 25.2 might not get released at all. But it probably will, and it'll 
be cut from emacs-25, like the branch's name implies.

Re: Next release from master

[Paul Eggert]

On 01/21/2016 05:28 PM, Dmitry Gutov wrote:
> Why not get back to the simpler scheme?

I also don't see the need for three common development branches. Emacs 
developers are already spread pretty thin with two.

I know of a GNU project that has three such branches: Automake. The 
branches are called 'master', 'minor', and 'micro', and have roughly the 
three roles that John suggested. My own impression is that the extra 
complexity of the three branches discouraged contributors ("which branch 
should this patch go into?", that sort of thing).

Automake development is currently moribund.

Re: Next release from master

[Xue Fuqiao]

On Fri, Jan 22, 2016 at 9:42 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 01/21/2016 05:28 PM, Dmitry Gutov wrote:
>>
>> Why not get back to the simpler scheme?
>
> I also don't see the need for three common development branches. Emacs
> developers are already spread pretty thin with two.
>
> I know of a GNU project that has three such branches: Automake. The branches
> are called 'master', 'minor', and 'micro', and have roughly the three roles
> that John suggested. My own impression is that the extra complexity of the
> three branches discouraged contributors ("which branch should this patch go
> into?", that sort of thing).
>
> Automake development is currently moribund.

+1

I think the current process (as described in `admin/release-process' and
`admin/notes/versioning') is good enough.  More complexity will
discourage current/potential contributors.

Re: Next release from master

[John Wiegley]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

> Why not get back to the simpler scheme? "New work" will go into the next
> major release (26.1, in this case), into master.

What about changes that should go into 25.2, but before 25.1 is ready? Where
do those go? Or are you saying that once we've frozen for X.1, any and all
changes to be included in X are allowed, since they should all be stabilizing
changes?

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

Re: Next release from master

[Dmitry Gutov]

On 01/22/2016 04:46 AM, John Wiegley wrote:
> Or are you saying that once we've frozen for X.1, any and all
> changes to be included in X are allowed, since they should all be stabilizing
> changes?

More or less, yes. No breaking changes in 25.2.

Re: Next release from master

[John Wiegley]

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

>> Or are you saying that once we've frozen for X.1, any and all
>> changes to be included in X are allowed, since they should all be stabilizing
>> changes?

> More or less, yes. No breaking changes in 25.2.

What do you think, Eli? Should master become 26.1? What would this mean for
the likelihood of 25.2? Or do we just keep developing on emacs-25 until we get
tired of doing so?

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

Re: Next release from master

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: emacs-devel@gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Thu, 21 Jan 2016 17:56:03 -0800
> 
> >>>>> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
> >> Or are you saying that once we've frozen for X.1, any and all
> >> changes to be included in X are allowed, since they should all be stabilizing
> >> changes?
> 
> > More or less, yes. No breaking changes in 25.2.
> 
> What do you think, Eli? Should master become 26.1?

If we decide that emacs-25 will only be used for fixing bugs, i.e. all
25.x releases after 25.1 will be bugfix releases, then yes, I think
master should become 26.1.

> What would this mean for the likelihood of 25.2?

It would mean 25.2, 25.3, etc. will fix bugs and generally add nothing
new.  It might also mean the release cycle on the emacs-25 branch
could be very fast (beyond 25.1), with just a small number of pretests
before the actual release.  We never tried to stick to this principle,
though, except with Emacs 24.5.

Re: Next release from master

[John Wiegley]

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

>> What do you think, Eli? Should master become 26.1?
> If we decide that emacs-25 will only be used for fixing bugs, i.e. all 25.x
> releases after 25.1 will be bugfix releases, then yes, I think master should
> become 26.1.

I actually sort of like this plan. Even when 25.1 is out, I'd love to spend
some time getting the bug list under control before we move on to brave new
features, if others are up for it.

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

Re: Next release from master

[Barry Fishman]

On 2016-01-21 23:38:58 -0800, John Wiegley wrote:
>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>> What do you think, Eli? Should master become 26.1?
>> If we decide that emacs-25 will only be used for fixing bugs, i.e. all 25.x
>> releases after 25.1 will be bugfix releases, then yes, I think master should
>> become 26.1.
>
> I actually sort of like this plan. Even when 25.1 is out, I'd love to spend
> some time getting the bug list under control before we move on to brave new
> features, if others are up for it.

I think you all are making things more difficult for yourselves.

I think master should be the focus of release testings.  When bugs are
fixed in a release this would be done in master.  When things are ready
for release they are fast-forwarded in to the numbered release branch,
and tagged.  So the each release branch just has the complete,
development of that release.

Major changes would start with master and be branched into their own
initial development branch.  Ultimately they could be integrated into the
"next" branch.  This is where new ideas that you don't want to add to
the current release would be integrated.  Important bug fixes could be
merged in here, but this is not crucial.  The idea of the "next" branch
is to get new ideas all working together.

When you are ready for a new release, the "next" branch is merged into
"master".  This is important because it is the responsibility of the
people coding in fundamental changes to get them working in the baseline
emacs and not the other way around.  When you merging the last release into
the next, its the already tested bug fixes that flag changes, which
seems backwards.

One might even consider branching "master" into a temporary branch, then
merging in "next".  (Of even branching "next" as the new temporary
branch and rebasing with "master").  This way the initial merge fixes
can be performed prior to fast forwarding into "master" for general
testing, and master does not go though a period of major breakage.

After this major version update of master, security fixes would be added
to released branches without going through master.

In this way master is the testing branch, and people can rely on just
getting master if they want to help test Emacs.  The "next" branch is
were the latest features are added, possibly after they are tried and
evaluated in their own branches.

The important thing is that you want in mergers to focus on fixing new
features not old tested bug fixes.

--
Barry Fishman

Re: Next release from master

[John Wiegley]

>>>>> Barry Fishman <barry@ecubist.org> writes:

> I think you all are making things more difficult for yourselves.

Hi Barry, I didn't really understand your e-mail; it sounded just as difficult
as anything else that's been proposed. Could you summarize what exactly would
make it an easier solution?

In a sense "emacs-25" is the current master for our developers, with "master"
collecting new features that we reject as too destabilizing for emacs-25. When
we are done with "stabilizing mode", we'll go back to "feature mode", and
master will resume its role as master.

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

Re: Next release from master

[Barry Fishman]

On 2016-01-22 09:45:54 -0800, John Wiegley wrote:
>>>>>> Barry Fishman <barry@ecubist.org> writes:
>> I think you all are making things more difficult for yourselves.
>
> Hi Barry, I didn't really understand your e-mail; it sounded just as difficult
> as anything else that's been proposed. Could you summarize what exactly would
> make it an easier solution?
>
> In a sense "emacs-25" is the current master for our developers, with "master"
> collecting new features that we reject as too destabilizing for emacs-25. When
> we are done with "stabilizing mode", we'll go back to "feature mode", and
> master will resume its role as master.

We both seem to agree that the numbered "emacs-25" type branches track
the development of each release.

I suggested branches not have modes.  "Master" would always be where the
major testing occurs.  "Next" would be were new, possibly destabilizing
changes could be made.  Numbered branches would always contain the
history associated with that release.

When developers work on feature that are destabilizing, these get merged
into a "next" branch, hopefully when they have initially tested them in
there own local branch.  "Next" would be where integration testing is
done.

When "emacs-25" is considered complete, in the sense that the next
release would be in "emacs-26", The next branch goes though the process
of merging into master for final testing and bug fixes.  When ready it
it branched as the "emacs-26" release.

At worst this is just a relabeling of the current "master" to "next",
and move the "emacs-25" development to master.  But it makes the
mainline development process more linear.

"Master" would be where most of the bug testing is done, so people who want
to help out testing Emacs but are not major developers could go and
help.  General users finding bugs could see there fixes done there.
Being "master" it would be the easiest for people to track and build.

People working on next would be more seasoned developers involved
integrating new features and doing the more complex debugging.

No matter what approach is used, I think the major revision time merge
of "next" and "master", (or currently "emacs-25" into master) needs to
be done carefully.  I just think that what is going on in each branch
should the established, rather than a cycling though modes.

I also think that making the "master" branch less volatile and always
the current test area would help open up the bug fixing to a wider
audience who may have less Git skills.  People who hope to generally
contribute to bug fixing need only clone the Git repo and use that.

Irrespective of what the policy is, I think you will find most people
that check out Emacs build from the master branch.

--
Barry Fishman

Re: Next release from master

[John Wiegley]

>>>>> Barry Fishman <barry@ecubist.org> writes:

> I suggested branches not have modes. "Master" would always be where the
> major testing occurs. "Next" would be were new, possibly destabilizing
> changes could be made. Numbered branches would always contain the history
> associated with that release.

Ah, I _think_ this is just what I was suggesting with "emacs-25", "master" and
"next" before, but it was felt that 3 branches is not yet better than two. So
I think we'll stick with two until we feel a more pressing need.

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

Re: Next release from master

[Alex Bennée]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Barry Fishman <barry@ecubist.org> writes:
>
>> I suggested branches not have modes. "Master" would always be where the
>> major testing occurs. "Next" would be were new, possibly destabilizing
>> changes could be made. Numbered branches would always contain the history
>> associated with that release.
>
> Ah, I _think_ this is just what I was suggesting with "emacs-25", "master" and
> "next" before, but it was felt that 3 branches is not yet better than two. So
> I think we'll stick with two until we feel a more pressing need.

It really depends on what you want happening in the various branches. To
give another example from QEMU our strategy is:

* master is always the latest greatest
* as we approach release the criteria to commit to master gets tighter
  - soft feature freeze, no new features (only features that are "ready" get merged, maybe in stages)
  - hard feature freeze, any feature for this cycle needs to be in my then
  - release candidates, bug fixes only
  - release x.0

Once the x.0 release is done a stable branch is created for future .n
releases and the metaphorical flood gates opened for features that
weren't ready for the last cycle can go in.

Of course the control of this is helped by  the fact we have a lead
maintainer who merges pull requests from the subsystem maintainers
(much like the Linux kernel). Very few people have direct commit rights
to the master repository.

Would you have people with code that needs to go somewhere during a
stabilisation cycle? I would hope anything funky just lives on feature
branches until the next dev cycle opens.

--
Alex Bennée

Re: Next release from master

[Eli Zaretskii]

> From: Alex Bennée <alex.bennee@linaro.org>
> Date: Mon, 25 Jan 2016 10:38:23 +0000
> Cc: Barry Fishman <barry@ecubist.org>, emacs-devel@gnu.org
> 
> * master is always the latest greatest
> * as we approach release the criteria to commit to master gets tighter
>   - soft feature freeze, no new features (only features that are "ready" get 
> merged, maybe in stages)
>   - hard feature freeze, any feature for this cycle needs to be in my then
>   - release candidates, bug fixes only
>   - release x.0
>
> Once the x.0 release is done a stable branch is created for future .n
> releases and the metaphorical flood gates opened for features that
> weren't ready for the last cycle can go in.

That's how Emacs development used to work until several years ago.
Since then, we have made the feature freeze period on master much
shorter, and the release branch fork sooner, because there was
considerable pressure from contributors who didn't like the long
freeze.

> Of course the control of this is helped by  the fact we have a lead
> maintainer who merges pull requests from the subsystem maintainers
> (much like the Linux kernel). Very few people have direct commit rights
> to the master repository.

Which of course is anathema in Emacs development.  In fact, I don't
even think it could work in principle for Emacs, because of the number
of distinct areas of expertise which a single individual has no hope
of mastering to be an efficient gatekeeper.

> Would you have people with code that needs to go somewhere during a
> stabilisation cycle? I would hope anything funky just lives on feature
> branches until the next dev cycle opens.

People don't like too many feature branches, even if they are public,
because many times they want more than one feature in their hottest
latest Emacs.

Re: Next release from master

[Stefan Monnier]

> Irrespective of what the policy is, I think you will find most people
> that check out Emacs build from the master branch.

IIUC your proposal aims specifically at making sure that the focus of
work is always on "the same branch", so uses don't need to ask here
whether they should be using emacs-25 or master: we arrange our workflow
such that "master" corresponds to "the branch we currently want normal
users to test&debug".

I think this makes a lot of sense, but it basically requires always
having 2 active branches (master and next, currently corresponding to
emacs-25 and master), whereas until now we've always had longish periods
of time where we only have 1 active branch (which we call master but
would be called "next" in your proposal).


        Stefan

Re: Next release from master

[Barry Fishman]

On 2016-01-23 00:17:07 -0500, Stefan Monnier wrote:
>> Irrespective of what the policy is, I think you will find most people
>> that check out Emacs build from the master branch.
>
> IIUC your proposal aims specifically at making sure that the focus of
> work is always on "the same branch", so uses don't need to ask here
> whether they should be using emacs-25 or master: we arrange our workflow
> such that "master" corresponds to "the branch we currently want normal
> users to test&debug".
>
> I think this makes a lot of sense, but it basically requires always
> having 2 active branches (master and next, currently corresponding to
> emacs-25 and master), whereas until now we've always had longish periods
> of time where we only have 1 active branch (which we call master but
> would be called "next" in your proposal).

I was just following the approach somewhat like that used by some Linux
package managers.  For example with Debian the "master" branch would
work like Debian's "test" branch, and "next" like Debian's "unstable".
(Debian also has a "experimental" branch where the initial part of merges
are done, to keep unstable a bit less unstable.)  Like Emacs, changes
may be held back from "test" while a new release is being tested.

Its also close to the approach used by Git's own Git repository.

The "next" branch would where integration testing happens, and might be
badly broken for chunks of time.  A place where component maintainers make
sure that major structural changes are reflected in their components.

The "master" branch is where most of the final debugging takes place.

If "next" is active and "master" isn't, would be a time when some major
reworking is being performed.

It is more of a pipelined development:
    <new-feature-branch> -> "next" -> "master" -> <release>
or:
    <try-an-idea> -> <accept-and-put-into-general-use> -> <test> -> <release>

If this does not fit how Emacs development works, OK.  Its just an idea,
and I though worth consideration.  I think Emacs has always been great
software, and I certainly don't want to adversely effect that.

--
Barry Fishman

Re: Next release from master

[John Wiegley]

>>>>> Barry Fishman <barry@ecubist.org> writes:

> If this does not fit how Emacs development works, OK. Its just an idea, and
> I though worth consideration. I think Emacs has always been great software,
> and I certainly don't want to adversely effect that.

Hi Barry, I like your suggestion, and in fact it's what I'm more used to, but
we also must choose a methodology that works for the Emacs developers. Since a
few people have expressed the feeling that a 3-branch system would create
inertia for them, we'll stick with a 2-branch system (plus feature branches)
until it becomes an issue.

It's still an open question whether we should be using emacs-X+master, or
master+next, though. Our current activity is something of an experiment in
that regard, since in my experience (having gotten used to "next" branches), I
was unfamiliar with a 'master' that is periodically frozen with respect to
feature work.

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

Re: Next release from master

[Stefan Monnier]

> It's still an open question whether we should be using emacs-X+master, or
> master+next, though. Our current activity is something of an experiment in
> that regard, since in my experience (having gotten used to "next" branches), I
> was unfamiliar with a 'master' that is periodically frozen with respect to
> feature work.

FWIW, here are the two main constraints we want to try and satisfy:
- coders should know where to install bug-fixes and new features.
- users should know where to get the current "stable bleeding-edge".
- "should know" means that it doesn't depend on whether we're in
  feature-freeze, in pretest, or anything else.
Currently, we don't satisfy those constraints, and Barry's suggestion
would seem to help in this regard.


        Stefan

Re: Next release from master

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 23 Jan 2016 23:26:32 -0500
> 
> - coders should know where to install bug-fixes and new features.

The chances of them knowing this with any certainty close to 100% are
nil, IME.  Moreover, each branch we add only _adds_ to the uncertainty
and possible confusion.

The main problem here is that most coders don't follow this list and
emacs-diffs actively enough to be "in the know".  That problem cannot
be solved by procedures or by rearranging branches.

> - users should know where to get the current "stable bleeding-edge".

Same problems, for the same basic reasons.  (Also, I think "stable
bleeding-edge" is self-contradictory.)

> - "should know" means that it doesn't depend on whether we're in
>   feature-freeze, in pretest, or anything else.

That is an impossible requirement.  Even Barry's suggestion (which I
think is not right for Emacs, see below) doesn't promise that

> Currently, we don't satisfy those constraints, and Barry's suggestion
> would seem to help in this regard.

IMO, what Barry suggests cannot be done with our current resources and
level of proficiency.  Like many other similar proposals, it tries to
copy procedures from other projects, without considering the resources
each project has, relative to the project's size and the number and
interdependencies of distinct areas of expertise involved.

Re: Next release from master

[Stefan Monnier]

>> - coders should know where to install bug-fixes and new features.
> The main problem here is that most coders don't follow this list and
> emacs-diffs actively enough to be "in the know".  That problem cannot
> be solved by procedures or by rearranging branches.

That's the point: they shouldn't need to follow any list, because the
place where to put bug fixes should always be the same (and same for
new features).

> (Also, I think "stable bleeding-edge" is self-contradictory.)

Yes, it is, but that's what we want people to use for things like
`emacs-snapshot': when we're in feature freeze, they should use the
"bug-fix branch", and when we're not they should use the "new
features" branch.


        Stefan

Re: Next release from master

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Sun, 24 Jan 2016 13:04:40 -0500
> 
> the place where to put bug fixes should always be the same (and same
> for new features).

That's impossible.  Every development means bugs, so bugfixes will
happen on all active branches.  Some of them will be different, some
identical.  But all of the branches will get bugfixes.  And the same
for new features.

> > (Also, I think "stable bleeding-edge" is self-contradictory.)
> 
> Yes, it is, but that's what we want people to use for things like
> `emacs-snapshot': when we're in feature freeze, they should use the
> "bug-fix branch", and when we're not they should use the "new
> features" branch.

With 3 branches, there's no need for feature freeze, so I don't think
I understand how all this is relevant to the issue at hand.

Also, didn't you just say that "stable bleeding-edge" should always be
the same branch?  But here you seem to be saying that it's sometimes
this and sometimes that.

Re: Next release from master

[Stefan Monnier]

>> the place where to put bug fixes should always be the same (and same
>> for new features).
> That's impossible.  Every development means bugs, so bugfixes will
> happen on all active branches.  Some of them will be different, some
> identical.  But all of the branches will get bugfixes.  And the same
> for new features.

Of course, some things are impossible.  But there are many cases where
it *is* possible.  In lots of cases, a given bug-fix can apply just as
well to `master' as to `emacs-25', and in that case it should go to
`emacs-25' currently whereas it should go to `master' when we're not in
the process of preparing a release.

How many times have we seen people install bug-fixes into `master'
without realizing that it should have gone to the release
branch instead?

Of course we can't completely avoid this problem, but part of the reason
is that we can't just tell them "always install your bug-fixes to the
release branch (when possible)".  Instead, they have to know the current
"mode of development".

> With 3 branches, there's no need for feature freeze, so I don't think
> I understand how all this is relevant to the issue at hand.

I'm not talking about a 3-branches case.  I'm just talking about what
I think would be desirable goals if we try to change the workflow.

> Also, didn't you just say that "stable bleeding-edge" should always be
> the same branch?  But here you seem to be saying that it's sometimes
> this and sometimes that.

Yes, it should be the same branch, but currently it's
sometimes one and sometimes another.


        Stefan

Re: Next release from master

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Date: Thu, 21 Jan 2016 17:46:02 -0800
> Cc: emacs-devel@gnu.org
> 
> >>>>> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
> > Why not get back to the simpler scheme? "New work" will go into the next
> > major release (26.1, in this case), into master.
> 
> What about changes that should go into 25.2, but before 25.1 is ready? Where
> do those go?

This problem should only exist with externally maintained packages
that are then merged into Emacs's repository.  If such a package has
faster release schedule, it might have such a problem because some
change not appropriate for the Emacs release branch doesn't want to
wait for the next major Emacs release.

But for core Emacs, this problem shouldn't exist, as long as we decide
that a release branch gets only bugfixes.  With that decision, any
change that does not fix a bug should by default go to master.  There
are 2 major exceptions from that rule:

  . Some bugfixes are too invasive/unsafe to have on the release
    branch.  But these cases are rare.

  . Some changes that don't fix bugs, but are clearly safe, can be
    allowed on the release branch.  Examples include changes in
    documentation (including doc strings), and addition of packages
    or minor features that have no impact on the rest of Emacs.

Re: Next release from master

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

> This problem should only exist with externally maintained packages
> that are then merged into Emacs's repository.  If such a package has
> faster release schedule, it might have such a problem because some
> change not appropriate for the Emacs release branch doesn't want to
> wait for the next major Emacs release.

Counter example: kqueue integration. It was a candidate for 25.1, but
didn't reach it because it was one or two weeks too late.

That was two months ago ... and now, according to that plan, it would be
postponed until Emacs 26 appears. There's even no pretest for Emacs 25.1
until now.

Best regards, Michael.

Re: Next release from master

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: John Wiegley <johnw@gnu.org>,  emacs-devel@gnu.org,  dgutov@yandex.ru
> Date: Fri, 22 Jan 2016 09:10:53 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This problem should only exist with externally maintained packages
> > that are then merged into Emacs's repository.  If such a package has
> > faster release schedule, it might have such a problem because some
> > change not appropriate for the Emacs release branch doesn't want to
> > wait for the next major Emacs release.
> 
> Counter example: kqueue integration. It was a candidate for 25.1, but
> didn't reach it because it was one or two weeks too late.
> 
> That was two months ago ... and now, according to that plan, it would be
> postponed until Emacs 26 appears. There's even no pretest for Emacs 25.1
> until now.

Actually, we could backport the kqueue changes to emacs-25 branch,
IMO.  The pretest should be out in a couple of days, so if we hurry,
we can make the deadline.  John?

Re: Next release from master

[Nicolas Petton]

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

Eli Zaretskii <eliz@gnu.org> writes:

> Actually, we could backport the kqueue changes to emacs-25 branch,
> IMO.  The pretest should be out in a couple of days, so if we hurry,
> we can make the deadline.  John?

I planned to release the first pretest tomorrow.  Do you need more time?

Nico

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

Re: Next release from master

[Michael Albinus]

Nicolas Petton <nicolas@petton.fr> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Actually, we could backport the kqueue changes to emacs-25 branch,
>> IMO.  The pretest should be out in a couple of days, so if we hurry,
>> we can make the deadline.  John?
>
> I planned to release the first pretest tomorrow.  Do you need more time?

I would need about 2 hours for backporting, after the OK.

> Nico

Best regards, Michael.

Re: Next release from master

[John Wiegley]

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

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

> I would need about 2 hours for backporting, after the OK.

You have the OK.

-- 
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: Next release from master

[Michael Albinus]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Michael Albinus <michael.albinus@gmx.de> writes:
>
>> I would need about 2 hours for backporting, after the OK.
>
> You have the OK.

Done.

Best regards, Michael.

Re: Next release from master

[Alan Mackenzie]

Hello, Michael.

On Fri, Jan 22, 2016 at 08:02:02PM +0100, Michael Albinus wrote:
> John Wiegley <jwiegley@gmail.com> writes:

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

> >> I would need about 2 hours for backporting, after the OK.

> > You have the OK.

> Done.

What, the backporting or the entire build?

Or, more relevantly, is the emacs-25 branch currently open for bug
fixes, or is it "blocked" whilst you do the build?

> Best regards, Michael.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Next release from master

[Eli Zaretskii]

> Date: Fri, 22 Jan 2016 19:16:19 +0000
> Cc: Nicolas Petton <nicolas@petton.fr>, Eli Zaretskii <eliz@gnu.org>,
>   emacs-devel@gnu.org, dgutov@yandex.ru
> From: Alan Mackenzie <acm@muc.de>
> 
> Hello, Michael.

I'm not him.

> > >> I would need about 2 hours for backporting, after the OK.
> 
> > > You have the OK.
> 
> > Done.
> 
> What, the backporting or the entire build?
> 
> Or, more relevantly, is the emacs-25 branch currently open for bug
> fixes, or is it "blocked" whilst you do the build?

No one (yet) does the build, and the branch is not, and will not be,
blocked.  Michael just backported the kqueue changes from master, so
that they will be available in Emacs 25.1, starting with the first
pretest.

Re: Next release from master

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Date: Thu, 21 Jan 2016 17:01:50 -0800
> 
> I think that maybe we need three branches: one for current release work (such
> as emacs-25); one towards the next release (master); and one towards the next
> major release (possible name: "next"?).

IMO, we shouldn't start another branch before we successfully pass the
exam for "branches 101" -- being able to reliably handle 2 branches.
Right now, we are not there yet, witness the latest merge problems.

And if this is just to solve the problem of references to the future
release in defcustom and in make-obsolete calls, then we should be
better off introducing some script that would change all of them
automatically when we change our decisions about where should the next
release come from.

Re: Next release from master

[Stefan Monnier]

> I think that maybe we need three branches: one for current release work (such
> as emacs-25); one towards the next release (master); and one towards the next
> major release (possible name: "next"?).

AFAIK, we've never had a clear plan of what should be the next
"major" release.  IOW Emacs releases only become "major" because they
accumulate lots of "not so major" changes.

There has been exceptions, but for those we've usually ended up using
indeed an extra branch, but these branches were more like feature
branches than like "a branch for the next major release".  I think the
"unicode" branch was the only real exception.

I think this workflow (i.e. only 2 integration branches (a "stable" one
for bugfixes and a "devel" one for new features) plus feature branches
as needed for things which aren't quite ready yet for "devel") worked
pretty well.


        Stefan

Re: Next release from master

[Angelo Graziosi]

Mark Oteiza wrote:
> I have been watching this thread and I still have the question: what is
> wrong with the status quo?
>
> AIUI, this is:
>
> - 25.1 lives in emacs-25
> - after 25.1 is released, emacs-25 becomes 25.2 and receives bug fixes and
>   non-breaking features, either by merging from master or simply being
>   applied to emacs-25. Bug fixes applied to emacs-25 periodically get
>   merged back into master when appropriate
> - 26.1 is master

the only simple, clear, right, acceptable written in this thread...

Re: Next release from master

[John Wiegley]

>>>>> Angelo Graziosi <angelo.graziosi@alice.it> writes:

>> - 25.1 lives in emacs-25 - after 25.1 is released, emacs-25 becomes 25.2
>> and receives bug fixes and non-breaking features, either by merging from
>> master or simply being applied to emacs-25. Bug fixes applied to emacs-25
>> periodically get merged back into master when appropriate - 26.1 is master

> the only simple, clear, right, acceptable written in this thread...

Well, I guess that's one opinion. :)

I'm interested to hear what the core developers want: anyone who commits more
than once in a blue moon, which option do you want?

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

Re: Next release from master

[Paul Eggert]

On 02/11/2016 09:09 AM, John Wiegley wrote:
> I'm interested to hear what the core developers want: anyone who commits more
> than once in a blue moon, which option do you want?

I agree with Mark Oteiza that the status quo is good enough. If we had 
more developers and could profitably work on 25.1 and 25.2 and 26.1 in 
parallel then the extra complexity and confusion of three branches would 
be worth it. But we don't have that many developers, and even working on 
two branches in parallel is a strain for us. I sometimes wish that we 
had just one branch, to be honest.

Re: Next release from master

[Angelo Graziosi]

Il 11/02/2016 18:09, John Wiegley ha scritto:
>>>>>> Angelo Graziosi <angelo.graziosi@alice.it> writes:
>
>>> - 25.1 lives in emacs-25 - after 25.1 is released, emacs-25 becomes 25.2
>>> and receives bug fixes and non-breaking features, either by merging from
>>> master or simply being applied to emacs-25. Bug fixes applied to emacs-25
>>> periodically get merged back into master when appropriate - 26.1 is master
>
>> the only simple, clear, right, acceptable written in this thread...
>
> Well, I guess that's one opinion. :)
>
> I'm interested to hear what the core developers want: anyone who commits more
> than once in a blue moon, which option do you want?
>

For what I remember, the development of Emacs has been always so in the 
last 10 year, both with CVS, BAZAR and up to few months ago, with Git. I 
don't see any reason to change. I have built Emacs on Cygwin, GNU/Linux 
and OSX (and now MSYS2/MINGW64) for 8-9 years almost one or two times 
per week (and sometimes also more). It's only from some months that I 
build Emacs rarely.. master is always behind other branches and don't 
know project where master, trunk or whatever is called is behind other 
branches..

Re: Next release from master

[Eli Zaretskii]

> From: Angelo Graziosi <angelo.graziosi@alice.it>
> Date: Thu, 11 Feb 2016 18:27:10 +0100
> 
> I have built Emacs on Cygwin, GNU/Linux and OSX (and now
> MSYS2/MINGW64) for 8-9 years almost one or two times per week (and
> sometimes also more). It's only from some months that I build Emacs
> rarely.. master is always behind other branches and don't know
> project where master, trunk or whatever is called is behind other
> branches..

That's what we get for not investing enough efforts in making the
release branch release-ready, coupled with the fact that the number of
people who do the mundane stuff continues to diminish.  It will get
worse unless more people become ready to get their hands dirty.

Re: Next release from master

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Date: Thu, 11 Feb 2016 12:09:46 -0500
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> I'm interested to hear what the core developers want: anyone who commits more
> than once in a blue moon, which option do you want?

I think what Mark suggested makes the most sense, and fits best our
scarce resources and also (to some extent) past practices.

All the alternatives are significantly more complex, and I don't
believe we will be able to sustain them, the way we currently work.

Re: Next release from master

[Stefan Monnier]

>> - 25.1 lives in emacs-25
>> - after 25.1 is released, emacs-25 becomes 25.2 and receives bug fixes and
>> non-breaking features, either by merging from master or simply being
>> applied to emacs-25. Bug fixes applied to emacs-25 periodically get
>> merged back into master when appropriate
>> - 26.1 is master

Right.  That's indeed the model I concluded works best for us, based on
the 24.x experience (and which lead to keeping 24.5 for bugfix only, and
naming the next release 25.1 rather than 24.6).


        Stefan

Re: Next release from master

[John Wiegley]

>>>>> Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Right. That's indeed the model I concluded works best for us, based on the
> 24.x experience (and which lead to keeping 24.5 for bugfix only, and naming
> the next release 25.1 rather than 24.6).

Eli, Artur, Glenn, Richard, what say you?

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

Re: Next release from master

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Right.  That's indeed the model I concluded works best for us, based on
  > the 24.x experience (and which lead to keeping 24.5 for bugfix only, and
  > naming the next release 25.1 rather than 24.6).

It is fine with me.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.