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
up-to-date.
...
> 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.
Regards,
--
Jérôme Marant
Reply to: