Stephen> Well, that's true of the dedicated maintainer, too. :-) Besides having the time and interest you'll need the rights do to the check in, too ;-) I'm trying to understand the XEmacs development process and by looking at the jobs-page it seems(!?) like it is the "Package Patch Tender"s job to follow up on these types of patches. Since there is no dedicated XEmacs maintainer of the package he should look for a maintainer outside of XEmacs. In this case the package comes from ruby itself so he should look for someone there to approve of the patch. Right!? So packages that are maintained for XEmacs outside of XEmacs should be more or less possible just to accept when they are updated? A good strategy for Hans would then be to adress the ruby maintainer either to accept the patch or, better yet, accept and include it in the distribution? Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Mats Lidell writes: True, but the XEmacs maintainer will automatically have the permissions and authority to check in, as well as a veto over others' patches. That's what defines an XEmacs package maintainer. jobs.html is way out of date. I really doubt we have a package patch tender anymore (if we ever did :-). _ No, if he wants it fixed in the XEmacs packages, it needs to be an XEmacs developer with commit privileges. That includes all the Reviewers, and the listed maintainer(s) if any. If the ruby people want to take on the job of maintaining the XEmacs package, then we'll surely give them the necessary permissionts. But Hans or anybody else interested could volunteer. There are none, and there won't be. That's what the conflict between XEmacs and the AUCTeX maintainers is all about. Our past experience says that it's important to build a package in the XEmacs package tree to ensure consistency, especially of inlined code (macros and defsubsts). The AUCTeX maintainers are unwilling to do that (for good and sufficient reason), so we are unwilling to distribute their tarball-in-XEmacs-package-format. Somebody has to maintain the package *in* the XEmacs tree. Normally this is trivial for single-file packages, except that a lot of people balk at checking out 100MB of package tree for a 5KB library. It was my understanding that Hans basically wants us to update to the current upstream version. Which will happen when somebody with the power has the interest and the time. I have the power and the interest, but at my current rate of fulfilling promises of this kind I'd say a commit is due in 2010 or so. There's a long queue already. ;-) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta