Re: Ceasing the emacs-snapshot effort?
Jérôme Marant <jmarant@free.fr> writes:
> Selon David Kastrup <dak@gnu.org>:
>
>> Jérôme Marant <jmarant@free.fr> writes:
>>
>> > While contributing to maintainership of the emacs21 package, it
>> > became more and more obvious to me that maintaining lisp modes
>> > within Emacs is not an easy task: upstream fixes bugs in the CVS
>> > trunk and since years separate stable Emacs releases, modes are
>> > diverting which makes this task difficult.
>>
>> Well, the solution, of course, is to release more often. It is not
>> like the problem of stable releases and backports and so on is
>> exactly unknown to Debian.
>
> Releasing more often is the ideal solution. Providing more bugfix
> releases would fullfil my/users needs as well. See further.
Well, the problem is then how much impact supporting your users should
have upstream. Upstream Emacs is at the moment in a tense phase,
progressing too slowly, developers being distracted, bad blood
exchanged over changes that see inappropriate at the current point of
time, changes that would seem beneficial rejected because of possible
bad consequences, other destabilizing changes being checked in partly
without coordination...
At the current point of time I suppose that RMS is tearing his hair
over Emacs development and developers at least twice a week or so.
It is just not a good time at the moment.
>> All the backport and back compatibility worries of a separate
>> package management have not had the most convincing results with
>> XEmacs, which often features barely working, decrepit packages.
>> And not being able to use new XEmacs core features in those
>> packages without risking breaking earlier XEmacs installations is
>> not good, either. It means that bug workarounds need to stay (and
>> be maintained) for longer than desirable.
>
> I knew that RMS hates package systems such as the one from XEmacs so
> I certainly did not want to propose this.
Sometimes you assign too strong emotions to RMS. He has decided at
one time that a package system for Emacs and the corresponding
infrastructure would not pay off. So he said "No". What he can get
pretty testy about is if people don't accept his decisions (which tend
not to be done on a whim and without prior consideration) and come
back time and again. Certainly he said "No" to adopting the XEmacs
package system, and I can only applaud that move. The centralistic
approach of the XEmacs package system does not facilitate maintenance
and/or provision of packages by the upstream authors. This is a
mistake leading to outdated packages, not rarely broken. It is the
same problem that the overengineered Debian Emacs system suffers from.
The moment that one has to cater for lots of different versions and
maintain metafiles and special compilation procedures and so on, stuff
gets complicated.
> What I thought was a good idea was to have non-core packages in a
> separate CVS module, shipped altogether in a single tarball, updated
> more frequently and to be unpacked at regular locations. No package
> system involved.
Uh, there are no non-core packages. Non-core would have to organized
and maintained and bickered over. This is absolutely not the right
time for that.
>> Actually, RMS is rather discouraging investing too much work into
>> emacs-regular, like backporting, trying to get changes into Emacs
>> CVS for the sake of Emacs-21.4 and so on. So if you want to take
>> his advice personally, it would more likely cause you to quit work
>> on the "regular" emacs package rather than emacs-snapshot.
>
> I have one additional requirement which is satisfying Debian users
> as much as possible. I can't tell them that they have to wait more
> years before seeing their bugs fixed (I don't blame emacs-devel).
> So, I have to do a backport work when possible.
Yes, this is nontrivial work. And the decision has been made at Emacs
central quite a number of months ago, after heated discussions, that
the Emacs core developers would not work on any "stabilized" branch
any more, in order to be able to get Emacs 22 out sooner. There will
be destabilizing changes immediately afterwards: Emacs-unicode is
going to be merged (making utf-8 the Emacs-internal encoding), the
multi-tty branch is going to be merged (probably making emacsclient a
viable full gnuclient replacement for the first time). It does not
yet look like Emacs-bidi might also have a chance to be merged. That
will be the time when one could think about structural changes, if at
all: there will have to be a branching, and the details of that do not
seem clearly after that.
>> The basic message is: upstream Emacs development does not have the
>> resources to support backports to Emacs-21 in any manner, and
>> should not be bothered about it if possible. Questions are ok, I
>> guess, but expensive discussions about going backwards are not
>> really appreciated, and you must not expect backport considerations
>> to make it into the CVS code: we have enough problems going
>> forward, and that is where the priority lies.
>
> Do you remember I proposed to take care of bugfix releases with
> interested people? Many patches against 21.3 are sent to
> bug-gnu-emacs and are ready to be applied as is. I think we can add
> more resources for this. RMS was no against even, IIRC.
Quite so, and it would be beneficial in the long run. But I don't
think that we shall see a system like that in place before Emacs 22.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Reply to: