>>>> "Ben" == Ben Wing <ben(a)xemacs.org>
Ben> if we maintain the stuff anyway, and its critical to the
Ben> core, there's zero point in it being in the packages.
That's assuming there's only one version of XEmacs we support.
Unfortunately, even under that assumption, the supported version is
21.4, which will not get the changes you propose.
> I know having stuff in packages is annoying to you, Ben, but I
> believe that the prospect of working with that big ball of mud
> we call "core" is a prohibitive deterrent to a lot of people
> who might otherwise contribute an occasional fix.
Ben> what's your evidence?
As a general principle, it's surely true. Modern programming practice
is one of the things that we have always argued makes XEmacs
development faster and more fun than GNU Emacs development.
No, I don't have any hard direct evidence, just the obvious dwindling
of contributors and the lack of fixes to many of these (in principle
relatively self-contained) problems like lack of HTTP transport. And
the comparison to projects like Python and Ruby which are gathering,
not losing, steam, and emphasize modern programming practices even
more than we do.
Ben> has it stopped contributors to gnu emacs, where there is even
Ben> more in the core?
It doesn't stop them, obviously, but packages are one of the most, if
not the most, often-vetoed RFEs on emacs-devel. Furthermore, GNU
Emacs has a simple way of resolving specification problems: ask rms.
He'll give you a spec, and there are plenty of people more than
willing to contribute by implementing them. We don't do things that
way, which IMHO implies a more modular architecture is to be
Ben> why? it has to get implemented, either way. core or package
Ben> won't make much difference
It does to the _supported_ version of XEmacs, which is 21.4, and will
be for at least the coming year. It's not going into core there until
it's well-tested. Of course that's Vin's decision, but until he says
otherwise I'm more than willing to risk looking like an idiot by predicting
that's what he'll say.
OTOH, we can have the transport _tomorrow_ (cf J Schrod's post, also
an old patch by Steve Y) in packages.
Ben> except that putting it in a package means someone has to go
Ben> to extra work to implement the "put the packages in the core
Ben> distribution" bit. will that be you?
Yes. I've prototyped it a couple of times, but never submitted
anything because it requires changing defaults, and I had no stomach
for that. OK, I'll take a couple of Alka-Seltzer, and we'll see
whether you all like it or not.
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.