>>>> "Malcolm" == Malcolm Purvis
<malcolmpurvis(a)optushome.com.au> writes:
>>>> "Cristalle" == Cristalle Azundris Sabon
<xemacs(a)azundris.com> writes:
Cristalle> I am not implying any ill will here;
Malcolm> I'm not implying any ill will here either,
Why don't you ask Bill? I suppose he's like most of us; he'd be
pleased by the interest. If we (ie, my department) can find a way for
him to participate effectively with a minimum of effort on his part, I
bet he would.
Malcolm> but William's lengthy absence from these lists does make
Malcolm> it more difficult for the few people who are interested
Malcolm> in GTK to gain sufficient credibility (through
Malcolm> successfully applied patches) to be allowed to help more.
Malcolm> Not that I'm asking for CVS write access. Even I don't
Malcolm> think I qualify for it yet.
The main qualification for write access is the Hippocratic one:
promise to, first, do no harm. :-) Seriously, for 21.4, nobody but
Vin commits, and for 21.5, non-Reviewers don't commit without
approval. Commit privilege by itself is not that big a deal, as long
as the net persona is well-known to us and we can work out ways to
avoid inadvertant commits to non-GTK code.
One possibility would be to fork off a GTK development branch from
21.4. For this to make sense from the project's standpoint, we'd need
to get almost all of the resources (release engineer and developers)
from new people. And it probably would detract from the mainline,
anyway, since it would split the tester population. (Speaking as one
vote, and I don't know what the rest of the Board might say.)
Malcolm> Thinking this through today I've come to the conclusion
Malcolm> that for 21.4 it might be best to either disable the
Malcolm> --with-gtk and --with-gnome config flags entirely or
Malcolm> change the status of the port from 'experimental' to
Malcolm> 'technology demo' and supply a suitable warning message.
Malcolm> I can't see further gtk fixes going into 21.4 under any
Malcolm> circumstances and it will cut down on bug reports.
Artificially cutting down on bug reports is not a goal; I haven't
heard enough screams about "too much traffic" on xemacs-beta recently
:-(. Also, at least Debian provides packaged XEmacs/GTK binaries.
As for fixes going into 21.4, my policy was that anything that Bill
wanted that stayed inside of #ifdef HAVE_GTK ... #endif could go in.
Some fixes to the Lisp files (where we don't really have such a
concept, but do have guards like (featurep 'gtk) and device-type tags
in specifiers) have also gone in. Under current circumstances, with
Bill P out of action and the code bit-rotting, I would strongly
consider committing patches by "interested parties" with "competent
review" (rather than requiring the review be done by Bill).
However ... for 21.4, you'd have to see how _Vin_ feels about it.
Why don't the GTK "interested parties" designate a rendezvous (here on
xemacs-beta or a separate CC list) and caucus about (1) what manpower
you can provide and (2) what (automated) support you'd need from the
XEmacs Project? Mailing list (considering Bill P's convenience, for
example), home page (that's just a matter of committing to the
xemacsweb module, which automatically pushes to the primary web
mirrors), CVS branch, subdir in the FTP archive, what else?
For the main thing (a release engineer), we have scripts that should
be easily adaptable. The release engineer would basically have to be
committed to staying on top of the patch process, writing the
CHANGES-GTK file (essentially, abstracting ChangeLogs for addition to
NEWS in the next public release), and tagging CVS and declaring
milestones ("releases") when you've got something that seems to build
and work. Uploading tarballs for FTP would be optional.
If you can organize that much, I suppose the Board would be persuaded
to provide reviewing and some direct labor for application to the 21.5
tree, and maybe even back ports to 21.4 (which is up to Vin, but he
would probably go with any consensus of the Board).
--
Institute of Policy and Planning Sciences
http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.