Vin Shelton writes:
I tried to re-start this conversation a little while ago; is this
thing on?
Yes.
XEmacs 21.4 EOL, take 2:
Given the lack of response, you would be entirely within your rights
to declare that you're retiring after 21.4.23, and make a last call by
yyyy-mm-dd declaration. (You could declare immediate retirement, too,
but I'd whine quite a bit about that since there are a few patches
remaining in the pipeline. ;-)
First off, src/ChangeLog says this:
2012-07-12 Vin Shelton <acs(a)xemacs.org>
* glyphs-eimage.c: Fix this so it compiles with libpng-1.5.10.
It does now, after a fresh clone. "hg pull -u" in an older clone
didn't pull that in. :-(
Secondly, I have no objections to patches to fix this and the clang
3.4 issue you identified elsewhere,
I'd like to fix this bug, too. I've made progress on localizing it
but don't have a fix yet.
but shouldn't we call "Olly, olly,
oxen-free" and declare 21.4.23 to be the end of the line? Sooner or
later, we have to let Grandma RIP.
Sure. We can promote 21.5 to 21.6 and release it. Let me roll one
last beta next weekend and we shoot for a (US) Thanksgiving release,
unless one of the core people wants to promise significant
contributions for a New Year's release. When would you want to
release 21.4.23?
I don't much like that because essentially no work has been done on
usability (fontconfig configuration being the biggest pain point, but
many users would like to see a GTK3 port (GTK3 programming makes me
barf, if that's the way we're going to go I'll help but really would
rather not lead), there remain display glitches with Xft, there are a
lot of rough edges in Mule which probably affect only me these days,
and so on). But the alternative is no better, given that the work
described isn't likely to be forthcoming in large quantity any time
soon.
I would say that 21.7 development should be officially focused on
supporting upgrades to the packages. After that the work would be on
porting Emacs features. If people want to work privately on their own
features, fine, but at this point I think we need Emacs compatibility
improvements more than anything else.
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta