|--==> "MS" == Martin Schwenke <martin(a)meltin.net&gt; writes: MS> Even so, I'm still a little unsure of the sequence of events. Do I: MS> * Initially post the patch with a [PATCH] tag, wait a couple of days MS> and post a followup with [AC]. MS> * Initially post with [A] [PATCH] and then later [C]. MS> * Commit anything I like and then simply post a [AC] [PATCH] message. It's pretty much a judgment call. If it's an "obviously correct" type of patch, you're quite welcome to do "[AC] [PATCH]" type of submission and commit straight away. If it's something you're not quite sure of, do "[PATCH]" type of submission and ask for someone to review it for you. Then commit (or not) based on what the reviewer says. In this case the reviewer will post a followup to the patch with a [A] or [V]. This reminds me, are you happy with our "keyword" thing we do with patches? Here's a brief summary: A - APPROVE -- The patch is approved. C - COMMIT -- The patch has been committed. F - FORWARD -- The patch has been forwarded upstream. Q - QUERY -- More information is needed or patch needs revising. R - RECOMMEND -- The patch is recommended for another branch (ie, a patch to 21.5 that should also go in 21.4, used in conjunction to 'version no.' below). Patches to packages wouldn't normally need this keyword. S - SUPERSEDES -- This patch supersedes the one we're following up to. V - VETO -- The patch has been vetoed (reasons will be given). version no. -- eg, '21.5' or '21.5' this patch is for a particular version of XEmacs. (this wouldn't ever be needed for patches to packages). Take a look at 'patch-keywords.el' in the xemacs-devel package. It makes adding these keywords in the right place and format a breeze. -- |---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---| | XEmacs - It's not just an editor. | | It's a way of life. | |------------------------------------&lt;youngs(a)xemacs.org&gt;---|