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" == Darryl Okahata <darrylo(a)soco.agilent.com> writes:
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> 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>
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."