Re: [A] Re: [PATCH] prog-modes: eiffel.el filename fixes + other minor fixes
|--==> "MS" == Martin Schwenke <martin(a)meltin.net> 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. |
|------------------------------------<youngs(a)xemacs.org>---|