Re: Ceasing the emacs-snapshot effort?
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.
> Yesterday, I took the opportunity to participate to a thread in
> which I expressed the idea of releasing the core Emacs and others
> lisp modes separately in order to provide users with bugfixes more
> often. Hence, waiting for the next stable release would be painless
> for both users, and us, maintainers.
>
> Unfortunately, it quickly ended with this message from RMS:
>
> http://www.opensubscriber.com/message/emacs-devel@gnu.org/1445574.html
You have to be aware that there are rather few Emacs developers, and
an inordinate time is spent getting Emacs into releasable state. You
are proposing to distract developers by having to cater for code (and
we are talking hundreds of packages here), cater for backports, not
make use of Emacs features _for_ _years_ that are introduced for the
sake of making code easier to write, and so on.
Basically, this would lead to the consequence that Emacs won't get
released at any time. All efforts would be spent on backporting,
regression testing against versions and so on.
It also reduces the ability of people to join Emacs development (the
very same reason that there are so few people working on Debian
Emacs): instead of just fixing a bug, people now have to be aware of
an intertwining network of backward compatibilities and versions.
Emacs-21 has integrated a lot more packages than before, and Emacs-22
will continue that trend. And the reason is that there is still large
progress going on in the core, and that migrating to a newer, more
friendly code base would complete be impossible if one had to watch
out for backward compatibility constantly.
There are no resources for that. It is already painful how long we
are taking to get Emacs-22 into shape, and you are testament to it.
What you are demanding is that a major amount of packages is
backported.
If that would have seemed feasible, then Emacs-22 development would
not happen on the CVS trunk, but rather in a separate branch. We are
going forward and don't have the resources to maintain an outpost in
the past.
> Some will say I deserved it. Maybe.
I think that RMS' reaction was somewhat overblown. However, this sort
of detraction and bickering and demands to keep Emacs development
nailed to Emacs-21 have long been discussed and choices have been
made. Questioning them every month anew as if nothing was already
said about them, is not productive. Also keep in mind that RMS has a
busy schedule with partly patchy Email access. And that means
sometimes discussions and proposals which he'd otherwise shoot down in
a minute develop a life of their own, waste a lot of time and effort
over days, only to be closed down afterwards. And if he is of the
opinion that he already shot down an unfruitful discussion, and still
people waste more days about it, it does not help his mood.
> I'm just surprised about such a reaction from someone who mentions
> Free Speech as an analogy to Free Software. I would never have
> imagined that expressing ones opinion would lead to being considered
> as a threat to the development of Emacs.
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.
> After all, I already managed to send modest patches to improve the
> build process. Would an Agent of Destruction even do that?
He did not claim you were acting out of malice. Most projects die
from the inside.
> Now, the question is how I should interprete "Please stop
> interfering with Emacs development"? Are my (even modest)
> contributions nor interventions not wanted any more? In that case,
> there is no point for me to keep on working on emacs-snapshot. I
> don't know him very well, so I'm just wondering.
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.
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.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Reply to: