Patches for ruby-modes

[Stephen J. Turnbull]

Mats Lidell writes:

 > >>>>> Stephen J Turnbull <stephen at xemacs.org> writes:
 > 
 > 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 ;-)

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.

 > 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. 

jobs.html is way out of date.  I really doubt we have a package patch
tender anymore (if we ever did :-).

 > 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!?
_
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.

 > So packages that are maintained for XEmacs outside of XEmacs should be
 > more or less possible just to accept when they are updated?

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.

 > 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?

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. ;-)