Tracker-based patch flow? [was: Why I attempted to port dired/VC...]

[Stephen J. Turnbull]

Rodney Sparapani writes:

 > Now that we have all of these nice patches in the tracker, do we have to 
 > submit them to xemacs-patches?

Yes.  This is obviously redundant, so you *shouldn't* have to, but as
a practical matter the mailing list is where I look for patches, I
suspect most other committers do too, and sending patches to
xemacs-patches is the documented workflow.

Given the redundancy, I think it would be reasonable to substitute a
tracker issue id, file id, or (if you've got lots and lots of MIME-fu
:-) a MIME external object pointing to the patch's URL.

Regarding transition to a tracker-based workflow, discussion and
proposals are welcome.  Two issues I can see offhand are that a lot of
people use Didier's patcher.el, which not only sends the mail but does
a lot of other stuff; people would still want to use patcher in the
tracker-based workflow.  Probably the best strategy for a transition
would be to ensure that Roundup can handle patches by mail in some
appropriate way, and provide some patcher.el integration for that.

This might also be a killer app for the curl/neon modules I've been
working on for a while.

Other suggestions would be welcome, too.