21.4 (ex 22.0) Release Status / Call for Testers and Volunteers

** STATUS REPORT The version number of the March 1 release is being demoted from 22.0 to 21.4, due to late delivery of the merge of GTK+ support to the 21.2 code base, and of the Mule on Windows work being done by Ben Wing. Inclusion of these features wasn't terribly plausible on the tight schedule we chose, but it was worth a try. Perhaps related to that impetus, these features are being actively worked on, and are scheduled for delivery in the release of 22.0 in the third quarter of 2001. This schedule is realistic on current pace. In the 21.4 tarballs, GTK support is planned for inclusion on an untested, unsupported experimental basis. Configuration of the support will default to _off_, in testing as well as in the release. Mule on Windows is more problematic. A CVS branch will be created in the near future, and we hope for a merge into the _21.5 development branch_ by early spring. The 21.4 release will include the gutters and widgets feature, allowing embedding of toolkit widgets in frames and buffers. The basic framework is fairly solid, but 21.4 will include only minimal, demonstration-level application code. The other major feature planned for 21.4 is "SUMO in source kit." This is intended to address the "OK, I've built it, it starts, but it doesn't _do_ anything" FAQ. Although the package architecture is sound, it is still difficult to bootstrap. The default tarball will include the SUMO package tarball, so that the build will install a full-featured XEmacs environment. Disaggregated source kits will still be available for those who prefer to choose what they install, rather than installing everything then removing what's not wanted. On the Windows platform, this issue seems to have been successfully addressed via Andy Piper's port of the Cygwin netinstaller. Other features' development is generally proceeding on schedule, and assorted bugs and "pessimizations" have been discovered. Many have been fixed, others are being worked on. More details, and information on individual features, will be made available on the Release Status Page: http://www.xemacs.org/Releases/Public-21.2/ Discussion of release plans, as well as all other issues related to XEmacs development, is taking place on the developers' mailing list, xemacs-beta(a)xemacs.org xemacs-beta is an open mailing list. You can subscribe from the XEmacs home page, http://www.xemacs.org/, or by sending a request containing the word `subscribe' (without quotes) in the _body_ of the message to xemacs-beta-request(a)xemacs.org. List archives are available at http://list-archives.xemacs.org/xemacs-beta/. ** RELEASE MANAGER Yes, I've been out of it for a couple of weeks. "Senior panic" is over (Japanese students graduate in mid-March), so I'll have more time to devote to things like monitoring comp.emacs.xemacs, and updating the release pages. Specifically management-related tasks like this announcement are lagging schedule by about a week. However, coding and testing are proceeding on schedule as far as can be known. ** CALL FOR TESTERS We need beta testers! Only you can tell us if XEmacs builds and works well on your system, in the configuration you need. We especially need to test --with-gtk=no builds on systems that don't support GTK+. The number one testing priority now is building the gtk-xemacs merged code, _without_ GTK+ support. To include GTK+ support, even on an experimental basis, in the release tarballs, we must be sure it has no adverse impact on the supported code. For details on getting, building, and testing the GTK+ branch and development mainline, see http://www.xemacs.org/Releases/Public-21.2/tester.html Testers should subscribe to xemacs-beta, or review the archives regularly. ** 22.0 RELEASE A proposal to release the next version of XEmacs, 22.0, planned to include support for GTK+ and better integration of Mule with the Windows I18N API, is in the works. The target will be the end of 3rd Quarter, 2001. If you have "big things" in mind for XEmacs, why don't you write up a "feature proposal" and send it my way? It needn't be something you personally plan to do. Some people implement their wishes (e.g., http://www.xemacs.org/ArchitectingXEmacs/, Ben Wing's "Architecting XEmacs"); others just publish them (for example, Jamie Zawinski's "XEmacs Wishlist", http://www.jwz.org/doc/xemacs-wishlist.html). ** CALL FOR VOLUNTEERS We need workers! * 22.0 Release Manager The 21.4 Release Manager plans to retire in April. How would _you_ like to be known for releasing the first XEmacs with GTK and Windows I18N API support? You _know_ you would! Write me, Stephen Turnbull <stephen(a)xemacs.org&gt;, and we can talk about your qualifications and the job's responsibilities. Currently active XEmacs developers preferred, of course, but it's not an absolute requirement. You mostly just need to be able to say "no". :-) (It does help to have a track record as a developer. But there are other ways to establish credibility.) Appointment subject to approval of the XEmacs Review Board. * Bug Tracking System Gunnar Evermann, our BTS maintainer, is doing the best he can. But after years of neglect of the BTS, he needs help. There are about 1000 entries in the system. If we can get 5 volunteers to just _classify_ 10 messages, and prioritize maybe one actual bug, per week, in six months we'll be on top of the problem. You don't need to be intimately familiar with XEmacs internals, nor even terribly technical, to do this. The data doesn't get thrown away, so a few misclassifications won't hurt anywhere near as much as a little bit of classification will help. * Documentation Much effort has been made to improve the documentation, especially by Adrian Aichner in creation of the Sourceforge project to handle our web page, and putting together the bits and pieces that are the XEmacs FAQ list. Our own "sorceror's apprentice", Martin Buchholz, has been busily sweeping away typographical lint from comments and docstrings as he cleans up the code. But there are many places where XEmacs documentation is inaccurate, incomplete, inaccessible, or simply nonexistent. All of these are bugs, and we ask you all to report them, and where possible provide fixes, just as enthusiastically as you report crashes and functionality bugs. * General We always need people to fix bugs and add features. It's not necessarily technically hard, especially at the Lisp level. And XEmacs's development process imposes relatively few political obstacles. With the addition of GTK+ support in the near future, we will get libglade support, allowing use of the Glade UI design tool to prototype Custom interfaces and dialog boxes. If you have GTK+/GNOME support on your system, you can install Glade and start prototyping the XEmacs of the future. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."