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

Rodney Sparapani writes: 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. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta