|
Searching XEmacs
Quick Links
About XEmacs
Getting XEmacs
Customizing XEmacs
Troubleshooting XEmacs
Developing XEmacs
|
|
|
XEmacs Release Plan for Late Q1 2001
Revised: 29 March 2001
This is the current revision of the Release Plan for
XEmacs 21.4. It describes
how the release will be managed and implemented. This version
emphasizes current status.
For historical interest, the original draft as submitted to the
XEmacs Review Board on 19 December 2000 is
here. Other history is
in the ChangeLog and CVS.
Currently known bugs and their statuses are in
Bug Status.
Plans are being made for a release of version 22.0,
including many improvements as well as integration of those
features which were not ready for 21.4, to be made in 3d quarter.
Disclaimer
This document is maintained by the Release Manager, Stephen
J. Turnbull <stephen@xemacs.org>. It should
reflect the
current policy of the XEmacs Review Board closely. I have tried
to incorporate as much as possible of the comments and discussion
to date, but errors and omissions surely remain. The
responsibility for errors is mine alone.
Rationale
It's time for a release. What more can we say?
The theme of this release will be consolidation and
integration of current projects.
Target date: 1 March 2001
The schedule has slipped three times, first to March 15, then to
March 26, and now the release is scheduled for April
15. I said ``it cannot slip anymore,'' but it did.
Newbie release manager, what can I say? The code is ready, and
now the management is too.
This is a very ambitious target. As mentioned above, a couple of
the major features are not going to be ready. Although this is
disappointing, there are many small improvements, along with a
couple of major features (such as native widgets and the net
installer for Windows, both due to Andy Piper). We hope you will
find XEmacs 21.4 a substantial improvement over XEmacs 21.1.
And of course many new packages have been added over the months
since 21.1 was released. Some of these use the new features in
21.4.
I have volunteered to act as Public Release Manager as an
explicitly term-limited position, and have been accepted by the
Review Board. The term of the Public Release Manager is up when
Vin (or his successor) accepts handover of the release as
"stable." The Public Release Manager will be responsible for
tracking progress, publicity, and announcing and enforcing feature
freeze. Further details are in the
job description.
The Public Release Manager may of course delegate any of these
responsibilities; he just has to make sure they get done. In
particular, Martin will continue to actually roll the tester
tarballs. Thank you, Martin!
Testers
Yes, please! Right over here.
This is a short list of projects proposed for the 21.4 release.
Each has an abstract more or less suitable for NEWS
(draft version now available), and a brief status
indication. For details, including checkout, configure, and test
procedures, follow the links provided. They are more or less
ordered by size (big, risky ones first).
-
XEmacs on the GTK platform:
Bill Perry
-
XEmacs has been ported to the GTK platform. The basic text
editor still uses native X11 features to implement buffer
redisplay and so on. However, it is now possible to use the
GTK and GNOME widgets (such as dialogs and toolbars) to
implement GUI components in XEmacs. It is an optional
feature, and not included in the default configuration.
The GTK support is being added on a branch from the 21.2 code
base. It may be checked out and tested. After a short
period, it is planned for merger (now complete!) to the main
code branch, but its status is experimental and
unsupported. (If you were hoping for a miracle, it
didn't happen. GTK/XEmacs is still experimental and
unsupported. But sometimes it really works and looks good!)
Testing will be aimed at making sure it does not have negative
impacts on other platforms; neither failure to build nor
catastrophic data loss will be considered a ``showstopper'' if
GTK is configured in to XEmacs.
-
Mule on Windows:
Ben Wing
-
Windows has a well-elaborated interface for
internationalization. Mule is being ported to that
environment.
This code is currently incomplete, and neither builds nor
runs. It will not be included in the March 1 release. It is
in the process of being added as a branch in CVS, and
procedures for checking it out and testing it will be
announced when that is done.
-
Portable dumper:
Olivier Galibert
-
The portable dumper is a subsystem that replaces the
traditional ``unexec'' method of creating an Emacs pre-loaded
with Lisp code and data. The traditional method actually
``dumps'' the core image of the executable to a file, then
adjusts the file so that it can be executed by the operating
system, restoring the execution state. The portable dumper
executes Emacs as usual, then reloads the Lisp code and data
very quickly from a specially formatted dump file. This is
not as fast as the unexec method, but it requires much less
knowledge of the operating system, and is thus more portable
and maintainable.
This code has been merged to the release code base and in
active test for some months.
-
Gutters and native widgets:
Andy Piper
-
Gutters are GUI components of an XEmacs frame. They can hold
arbitrary text. This text does not change with buffer motion.
There is one gutter on each edge of the frame. In theory
scrollbars, menubars, and toolbars could be placed in the
gutter instead of being given special status.
Native widgets are conceptually unrelated, but were convenient
to implement at the same as the gutters. Instead of
implementing GUI widgets via image glyphs and Lisp code,
native widgets are implemented using the underlying GUI.
This code has been merged to the release code base and in
active test for some months.
-
Custom themes:
Jan Vroonhof
-
The Customize interface provides a flexible way to document
configuration variables, and reset them with varying degrees
of permanency. Custom themes intend to extend this
flexibility to groups of related settings that tend to be
correlated (either for a priori reasons or as a matter of
typical tastes of users).
Theme support requires certain hooks in the core Lisp, and may
be considered a major new feature. However, most of the code
will be implemented as an add-on package at first. It is very
likely that it will be integrated into the core in the
following release.
Currently incomplete, but because of the package development
strategy there is a good chance it can be released at about
the same time as the 21.4 core. (Note: Jan has not
reported or been active recently, and the status of Custom
themes must be considered dubious.)
-
CCL improvements:
Hisashi Miyashita
-
Improvements to the Code Conversion Language (CCL) and its
interpreter.
This code is unconditionally built in. It has been merged to
the release code base and in active test for some weeks.
-
Mule case tables:
Yoshiki Hayashi
-
Improvements to the case tables, especially making them work
on Mule.
This code is unconditionally built in. It has been merged to
the release code base and in active test for some weeks.
-
Syntax table improvements:
Matt Tucker
-
Syntax table improvements.
This code is unconditionally built in. It has been merged to
the release code base and in active test for some weeks.
-
PostgreSQL Lisp interface:
Steve Baur
-
Emacs Lisp interface to PostgreSQL. This is PostgreSQL-specific.
PostgreSQL development suopprt is autodetected, and if found
this code is built in by default. It has been merged to the
release code base and in active test for some months.
-
SUMO integration:
Stephen Turnbull (Volunteers eagerly sought!)
-
We should reverse Steve Baur's decision to not distribute the
SUMO Lisp in the main tarball. The packages are popular, but
the typical user of the core tarball wants the kitchen sink.
-
MS-Windows printing support:
Kirill 'Big K' Katsnelson
-
Printing support as Windows users expect it.
Kirill has said this is mostly done, but hasn't reported on
XEmacs Beta recently.
-
Mr. Preprocessor's miscellaneous projects:
Michael Sperber
-
-
complete the init-file migration/back-migration code
-
complete the movemail/locking integration
-
fix some build issues, for example the recent path-searching
bug report, and the pdump thingie.
Asynchronous projects
An asynchronous project is one which will be publicized
along with the release of the core code, but is under the control
of the taskmaster, not the Release Manager. These projects may
involve installable Lisp packages or separate binaries. They are
supported by XEmacs.org, but a problem in an asynchronous project
will not be a considered a ``showstopper'' for the rest of the
release.
-
Documentation: everybody.
-
Documentation. I hope there will be lots of documentation
added! Documentation is always badly needed. Some of our
documentation is buggy, other parts have become incorrect
through changes in the functionality they describe. Many
features are simply not described at all.
It's not hard to write documentation correctly. Please give
it a try!
Even if you're uncomfortable writing docs, inaccurate
or missing documentation is a severe hindrance to users, and
we consider that a bug. Please report any problems you have
with the documentation.
-
Cygwin netinstaller for XEmacs on Windows:
Andy Piper
-
The Cygwin netinstaller has been ported to XEmacs. This will be
mentioned in the release NEWS. Otherwise it will be treated as
"not part of the core" for the purposes of feature freeze in the
same way that packages aren't part of the core. Available in
betas now (since 21.2.40).
Projects not to be included in the 21.4 release
A number of projects are or have recently been active in
XEmacs.org, but are not planned for inclusion in this release.
See the list of planned
features. There are three possible reasons:
- Coding is not complete.
- The author is not available to work on the feature during
the prerelease period.
- The Release Manager has incorrect information about the state
of the code or availability of developers to work on the code.
For a short period, status of these projects (to be included or
omitted) may change at the discretion of the Board of Reviewers.
Suggestions or status inquiries may be sent to the Release Manager
or to the
Developers' Mailing List.
Other projects seem to be completely inactive.
A lot of people have presented ideas for improving XEmacs. Two
lists that I think are interesting are
-
Ben Wing's
Architecting XEmacs
which describes general directions for improvement, with some
design suggestions, and
-
Jamie Zawinski's
xemacs wishlist
which describes practical features that can be implemented
independently of improvements in the core in most cases.
Your suggestions, both direct and for links to pages about
desirable features for XEmacs, are
welcome.
Timetable
Note: I believe this now reflects current status. It
is important that we decide the default configuration for test
releases soon. Martin or I will present RFCs to the Review Board
shortly.
- December 19:
-
Submit draft proposal to the board; request detailed status
reports from PWPs; feature slush/RFP to board. RFP means no
completely new features, only features with some history of
discussion, design complete, and preferably prototype code,
are acceptable. Status on 1 February: complete.
- January 2:
-
Post revised draft on www.xemacs.org; RFC to xemacs-beta; nag
PWPs. Status on 1 February: complete (lack of response
from some PWPs means their projects are currently
orphaned).
- January 9:
-
Close board-level RFPs == full feature freeze; re-revise and
post release proposal on comp.emacs, comp.emacs.xemacs; post
known bug/issue list to www.xemacs.org. Status on 1
February: public announcement made on 11 January, feature
freeze in place, known bug/issue list ... uh what did you say
again?
- January 11 (new):
-
Decide details of default configuration for prerelease versions,
and schedule of changes, if any.
- January 16:
-
Open new development branch in CVS. Weekly tarballs that build
and run from now until release. Bug/issue list updated at least
weekly. Status on 1 February: development branch delayed to
approximately 5 February; issue list mea maxima culpa. Weekly
tarballs: on schedule. All hail Martin!
- February 1:
-
Code expected to be complete. Interim reports from PWPs;
triage the features. Reports emphasize known issues for
testers to bang on. Status on 1 February: err, sorta.
- February 1:
-
Implement default configuration for testing. Announce
explicit testing goals (bugs, issues, features) to
xemacs-beta. Update frequently. Status on 1 February:
likely delayed to 5 February.
- February 15:
-
Final reports from PWPs: code complete and design bugs
cleared. Triage features not meeting this criterion.
Status on 1 February: on schedule.
- March 26:
-
The original target date has slipped twice. That's life. So
we'll do the release on March 26.
Didn't happen. Oh, well.
- April 15:
-
The original target date has slipped three times. Sigh. This
is called ``learning by doing.''
"Release" 21.4.0 as "gamma". Branch 21.1 off trunk, move
devel code to trunk as 21.5, open 21.4 as new stable branch.
21.1 will continue to be supported as the "stable" branch,
with hopefully no more releases until:
- Mid-May::
-
Acceptance of 21.4.x as stable by Vin; mothball 21.1.
|