Hello again, Having been a person who spends all day with at least one Xemacs and one Gnu Emacs session open, I would like to help. I would be quite willing to give a hand. I have a few machines with CVS repositories here at Wesleyan; so I might be able to help with that (though I imagine that something under xemacs.org would be more apropos). Have fun, -Trey

mb> permanent mechanism, involving some kind of long-term mb> availability from xemacs.org, is appropriate. I can think of mb> 3 levels of lisp packages mb> - those effectively in the core, like xemacs-base mb> - those we provide as part of the sumos mb> - those we provide in a "contrib" directory. mb> These levels indicate different levels of certainty that they mb> work and are useful with XEmacs. At present we simply don't distinguish between "sumo" and "contrib"; that's why they're called "sumo". mb> Obviously we have problems responding to all the demands on mb> our time. Ideally we would have an ongoing job of mb> package-author-interface person who: This is Andreas, no? mb> - keeps track of the status of external packages. Not so big, at least once systematized. Maybe a 'bot that mails listed maintainers once a month, and if it doesn't get a reply notifies the PAI guy, who either sends out a panic call for volunteers on -announce and/or -beta, or boots the package to xemacs-contrib (or xemacs-bitrot, qqv). The status-tracker has to be Andreas (the package release engineer). mb> - integrates or helps the author integrate packages into the mb> XEmacs framework somewhere. We don't really have anybody competent to "help" (really only Steve Baur fully understands the package creation/maintenance process AFAIK). I guess Karl Hegbloom is working on this; it would be really nice if he would document what he's learned. IMHO docs are far more important than tweaking the Makefiles at this point. Picking the right group is not so hard at present. What else is there, policy-wise? This doesn't have to be Andreas. mb> - sets up CVS commit access for all package authors. mb> - creates "beta" and "stable" versions of packages, as mb> appropriate. It's the "as appropriate" clause that's the killer here. What really ought to be done (IMHO) is to split the packages three ways: xemacs-base: functionality without which the kitchen sink can't function: efs, dired, fsf-compat, ... Also anything without which the package stuff won't function. Probably the core release engineer(s) should (jointly) own this. Definitely needs authoritative beta and stable. xemacs-standard: typically desirable functionality: vc, lazy font-lockers, various modes, ... Must have a maintainer. If the release engineers and the package honcho all disclaim it, and no volunteer steps forward, it must be booted to contrib. Probably ought to have authoritative beta and stable. xemacs-contrib: everything else. May or may not have a maintainer. Special interest stuff (eg, my own edict.el) might very well belong here even if there is an active maintainer. Maintainer decides; maybe Andreas needs to care, maybe not. We could also require a maintainer of contrib stuff and split off the unmaintained stuff into xemacs-bitrot (or more politely, xemacs-at-your-own-risk-and-rather-risky-indeed). Authors of xemacs-bitrot wouldn't even need to have commit access (or even really be the author if it's GPL, which presumably it would be). I'd say split off xemacs-mule, but we want to go in the direction of Mule (or Mule-TNG) standard, anyway. I don't know where you divide between -standard and -SUMO. jsja> If that is the "eventual goal", then the question: "How do I jsja> get my elisp package added to the XEmacs distribution" jsja> should probably be in the FAQ, along with an answer jsja> outlining the process. I'm not currently clear on what that jsja> process is supposed to be. mb> Neither am I. We elect someone to do the job, but perhaps the mb> job is too boring to attract people in a hacker-driven mb> community? People are maintaining FAQs, the web site, and so on slowly but surely. Really, the Jobs Liaison and Head PITA ought to be keeping tabs on this stuff, it's part of the >80% (yo, Ben!) If it doesn't get assigned to somebody (and Ben doesn't want it), I'll take on the Jobs Liaison thingie and (if Andreas doesn't want it) the PAI guy role starting beginning of August (travel intervenes). I don't promise to _do_ anything, just be noisy about it about once a month ;-). Maybe I'll actually _do_ stuff too, but that would be novel.... mb> We really need to do a better job of enabling other people to mb> contribute to XEmacs. But instead of trying to solve the BIG mb> problem, let's just try today to solve the problem of helping mb> Trey. As an ad-interim policy, how about: ... put it in patch form (diff -u /dev/null checkers.el) and post it to -patches (that's sufficiently baroque to be cool). If somebody on -review thinks it's usable (and there are no vetos), they commit it to a new "contrib" group under /cvs/xemacs-packages/, and Andreas picks it up in the next SUMO. If the patch method is _too_ baroque, something alternative (post an attachment to -beta, put it on a web site an post an announcement to -beta, something else?) could be done. The patch method has the advantage of using the current machinery for queuing up to -review, tho. -- 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."