Redirected to xemacs-beta. Long answer to a couple of simple questions. All of this really needs to be in an Info document, but isn't yet. So here goes: Darryl> [ Should I even bother with 21.4.4 patches? Yes. Please. I'd consider it a personal favor. *grovel* Darryl> What's the criteria for determining whether or not a patch Darryl> goes into 21.4.XX? ] Whether the 21.4 Release Manager == me <stephen(a)xemacs.org&gt; likes it or not. In principle: For *nix platforms and cross platform code (including the great majority of Lisp code), increasing stability. All accurate doc patches will be accepted. For code changes, it should be "obviously and provably safe" especially for platforms where the change provides no immediate benefit. You don't need to provide a proof, but if I have to do it, application will be delayed. Cf. GTK below for one way to prove safety. An alternative is that the patch have been in 21.5 for more or less time without reports of problems, but I don't like that very much. A lot of MS Windows code gets in that way. For experimental platforms (eg, GTK) and code, ie, code that is not autodetected and must be enabled with a configure option (eg, --with-modules), anything that a "responsible party" (Bill Perry for GTK, eg) recommends will probably go in, as long as it is guarded by #ifdef HAVE_GTK, is in a file that is only linked in builds for that platform, or the like. Provably safe for other platforms, and I don't actually care about stability of experimental platforms. Another example: Normally I'd consider Andy Begel "responsible" enough for the modules, but I couldn't swallow his remove-module patch because it violates the basic assumption that Lisp calls can't crash XEmacs. As both those examples indicate, "responsible persons" need not be review board members. MS Windows: I defer to Ben and Andy. The platform is de facto not stable, so I'm not going to try to enforce it any more. Judgements as to "overall stability-improving" on that platform are beyond my competence under current conditions. In general I would probably accept patches on the recommendation of any review board member who's been active in the Windows platform, since mostly they wouldn't push if there was some chance Ben or Andy wouldn't like it. The policy is pretty much the same for 21.1, except that it's Vin Shelton, 21.1 Release Manager, who has sole approval power there. (And it's probably relevant. Once 21.4 seems to be really stable, we plan to retire 21.1 and Vin will take over 21.4. I'll move on to planning the next major release.) For 21.5, basically any reviewer can approve any patch, subject to veto. A veto overrides any approvals. Vetos can be appealed but that's one of the functions of xemacs-review, it's not really a public process. Example at point: Darryl> XEmacs 21.4.4 still needs Xmu even with --with-xmu=no. Darryl> Here's a patch that fixes it. Darryl> 2001-10-02 Darryl Okahata <darrylo(a)sonic.net&gt; Darryl> * If HAVE_XMU was not defined (xmu was not being Darryl> used), xlwgcs.c was still referencing xmu functions. This is not quite provably safe in execution (there's no easy guarantee that over the years we haven't broken the functionality that substitutes for the Xmu code), but I interpret it increasing stability on the only affected (fairly unusual --with-xmu=no) platform. Ie, it won't break anything else and is necessary for that one. It will go in. (Subject to a more careful review, but a quick look seems OK.) Darryl> [ Side note: I've had commit access for nearly a year, but Darryl> I've yet to commit anything (I use CVS a lot, so using CVS In general, only Vin and I commit to the "official" releases, 21.1 and 21.4. It's a matter of personal convenience for the release managers. We both like it that way. For small/occasional patches to the trunk (21.5), it's typically more convenient to have the approving reviewer do commits. For packages, things are a little more complex. Many packages have external maintainers, who usually do all commits. Most other commits are done by Steve Youngs, the packages release manager. Commit privileges for non-reviewers allow (1) package maintainers to do their jobs directly, (2) the convenience of personal branches for large but as yet unapproved changes (eg, Richard Reingrub's garbage collection work), (3) integration of things that would otherwise be forks (eg, Bill Perry's GTK work), and (4) convenience for both reviewers and developer where a series of changes has been discussed and approved in principle, but the detailed patches haven't been submitted (mostly because they probably will need frequent and "obviously correct" adjustments). Darryl> isn't a problem). Do I need to subscribe to xemacs-review Darryl> (does it still exist)? ] No need to subscribe, and yes, it exists. Patch submissions, approvals/denials, and similar administrivia now all go to xemacs-patches. You may subscribe to that if you want to be sure to see the approvals etc. Or you can check the archives. xemacs-review is the policy channel, for people with patch approval power, policy votes, and/or final say over some part of the mainline. That's where we discuss personnel decisions, appeals of patch vetoes, and broad policy such as timing and major features in release plans, etc. So it's a closed list---most of those discussions are generally considered inappropriate for publication. But it's not appropriate if your contribution will be only in submitting patches, and discussing them when you have an interest. If you're willing to take on the responsibility of helping to ensure that all patches get reviewed, and policy-making, then xemacs-review membership is needed. XEmacs Review is a cabal in the sense that it chooses its own membership. The decision is primarily based on a history of past contribution and willingness to help process the patch queue or a few other policy- related admin positions (eg, Release Manager). Although you need to be a reviewer to have approval/veto power, *all* interested parties are always welcome to direct comments on patches (as to their importance and/or correctness) to *xemacs-beta*. Not *xemacs-patches*, which is basically the "for the record channel" for patchs and decisions, not for discussion. (You will be arrested by the Topic Police if you post discussion to xemacs-patches.) -- 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."