Re: What is the status of 21.5?
What's wrong with this picture? There's more stuff listed here
than the TODO list I inherited from Chuck after 19.14 that took
about 4 years to complete.
On 8/15/07, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
SL Baur writes:
> So, what's left to sign off on a 21.5?
Oh, just about everything.
1. The long-standing bug in the progress gauge is still there; the
only way to be sure not to crash is to disable the widget.
I've seen that it's annoying. Why not drop the patch until
it's fixed or turn off the feature.
2. Unicode support sucks.
That was a v22 item. Did you move it 21.5?
3. Xft support sucks.
No comment until I get a working X11 setup and/or Linux box
for testing.
4. Carbon support isn't in the mainline yet.
I'll pitch in there, but I wouldn't hold back 21.5 for it.
5. Gtk is effectively unsupported (we still require v1).
That's a problem I guess.
6. The new GC sucks, at least RAM and CPU.
That's a problem. I'll read the archives to see what
happened. Our tradition has been always a bit faster.
That way as hardware keeps up with the Microsoft
curve we're way faster.
7. There are infloops or something like them in the regexp engine.
O.K. That's a problem.
8. Fontlock is still way too slow, partly due to 7, partly due to 9.
Fontlock has always been slow. Is fastlock slow now?
9. The stack of extents code is not robust to "large"
extents, at
least with Mule support. (Eg, putting an extent on (point-min),
(point-max) will slow things very badly.)
That's a problem.
10. comint needs GNU sync, but this is known to be hard, as we just
had to back out the last attempt.
Yeah, I've noticed that they are diverging. I don't think that's a
good thing and unfortunately it is costing me a lot of time at
work.
11. We still don't have an all in one tarball.
Yeah, I read about this one. I have no objections so long as
Linux distro makers can still get separate core & Sumo tarballs
to make packages from. It's probably the right thing to do
on Microsoft Windows, but it shouldn't hold up an initial release.
The world is a lot different place than it was when I split things
up. Bandwidth isn't what it used to be and XEmacs is now a
pretty light weight application compared to what's now out there.
Just remember though that some people don't always want to
upgrade their packages. God got angry at us for that. (Is Dr.
McCarthy still an XEmacs user?)
12. AUCTeX and preview-latex support is a real issue for many
people;
it seems we can't do that without supporting more of the GNU image API.
Is this more Stallman crock, or did someone actually design it
for a change?
13. Mule coding systems suck, and autodetection needs a lot of
tuning.
O.K. How much do they suck, how many people are really
affected? Personally I would be more worried about proper UTF-8
support.
14. Modules don't really work right yet. I think we should go to
a
model like Python's where .so's and .py's mix interchangably, but that
doesn't go with binary packages very well. Elisp eggs would be nice,
too (Google for "python eggs").
This should not hold back 21.5. I was and am of the opinion that this
was a cool hack, but shouldn't ever be relied upon as a core feature.
Now, which of these are reversions and which are not?
> Inspire me. XEmacs is good! It must not die.
Do your PostgreSQL support. I don't know about "one true way"; MySQL
at least is still way popular in the webapp end of the world. But
more SQL support would be a good thing.
I'll need some kind of SQL back end, at least as a demo, for my forms
package. And it shouldn't take me that long to upgrade the build
to deal with more recent versions of PostgreSQL.
I have a few desiderata, I've got libneon and libcurl added as
modules
in a private workspace, and I'd like to see libsvg and expat or libxml
supported as modules. We also need to do something with git, which is
just LISP in C clothing. It is just dying to be given LISP bindings.
I've got git installed and working. Anything written/designed by Linus is
interesting. (The lack of) git bindings shouldn't hold up a release,
neither should the other things you've listed.
Release early, release often. Be ruthless. Drop everything that isn't
working properly, defer stuff that needs a lot more work. It doesn't
have to be perfect, it just has to be a bit better than the previous
version. The Japanese know this and so does Microsoft. Kaizen
works.
-sb
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta