[jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Richard Stallman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2999 bytes --]

Marant is proposing to make a 21.4 release in the short term
based on 21.3.  I'm inclined to accept his offer, but does anyone
argue against it?

------- Start of forwarded message -------
Date: Sun, 26 Sep 2004 16:30:46 +0200
From: =?iso-8859-1?b?Suly9G1l?= Marant <jerome.marant@free.fr>
To: rms@gnu.org
Cc: Rob Browning <rlb@defaultvalue.org>
Subject: Re: Possible help with stable Emacs releases.
In-Reply-To: <E1C65Sp-0000yG-Ha@fencepost.gnu.org>
X-Originating-IP: 62.212.105.6
X-Spam-Status: No, hits=-1.8 required=5.0
	tests=IN_REP_TO,QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES,
	      REPLY_WITH_QUOTES,USER_AGENT_IMP
	version=2.55
X-Spam-Level: 
X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp)


Hi,

Sorry for the late participation into the thread.

Selon Richard Stallman <rms@gnu.org>:

>     Practically speaking, this would probably mean having a stable branch
>     of Emacs CVS or separate CVS repository (if there isn't either
>     already) to which we would add the appropriate fixes as they are
>     found.  Eventually this tree would be used to produce a new stable
>     Emacs point release (i.e. 21.3.1, etc.).
>
> At this point we are starting to aim for a new release
> from the development sources.  I don't know if we want to
> make another release now from the old stable sources.

As Rob said, we are proposing this once Emacs 21.4 is released.
So, we are definitely not asking anything to Emacs developers currently.

> If you were to do the whole work of making the new release from the
> stable sources, then I guess we could do it.  But I fear that would
> tend to need help form the main Emacs developers, and the result would
> be to interfere with making the new development release.

Richard, it does not change for what is happening with the Debian
package. And you will notice that despite a growing number of
patches in the Debian package, we are rarely asking emacs developers
for help. So, we are definitely able to do a decent job with
a good cohabitation with emacs people. Sometimes, patches applied
to the stable branch are applied to the mainline as well.

As an example of why we need this: I need to use another GNU system
at work (namely Suse) and I use GNU Emacs but I can't benefit
from bugfixes and patches from the Debian package. And I don't have
time to grab the source, apply patches and so on. If patches were
directly applied to the stable branch, every other system would
benefit from them. And there are many people like me.

Since Emacs stable releases are quite rare, it would be a plus for
our users see their bug fixed sooner. This is why I reiterate
our proposal (again, we have time to think about it).

Would you mind that we ask emacs developers for what they think
about it?

> The main obstacle to a new release from the development sources is
> finding people to check the manual for errors.  Can you help with
> that?

We'll try to.

Cheers,

- --
Jérôme Marant
------- End of forwarded message -------

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> Marant is proposing to make a 21.4 release in the short term
> based on 21.3.  I'm inclined to accept his offer, but does anyone
> argue against it?

Well, most of you wise guys rejected my sensible idea to use 21.5 for
the next release from the trunk, as there would not going to be
another bug-fix release from the RC1 branch.  :-|

Now you say that it is going to happen anyway -- if nothing else, it
puts the burdon on us to (once again) update the trunk version numbers
everywhere...  Sigh!  

Why can't we just get our sense together and use 22.1 for the trunk
now -- and then use 23.1 for the unicode version ?

After all, the next release from the trunk is a pretty major update --
and if nothing else, if we release a 21.4 bug fix release soon, it is
much less confusing to people if the next _major_ update is named
22.1, not 21.5 (or 21.6 or whatever).


Other than that, I don't object to a 21.4 bug fix release.

But I'm a bit puzzled by these statements:

>>     Practically speaking, this would probably mean having a stable branch
>>     of Emacs CVS or separate CVS repository (if there isn't either
>>     already) to which we would add the appropriate fixes as they are
>>     found.  Eventually this tree would be used to produce a new stable
>>     Emacs point release (i.e. 21.3.1, etc.).

.. as they are found. Eventually ...

I thought the idea was to make a release with the current set of fixes
-- what's the point in a parallel bug-fix path if it's not going to
release anything _soon_.

> As Rob said, we are proposing this once Emacs 21.4 is released.

Why would you release a 2.3.1 after 21.4 is released  ??

> Richard, it does not change for what is happening with the Debian
> package. And you will notice that despite a growing number of
> patches in the Debian package, we are rarely asking emacs developers
> for help. So, we are definitely able to do a decent job with
> a good cohabitation with emacs people. Sometimes, patches applied
> to the stable branch are applied to the mainline as well.

Are you saying that you have a separate "Debian Emacs" (based on 21.3)
with a separate set of patches that are NOT in CVS emacs?

As a minimum, the patches included in your tree must be reflected in
the emacs CVS trunk -- otherwise, you will have fixed bugs in 21.4
that will re-appear in 22.1  (or 21.5 ... :-/ ).

>
> As an example of why we need this: I need to use another GNU system
> at work (namely Suse) and I use GNU Emacs but I can't benefit
> from bugfixes and patches from the Debian package. And I don't have
> time to grab the source, apply patches and so on. If patches were
> directly applied to the stable branch, every other system would
> benefit from them. And there are many people like me.

If you don't have time for that, do you really have time to take on
the task of releasing a new bug-fix release for emacs  (you have
to make snapshots, run the pretest procedure, etc.)

> Since Emacs stable releases are quite rare, it would be a plus for
> our users see their bug fixed sooner. This is why I reiterate
> our proposal (again, we have time to think about it).

Again, I don't see much time to think about this -- if you are going
to make a bug-fix release a reasonable time before the 22.1 release,
you should start the pretest pretty soon!

>> The main obstacle to a new release from the development sources is
>> finding people to check the manual for errors.  Can you help with
>> that?
>
> We'll try to.

That would be great!

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

Hi,

I'm not quoting your message because I think everything shall be
clarified. It seems that our proposal has been misunderstood.

What we propose is to maintain bugfix releases from stable
releases. This is exactly the kind of job we are doing with
the Debian Emacs package: collecting bugfixes, backporting
fixes from the trunk.
Currently, bugs are only fixed in the trunk and Emacs users
needs to wait for the next stable releases to see their bugs
fixed. Unfortunately, Emacs releases are quite rare and this is
understandable because releasing is boring.

This is why the packages maintainers need to do the job for
their users by adding tons of patches.
So, the main idea is to make a bugfix release every 4-6 months,
versioned X.Y.Z with Z varying. Hence, all Emacs users (and
not only Debian users, speaking of Debian) would benefit from
those bugfixes and we'd have less pathes in packages.

We propose to start this once 21.4 (the current CVS trunk) is
released. We don't intend to do anything about 21.3 because
21.4 is approching and it would be counterproductive.
It could be performed the GCC way: creating a bugfix branch
as soon as emacs is officially released. We'd be in charge
of applying patches there with emacs-devel consent, of course.
I'm sure it would be little demaning for emacs developers.

I hope it is clearer now.

Thanks for your feedback.

Cheers,

--
Jérôme Marant

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Kenichi Handa]

In article <E1CBq57-0000yV-4j@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:

> Marant is proposing to make a 21.4 release in the short term
> based on 21.3.  I'm inclined to accept his offer, but does anyone
> argue against it?

I'm strongly against it.  If the main reason why we don't
start 21.4 pretest from the trunk is that we have not yet
checked manuals, the same can be said for 21.3.  It seems
that most of documentation problems reported exist in 21.3
(thus not specific to changes done after 21.3).  It's
perhaps because we didn't checked the manual as precisely as
what Luc is now doing.

In other words, if we decide to fix pre-21.3 documentation
bugs later and concentrate on checking manuals only for
after-21.3 changes, I think we can start 21.4 preteset much
earlier.  I've just checked NEWS entries after 21.3.  There
are 629 entries and 328 of them don't have "+++" nor "---"
flags.  Who put flags on them how and when?  May I put flags
on mule-related changes (of course by updating manuals if
necessary)?

---
Ken'ichi HANDA
handa@m17n.org

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Stefan Monnier]

>> Marant is proposing to make a 21.4 release in the short term
>> based on 21.3.  I'm inclined to accept his offer, but does anyone
>> argue against it?

I think it would be a waste of time.  And several users would be
disappointed because the new release "still doesn't fix the bug I reported
4 years ago".
I haven't seen enormous amounts of bug reports in gnu.emacs.bug since 21.3
came out, and I haven't seen any significant bugfix on the RC branch, so
I think we should just fous on releasing the trunk rather than spend time on
a minor release that noone will care about (most machines I have access to
still use 21.2, BTW).


        Stefan

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Stefan Monnier]

> What we propose is to maintain bugfix releases from stable
> releases.  This is exactly the kind of job we are doing with
> the Debian Emacs package: collecting bugfixes, backporting
> fixes from the trunk.
> Currently, bugs are only fixed in the trunk and Emacs users
> needs to wait for the next stable releases to see their bugs
> fixed.  Unfortunately, Emacs releases are quite rare and this is
> understandable because releasing is boring.

Actually, we already have "the RC branch" from which 21.2 and 21.3 came.
So I agree to the extent that "Debian patches" should be applied to the RC
branch of Emacs rather than just to the Debian Emacs package (assuming the
fixes are sufficiently clean, of course).


        Stefan

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

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

> >> Marant is proposing to make a 21.4 release in the short term
> >> based on 21.3.  I'm inclined to accept his offer, but does anyone
> >> argue against it?
>
> I think it would be a waste of time.  And several users would be
> disappointed because the new release "still doesn't fix the bug I reported
> 4 years ago".

Please comment on my other reply. We do not intend to do anything
with 21.3. This is a general practice that could be started once
the next trunk is released.
You are telling that it is a waste of time: are you saying that
the time we spend providing bugfixes for Debian users of Emacs
is a waste of time?

> I haven't seen enormous amounts of bug reports in gnu.emacs.bug since 21.3
> came out, and I haven't seen any significant bugfix on the RC branch, so
> I think we should just fous on releasing the trunk rather than spend time on
> a minor release that noone will care about (most machines I have access to
> still use 21.2, BTW).

We have received tons of bug reports at Debian, and used to spend a
huge amount of time digging into the CVS trunk to backport fixes
for Emacs crashes. We wouldn't have to spend so much time if we had
provided a patch at the time it was applied to the trunk.
Saying that noone cares is plain wrong. Bug reports we receive
every day definitely proves you wrong.

--
Jérôme Marant

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

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

> > What we propose is to maintain bugfix releases from stable
> > releases.  This is exactly the kind of job we are doing with
> > the Debian Emacs package: collecting bugfixes, backporting
> > fixes from the trunk.
> > Currently, bugs are only fixed in the trunk and Emacs users
> > needs to wait for the next stable releases to see their bugs
> > fixed.  Unfortunately, Emacs releases are quite rare and this is
> > understandable because releasing is boring.
>
> Actually, we already have "the RC branch" from which 21.2 and 21.3 came.
> So I agree to the extent that "Debian patches" should be applied to the RC
> branch of Emacs rather than just to the Debian Emacs package (assuming the
> fixes are sufficiently clean, of course).

It is much easier to create a new branch for every stable release: you
can then avoid the pain of CVS merges for the same cost (I'm not
inventing anything, GCC people do this).

--
Jérôme Marant

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Miles Bader]

On Mon, Sep 27, 2004 at 03:21:11PM +0200, J?r?me Marant wrote:
> Please comment on my other reply. We do not intend to do anything
> with 21.3. This is a general practice that could be started once
> the next trunk is released.
> You are telling that it is a waste of time: are you saying that
> the time we spend providing bugfixes for Debian users of Emacs
> is a waste of time?

I think it's a great idea if it starts from 21.4 like you said.

It would mean that the somewhat moribund "bugfix" branches in Emacs CVS would
actually be rather more actively updated, thanks to the Debian maintainers.
Since it they're _already_ doing that work  (in Debian), it won't mean much
extra burden for them.

So (1) Emacs users win (get more robust minor bugfix releases), (2) Emacs
maintainers win (have happier uers, and can worry less about rushing out
major releases because more bugs get fixed in the bug-fix releases), and
(3) the Debian maintainers win (by getting a wider audience for their
fixes, without all that much extra work).

Geez, what's there _not_ to like about this plan...?

-Miles
-- 
`There are more things in heaven and earth, Horatio,
 Than are dreamt of in your philosophy.'

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Stefan Monnier]

>> Actually, we already have "the RC branch" from which 21.2 and 21.3 came.
>> So I agree to the extent that "Debian patches" should be applied to the RC
>> branch of Emacs rather than just to the Debian Emacs package (assuming the
>> fixes are sufficiently clean, of course).

> It is much easier to create a new branch for every stable release: you
> can then avoid the pain of CVS merges for the same cost (I'm not
> inventing anything, GCC people do this).

OK, it seems we're mis-communicating because I assume you know things you
don't.  "The" RC branch is the branch that's created when a new major
release is made.  I.e. when 21.1 was released, a new branch was created
(EMACS_21_1_RC).  From this branch were cut the bugfix releases 21.2 and
21.3.  When 21.4 will be release a new RC branch will be created.

I.e. right now there's a single RC branch for the simple reason that there's
only been a single major release since we switched to CVS.  But there will
be more (but obviously at any point in time only one RC branch is active,
because we don't have the manpower to continue releasing bugfix releases of
several major versions).

I.e. what you're suggesting is "what we already do" except that you're
proposing to be more actively involved in maintaining the RC branch (and you
suggest we call the revisions 21.1.N rather than 21.2, 21.3, ...).  I think
that any separately maintained set of patches is a waste of resouces, so of
course I'd welcome it if Debian put their patches directly in the RC branch
rather.


        Stefan

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Richard Stallman]

    We propose to start this once 21.4 (the current CVS trunk) is
    released. We don't intend to do anything about 21.3 because
    21.4 is approching and it would be counterproductive.

I had misunderstood that point.  Since this is only for
after 21.4, we don't need to make any real decisions now.
If you want to take charge of making bug fix releases
off 21.4, it sounds like a good thing.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

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

> >> Actually, we already have "the RC branch" from which 21.2 and 21.3 came.
> >> So I agree to the extent that "Debian patches" should be applied to the RC
> >> branch of Emacs rather than just to the Debian Emacs package (assuming the
> >> fixes are sufficiently clean, of course).
>
> > It is much easier to create a new branch for every stable release: you
> > can then avoid the pain of CVS merges for the same cost (I'm not
> > inventing anything, GCC people do this).
>
> OK, it seems we're mis-communicating because I assume you know things you
> don't.  "The" RC branch is the branch that's created when a new major
> release is made.  I.e. when 21.1 was released, a new branch was created
> (EMACS_21_1_RC).  From this branch were cut the bugfix releases 21.2 and
> 21.3.  When 21.4 will be release a new RC branch will be created.

I knew about this branch but I've been confused by 21.2 and 21.3 being
bugfix releases. This is why we do propose a different versioning scheme
for such releases.

> I.e. right now there's a single RC branch for the simple reason that there's
> only been a single major release since we switched to CVS.  But there will
> be more (but obviously at any point in time only one RC branch is active,
> because we don't have the manpower to continue releasing bugfix releases of
> several major versions).
>
> I.e. what you're suggesting is "what we already do" except that you're
> proposing to be more actively involved in maintaining the RC branch (and you
> suggest we call the revisions 21.1.N rather than 21.2, 21.3, ...).  I think
> that any separately maintained set of patches is a waste of resouces, so of
> course I'd welcome it if Debian put their patches directly in the RC branch
> rather.

This is exactly what we offer to do.

Cheers,

--
Jérôme Marant

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> On Mon, Sep 27, 2004 at 03:21:11PM +0200, J?r?me Marant wrote:
>> Please comment on my other reply. We do not intend to do anything
>> with 21.3. This is a general practice that could be started once
>> the next trunk is released.
>> You are telling that it is a waste of time: are you saying that
>> the time we spend providing bugfixes for Debian users of Emacs
>> is a waste of time?
>
> I think it's a great idea if it starts from 21.4 like you said.
>
> It would mean that the somewhat moribund "bugfix" branches in Emacs CVS would
> actually be rather more actively updated, thanks to the Debian maintainers.
> Since it they're _already_ doing that work  (in Debian), it won't mean much
> extra burden for them.
>
> So (1) Emacs users win (get more robust minor bugfix releases), (2) Emacs
> maintainers win (have happier uers, and can worry less about rushing out
> major releases because more bugs get fixed in the bug-fix releases), and
> (3) the Debian maintainers win (by getting a wider audience for their
> fixes, without all that much extra work).
>
> Geez, what's there _not_ to like about this plan...?

I agree.  This would be great!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

Selon Richard Stallman <rms@gnu.org>:

>     We propose to start this once 21.4 (the current CVS trunk) is
>     released. We don't intend to do anything about 21.3 because
>     21.4 is approching and it would be counterproductive.
>
> I had misunderstood that point.  Since this is only for
> after 21.4, we don't need to make any real decisions now.

Yes, we have some time to think about the details.

> If you want to take charge of making bug fix releases
> off 21.4, it sounds like a good thing.

Yes, we do. I'm convinced everyone would benefit from this.

--
Jérôme Marant

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Rob Browning]

Miles Bader <miles@gnu.org> writes:

> I think it's a great idea if it starts from 21.4 like you said.

So I'm wondering a little about the details.  From some other
projects, I'm used to an aproach where an X.Y.0 (or just X.Y) release
is a "major" release, one which might break things, might have "more
adventurous" changes in it, and might not happen very frequently , and
an X.Y.Z (for Z > 0) release is just a bugfix release, which is made
"as often as needed".  (Of course, X.0.0 releases would represent an
even bigger change than X.Y.0 releases.)

In the above scenario, whenever an X.Y.0 release is made, an X.Y
branch would be created for work on subsequent X.Y.Z releases.
However, from some of the discussion, I'm not sure this maps as
directly to the Emacs development process as I'd first thought.

Just to make sure what we've been proposing is clear -- if this
proposal had been implemented with the 23.1 release, then rather than
just backporting fixes into the Debian tree, Jerome and I would have
been backporting those fixes into a new branch created during the 23.1
release, and then would have released 23.1.1, 23.1.2, etc. from there.

It would also be important to try to be careful that the changes to
the bugfix branch are minimal and uncontroversial (i.e. bug fixes
rather than giant patches with new features), so that the divergence
from the mainstream development branch is minimized, and so that it's
not likely that a new point-release would cause unintentional new
breakage.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Stefan Monnier]

> So I'm wondering a little about the details.  From some other
> projects, I'm used to an aproach where an X.Y.0 (or just X.Y) release
> is a "major" release, one which might break things, might have "more
> adventurous" changes in it, and might not happen very frequently , and
> an X.Y.Z (for Z > 0) release is just a bugfix release, which is made
> "as often as needed".  (Of course, X.0.0 releases would represent an
> even bigger change than X.Y.0 releases.)

Let's ignore version numbers for now.  The issue of how to number them seems
to always drift into never ending discussions and I have no interest
in them.  Use whichever scheme you like.

Let's call 21.1 FOO, 21.2 BAR and 21.3 BAZ.

FOO was a major release, BAR and BAZ were minor releases cur from a branch
(that started off of FOO) and with only safe bugfixes applied.


        Stefan

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Rob Browning]

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

> Let's ignore version numbers for now.  The issue of how to number
> them seems to always drift into never ending discussions and I have
> no interest in them.  Use whichever scheme you like.
>
> Let's call 21.1 FOO, 21.2 BAR and 21.3 BAZ.
>
> FOO was a major release, BAR and BAZ were minor releases cur from a
> branch (that started off of FOO) and with only safe bugfixes
> applied.

The only problem I can see with that approach (though it might not
matter to you upstream) is that it makes the eventual version number
of the more substantial upstream development releases a moving target.

Imagine that 21.4 has been relased, and then imagine Jerome and I have
made 21.5, 21.6, and 21.7 bugfix releases using backports or patches
that were submitted to Debian, that have been approved by the Emacs
developers.  Now imagine that you're preparing to make a new release
from the "main" upstream development branch.  What do you call it?  If
you pick 21.8 and then you're unexpectedly delayed for a month or two
(for whatever reason), then we're in trouble if we need to make a
bugfix release (imagine a data-destroying bug of some kind that can't
wait).  We'd need something between 21.7 and 21.8.

Of course if you don't the possibility that you might have to keep
changing the pending upstream release number whenever we make a minor
bigfix release, then there's no problem, but even so, I suspect
there's also some value in people being able to easily tell the
difference between a truly minor bugfix release and one that's been
worked on for (historically) on the order of a year.

So while I don't have any special attachment to the X.Y.Z numbering
scheme, it's at least one way to fix both those problems.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Stefan Monnier]

> The only problem I can see with that approach (though it might not
> matter to you upstream) is that it makes the eventual version number
> of the more substantial upstream development releases a moving target.

As I said, I have no interest in discussing revision numbers.
If you feel like naming them 2.1, then 876.23.56.88, and the next one Toby,
that's perfectly fine with me.  Others here will probably disagree, but in
any case I think most such discussions are wastes of time, because it's
really not nearly as important as it's made out to be.


        Stefan

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

Selon Rob Browning <rlb@defaultvalue.org>:

> So while I don't have any special attachment to the X.Y.Z numbering
> scheme, it's at least one way to fix both those problems.

It brings some consistency to version numbering at least. If noone
objects (Stefan won't :-), we'll adopt this scheme.

Cheers,

--
Jérôme Marant

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Miles Bader]

Rob Browning <rlb@defaultvalue.org> writes:
> So while I don't have any special attachment to the X.Y.Z numbering
> scheme, it's at least one way to fix both those problems.

I think this sounds fine, and less confusing that recent practice.

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Luc Teirlinck]

Jerome Marant wrote:

   Selon Rob Browning <rlb@defaultvalue.org>:

   > So while I don't have any special attachment to the X.Y.Z numbering
   > scheme, it's at least one way to fix both those problems.

   It brings some consistency to version numbering at least. If noone
   objects (Stefan won't :-), we'll adopt this scheme.

After grepping for `emacs-version', it appears that changing the
current convention would require checking a surprisingly *huge* amount
of code.  A non-trivial amount of code will probably have to be
rewritten.  version.el definitely would have to be rewritten.  This is
a small file.  But it would then in turn force rewriting all kind of
other stuff, spread all over the place.  Many third party packages may
get broken, as they tend to check for emacs-version a lot and rely on
the current conventions.

Sincerely,

Luc.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Miles Bader]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:
> After grepping for `emacs-version', it appears that changing the
> current convention would require checking a surprisingly *huge* amount
> of code.  A non-trivial amount of code will probably have to be
> rewritten.

Huh?  Why?  Emacs already uses three-component version numbers, it's
just that nobody ever seems to use the last one except for setting it to
"50" in CVS.  Can you point out an example of code that would have to be
rewritten?  To my knowledge, about 99.9% of version-checking code does
simple string-compares to look at the first 2 digits.

An interesting idea might be to make `emacs-minor-version' a
floating-point number, e.g. for 21.4, emacs-minor-version is 4, but for
21.4.1, it would be 4.1.  I'll bet that would make a lot of code `just
work'.

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Rob Browning]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> After grepping for `emacs-version', it appears that changing the
> current convention would require checking a surprisingly *huge*
> amount of code.  A non-trivial amount of code will probably have to
> be rewritten.  version.el definitely would have to be rewritten.
> This is a small file.  But it would then in turn force rewriting all
> kind of other stuff, spread all over the place.  Many third party
> packages may get broken, as they tend to check for emacs-version a
> lot and rely on the current conventions.

Ahh.  I wondered about that.

OK, well, as I mentioned, I'm not set on any particular approach.  I
just wanted to bring up the release issues before deciding on a
process.  Of course, none of this has to be resolved immediately.  It
can certainly wait until 21.4 is ready.

Thanks
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

Quoting Rob Browning <rlb@defaultvalue.org>:

> Ahh.  I wondered about that.
>
> OK, well, as I mentioned, I'm not set on any particular approach.  I
> just wanted to bring up the release issues before deciding on a
> process.  Of course, none of this has to be resolved immediately.  It
> can certainly wait until 21.4 is ready.

No, if there is any problem, it shall be fixed in the trunk ASAP because
we don't want this part of the code to divert from the trunk in a bugfix
release.
Otherwise, we need to adopt another scheme.

Cheers,

--
Jérôme Marant

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Kim F. Storm]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> Jerome Marant wrote:
>
>    Selon Rob Browning <rlb@defaultvalue.org>:
>
>    > So while I don't have any special attachment to the X.Y.Z numbering
>    > scheme, it's at least one way to fix both those problems.
>
>    It brings some consistency to version numbering at least. If noone
>    objects (Stefan won't :-), we'll adopt this scheme.
>
> After grepping for `emacs-version', it appears that changing the
> current convention would require checking a surprisingly *huge* amount
> of code.  A non-trivial amount of code will probably have to be
> rewritten.  version.el definitely would have to be rewritten.  

I don't see why.

CVS emacs currently has emacs-version 21.3.50.12 or similar, so
what need changing?

>                                                                This is
> a small file.  But it would then in turn force rewriting all kind of
> other stuff, spread all over the place.  Many third party packages may
> get broken, as they tend to check for emacs-version a lot and rely on
> the current conventions.

If code usese emacs-version to check for what features are available then

a) that code is broken in the first place if it cannot handle the
   CVS emacs version string format, and

b) such code should only look at the X and Y components of the
   version number.


The rationale for b) is that the Z component differentiates BUG FIX
releases, so from 3rd party packages point of view, X.Y, X.Y.0 and
X.Y.7 are to be considered equivalent functionality-wise.

So I think X.Y.Z would work fine.



BTW, what is currently really broken in CVS emacs is that
emacs-minor-version is 3 -- it should be 4.

Since we use X.Y.50 and X.Y.90 for cvs and pretest versions
for X.(Y+1), a better approach would be:

(defconst emacs-minor-version
  (if (and (string-match "^[0-9]+\\.\\([0-9]+\\)\\.\\([0-9]+\\)" emacs-version)
           (>= (string-to-int (match-string 2 emacs-version)) 50))
      (1+ (string-to-int (match-string 1 emacs-version)))
    (string-to-int (match-string 1 emacs-version)))
  "Minor version number of this version of Emacs.
This variable first existed in version 19.23.")


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: Thu, 30 Sep 2004 11:36:33 +0200
> Cc: jerome.marant@free.fr, rms@gnu.org, emacs-devel@gnu.org,
> 	monnier@iro.umontreal.ca, rlb@defaultvalue.org, miles@gnu.org
> 
> CVS emacs currently has emacs-version 21.3.50.12 or similar, so
> what need changing?

I might be missing something, but don't we assume somewhere that
X.Y.Z.NN version signals a pretest, while X.Y.NN signals a released
version?

Anyway, what's wrong with the current scheme that we need to abandon
it, and how does the suggested 3-component scheme improves that to a
degree that justifies additional work (to fix all those places that
will need fixing)?

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Eli Zaretskii]

> From: Rob Browning <rlb@defaultvalue.org>
> Date: Wed, 29 Sep 2004 14:29:20 -0500
> Cc: "Kim F. Storm" <storm@cua.dk>, emacs-devel@gnu.org, rms@gnu.org,
> 	Jerome Marant <jmarant@free.fr>, Miles Bader <miles@gnu.org>
> 
> Imagine that 21.4 has been relased, and then imagine Jerome and I have
> made 21.5, 21.6, and 21.7 bugfix releases using backports or patches
> that were submitted to Debian, that have been approved by the Emacs
> developers.  Now imagine that you're preparing to make a new release
> from the "main" upstream development branch.  What do you call it?  If
> you pick 21.8 and then you're unexpectedly delayed for a month or two
> (for whatever reason), then we're in trouble if we need to make a
> bugfix release (imagine a data-destroying bug of some kind that can't
> wait).  We'd need something between 21.7 and 21.8.

The way it worked until now was that if a decision was made to release
the version X.N from a branch, the version number on the trunk was
bumped up to X.N+1.50.  This involves running "M-x set-version RET"
from admin.el.

The situation you describe, where both a branch and a trunk version
are undergoing a pretest never happened before, since Emacs
development until now assumed that we don't have enough resources to
do that, and so there was at most one pretest at a time.  I'm not sure
we can change that, given the available resources.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

Quoting Eli Zaretskii <eliz@gnu.org>:

> The way it worked until now was that if a decision was made to release
> the version X.N from a branch, the version number on the trunk was
> bumped up to X.N+1.50.  This involves running "M-x set-version RET"
> from admin.el.
>
> The situation you describe, where both a branch and a trunk version
> are undergoing a pretest never happened before, since Emacs
> development until now assumed that we don't have enough resources to
> do that, and so there was at most one pretest at a time.  I'm not sure
> we can change that, given the available resources.

So, are you telling that maintaing bugfix release like we proposed
is not doable because of the current numbering scheme?

If not, what do you propose?

Thanks.

--
Jérôme Marant

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Miles Bader]

On Thu, Sep 30, 2004 at 04:11:38PM +0200, Eli Zaretskii wrote:
> Anyway, what's wrong with the current scheme that we need to abandon
> it

Because the current scheme is confusing to users.  I've certainly observed
doubt as to whether a new Emacs release "means anything" (i.e. lots of new
features, or just a few random fixes) or not.

> and how does the suggested 3-component scheme improves that to a
> degree that justifies additional work (to fix all those places that
> will need fixing)?

What work?  I saw a similar claim earlier in this thread, grepped around a
bit, and saw no places that seemed to care what the version looks like.  No
doubt there are a few places like the maintenance scripts in admin, but
frankly if it's _only_ that, it's a silly objection -- there's certainly
somebody willing to fix those up.  Lisp packages are really the place that
matters, and as I mentioned, I've seen absolutely no evidence that such a
change would have any adverse impact at all.

I think the suggestion that a third-level component >= 50 mean "development"
is a very reasonable idea to retain that distinction, and in general
following Rob's would seem to result in something that's a lot less clunky
than the current system.

-Miles
-- 
I'm beginning to think that life is just one long Yoko Ono album; no rhyme
or reason, just a lot of incoherent shrieks and then it's over.  --Ian Wolff

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Miles Bader]

On Thu, Sep 30, 2004 at 04:21:47PM +0200, Eli Zaretskii wrote:
> The situation you describe, where both a branch and a trunk version
> are undergoing a pretest never happened before, since Emacs
> development until now assumed that we don't have enough resources to
> do that, and so there was at most one pretest at a time.  I'm not sure
> we can change that, given the available resources.

Um, the whole point of this thread is that more resources are on offer, for
this specific purpose.

-Miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

Quoting Eli Zaretskii <eliz@gnu.org>:

> Anyway, what's wrong with the current scheme that we need to abandon
> it, and how does the suggested 3-component scheme improves that to a
> degree that justifies additional work (to fix all those places that
> will need fixing)?

What scheme do you have in mind that won't clash with the current
scheme, that is, changing bugfix versions separately from trunk
versions?

--
Jérôme Marant

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Kim F. Storm]

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

>
> The way it worked until now was that if a decision was made to release
> the version X.N from a branch, the version number on the trunk was
> bumped up to X.N+1.50.  This involves running "M-x set-version RET"
> from admin.el.

And manually going through all the lisp modules changing "X.N" to "X.(N+1)".

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Kim F. Storm]

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

>> From: storm@cua.dk (Kim F. Storm)
>> Date: Thu, 30 Sep 2004 11:36:33 +0200
>> Cc: jerome.marant@free.fr, rms@gnu.org, emacs-devel@gnu.org,
>> 	monnier@iro.umontreal.ca, rlb@defaultvalue.org, miles@gnu.org
>> 
>> CVS emacs currently has emacs-version 21.3.50.12 or similar, so
>> what need changing?
>
> I might be missing something, but don't we assume somewhere that
> X.Y.Z.NN version signals a pretest, while X.Y.NN signals a released
> version?

Yes, and it is VERY confusion --- since X.Y.Z.NN is really a pretest
of X.(Y+1)

We once discussed the idea to use negative Z values for CVS and pretests,
e.g. instead of 21.3.50.NN we would have 21.4.-99.NN for CVS version
and pretests vould be 21.4.-98, 21.4.-97 etc.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Stefan Monnier]

>> Anyway, what's wrong with the current scheme that we need to abandon it

> Because the current scheme is confusing to users.  I've certainly observed
> doubt as to whether a new Emacs release "means anything" (i.e. lots of new
> features, or just a few random fixes) or not.

If you want that kind of clarity, then either say:
- use MAJOR.MINOR where MINOR is only incremented for bugfix releases and
  MAJOR is incremented for non-bugfix releases.  I.e. the next release would
  then be 22.1 and unicode would be 23.1.
- Use MAJOR.MIDDLE.MINOR where the difference is that some non-bugfix
  releases are deemed non-major (e.g. the next one would then be 21.4.1 and
  unicode would be 22.1.1).


        Stefan

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Rob Browning]

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

> The way it worked until now was that if a decision was made to release
> the version X.N from a branch, the version number on the trunk was
> bumped up to X.N+1.50.  This involves running "M-x set-version RET"
> from admin.el.

So the presumption was that there won't be more than about 50 bugfixes
before the next "primary release".  I suppose that has been true
historically speaking with respect to the Debian packages, though the
three number versioning scheme would avoid the whole concern.

To a large extent how many bugfix releases we could make in a year or
so will depend on how the developers want to handle the "bugfix only"
testing process.  Will it be the same process as for a "bigger"
release, or can it be handled differently since the changes allowed
are much more restricted?

A related question is what relevance/relationship (if any) should the
Debian release process have?

(In Debian, we normally release a new package as soon as we have a
 fix, it goes to unstable, and then it waits there for a time.  If
 "nothing goes wrong" with it or anything it depends on during that
 time, then that package migrates to testing for eventual inclusion in
 our next stable release.)

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Eli Zaretskii]

> Date: Thu, 30 Sep 2004 16:32:18 +0200
> From: =?iso-8859-1?b?Suly9G1l?= Marant <jmarant@free.fr>
> Cc: Rob Browning <rlb@defaultvalue.org>, emacs-devel@gnu.org
> 
> So, are you telling that maintaing bugfix release like we proposed
> is not doable because of the current numbering scheme?

I don't understand what ``like we proposed'' means.  I don't think the
current scheme disallows anything.

> If not, what do you propose?

To keep the current scheme.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Eli Zaretskii]

> Date: Thu, 30 Sep 2004 10:32:41 -0400
> Cc: storm@cua.dk, jerome.marant@free.fr, rlb@defaultvalue.org,
> 	emacs-devel@gnu.org
> From: Miles Bader <miles@gnu.org>
> 
> What work?  I saw a similar claim earlier in this thread, grepped around a
> bit, and saw no places that seemed to care what the version looks like.  No
> doubt there are a few places like the maintenance scripts in admin, but
> frankly if it's _only_ that, it's a silly objection -- there's certainly
> somebody willing to fix those up.

I suspect there's more than that.  E.g., the scripts we use to prepare
a release, etc.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Eli Zaretskii]

> Date: Thu, 30 Sep 2004 10:34:04 -0400
> Cc: Rob Browning <rlb@defaultvalue.org>, jmarant@free.fr,
> 	emacs-devel@gnu.org
> From: Miles Bader <miles@gnu.org>
> 
> On Thu, Sep 30, 2004 at 04:21:47PM +0200, Eli Zaretskii wrote:
> > The situation you describe, where both a branch and a trunk version
> > are undergoing a pretest never happened before, since Emacs
> > development until now assumed that we don't have enough resources to
> > do that, and so there was at most one pretest at a time.  I'm not sure
> > we can change that, given the available resources.
> 
> Um, the whole point of this thread is that more resources are on offer, for
> this specific purpose.

Like everyone else, I'm grateful for the offer, but I think you know
that it takes more to pretest a version than just administrative help
we are offered.  If this is enough to be able to run 2 pretests in
parallel, I just don't know; thus ``I'm not sure'' above.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Robert J. Chassell]

    > After grepping for `emacs-version', it appears that changing the
    > current convention would require checking a surprisingly *huge*
    > amount of code.

Can we not just increment the last component of the existing
three-component version number?

Right now, emacs/lisp/version.el says

    (defconst emacs-version "21.3.50" "\
    Version numbers of this version of Emacs.")

Could not that be incremented to "21.3.51" for a bug fix release?

(Or better yet, have the release be "21.4.0" and the bug fix releases
be "21.4.1", "21.4.2", etc; this would enable us to continue to
specify a 50 for the next version's CVS trunk and a 90 for the
pretest, as in "21.4.50". ... Of course, I presume fewer than 50 bug
fix releases before a minor or major version number increment .... :)

Let's refer to the existing third component as the tertiant, with its
adjective being `tertiary'.  If for whatever reason, we need to
specify a variable then it would be the third of this sequence;

    emacs-major-version
    emacs-minor-version
    emacs-tertiary-version

as in 

(defconst emacs-tertiary-version
  (progn 
    (string-match "\\(^[0-9]+\\.\\([0-9]+\\).\\([0-9]+\\)\\)" emacs-version)
    (string-to-int (match-string 3 emacs-version)))
  "Version number of the third component of emacs-version.")

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Eli Zaretskii]

> From: storm@cua.dk (Kim F. Storm)
> Date: Thu, 30 Sep 2004 16:55:02 +0200
> Cc: jmarant@free.fr, Rob Browning <rlb@defaultvalue.org>, emacs-devel@gnu.org
> 
> "Eli Zaretskii" <eliz@gnu.org> writes:
> 
> >
> > The way it worked until now was that if a decision was made to release
> > the version X.N from a branch, the version number on the trunk was
> > bumped up to X.N+1.50.  This involves running "M-x set-version RET"
> > from admin.el.
> 
> And manually going through all the lisp modules changing "X.N" to "X.(N+1)".

That can be handled by using a far-ahead value for the minor version
on the trunk (we did that in the past).

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org, jmarant@free.fr
> From: Rob Browning <rlb@defaultvalue.org>
> Date: Thu, 30 Sep 2004 10:15:06 -0500
> 
> So the presumption was that there won't be more than about 50 bugfixes
> before the next "primary release".

Yes.

In my experience, most pretest versions started from .80, with some
major ones beginning at .70.

> To a large extent how many bugfix releases we could make in a year or
> so will depend on how the developers want to handle the "bugfix only"
> testing process.  Will it be the same process as for a "bigger"
> release, or can it be handled differently since the changes allowed
> are much more restricted?

I don't think it matters: in any case, it takes a non-trivial amount
of time to run a pretest.

One related problem is that AFAIK we have no clear criteria for when a
version, be it bugfix or major, is ready for a release.

> (In Debian, we normally release a new package as soon as we have a
>  fix, it goes to unstable, and then it waits there for a time.  If
>  "nothing goes wrong" with it or anything it depends on during that
>  time, then that package migrates to testing for eventual inclusion in
>  our next stable release.)

I think Emacs is such a large package that it doesn't make sense to
have a new version more than once in a month or two.  But that, too,
was never discussed nor codified since we never could end a pretest as
soon as that.  Perhaps we should delay this discussion until we get to
such a situation for the first time.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

Quoting Eli Zaretskii <eliz@gnu.org>:

> > Um, the whole point of this thread is that more resources are on offer, for
> > this specific purpose.
>
> Like everyone else, I'm grateful for the offer, but I think you know
> that it takes more to pretest a version than just administrative help
> we are offered.  If this is enough to be able to run 2 pretests in
> parallel, I just don't know; thus ``I'm not sure'' above.

Why would we necessarily have to go through this pretest phase the
way it is currently done for major releases?

You look worried about being involved in such releases, but we
are proposing to be delegated to perform such a job (which we are
used to do for debian package).

--
Jérôme Marant

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

Quoting Eli Zaretskii <eliz@gnu.org>:

> I think Emacs is such a large package that it doesn't make sense to
> have a new version more than once in a month or two.  But that, too,
> was never discussed nor codified since we never could end a pretest as
> soon as that.  Perhaps we should delay this discussion until we get to
> such a situation for the first time.

How about using odd minor version numbers for development versions
and even minor version number for stable releases?

Hence, 21.4.z would be a stable release and we would freely use z.
21.5.z would be the next development release renamed 22.0 later?

--
Jérôme Marant

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Richard Stallman]

    Imagine that 21.4 has been relased, and then imagine Jerome and I have
    made 21.5, 21.6, and 21.7 bugfix releases using backports or patches
    that were submitted to Debian, that have been approved by the Emacs
    developers.  Now imagine that you're preparing to make a new release
    from the "main" upstream development branch.  What do you call it?

22.1, I think.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Eli Zaretskii]

> Date: Thu, 30 Sep 2004 17:53:39 +0200
> From: =?iso-8859-1?b?Suly9G1l?= Marant <jmarant@free.fr>
> Cc: Miles Bader <miles@gnu.org>, rlb@defaultvalue.org,
> 	emacs-devel@gnu.org
> 
> > Like everyone else, I'm grateful for the offer, but I think you know
> > that it takes more to pretest a version than just administrative help
> > we are offered.  If this is enough to be able to run 2 pretests in
> > parallel, I just don't know; thus ``I'm not sure'' above.
> 
> Why would we necessarily have to go through this pretest phase the
> way it is currently done for major releases?

I don't understand the question; are you saying that bugfix releases
don't need to go through a pretest phase?  I wasn't aware something
like that was being proposed in these discussions.

> You look worried about being involved in such releases, but we
> are proposing to be delegated to perform such a job

Unless we will agree to release bugfix versions without pretesting
them, I don't think you will be able to perform that job on your own.
A pretest needs to be done on several platforms, for starters.  Also,
at least in the past, some of the changes checked in to the release
branch were non-trivial enough to warrant significant testing.

Changing all that would mean a serious surgery of the current
development procedures.  I'm not necessarily opposed to such changes,
but I'd say that a change in version numbering is dwarfed by the
seriousness of issues we need to discuss and agree before such a
surgery could take place.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Rob Browning]

storm@cua.dk (Kim F. Storm) writes:

> Yes, and it is VERY confusion --- since X.Y.Z.NN is really a pretest
> of X.(Y+1)

I think that's one of the motivations for projects that have gone to
the even/odd MINOR convention given the MAJOR.MINOR.MICRO versioning
style.  Then you can release as many odd-numbered versions as you
like, as long as everyone knows the convention.

Changing to that approach in guile has been fairly successful, though
there are still issues.  For example, for the final tests of a
X.EVEN.0 candidate (say 1.6.0), you may not want to test something
that's actually numbered 1.5.43 in the code, and then change the
version to 1.6.0 just before making the release build.  Even if that
final build has no other changes, it still hasn't been tested.

The solution I'm currently using for guile is to actually version the
final release candidate as the final release, i.e. 1.6.0, but to name
the pre-release tarfiles as guile-1.6.0rcN.tar.gz rather than
guile-1.6.0.tar.gz, and then place them on alpha.gnu.org.  In all
other ways, the release candidate tarfile *is* the tarfile that will
become the final release, if no relevant bugs are found.

Actually, that's not exactly right.  I'm also considering placing a
file inside the pre-release indicating that it's a pre-release and
indicating which pre-release.  When a pre-release (rcN) tarfile
finally checks out and is ready to become the the final release, that
"pre-release indicator" file will just be removed without building a
new dist via tar --delete or similar.

This will still leave misleading things like "Guile 1.6.0 released."
in a pre-release ChangeLog (when it should really say "Guile 1.6.0
release candidate N.", but in my estimation that's better than
alternatives that would require another CVS commit, and building an
untested new distfile.  Also, since the pre-releases will only be
uploaded to alpha.gnu.org, it seems unlikely that someone would end up
accidentally confused.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Rob Browning]

Jérôme Marant <jmarant@free.fr> writes:

> Why would we necessarily have to go through this pretest phase the
> way it is currently done for major releases?

I don't think it's reasonable to presume that emacs-devel would want
to be as agressive about these micro releases as Debian.  Debian's
model is different, handling the testing *after* the intial release
via the progression from unstable -> testing -> stable.

During this entire process (of considering helping make emacs stable
releases), I've felt like this issue is likely to be the critical one.
It's possible that the emacs developers will want to be cautious
enough about all the releases (even the minor ones) that the overhead
will be too high for two people (who are already busy) to handle on
their own.  That's fine, and I can understand it.

The key here, in my opinion, is to find out what the emacs developers
*would* be comfortable with, then figure out how that would fit in
with the work we already have to do in Debian, and then determine
whether or not the impedence mismatch is low enough that it's an
overall win for everyone.

If not, then we should just go back to working on the Debian packages.
In that situation, I suppose we could also consider offering an
unofficial "branch" that just contained the non-debian-specific
patches from debian/patches/*, but I wouldn't be excited about that
unless most of the emacs developers are comfortable with it.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Rob Browning]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Let's refer to the existing third component as the tertiant, with its
> adjective being `tertiary'.  If for whatever reason, we need to
> specify a variable then it would be the third of this sequence;
>
>     emacs-major-version
>     emacs-minor-version
>     emacs-tertiary-version

FWIW this has also been called the "micro" version in other projects,
i.e. emacs-micro-version.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Rob Browning]

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

> I don't understand the question; are you saying that bugfix releases
> don't need to go through a pretest phase?  I wasn't aware something
> like that was being proposed in these discussions.

I'm not sure about Jerome's position, but as my other message
suggested I'm fairly agnostic with respect to what process the emacs
developers will feel is appropriate for these more minor releases.  In
the end, the thing I'll have to evaluate is whether or not I feel I
can handle the work required by that process.

I can understand both the argument that these releases should be
tested just as fully as any other release, and the alternative
argument that they should be treated as much lighter-weight.

The latter argument usually claims that since the changes that go into
these releases are much more controlled (and much smaller) than other
releases, and since it's relatively easy to follow up a problematic
minor release with a repair, then the minor releases won't normally
need as much testing as the more major releases.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Stefan Monnier]

>> The way it worked until now was that if a decision was made to release
>> the version X.N from a branch, the version number on the trunk was
>> bumped up to X.N+1.50.  This involves running "M-x set-version RET"
>> from admin.el.

> So the presumption was that there won't be more than about 50 bugfixes
> before the next "primary release".

No, the .50 is used for all the "versions" until the first pretest.
The pretests then start at .90, then .91, .92, ... and can go to
.9999999999999999997, ... so we have a large enough pool of pretest
version numbers.


        Stefan

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Richard Stallman]

    We once discussed the idea to use negative Z values for CVS and pretests,
    e.g. instead of 21.3.50.NN we would have 21.4.-99.NN for CVS version
    and pretests vould be 21.4.-98, 21.4.-97 etc.

One drawback of this idea is that the pretest version numbers are moving
towards a fixed limit of zero, which puts a bound on them.  What we
really want is numbers like 21.4.-1/1, 21.4.-1/2, 21.4.-1/3, where
the pretest version numbers form series converging towards zero.
Or perhaps 21.4-1/2, 21.4-1/3, 21.4-1/4, which converge towards 21.4.

    - use MAJOR.MINOR where MINOR is only incremented for bugfix releases and
      MAJOR is incremented for non-bugfix releases.  I.e. the next release would
      then be 22.1 and unicode would be 23.1.

That would be a good scheme, I think.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Stefan Monnier]

> I don't understand the question; are you saying that bugfix releases
> don't need to go through a pretest phase?  I wasn't aware something
> like that was being proposed in these discussions.

Can we distinguish issues here, lest we end up frustrating people.
I see 3 parts:

1 - "unify" the Debian patches and the RC branch.  I.e. that the Debian
    maintainer install fixes directly on the RC branch rather than in some
    unrelated Debian-only area.

2 - somehow change the bugfix release process (to be more frequent), again
    here, basically leveraging from Debian's own bugfix-release process.

3 - fiddle with the release numbering.

As long as 1 and 2 are done in a way that it not Debian-only
(i.e. things like patches that introduce bugs on non-Debian systems),
1 and 2 seem like good ideas to me, basically giving us more manpower
(which is currently only beneficial to Debian).

I think the issue of whether we can do 2 or not is mostly irrelevant: if the
pretests take too much time, then we necessarily won't make them more often.
I.e. if it works it works and if it doesn't, then it works as before.
I don't see what's to discuss.


        Stefan

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Eli Zaretskii]

> Cc: jmarant@free.fr, emacs-devel@gnu.org
> From: Rob Browning <rlb@defaultvalue.org>
> Date: Thu, 30 Sep 2004 12:20:49 -0500
> 
> I can understand both the argument that these releases should be
> tested just as fully as any other release, and the alternative
> argument that they should be treated as much lighter-weight.
> 
> The latter argument usually claims that since the changes that go into
> these releases are much more controlled (and much smaller) than other
> releases, and since it's relatively easy to follow up a problematic
> minor release with a repair, then the minor releases won't normally
> need as much testing as the more major releases.

I agree that bugfix releases should need less testing, but still we
do have a pretest phase for them.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 30 Sep 2004 13:31:03 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, jmarant@free.fr, emacs-devel@gnu.org
> 
> No, the .50 is used for all the "versions" until the first pretest.
> The pretests then start at .90, then .91, .92, ... and can go to
> .9999999999999999997, ... so we have a large enough pool of pretest
> version numbers.

Actually, some major releases went above .100 in the minor-minor
field.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Stefan Monnier]

>> No, the .50 is used for all the "versions" until the first pretest.
>> The pretests then start at .90, then .91, .92, ... and can go to
>> .9999999999999999997, ... so we have a large enough pool of pretest
>> version numbers.

> Actually, some major releases went above .100 in the minor-minor
> field.

True, that's another way to continue the sequence after .90, ..., .99
and IIRC both have been used in the past.  I like the .999 scheme better,
tho ;-)


        Stefan

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

Selon Eli Zaretskii <eliz@gnu.org>:

> > Why would we necessarily have to go through this pretest phase the
> > way it is currently done for major releases?
>
> I don't understand the question; are you saying that bugfix releases
> don't need to go through a pretest phase?  I wasn't aware something
> like that was being proposed in these discussions.

Me neither. I've never said there wouldn't be any pretest phase.
I'm saying that pretesting a bugfix release is different from
pretesting a major release; it is shorter at least.
I'll also in favour of test cases we can replay every time we
add new patches. Since emacs is able to run in batch, there is
no reason no to do so.

> > You look worried about being involved in such releases, but we
> > are proposing to be delegated to perform such a job
>
> Unless we will agree to release bugfix versions without pretesting
> them, I don't think you will be able to perform that job on your own.

I've never intended to avoid pretesting bugfix releases.
We are doing the same job on the Debian side and we never release
patches in hurry.

> A pretest needs to be done on several platforms, for starters.  Also,
> at least in the past, some of the changes checked in to the release
> branch were non-trivial enough to warrant significant testing.

Patches are usually tested in the trunk first at least. We can
delay their application to the bugfix branch while they are being
tested.

> Changing all that would mean a serious surgery of the current
> development procedures.  I'm not necessarily opposed to such changes,
> but I'd say that a change in version numbering is dwarfed by the
> seriousness of issues we need to discuss and agree before such a
> surgery could take place.

Isn't what we are doing currently?

--
Jérôme

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Robert J. Chassell]

As I understand, we are talking about two different entities:

  * Debian, who only work with releases from the Emacs developers

  * Emacs, the developers, who work with CVS

The Debian people have been making Debian packages out of Emacs for
years.  They are not planning on becoming Emacs developers.

They have not and are *not* proposing to test a release from _Emacs_
developers.

The Debian people are proposing

 1. to continue to make Debian packages out of Emacs releases, and,

 2. occasionally to fix bugs in their packages, which means making new
    Debian packages.

They hope to get their bug fixes from the Emacs CVS development trunk,
but they are not, themselves proposing to do any of the pretesting
needed for a release from _Emacs_ developers.

In other words, the Debian people are *not* proposing to do a
`pretest' as Emacs developers understand it.  They are proposing to
back port some bug fixes to an old version previously released by
Emacs developers.

Currently, the Debian Emacs has a version number that looks like this:

    21.3+1

(I just checked using `apt-cache show emacs21'; the full Debian Emacs
version number is `21.3+1-7' but my understanding is that the `7'
merely means this is the 7th Debian package of this series and is as
irrelevant to us as the fourth component of my emacs-version is to
you.)

Should the Debian version number remain like that or should it be
changed?  For example, it might be changed to:

    21.3.1

and be distinguished from the version number of the current CVS, which
looks like this:

    21.3.50

The advantage of a closer connection with the Debian people is that we
can be more confident in our pretests that some of the bug fixes will
work (probabilistically speaking).  This is because the Debian people
will have backported them and tested them on a previous release.

(This does not mean that the changes will be without bugs in the new
release; it means that they worked for the previous release.
Pretesting will still be necessary.  But, probabilistically speaking,
we can be somewhat more confident.)

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Robert J. Chassell]

Rob Browning <rlb@defaultvalue.org> wrote

   >     emacs-major-version
   >     emacs-minor-version
   >     emacs-tertiary-version

   FWIW this has also been called the "micro" version in other projects,
   i.e. emacs-micro-version.

That is OK with me.  It is not a big deal.

The reason I think in terms of `tertiants', is that the base of each
component in a version number may be different.  

Dates and times use months, days, hours, minutes, seconds, and
(occasionally) tertiants.  These components are not all numbered in
base 12 (as they ought to be).  Whenever I think in terms of `micro',
and `nano', I think of components using the same base, like
microseconds and nanoseconds.

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Robert J. Chassell]

       - use MAJOR.MINOR where MINOR is only incremented for bugfix
         releases and MAJOR is incremented for non-bugfix releases.
         I.e. the next release would then be 22.1 and unicode would be
         23.1.

   That would be a good scheme, I think.

The goal is to provide a decent program.  One whose version numbers
confuse people, so they think a major upgrade is a minor bug fix, is
no good.  Historically, Emacs has signified major changes with
integral number changes: version 19 was the biggest of those changes
(from a user's point of view).  

Why not make more use of the three component numbering scheme we
already have and use in CVS?  

-- 
    Robert J. Chassell                         
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

Selon "Robert J. Chassell" <bob@rattlesnake.com>:

> As I understand, we are talking about two different entities:
>
>   * Debian, who only work with releases from the Emacs developers
>
>   * Emacs, the developers, who work with CVS
>
> The Debian people have been making Debian packages out of Emacs for
> years.  They are not planning on becoming Emacs developers.
>
> They have not and are *not* proposing to test a release from _Emacs_
> developers.
>
> The Debian people are proposing
>
>  1. to continue to make Debian packages out of Emacs releases, and,
>
>  2. occasionally to fix bugs in their packages, which means making new
>     Debian packages.

Robert,

Please re-read the whole thread and come back when you have done so.
You misunderstood everything, no offence meant.

Thanks in advance.

--
Jérôme Marant

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     We once discussed the idea to use negative Z values for CVS and pretests,
>     e.g. instead of 21.3.50.NN we would have 21.4.-99.NN for CVS version
>     and pretests vould be 21.4.-98, 21.4.-97 etc.
>
> One drawback of this idea is that the pretest version numbers are moving
> towards a fixed limit of zero, which puts a bound on them.  

So call the CVS version 21.4.-999 and let the pretests use -998 -997 etc.
That should be enough I think (hope :-)

>     - use MAJOR.MINOR where MINOR is only incremented for bugfix releases and
>       MAJOR is incremented for non-bugfix releases.  I.e. the next release would
>       then be 22.1 and unicode would be 23.1.
>
> That would be a good scheme, I think.

I really wish we could agree on renumbering the next release from trunk to 22.1.

It is the first major release in YEARS, so it warrants a new major release number.

And it could mark the start of a new bug-fix numbering scheme:

CVS version:  22.1.-999
Pretests:     22.1.-998 ... 22.1.-1
Initial release: 22.1  (or 22.1.0)
Bug fixes:    22.1.1, 22.1.2, ...

Minor releases: 22.2, 22.3, ...


I hereby offer to make all the necessary changes!

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Stefan Monnier]

> CVS version:  22.1.-999
> Pretests:     22.1.-998 ... 22.1.-1
> Initial release: 22.1  (or 22.1.0)
> Bug fixes:    22.1.1, 22.1.2, ...
> Minor releases: 22.2, 22.3, ...

Counter proposal:

CVS version:  22.0.50
Pretests:     22.0.90, 22.0.91, ..., 22.0.99, 22.0.991, ...
Initial release: 22.1
Bug fixes:    22.2, 22.3, ...
Minor release = bug fix

I hereby offer to make all the necessary changes (barely any, other than
change all the references to 21.4 to say 22.1 and to change 21.3.50 to
22.0.50).


        Stefan

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

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

> I think the issue of whether we can do 2 or not is mostly irrelevant: if the
> pretests take too much time, then we necessarily won't make them more often.
> I.e. if it works it works and if it doesn't, then it works as before.
> I don't see what's to discuss.

But if people think this change in the management of bugfix releases
is a good thing, aren't they going to do everything for it to succeed?
Let's clarify: we do propose to add more manpower for doing the
"dirty job" (honestly, noone loves tracking bugs), but it will never
work without a little cooperation from Emacs developers.
Can I have a guaranty that I'll never be pissed off or ignored on
blocking situations? ("go fuck yourself! You wanted to do the job,
you'll have to do this without us!")

--
Jérôme Marant

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

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

> > CVS version:  22.1.-999
> > Pretests:     22.1.-998 ... 22.1.-1
> > Initial release: 22.1  (or 22.1.0)
> > Bug fixes:    22.1.1, 22.1.2, ...
> > Minor releases: 22.2, 22.3, ...
>
> Counter proposal:
>
> CVS version:  22.0.50
> Pretests:     22.0.90, 22.0.91, ..., 22.0.99, 22.0.991, ...
> Initial release: 22.1
> Bug fixes:    22.2, 22.3, ...
> Minor release = bug fix

Counter proposal (the linux way):

CVS version: 21.5.50
Pretests: 21.5.90 ...
Initial release: 22.0
Bugfix releases: 22.0.1, 22.0.2 ...

CVS version: 22.1.50
Pretests: 21.1.90 ...
Initial release: 22.2
Bugfix releases: 22.2.1, 22.2.2 ...

Nothing to change in the current code.

--
Jérôme Marant

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Kim F. Storm]

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

>> CVS version:  22.1.-999
>> Pretests:     22.1.-998 ... 22.1.-1
>> Initial release: 22.1  (or 22.1.0)
>> Bug fixes:    22.1.1, 22.1.2, ...
>> Minor releases: 22.2, 22.3, ...
>
> Counter proposal:
>
> CVS version:  22.0.50
> Pretests:     22.0.90, 22.0.91, ..., 22.0.99, 22.0.991, ...
> Initial release: 22.1
> Bug fixes:    22.2, 22.3, ...
> Minor release = bug fix
>
> I hereby offer to make all the necessary changes (barely any, other than
> change all the references to 21.4 to say 22.1 and to change 21.3.50 to
> 22.0.50).

This proposal still does not address the constant confusion (just look
at the mailing lists) about the unclear numbering of the CVS version;
IMO, the cvs version and pretests should use THE SAME minor number as
the final release -- not the minor number of previous release.

What about:

CVS version:  22.1.-999
Pretests:     22.1.-998 ... 22.1.-1
Initial release: 22.1
Bug fixes:    22.2, 22.3, ...
Minor releases = bug fix

This also allows us to have a "working" version in CVS for bug fixes /
minor releases, e.g.

     22.2.-999

and run pretests for minor releases, e.g.

     22.2.-998


-- 
Kim F. Storm  http://www.cua.dk

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Stefan Monnier]

>> I think the issue of whether we can do 2 or not is mostly irrelevant:
>> if the pretests take too much time, then we necessarily won't make them
>> more often.  I.e. if it works it works and if it doesn't, then it works
>> as before.  I don't see what's to discuss.

> But if people think this change in the management of bugfix releases
> is a good thing, aren't they going to do everything for it to succeed?
> Let's clarify: we do propose to add more manpower for doing the
> "dirty job" (honestly, noone loves tracking bugs), but it will never
> work without a little cooperation from Emacs developers.
> Can I have a guaranty that I'll never be pissed off or ignored on
> blocking situations? ("go fuck yourself! You wanted to do the job,
> you'll have to do this without us!")

I don't expect any such problem.  The worst I expect is that you might
sometimes be prevented from installing a bugfix because it's not "good
enough" (which is something that happens all the time anyway).
Also sometimes things won't go as fast as you'd like.

In order for you not to be frustrated, I think the best option is to take it
slow: after all, the process already exists, and you're just offering to
help out, so you can start by just systematically submitting the patches
that you'd like to apply to Debian's tree (so they get installed in RC),
then regularly bug people to remind them that we should get the next pretest
started, ...


        Stefan

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Kim F. Storm]

Jérôme Marant <jmarant@free.fr> writes:

> Can I have a guaranty that I'll never be pissed off or ignored on
> blocking situations? ("go fuck yourself! You wanted to do the job,
> you'll have to do this without us!")

I believe all of us will help as much as we can.

But even developers can have a bad day, so no guarantees :-)



-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Andreas Schwab]

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

> True, that's another way to continue the sequence after .90, ..., .99
> and IIRC both have been used in the past.  I like the .999 scheme better,
> tho ;-)

Since version numbers are not fractions, but rather sequences of numbers,
continuing with .100 is more natural.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Kim F. Storm]

Jérôme Marant <jmarant@free.fr> writes:

>
> Counter proposal (the linux way):
>
> CVS version: 21.5.50
> Pretests: 21.5.90 ...
> Initial release: 22.0
> Bugfix releases: 22.0.1, 22.0.2 ...

IMO this is even worse than the current scheme -- we could
be running a pretest with both major and minor numbers which
differs from the final release...

And traditionally, we don't use XX.0 (IIRC).

>
> CVS version: 22.1.50
> Pretests: 21.1.90 ...
> Initial release: 22.2
> Bugfix releases: 22.2.1, 22.2.2 ...
>
> Nothing to change in the current code.


Dejavu...
It seems that we run around in circles every time we discuss this issue.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Andreas Schwab]

storm@cua.dk (Kim F. Storm) writes:

> And it could mark the start of a new bug-fix numbering scheme:
>
> CVS version:  22.1.-999
                22.0.1
> Pretests:     22.1.-998 ... 22.1.-1
                22.0.50 ...
> Initial release: 22.1  (or 22.1.0)
> Bug fixes:    22.1.1, 22.1.2, ...
>
> Minor releases: 22.2, 22.3, ...

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Stefan Monnier]

> This proposal still does not address the constant confusion (just look
> at the mailing lists) about the unclear numbering of the CVS version;

I haven't seen much such confusion.
At least, it's eclipsed by the confusion of 21.3 being a bugfix release
rather than a major release.


        Stefan

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Kim F. Storm]

Andreas Schwab <schwab@suse.de> writes:

> storm@cua.dk (Kim F. Storm) writes:
>
>> And it could mark the start of a new bug-fix numbering scheme:
>>
>> CVS version:  22.1.-999
>                 22.0.1
>> Pretests:     22.1.-998 ... 22.1.-1
>                 22.0.50 ...
>> Initial release: 22.1  (or 22.1.0)
>> Bug fixes:    22.1.1, 22.1.2, ...
>>
>> Minor releases: 22.2, 22.3, ...
>

Or simpler:

 CVS version:  22.0
 Pretests:     22.0.1, 22.0.2, ...
 Initial release: 22.1
 Bug fixes:    22.2, 22.3
 Minor release = bug fixes


And CVS version bumps to 23.0 when 22.1 is released.

 
-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Stefan Monnier]

>  CVS version:  22.0
>  Pretests:     22.0.1, 22.0.2, ...
>  Initial release: 22.1
>  Bug fixes:    22.2, 22.3
>  Minor release = bug fixes

That's what I originally wrote and then I switched back to 22.0.50 and
22.0.90 because 22.0 bug reports would otherwise be sent to gnu.emacs.bug
rather than to emacs-pretest-bug ;-0


        Stefan

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Francesco Potorti`]

>Imagine that 21.4 has been relased, and then imagine Jerome and I have
>made 21.5, 21.6, and 21.7 bugfix releases using backports or patches
>that were submitted to Debian, that have been approved by the Emacs
>developers.  Now imagine that you're preparing to make a new release
>from the "main" upstream development branch.  What do you call it?  If
>you pick 21.8 and then you're unexpectedly delayed for a month or two
>(for whatever reason), then we're in trouble if we need to make a
>bugfix release (imagine a data-destroying bug of some kind that can't
>wait).  We'd need something between 21.7 and 21.8.

Fortunately this problem does not exist.  The release number is
generated the moment that the tarball is made, so no provision or number
locking is needed in advance of the very last step of making the
tarball.

>Of course if you don't the possibility that you might have to keep
>changing the pending upstream release number whenever we make a minor
>bigfix release, then there's no problem, but even so, I suspect
>there's also some value in people being able to easily tell the
>difference between a truly minor bugfix release and one that's been
>worked on for (historically) on the order of a year.

While I want to make clear once again that this is a separate issue,
which is completely independent from the previous one, yes, I agree that
clearly indicating which releases are bugfix-only and which are not
would be valuable.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

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

> >> I think the issue of whether we can do 2 or not is mostly irrelevant:
> >> if the pretests take too much time, then we necessarily won't make them
> >> more often.  I.e. if it works it works and if it doesn't, then it works
> >> as before.  I don't see what's to discuss.
>
> > But if people think this change in the management of bugfix releases
> > is a good thing, aren't they going to do everything for it to succeed?
> > Let's clarify: we do propose to add more manpower for doing the
> > "dirty job" (honestly, noone loves tracking bugs), but it will never
> > work without a little cooperation from Emacs developers.
> > Can I have a guaranty that I'll never be pissed off or ignored on
> > blocking situations? ("go fuck yourself! You wanted to do the job,
> > you'll have to do this without us!")
>
> I don't expect any such problem.  The worst I expect is that you might
> sometimes be prevented from installing a bugfix because it's not "good
> enough" (which is something that happens all the time anyway).
> Also sometimes things won't go as fast as you'd like.

I've told many time that we won't apply patches without emacs-devel
consents. Usually, by reading the list, you'll notice that we often
forward bug reports and patches to the list. Sometimes we write
patches ourselves for our users.

> In order for you not to be frustrated, I think the best option is to take it
> slow: after all, the process already exists, and you're just offering to
> help out, so you can start by just systematically submitting the patches
> that you'd like to apply to Debian's tree (so they get installed in RC),
> then regularly bug people to remind them that we should get the next pretest
> started, ...

Ok, I see. You are worried about giving CVS access to people with a
too low level of trust.
Well, no matter. The less I do, the more you have to. Maybe will you
manage to prove that it's not worth it because it requires too much
manpower from emacs-devel.
As I said, we are already doing the work of collecting patches (backporting,
and testing) for our users.

--
Jérôme Marant

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Stefan]

>> I don't expect any such problem.  The worst I expect is that you might
>> sometimes be prevented from installing a bugfix because it's not "good
>> enough" (which is something that happens all the time anyway).
>> Also sometimes things won't go as fast as you'd like.

> I've told many time that we won't apply patches without emacs-devel
> consents.

Right.  I assumed so.

> Usually, by reading the list, you'll notice that we often forward bug
> reports and patches to the list.  Sometimes we write patches ourselves for
> our users.

Yes, I know that, but I have no idea what other patches you apply on the
Debian side.  From what I've seen of your reports and patches here, I trust
you can do the job.

>> In order for you not to be frustrated, I think the best option is to take it
>> slow: after all, the process already exists, and you're just offering to
>> help out, so you can start by just systematically submitting the patches
>> that you'd like to apply to Debian's tree (so they get installed in RC),
>> then regularly bug people to remind them that we should get the next pretest
>> started, ...

> Ok, I see. You are worried about giving CVS access to people with a
> too low level of trust.

I didn't say anything about CVS access.  I actually assume you'd get CVS
access since I can't see how you could reasonably do the job without
CVS access.  Maybe it could be done, strictly speaking, but I can't see how
anyone could accept to do such a job without getting CVS access.

> Well, no matter. The less I do, the more you have to.  Maybe will you
> manage to prove that it's not worth it because it requires too much
> manpower from emacs-devel.

I think you misread me.  I won't try to slow you down and I hope nobody here
will try to either: I was just recommending to you that you take it slow
for your own sake (so that if we turn out to be unbearable tyrants for you,
you won't feel too bitter).


        Stefan

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

Quoting Stefan <monnier@iro.umontreal.ca>:

> > Usually, by reading the list, you'll notice that we often forward bug
> > reports and patches to the list.  Sometimes we write patches ourselves for
> > our users.
>
> Yes, I know that, but I have no idea what other patches you apply on the
> Debian side.  From what I've seen of your reports and patches here, I trust
> you can do the job.

"We", Rob and I.

> >> In order for you not to be frustrated, I think the best option is to take
> it
> >> slow: after all, the process already exists, and you're just offering to
> >> help out, so you can start by just systematically submitting the patches
> >> that you'd like to apply to Debian's tree (so they get installed in RC),
> >> then regularly bug people to remind them that we should get the next
> pretest
> >> started, ...
>
> > Ok, I see. You are worried about giving CVS access to people with a
> > too low level of trust.
>
> I didn't say anything about CVS access.  I actually assume you'd get CVS
> access since I can't see how you could reasonably do the job without
> CVS access.  Maybe it could be done, strictly speaking, but I can't see how
> anyone could accept to do such a job without getting CVS access.
>
> > Well, no matter. The less I do, the more you have to.  Maybe will you
> > manage to prove that it's not worth it because it requires too much
> > manpower from emacs-devel.
>
> I think you misread me.  I won't try to slow you down and I hope nobody here
> will try to either: I was just recommending to you that you take it slow
> for your own sake (so that if we turn out to be unbearable tyrants for you,
> you won't feel too bitter).

Sorry, I probably misread you. It's good to start the discussion early
in order to come to agreements on every single detail, before doing
anything.

Cheers,

--
Jérôme Marant

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Stefan]

> Sorry, I probably misread you. It's good to start the discussion early
> in order to come to agreements on every single detail, before doing
> anything.

I guess my point was exactly the opposite:
Not only trying to agree on every detail before doing "anything" can
artifically delay the beginning of "anything", but it's simply impossible
because you never know all the possible details beforehand and because
people might originally agree on X but later on discover that it's actually
not acceptable to them in practice, contrary to what they thought.

So in practice, whether you plan it that way or not, you end up fixing
details on the fly.  So I think it's better to accept this fact as a given
and work with it rather than against it.

What that boils down to, is that someone's commitment will depend on how
much implicit or explicit positive feedback he experiences *in practice*
(not just in preliminary discussions).  So go step by step and "ajuste le
tir" as you move (hpefully) forward.

Theory is just no match to practice,


        Stefan

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Kim F. Storm]

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

>>  CVS version:  22.0
>>  Pretests:     22.0.1, 22.0.2, ...
>>  Initial release: 22.1
>>  Bug fixes:    22.2, 22.3
>>  Minor release = bug fixes
>
> That's what I originally wrote and then I switched back to 22.0.50 and
> 22.0.90 because 22.0 bug reports would otherwise be sent to gnu.emacs.bug
> rather than to emacs-pretest-bug ;-0
>

We can just change the code!

-  (let ((pretest-p (string-match "\\..*\\..*\\." emacs-version))
+  (let ((pretest-p (string-match "\\.0" emacs-version))

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 30 Sep 2004 17:35:59 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, rlb@defaultvalue.org, emacs-devel@gnu.org
> 
> > But if people think this change in the management of bugfix releases
> > is a good thing, aren't they going to do everything for it to succeed?
> > Let's clarify: we do propose to add more manpower for doing the
> > "dirty job" (honestly, noone loves tracking bugs), but it will never
> > work without a little cooperation from Emacs developers.
> > Can I have a guaranty that I'll never be pissed off or ignored on
> > blocking situations? ("go fuck yourself! You wanted to do the job,
> > you'll have to do this without us!")
> 
> I don't expect any such problem.  The worst I expect is that you might
> sometimes be prevented from installing a bugfix because it's not "good
> enough" (which is something that happens all the time anyway).
> Also sometimes things won't go as fast as you'd like.
> 
> In order for you not to be frustrated, I think the best option is to take it
> slow: after all, the process already exists, and you're just offering to
> help out, so you can start by just systematically submitting the patches
> that you'd like to apply to Debian's tree (so they get installed in RC),
> then regularly bug people to remind them that we should get the next pretest
> started, ...

Full agreement.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Eli Zaretskii]

> Date: Thu, 30 Sep 2004 21:09:04 +0200
> From: =?iso-8859-1?b?Suly9G1l?= Marant <jmarant@free.fr>
> Cc: rlb@defaultvalue.org, emacs-devel@gnu.org
> 
> I've never said there wouldn't be any pretest phase.
> I'm saying that pretesting a bugfix release is different from
> pretesting a major release; it is shorter at least.

Shorter in practice, yes.  But since the process of pretesting is not
a formal one, we don't have any ways to modify that process for bugfix
releases.  We simply let pretesters use the release candidate and
report any problems.

> I'll also in favour of test cases we can replay every time we
> add new patches. Since emacs is able to run in batch, there is
> no reason no to do so.

Alas, there's no test suite for Emacs.  We discussed this in the past,
so you can find in the archives why it is difficult to come up with
such a test suite (display testing is one problem).

Of course it would be good to have such a suite, but we don't.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

Selon Stefan <monnier@iro.umontreal.ca>:

> I guess my point was exactly the opposite:
> Not only trying to agree on every detail before doing "anything" can
> artifically delay the beginning of "anything", but it's simply impossible
> because you never know all the possible details beforehand and because
> people might originally agree on X but later on discover that it's actually
> not acceptable to them in practice, contrary to what they thought.
>
> So in practice, whether you plan it that way or not, you end up fixing
> details on the fly.  So I think it's better to accept this fact as a given
> and work with it rather than against it.
>
> What that boils down to, is that someone's commitment will depend on how
> much implicit or explicit positive feedback he experiences *in practice*
> (not just in preliminary discussions).  So go step by step and "ajuste le
> tir" as you move (hpefully) forward.

I'm fine with this. After all, there's nothing to loose and we'll see if
it works in the real. Furthermore, untill 21.4 is release, there's a plenty
of time to think of it.

Cheers,

--
Jérôme Marant

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacsreleases.]

[Lennart Borgman]

----- Original Message ----- 
From: "Eli Zaretskii" <eliz@gnu.org>

: > I'll also in favour of test cases we can replay every time we
: > add new patches. Since emacs is able to run in batch, there is
: > no reason no to do so.
:
: Alas, there's no test suite for Emacs.  We discussed this in the past,
: so you can find in the archives why it is difficult to come up with
: such a test suite (display testing is one problem).

Just for the record: There seem to something coming on the GUI side for
testing. The page
http://www.testdriven.com/modules/mylinks/viewcat.php?cid=13 contains two
tools that could be used: Autolt (GPL) and X11::GUITest (GPL). As far as I
can see Autolt is only for Windows platforms and X11::GUITest is in an early
beta stage.

I guess testing on MS Windows has some drawbacks. However it could also be a
good idea since many things are made available on the screen. (This has been
part of MS investment in accessability.) I don't have any idea how the state
of these things are on X, but I guess there is something similar since
X11::GUITest is beeing written. Anyway tests could be written in layers to
hide the dependency of the exact tool used. (But this would perhaps make it
slow, beeing quite contrary to the idea of unit tests.)

- Lennart

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Kai Grossjohann]

Rob Browning <rlb@defaultvalue.org> writes:

> "Eli Zaretskii" <eliz@gnu.org> writes:
>
>> The way it worked until now was that if a decision was made to release
>> the version X.N from a branch, the version number on the trunk was
>> bumped up to X.N+1.50.  This involves running "M-x set-version RET"
>> from admin.el.
>
> So the presumption was that there won't be more than about 50 bugfixes
> before the next "primary release".

No: 21.3.1 means the first compilation of 21.3, 21.3.2 means the
second compilation of 21.3, and so on.  That is, the last number
allows you to see how often the person has invoked "make" from the
same source tree.

21.3.50.1 is the first "make" from the current CVS head.

So if somebody compiles the same source tree 50 times, then we might
get a confusion, because the difference between 21.3.50 (50th build of
current stable release) and 21.3.50.1 (first build of CVS head) is
just too small, and people will routinely use 21.3.50 to refer to CVS
head.

A bugfix of 21.3 will result in 21.4, and the CVS head will be
renumbered to 21.4.50.

I do not know of any other project using a similar versioning scheme.

Kai

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Richard Stallman]

    The goal is to provide a decent program.  One whose version numbers
    confuse people, so they think a major upgrade is a minor bug fix, is
    no good.

I do not think this description fits.  There is nothing confusing
about changing the major version number when we make a non-bug-fix
release.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Robert J. Chassell]

Jérôme Marant wrote,

   Please re-read the whole thread and come back when you have done so.
   You misunderstood everything, no offence meant.

I just re-read the whole thread and as far as I can see, I described
the situation correctly.

What is not clear to me is whether Marant considers releases such as
21.2 and 21.3 as `stable'.  If not, then I did not describe his
proposal correctly.

My understanding is that currently, *every* release by the Emacs
developers is intended to be `stable'.  Every release is one that
should be able to fit into the Debian stable distribution without
first going through unstable and testing.  21.2 was supposed to have
been a tested and stable release.

This is a totally different release model than that used in Debian.
As Rob Browning said

    Debian's model is different, handling the testing *after* the
    intial release via the progression from unstable -> testing ->
    stable.

Rob also introduced the term `micro release'.

In this language, Emacs major and minor releases are intended to go
into Debian stable immediately; `micro releases' are intended to go
into Debian unstable.

With Rob's term, then Marant's original proposal makes sense as one
favoring `micro releases':

    http://lists.gnu.org/archive/html/emacs-devel/2004-09/msg00935.html

    What we propose is to maintain bugfix releases from stable
    releases. This is exactly the kind of job we are doing with
    the Debian Emacs package: collecting bugfixes, backporting
    fixes from the trunk.

in which the proposal is to make releases that fix bugs in Emacs
releases such as 21.2 and 21.3.

However, if you do not think of 21.2 and 21.3 as stable, it also makes
sense as a proposal to stop Emacs developers from making releases like
21.2 and 21.3.

Put another way, two courses are possible:

  * to make `micro' releases from stable and pretested releases such
    as 21.2 and 21.3;

  * to abolish `major bug fix' releases such as 21.2 and 21.3 and make
    all bug fix releases off of a release such as 21.1.

I realize I have been presuming that Emacs developers would continue
to make bug fix releases as well as new feature releases and that they
would also stick to their model of pretesting all releases so they are
as good and as stable as they can make them.

Jérôme's proposal made sense with this presumption.  

But it also made sense if he proposed abolishing pretested bug fix
releases by the Emacs developers and replacing them with unstable and
less tested releases that then go through post-release testing.

--
    Robert J. Chassell
    bob@rattlesnake.com                         GnuPG Key ID: 004B4AC8
    http://www.rattlesnake.com                  http://www.teak.cc

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Richard Stallman]

    Or simpler:

     CVS version:  22.0
     Pretests:     22.0.1, 22.0.2, ...
     Initial release: 22.1
     Bug fixes:    22.2, 22.3
     Minor release = bug fixes

Although I like the idea of negative numbers for pretests best,
this plan is also simple and clear.  We could use it if the other
has some kind of problem.

    That's what I originally wrote and then I switched back to 22.0.50 and
    22.0.90 because 22.0 bug reports would otherwise be sent to gnu.emacs.bug
    rather than to emacs-pretest-bug ;-0

We can easily change the criteria in emacs-pretest-bug
for whatever version scheme we use.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Richard Stallman]

    Ok, I see. You are worried about giving CVS access to people with a
    too low level of trust.

I would be glad to give you CVS access for this.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Richard Stallman]

    I'm fine with this. After all, there's nothing to loose and we'll see if

I think you meant "nothing to lose".

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

Quoting Richard Stallman <rms@gnu.org>:

>     I'm fine with this. After all, there's nothing to loose and we'll see if
>
> I think you meant "nothing to lose".

Yes, I did.

Cheers,

--
Jérôme Marant

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Rob Browning]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> The Debian people are proposing
>
>  1. to continue to make Debian packages out of Emacs releases, and,
>
>  2. occasionally to fix bugs in their packages, which means making new
>     Debian packages.

Actually, the overall goal here was to figure out some way that the
work that we do on the Debian side can benefit a wider audience.

We might well release 10 Debian revisions in a given year, and each
one may fix some number of bugs in the current "stable" upstream Emacs
distribution.  We fix some of these bugs with backports from Emacs
CVS, some with patches from users, and some by our own hacking.

So we wanted to see if together with emacs-devel, we could come up
with a way to make those releases more publically available, so that
others can benefit from the improvements on a shorter timescale than
that of traditional emacs releases.

One way to do that might be for Emacs CVS to have a "branch" (or
whatever) that only allowed *really* uncontroversial bugfixes, and
hence was supposed to be nearly ready for release all the time.  In
that scenario, Jerome and I could commit our patches there and then
make relatively more frequent releases.  Since the changes are
required to be "minor", if one of these releases breaks something, we
should be able to just back out the change and release a new version
immediately.  Whether these releases would be called X.Y.Z, or
W.X.Y.Z, X.Y.bugfix.N, or something else doesn't really matter (though
see my next post about major number choices).

Another alternative might be for us to just maintain unofficial Debian
sub-releases.  We could provide emacs-debian...tar.gz on
people.debian.org, and make it clear that the release is unofficial,
but contains all of the non-Debian-specific fixes from the Debian
package.

Of course, I'm sure there are other solutions I'm not thinking of at
the moment.

> Currently, the Debian Emacs has a version number that looks like this:
>
>     21.3+1

The reason we have 21.3+1 rather than just 21.3 is that we repackage
the upstream source.  In particular our orig.tar.gz file contains leim
and does not contain any .elc files.  We use +1 to make it clearer
that this isn't exactly an upstream version, while still allowing dpkg
to sort the versions correctly.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Rob Browning]

Francesco Potorti` <pot@gnu.org> writes:

> While I want to make clear once again that this is a separate issue,
> which is completely independent from the previous one, yes, I agree
> that clearly indicating which releases are bugfix-only and which are
> not would be valuable.

Actually now that I think about it, at least for those packaging
Emacs, it's somewhat critical.  Right now Debian pacakges Emacs as
emacsXY where XY is the major number (i.e. emacs19, emacs21, etc.).
This is done under the assumption that only a change in XY signals the
potential for major breakage.

The Debian Emacs Policy is set up based on that assumption so that we
can have multiple major versions of Emacs installed without breakage.
This was very important back during the transition from emacs19 to
emacs20 because there were many users who had code that they couldn't
afford to port immediately.  It can also be important because it may
take a while for all of Debian's Emacs sub-packages (calc, bbdb, gnus,
psgml, ...) to be updated to work with the new major version of Emacs.

(In part, the Debian policy arranges things so that a given add-on
 package can tell which Emacs "flavor" it's being installed for, and
 can make decisions based on that if necessary.)

If Emacs ever had a nominal minor release that was really a major
release (which was significantly incompatible in some way), it could
cause a painful transition.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Kim F. Storm]

Rob Browning <rlb@defaultvalue.org> writes:

> Francesco Potorti` <pot@gnu.org> writes:
>
>> While I want to make clear once again that this is a separate issue,
>> which is completely independent from the previous one, yes, I agree
>> that clearly indicating which releases are bugfix-only and which are
>> not would be valuable.
>
> Actually now that I think about it, at least for those packaging
> Emacs, it's somewhat critical.  Right now Debian pacakges Emacs as
> emacsXY where XY is the major number (i.e. emacs19, emacs21, etc.).
> This is done under the assumption that only a change in XY signals the
> potential for major breakage.
>
> The Debian Emacs Policy is set up based on that assumption so that we
> can have multiple major versions of Emacs installed without breakage.
> This was very important back during the transition from emacs19 to
> emacs20 because there were many users who had code that they couldn't
> afford to port immediately.  It can also be important because it may
> take a while for all of Debian's Emacs sub-packages (calc, bbdb, gnus,
> psgml, ...) to be updated to work with the new major version of Emacs.

IIRC, 20.6 -> 20.7 was a pretty major update.

>
> (In part, the Debian policy arranges things so that a given add-on
>  package can tell which Emacs "flavor" it's being installed for, and
>  can make decisions based on that if necessary.)
>
> If Emacs ever had a nominal minor release that was really a major
> release (which was significantly incompatible in some way), it could
> cause a painful transition.

I know for sure that there are things in CVS emacs that breaks code
which run ok on 21.3.  Specifically this change has caused problems:

** `split-string' now includes null substrings in the returned list if
the optional argument SEPARATORS is non-nil and there are matches for
SEPARATORS at the beginning or end of the string.  If SEPARATORS is
nil, or if the new optional third argument OMIT-NULLS is non-nil, all
empty matches are omitted from the returned list.

This could be another argument for using 22.1 for the next release.


Another example is the version of cua-mode that I distribute from my
own web-site.  It works fine with 21.3, but it does not run on CVS
emacs due to changes in key parsing.

Instead a cua-mode specifically developed for CVS emacs is included
with CVS emacs, and the user _must_ remove the old cua-mode
installation from the load path before using the one included with CVS
emacs.

I suppose there may be other cases like that, as CVS emacs include
quite a number of new packages.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Stefan]

> Actually now that I think about it, at least for those packaging
> Emacs, it's somewhat critical.  Right now Debian pacakges Emacs as
> emacsXY where XY is the major number (i.e. emacs19, emacs21, etc.).
> This is done under the assumption that only a change in XY signals the
> potential for major breakage.

While I mostly agree that we should change emacs-major-version for
non-bug-fix releases, I think that limitations of specific packaging systems
are not a motivating factor.

I actually think that your problems should cause you to reconsider the
design of the packaging system since such problems surely happen with other
packages as well.


        Stefan "who's generally disappointed by the poor support for
                multiple concurrently installed versions of a single package
                in most package systems"

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

Quoting Stefan <monnier@iro.umontreal.ca>:

> > Actually now that I think about it, at least for those packaging
> > Emacs, it's somewhat critical.  Right now Debian pacakges Emacs as
> > emacsXY where XY is the major number (i.e. emacs19, emacs21, etc.).
> > This is done under the assumption that only a change in XY signals the
> > potential for major breakage.
>
> While I mostly agree that we should change emacs-major-version for
> non-bug-fix releases, I think that limitations of specific packaging systems
> are not a motivating factor.
>
> I actually think that your problems should cause you to reconsider the
> design of the packaging system since such problems surely happen with other
> packages as well.

Versioning package names is so far the best solution for avoiding binary
incompatibilities after upgrades.
It is usually being done with shared library package names by appending
the soname to the library name.

If 21.4 brings incompatibilities (that is, emacs modes needs to be modified
in order to work properly), we may decide to change the package name
to emacs21.4.

Cheers,

--
Jérôme Marant

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Rob Browning]

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

> While I mostly agree that we should change emacs-major-version for
> non-bug-fix releases, I think that limitations of specific packaging
> systems are not a motivating factor.

Perhaps not for you, though upstream can be a *great* help when their
versioning behaves sanely.

> I actually think that your problems should cause you to reconsider
> the design of the packaging system since such problems surely happen
> with other packages as well.

I'm not sure what kind of improvements you're suggesting, and for
which kinds of problems, but I don't recall a situation where we
*can't* accomodate multiple installs of something in Debian.  It's
just a matter of how much hassle it is and how far we have to diverge
from the upstream code, and that's usually determined by how much
attention the upstream developers have paid to the issue.  (It's also,
depending on the package, a question of manpower.)

For example, if emacs started making releases with major breakage that
only bumped the third version number, i.e. 21.4.1, then (as Jerome
suggests) we'd just have to start releasing emacs packages which
include all three versions: emacs21.4.1.

All that said, by all means, if you can suggest improvements, please
do.

>         Stefan "who's generally disappointed by the poor support for
>                 multiple concurrently installed versions of a single package
>                 in most package systems"

This blame (though not generally in the case of emacs) may lay as much
at the feet of the upstream developers as the downstream packagers
(speaking as one who works on both sides).  If the upstream hasn't
ever considered the problem, then it can be very difficult, and
require substantial hacking, to alter the upstream to handle multiple
installed versions.  This can be further hindered by the available OS
and tools.  For example, the fact that dlopen doesn't support
versioning the way that ld.so does can make it difficult to allow
multiply installed versions of software that relies on dlopened
libraries, unless the upstream has considered that problem and chosen
suitably unique library *names* for those libraries.

The more classic example is an upstream that doesn't bump its library
soname versions when making backward incompatible changes to the
code.  This can be a big problem.

All of these examples assume that the distribution is going to try to
conform to the FHS.  If you're willing to ignore that, then you may
have other options.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Stefan Monnier]

> I'm not sure what kind of improvements you're suggesting, and for
> which kinds of problems, but I don't recall a situation where we
> *can't* accomodate multiple installs of something in Debian.  It's
> just a matter of how much hassle it is and how far we have to diverge
> from the upstream code, and that's usually determined by how much
> attention the upstream developers have paid to the issue.  (It's also,
> depending on the package, a question of manpower.)

Just as it is possible if you don't use packages, it should be possible for
the end user to decide that she wants to install Emacs versions 20.3, 20.4,
21.1, 21.2, and 21.3.

> This blame (though not generally in the case of emacs) may lay as much
> at the feet of the upstream developers as the downstream packagers
> (speaking as one who works on both sides).

Using package systems like `depot' or `stow', I haven't had any trouble
with any existing package.  No need for special support from the
upstream developer.

> If the upstream hasn't
> ever considered the problem, then it can be very difficult, and
> require substantial hacking, to alter the upstream to handle multiple
> installed versions.  This can be further hindered by the available OS
> and tools.  For example, the fact that dlopen doesn't support
> versioning the way that ld.so does can make it difficult to allow
> multiply installed versions of software that relies on dlopened
> libraries, unless the upstream has considered that problem and chosen
> suitably unique library *names* for those libraries.

You don't need to change the name, just the directory in which to search for
the lib.


        Stefan

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Rob Browning]

storm@cua.dk (Kim F. Storm) writes:

>> emacs20 because there were many users who had code that they couldn't
>> afford to port immediately.  It can also be important because it may
>> take a while for all of Debian's Emacs sub-packages (calc, bbdb, gnus,
>> psgml, ...) to be updated to work with the new major version of Emacs.
>
> IIRC, 20.6 -> 20.7 was a pretty major update.

Well from what I recall, it wasn't nearly the same as say the Emacs 19
to Emacs 20 transition, at least from the Debian perspective.  I don't
recall any serious problems, though that doesn't mean that I haven't
just forgotten them.

> This could be another argument for using 22.1 for the next release.

Hmm.  I thought I saw some other posts that suggested that you were
going to number the next release 22.1.  If not, and if there really is
the potential for significant breakage, then please reconsider.  If
there may be trouble, what would be the argument against naming it
22.1?

> I suppose there may be other cases like that, as CVS emacs include
> quite a number of new packages.

Changes like that may be less problematic for Debian.  For some subset
of problems of that nature, we can solve them using packaging
dependencies, i.e. (i.e. Conflicts: calc << X.Y.Z or whatever's
needed).  We can work that kind of thing out in unstable.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Rob Browning]

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

> Just as it is possible if you don't use packages, it should be
> possible for the end user to decide that she wants to install Emacs
> versions 20.3, 20.4, 21.1, 21.2, and 21.3.

We probably could do that for many packages.  Often it comes down to a
decision based on the available manpower as compared to the value of
providing additional revisions, though if all packages were to do it,
it might also come down a decision based on the load on the
infrastructure.  It looks like we already provide over 15000 source
packages just in testing and unstable, and the number of actual
packages will be much more than that, related to the number of
architectures we support.

> Using package systems like `depot' or `stow', I haven't had any trouble
> with any existing package.  No need for special support from the
> upstream developer.

OK, well for now, I'm not familiar enough with them to meaningfully
debate their merit as compared to apt, dpkg, and Debian's current
policies.

> You don't need to change the name, just the directory in which to
> search for the lib.

The problem is that then -L linking will fail unless ld.so has also
been augmented with these paths, or unless the user has added that
directory to their LD_LIBRARY_PATH.  I'd still like to see dlpen
support for the algorithm that the normal linker uses, so you can tell
dlopen to open libbar version 4, and let it find the latest suitable
revision (i.e. the same one -L linking would find at runtime).

In any case, I suppose this is all somewhat off-topic.  The only plea
I'd like to make is that if possible, Emacs use some versioning
strategy where there's at least one number or numbers that changes iff
substantial backward compatibility is introduced.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> The only plea I'd like to make is that if possible, Emacs use some
> versioning strategy where there's at least one number or numbers
> that changes iff substantial backward compatibility is introduced.

Oh, and I wasn't trying to imply in the above that Emacs hasn't been
doing that.  From at least the packaging perspective, my impression is
that so far, Emacs has.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Juri Linkov]

Rob Browning <rlb@defaultvalue.org> writes:
> storm@cua.dk (Kim F. Storm) writes:
>> This could be another argument for using 22.1 for the next release.
>
> Hmm.  I thought I saw some other posts that suggested that you were
> going to number the next release 22.1.  If not, and if there really is
> the potential for significant breakage, then please reconsider.  If
> there may be trouble, what would be the argument against naming it
> 22.1?

Everyone already refers to Emacs 22 as Unicode version of Emacs.
Releasing 21.4 as 22.1 will cause a lot of confusion: people will
start downloading Emacs 22.1 as "Unicode Emacs" and later discover
it's actually not what they thought.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Rob Browning]

Juri Linkov <juri@jurta.org> writes:

> Everyone already refers to Emacs 22 as Unicode version of Emacs.
> Releasing 21.4 as 22.1 will cause a lot of confusion: people will
> start downloading Emacs 22.1 as "Unicode Emacs" and later discover
> it's actually not what they thought.

Presuming the developers wanted to make the change, I wonder if just
posting an explanation on emacs-devel and a few other suitable places
would clear things up.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Stefan Monnier]

> Everyone already refers to Emacs 22 as Unicode version of Emacs.

That's a gross overstatement.


        Stefan

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Richard Stallman]

    One way to do that might be for Emacs CVS to have a "branch" (or
    whatever) that only allowed *really* uncontroversial bugfixes, and
    hence was supposed to be nearly ready for release all the time.  In
    that scenario, Jerome and I could commit our patches there and then
    make relatively more frequent releases.  Since the changes are
    required to be "minor", if one of these releases breaks something, we
    should be able to just back out the change and release a new version
    immediately.

This is more or less the way we handled 21.2 and 21.3.
I think it is an uncontroversial proposal.
I gladly accept your offer to do this.

      Whether these releases would be called X.Y.Z, or
    W.X.Y.Z, X.Y.bugfix.N, or something else doesn't really matter (though
    see my next post about major number choices).

I think the question of version numbering is the ony one we are in
doubt about.  We would like you to do this maintenance.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Kim F. Storm]

Rob Browning <rlb@defaultvalue.org> writes:

> Rob Browning <rlb@defaultvalue.org> writes:
>
>> The only plea I'd like to make is that if possible, Emacs use some
>> versioning strategy where there's at least one number or numbers
>> that changes iff substantial backward compatibility is introduced.
>
> Oh, and I wasn't trying to imply in the above that Emacs hasn't been
> doing that.  From at least the packaging perspective, my impression is
> that so far, Emacs has.

>From a packaging point of view, 21.4 (or 22.1) includes the following:

** Leim is now part of the Emacs distribution.
You no longer need to download a separate tarball in order to build
Emacs with Leim.

** The Emacs Lisp Reference Manual is now part of the distribution.

** The Introduction to Programming in Emacs Lisp manual is now part of
the distribution.

** The `emacsserver' program has been removed, replaced with elisp code.

New Lisp packages included with emacs:

dns-mode, flymake, tree-widget, wdired thumbs, python, url, ido, cua,
kmacro, printing, calc, tramp, ruler-mode, ibuffer, table, ses,
syntax, gdb-ui, bindat, buttons, master-mode.

Updated packages: gnus, mh-e.

rmail will use mbox format rather than babyl  (not on trunk yet).

Besides, emacs 21.4 can be biult with GTK+ support -- I don't know if
you would want to distribute two versions in Debian (with and without
GTK).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Kim F. Storm]

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

>> Everyone already refers to Emacs 22 as Unicode version of Emacs.
>
> That's a gross overstatement.

That's a gross understatement :-)

I think more people have been confused by 21.3, 21.3.50, and 21.4 than
you can find people who have ever heard about "unicode emacs".  
(but I don't want to take a poll :-)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Eli Zaretskii]

> From: Rob Browning <rlb@defaultvalue.org>
> Date: Mon, 04 Oct 2004 17:40:36 -0500
> Cc: emacs-devel@gnu.org
> 
> So we wanted to see if together with emacs-devel, we could come up
> with a way to make those releases more publically available, so that
> others can benefit from the improvements on a shorter timescale than
> that of traditional emacs releases.
> 
> One way to do that might be for Emacs CVS to have a "branch" (or
> whatever) that only allowed *really* uncontroversial bugfixes, and
> hence was supposed to be nearly ready for release all the time.

That's how Emacs is being maintained since v21.1: there's a bug-fix
branch where only safe changes are being made.  The last version
released from that branch is 21.3.

How frequent can releases be made from that branch is another
question, and the answer depends mostly on how the pretest phase is
handled.

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Nick Roberts]

This thread has discussed help with stable Emacs releases. Much of the
frustration on this list seems to occur earlier in the development
process. Other projects, notably XEmacs, make beta releases for inclusion with
unstable GNU/Linux distributions such as Debian's sid and the Mandrake
Cooker. It occurs to me that if Emacs did this too i.e made beta releases from
the trunk, there would be more pairs of eyes and it would therefore make for a
faster stable release. It doesn't seem realistic or even reasonable to expect
a handful of developers to do all the work. I don't know, maybe the pretests
do get included in such distributions but it seems to me that more leverage
could be obtained by always having a beta version (not in CVS) available.

Nick

Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Jérôme Marant]

Quoting Nick Roberts <nickrob@snap.net.nz>:

>
> This thread has discussed help with stable Emacs releases. Much of the
> frustration on this list seems to occur earlier in the development
> process. Other projects, notably XEmacs, make beta releases for inclusion
> with
> unstable GNU/Linux distributions such as Debian's sid and the Mandrake
> Cooker. It occurs to me that if Emacs did this too i.e made beta releases
> from
> the trunk, there would be more pairs of eyes and it would therefore make for
> a
> faster stable release. It doesn't seem realistic or even reasonable to expect
> a handful of developers to do all the work. I don't know, maybe the pretests
> do get included in such distributions but it seems to me that more leverage
> could be obtained by always having a beta version (not in CVS) available.

As far as I know, XEmacs people do both stable (say bugfix) releases
and beta releases.


--
Jérôme Marant