• Download
• XEmacs in GSoC
• FAQ
• Mailing lists
• Documentation
• People
• How to help
• Bugs
• Links

• Mailing lists
• Status of Services
• Near Future
• History of XEmacs
• XEmacs vs. GNU Emacs
• Screenshots
• Sites Created With XEmacs
• Year 2000 Statement
• Who Wrote XEmacs?
• XEmacs Contributors
• Website

• Download
• Optional Libraries
• Installation HOWTOs
• Quickstart Package Guide
• Documentation
• Installation resources
• Releases

• XEmacs Packages
• Other Interesting Sites
• Customization Links

• FAQ
• Reporting Bugs
• Troubleshooting resources
• Debugging

• How to help
• XEmacs in GSoC
• Open Issues
• Who Wrote XEmacs?
• XEmacs Contributors
• Dev team responsibilities
• Architecting XEmacs

XEmacs Jobs

Current version: 22 February 2008
Maintainer: Stephen Turnbull

XEmacs Review Board Members

The XEmacs Review Board has the authority to approve or veto any patch to XEmacs. Patches should be posted to xemacs-patches@xemacs.org. If someone vetoes your patch, you will receive e-mail from them, stating the veto but also describing exactly why the patch was vetoed, and how it should be changed in order to be acceptable. To qualify for membership to the Review Board, you should generally be someone who has put a lot of work into developing XEmacs for a long enough period of time that you are aware of the all of the basic ideas and issues in XEmacs and the XEmacs community.

The current members of the XEmacs Review Board are:

• Adrian Aichner
• Aidan Kehoe
• Didier Verna
• Jerry James
• Malcolm Purvis
• Mats Lidell
• Michael Sperber
• Norbert Koch
• Stephen Turnbull
• Steve Youngs
• Ville Skyttä
• Vin Shelton
• Vladimir Ivanovic
• Andy Piper (inactive)
• Ben Wing (inactive)
• Gunnar Evermann (inactive)
• Hrvoje Niksic (inactive)
• Jan Vroonhof (inactive)
• Jareth Hein (inactive)
• Jonathan Harris (inactive)
• Kirill 'Big K' Katsnelson (inactive)
• Martin Buchholz (inactive
• Olivier Galibert (inactive)
• Steve Baur (inactive
• William M. Perry (inactive)
• Yoshiki Hayashi (inactive)

Primary Positions

Primary positions are important enough that they should not allowed to remain unfilled for any length of time. Detailed descriptions of primary positions appear below.

Documentation Positions:

All of the documentation is listed here. Some positions are listed without primaries. It would be really nice if there were people actively maintaining each of these documentation areas, but slippage here is not so catastrophic.

Coding Projects

Job Descriptions For Primary Positions

Technical Lead/Architect

The technical lead will generally be the active developer most broadly knowledgeable about the architecture of XEmacs, and the core C and Lisp code that makes up XEmacs. His duties include maintaining an overall vision for future development work on XEmacs, and either implementing this vision himself (this is frequently the case, as the technical lead may be the only developer with enough broad-based experience with XEmacs to make such changes) or finding others to do so. A traditional technical lead would have a great deal of personal control over shaping the actual form of the product. Since XEmacs is a looser, more democratic effort, working mostly by consensus, much of the technical lead's role is advisatory -- he provides advice to other developers concerning how to implement a feature, whether a prospective feature is reasonable or not, what other changes a particular modification would entail, etc. He is also expected to review a significant fraction of the patches coming in and supply input, particularly for those patches which no one else is competent to understand. In general, he serves as the "fallback guy", expected (in theory) to be able to handle any technical issue or question related to the core of XEmacs that eludes the other developers.

If and when XEmacs grows beyond a handful of primary developers, it may be useful to split up the jobs of technical lead and architect. The technical lead would then do more actual development and patch review, while the architect would be in charge of the overall future vision of XEmacs and act in a primarily advisory role.

Beta Release Maintainer

The beta release maintainer is the primary maintainer for XEmacs, and serves as the de-facto spokesman. His responsibilities are (a) to put out new beta releases on a regular basis, i.e. at least every one to two weeks (depending on activity), (b) to go out of his way to be responsive to e-mail sent to him and communicative about and interested in important issues in all major aspects of XEmacs, and (c) to decide when it's time to do an external release. At this point, he is responsible for initiating a code freeze and assuming quasi-dictatorial power over the development process, doing whatever it takes to ensure that a relatively stable, bug-free release gets put out in a timely fashion. If some important job is not getting done during the critical pre-release period, it is ultimately the duty of the beta release maintainer (in conjunction with the meta-maintainer) to ensure that this gets done, for example, by finding somebody else who is willing to take over this position, or (last resort) doing the job himself. During periods when an external release is not happening, the beta release maintainer goes back to being a relatively low-key position, responsible primarily just for putting out regular beta releases. It is imperative, however, that the beta release maintainer continue to be as responsive as possible to e-mail sent to him, because he is the de-facto spokesman and is looked up to as the one providing overall guidance for the project. If he fails to respond to email, he will create the impression that the entire project is in disarray.

Stable Release Maintainer

The stable release maintainer is responsible for putting out `stable' releases of the code. These are generally small updates to previous external releases. Once a major external release happens, the development tree is forked, with one branch becoming the stable branch, the other the development branch. It is from this stable branch that stable updates happen and it is the stable release maintainer's responsibility to oversee this branch, decide which patches belong in this branch, and do whatever else is necessary to put out a stable update.

Meta-Maintainer

The meta-maintainer is responsible for defining and managing the separation of XEmacs duties into spheres of responsibility or "jobs". He maintains the list of jobs, which lists the jobs, their descriptions, and the current primary and secondary jobholder(s) for each of these jobs. (Generally, the primary actually does the work of the job, but if the primary becomes derelict in his duties, for example by simply disappearing and becoming unresponsive to email contact, the secondary steps in as the "acting jobholder", until the primary returns (along with assurances that he will not just disappear again) or another primary is found.) The meta-maintainer is also responsible, along with the beta release maintainer, for filling empty positions and for noticing when a job is not getting done. During pre-release cycles, the beta release maintainer may take the most active role in filling positions; during other periods, the meta-maintainer primarily assumes these duties.

Webmaster

The webmaster is responsible for maintaining the www.xemacs.org web site.

Core Patch Tender

The core patch tender's responsibility is to make sure that no patch to the core of XEmacs falls through the cracks. Every core patch posted to XEmacs either needs to be approved and then applied, or vetoed with a suggestion for how to modify the patch so that it is acceptable. The core patch tender is responsible for making sure that this happens. If a patch is posted and is neither approved nor vetoed within a two-week period, the core patch tender needs to step up and make inquiries to determine what should be done with the patch. If a patch is posted and then vetoed with suggestions for improvements, but no improved patch is submitted within a week or so, the core patch tender needs to make inquiries to the patch submitter to see if he can finish up getting the patch up to snuff, and if not, the reviewers need to be contacted again.

Package Patch Tender

The package patch tender's job is analogous to the core patch tender's, except that it applies to the Lisp packages that are, in some sense, external to XEmacs itself. His job may be complicated by the fact that packages may have active maintainers who may not be directly involved in XEmacs development. In that case, he may need to track down the active maintainer and try to get him to accept the patch. The package patch tender also needs to create and maintain a list of all the packages that are part of the full XEmacs development tree. For each package, this list should specify the package's home page (if any), the maintainer and his contact address, any mailing lists devoted to the package, the number of the latest release and where to get it, the corresponding XEmacs package release number, and (if the information is available) a subjective judgment as to how well the package is currently being maintained, from 0 (package is obsolete, no one has maintained it in years) to 5 (package contains an active, well-organized development effort with regular releases, mailing lists, a web site, etc.).

Bug Tracker

The bug tracker is responsible for keeping track of all the bugs that have been posted anywhere, either to xemacs-beta, comp.emacs.xemacs, or similar sources. Properly speaking, they need to be kept in a database, assigned priorities, severities and owners, and managed in the standard way that bugs are managed. Unfortunately, we don't currently have such an infrastructure, so it's the current responsibility of the bug tracker to keep track of the bugs in any way possible (e.g. just a simple list), with the number one cardinal rule being: NO BUG MAY FALL THROUGH THE CRACKS. Every bug that gets reported through any standard means needs to end up on the list, along with as much information as possible from the bug report: The name of the person reporting the bug, the version number of XEmacs being run, the circumstances and behavior of the bug, etc. etc. etc. The secondary responsibility of the bug tracker is to investigate a workable bug-tracking system for XEmacs. I know that the Samba project has such a system in place, so we should just be able to use theirs, for example.

CVS Manager

The CVS manager is responsible for all CVS issues related to XEmacs.This includes, for example, the CVS trees for the core and thepackages, and the CVS web interface. This includes the important but thankless task of doing backups.

Postmaster

The mailing list manager is responsible for maintaining the XEmacs mailing lists.

Binary-Kit Coordinator

The binary-kit coordinator is responsible for organizing the preparation, release, and distribution of pre-compiled XEmacs software based on the stable branch.

I18N liaison

The I18N Liaison is responsible for synchronizing maintenance and development of language environments with Mule development. "Language environment" includes features like input methods, standardization issues, language defaults and user setup, etc.

Language skills, for both feature specification and coordinating communication, are a plus. (With the current user and developer, Japanese is most useful, but developers with skill in R2L BIDI languages, eg Hebrew, are eagerly sought. Any language character sets other than ISO-8859-1 is very helpful.)