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

[storm@cua.dk (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!