Re: Patches for ruby-modes
Mats Lidell writes:
>>>>> Stephen J Turnbull <stephen(a)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. ;-)
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta