Patch ettiquette [was: [PATCH] Re: pcl-cvs patch

Jarl> As a first-time patcher I hope it's acceptable with my Jarl> newbieness behaviour. I probably shouldn't cross-post a Jarl> patch (but only to patches) Don't worry about it. XEmacs is in your debt for your efforts, not the other way around. Thanks for your patches! :-) If you intend a patch for _application_ to the sources as is, _always_ post it to xemacs-patches, even if there are minor points you are asking for discussion about. Not doing so will resulting in patches getting "lost". If you expect that the patch will not be acceptable, but are using it to stimulate discussion, then don't post to xemacs-patches. Intermediate cases are up to your judgement; unless you're sure you'll followup with a "real" patch, better to err on the side of posting to xemacs-patches. Discussion of the _content_ of the patch (ie responses to reviewer comments beyond "that's right, ok, I'll do it your way") should _always_ be posted to xemacs-beta. (We may split xemacs-beta into code discussion and stuff that is more relevant to non-developer testers at some point, but at this point xemacs-beta is the correct place for this.) These rules will result in a fair number of cross posts, but we don't yet have a better way to handle that. Note: Developers should never post to xemacs-patches unless there is a patch in the post. We plan to enforce this with an automatic filter. The exceptions are administrative. If you have commit authorization, then post a short COMMIT notice to xemacs-patches when you commit to CVS. Menbers of the Review Board will also post short notices of administrative action (APPROVE, VETO, QUERY, etc) to xemacs-patches. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.