On Mon, 2002-08-12 at 16:30, Steve Youngs wrote: I haven't really thought about it, but here's something, based largely on the way I try to work, and applicable at least partially to patches in general too. Disclaimer: the following may contain stuff that is already crystal clear to most people around here. Mentioning something here doesn't imply that I've ever seen it happen before. I'd say I'm generally fine with these commits, provided that the committer knows *why* the change was made (bug fixes, new cool features etc), uses the package/mode in question, and is available to help out with the possible bugs introduced. Also, the "why" part should be spelled out in the ChangeLog entr(y|ies) or at the very minimum, in the corresponding message to xemacs-patches. The minimum requirements for a commit done by anyone is that the updated package builds, doesn't break the build of any other package, and at least starts up cleanly. In short: No untested, just-for-fun, hit-and-run commits. If you're planning to work on something bigger, let's say an upstream sync of a whole package, I think it would be a good idea to send a note about it to xemacs-beta already in the planning phase. This way we can avoid clashes from many people working on same stuff, and hear about possible problems that an update might cause early. Before committing a sync of some kind, one should inspect the changes made to the XEmacs version after the previous sync, and preserve them unless they're already addressed by the new version. Don't reintroduce old, fixed bugs... If you commit a change to something that there is "upstream" for, be sure also to submit it there if applicable, and mark this with the FORWARD keyword in the message you'll send to xemacs-patches. For example, it isn't be possible for other people to feed your changes to FSF, they won't accept it because the author is the only one who can assign the copyright of the change to them. AFAICT, this is true for all patches. On a side note, I haven't signed any FSF papers. Be also sure to communicate the status of the stuff in question after the change, whether you think it's ready for release, or needs considerable spanking. I and Pete really want to know that. Go ahead and commit the igrep sync Steve, I believe you know what you're doing:) -- \/ille Skyttä ville.skytta at xemacs.org