- 1) If it's a file which is thought of as being outside of Gnus (e.g.,
- the new "encrypt.el"), you should probably make the change in the
- Emacs tree, and it will show up in the Gnus tree a few days later.
-
- If you don't have Emacs CVS access (or it's inconvenient), you can
- change such a file in the v5-10 branch, and it should propagate to
- Emacs CVS -- however, it will get some extra scrutiny (by me) to see
- if the changes are possibly controversial and need discussion on the
- mailing list. [Many changes are obvious bug-fixes however, so often
- there won't be any problem.]
-
- 2) If it's to a Gnus file, and it's important enough that it should be
- part of Emacs/v5-10, then you can make the change on the v5-10
- branch, and it will go into Emacs CVS and the Gnus CVS trunk (a few
- days later).
-
- If you know that there will be conflicts (perhaps because the
- affected source code is different in v5-10 and the Gnus CVS trunk),
- then you can install your change in both places, and when I try to
- sync them, there will be a conflict -- however, since in most such
- cases there would be a conflict _anyway_, it's often easier for me
- to resolve it simply if I see two "identical" changes, and can just
- choose the proper one, rather than having to actually fix the code.
-
- 3) For general Gnus development changes, of course you just make the
- change on the Gnus CVS trunk and it goes into Emacs a few years
- later... :-)
+@itemize
+@item
+If it's a file which is thought of as being outside of Gnus (e.g., the
+new @file{encrypt.el}), you should probably make the change in the Emacs
+tree, and it will show up in the Gnus tree a few days later.
+
+If you don't have Emacs bzr access (or it's inconvenient), you can
+change such a file in the v5-10 branch, and it should propagate to Emacs
+bzr---however, it will get some extra scrutiny (by Miles) to see if the
+changes are possibly controversial and need discussion on the mailing
+list. Many changes are obvious bug-fixes however, so often there won't
+be any problem.
+
+@item
+If it's to a Gnus file, and it's important enough that it should be part
+of Emacs and the v5-10 branch, then you can make the change on the v5-10
+branch, and it will go into Emacs bzr and the Gnus git trunk (a few days
+later). The most prominent examples for such changes are bug-fixed
+including improvements on the documentation.
+
+If you know that there will be conflicts (perhaps because the affected
+source code is different in v5-10 and the Gnus git trunk), then you can
+install your change in both places, and when I try to sync them, there
+will be a conflict---however, since in most such cases there would be a
+conflict @emph{anyway}, it's often easier for me to resolve it simply if
+I see two @samp{identical} changes, and can just choose the proper one,
+rather than having to actually fix the code.
+
+@item
+For general Gnus development changes, of course you just make the
+change on the Gnus Git trunk and it goes into Emacs a few years
+later... :-)
+
+@end itemize