David Kastrup <[EMAIL PROTECTED]> 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
