\input texinfo
@setfilename gnus-coding
-@settitle Gnus Coding Style and Maintainance Guide
+@settitle Gnus Coding Style and Maintenance Guide
@syncodeindex fn cp
@syncodeindex vr cp
@syncodeindex pg cp
@copying
-Copyright (C) 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
+Copyright @copyright{} 2004--2005, 2007--2012 Free Software
+Foundation, Inc.
@quotation
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.3 or
any later version published by the Free Software Foundation; with no
-Invariant Sections, with the Front-Cover texts being ``A GNU
-Manual'', and with the Back-Cover Texts as in (a) below. A copy of the
-license is included in the section entitled ``GNU Free Documentation
-License'' in the Gnus manual.
+Invariant Sections, with the Front-Cover texts being ``A GNU Manual'',
+and with the Back-Cover Texts as in (a) below. A copy of the license
+is included in the section entitled ``GNU Free Documentation License''.
(a) The FSF's Back-Cover Text is: ``You have the freedom to copy and
-modify this GNU manual. Buying copies from the FSF supports it in
-developing GNU and promoting software freedom.''
-
-This document is part of a collection distributed under the GNU Free
-Documentation License. If you want to distribute this document
-separately from the collection, you can do so by adding a copy of the
-license to the document, as described in section 6 of the license.
+modify this GNU manual.''
@end quotation
@end copying
@titlepage
-@title Gnus Coding Style and Maintainance Guide
+@title Gnus Coding Style and Maintenance Guide
@author by Reiner Steib <Reiner.Steib@@gmx.de>
@insertcopying
@end titlepage
-@c Obviously this is only a very rudimentary draft. We put it in CVS
-@c anyway hoping that it might annoy someone enough to fix it. ;-)
-@c Fixing only a paragraph also is appreciated.
+@c Obviously this is only a very rudimentary draft. We put it in the
+@c repository anyway hoping that it might annoy someone enough to fix
+@c it. ;-) Fixing only a paragraph also is appreciated.
+@ifnottex
@node Top
-@top Gnus Coding Style and Maintainance Guide
+@top Gnus Coding Style and Maintenance Guide
This manual describes @dots{}
+
+@insertcopying
+@end ifnottex
+
@menu
* Gnus Coding Style:: Gnus Coding Style
-* Gnus Maintainance Guide:: Gnus Maintainance Guide
+* Gnus Maintenance Guide:: Gnus Maintenance Guide
+* GNU Free Documentation License:: The license for this documentation.
@end menu
@c @ref{Gnus Reference Guide, ,Gnus Reference Guide, gnus, The Gnus Newsreader}
The Gnus distribution contains a lot of libraries that have been written
for Gnus and used intensively for Gnus. But many of those libraries are
-useful on their own. E.g. other Emacs Lisp packages might use the
+useful on their own. E.g., other Emacs Lisp packages might use the
@acronym{MIME} library @xref{Top, ,Top, emacs-mime, The Emacs MIME
Manual}.
Functions for Cancel-Lock feature
@c Cf. draft-ietf-usefor-cancel-lock-01.txt
@c Although this draft has expired, Canlock-Lock revived in 2007 when
-@c major news providers (e.g. news.individual.org) started to use it.
+@c major news providers (e.g., news.individual.org) started to use it.
@c As of 2007-08-25...
There are no Gnus dependencies in these files.
XEmacs 21.1 and up.
@end itemize
-@node Gnus Maintainance Guide
-@chapter Gnus Maintainance Guide
+@node Gnus Maintenance Guide
+@chapter Gnus Maintenance Guide
@section Stable and development versions
-The development of Gnus normally is done on the CVS trunk, i.e. there
-are no separate branches to develop and test new features. Most of the
-time, the trunk is developed quite actively with more or less daily
-changes. Only after a new major release, e.g. 5.10.1, there's usually a
-feature period of several months. After the release of Gnus 5.10.6 the
-development of new features started again on the trunk while the 5.10
-series is continued on the stable branch (v5-10) from which more stable
-releases will be done when needed (5.10.8, @dots{}).
-@ref{Gnus Development, ,Gnus Development, gnus, The Gnus Newsreader}
-
-Stable releases of Gnus finally become part of Emacs. E.g. Gnus 5.8
-became a part of Emacs 21 (relabeled to Gnus 5.9). The 5.10 series
+The development of Gnus normally is done on the Git repository trunk
+as of April 19, 2010 (formerly it was done in CVS; the repository is
+at http://git.gnus.org), i.e., there are no separate branches to
+develop and test new features. Most of the time, the trunk is
+developed quite actively with more or less daily changes. Only after
+a new major release, e.g., 5.10.1, there's usually a feature period of
+several months. After the release of Gnus 5.10.6 the development of
+new features started again on the trunk while the 5.10 series is
+continued on the stable branch (v5-10) from which more stable releases
+will be done when needed (5.10.8, @dots{}). @ref{Gnus Development,
+,Gnus Development, gnus, The Gnus Newsreader}
+
+Stable releases of Gnus finally become part of Emacs. E.g., Gnus 5.8
+became a part of Emacs 21 (relabeled to Gnus 5.9). The 5.10 series
became part of Emacs 22 as Gnus 5.11.
@section Syncing
With the inclusion of Gnus 5.10, Miles Bader has set up an Emacs-Gnus
gateway to ensure the bug fixes from Emacs CVS are propagated to Gnus
-CVS semi-automatically. These bug fixes are installed on the stable
-branch and on the trunk. Basically the idea is that the gateway will
-cause all common files in Emacs and Gnus v5-10 to be identical except
-when there's a very good reason (e.g., the Gnus version string in Emacs
-says @samp{5.11}, but the v5-10 version string remains @samp{5.10.x}).
-Furthermore, all changes in these files in either Emacs or the v5-10
-branch will be installed into the Gnus CVS trunk, again except where
-there's a good reason.
+CVS semi-automatically.
+
+After Emacs moved to bzr and Gnus moved to git, Katsumi Yamaoka has
+taken over the chore of keeping Emacs and Gnus in sync. In general,
+changes made to one repository will usually be replicated in the other
+within a few days.
+
+Basically the idea is that the gateway will cause all common files in
+Emacs and Gnus v5-13 to be identical except when there's a very good
+reason (e.g., the Gnus version string in Emacs says @samp{5.11}, but
+the v5-13 version string remains @samp{5.13.x}). Furthermore, all
+changes in these files in either Emacs or the v5-13 branch will be
+installed into the Gnus git trunk, again except where there's a good
+reason.
+
@c (typically so far the only exception has been that the changes
@c already exist in the trunk in modified form).
Because of this, when the next major version of Gnus will be included in
-Emacs, it should be very easy -- just plonk in the files from the Gnus
+Emacs, it should be very easy---just plonk in the files from the Gnus
trunk without worrying about lost changes from the Emacs tree.
The effect of this is that as hacker, you should generally only have to
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 CVS access (or it's inconvenient), you can
+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
-CVS -- however, it will get some extra scrutiny (by Miles) to see if the
+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 CVS and the Gnus CVS trunk (a few days
+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 CVS trunk), then you can
+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
+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 CVS trunk and it goes into Emacs a few years
+change on the Gnus Git trunk and it goes into Emacs a few years
later... :-)
+
@end itemize
Of course in any case, if you just can't wait for me to sync your
For new customizable variables introduced in Oort Gnus (including the
v5-10 branch) use @code{:version "22.1" ;; Oort Gnus} (including the
-comment) or e.g. @code{:version "22.2" ;; Gnus 5.10.10} if the feature
+comment) or, e.g., @code{:version "22.2" ;; Gnus 5.10.10} if the feature
was added for Emacs 22.2 and Gnus 5.10.10.
@c
If the variable is new in No Gnus use @code{:version "23.1" ;; No Gnus}.
The same applies for customizable variables when its default value was
changed.
+@node GNU Free Documentation License
+@appendix GNU Free Documentation License
+@include doclicense.texi
+
@c Local Variables:
@c mode: texinfo
@c coding: iso-8859-1
@c End:
-
-@ignore
- arch-tag: ab15234c-2c8a-4cbd-8111-1811bcc6f931
-@end ignore
projects / gnus / blobdiff