[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Ceasing the emacs-snapshot effort?

David Kastrup <dak@gnu.org> writes:

>> 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,
> It is just not a good time at the moment.

I think so too.

>>> 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

Well, you right. He once said "I don't want a package system for
Emacs". It's not really hate.

> 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

I recalled he's been seduced by the install.el from Stefan, so things
may change some day.

> 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.

The Debian Emacs system has issues. Hopefully, packages are almost

> 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.

I think there are some way core packages, for instances Lisp libs
that are useless alone (say, like tooltips.el).

>> 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.

Alright. Let's wait and see.

>> 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.

We both agree on this.


Jérôme Marant

Reply to: