@syncodeindex pg cp
@copying
-Copyright (C) 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
+Copyright @copyright{} 2004, 2005, 2007, 2008, 2009, 2010 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.2 or
+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
@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
This manual describes @dots{}
+
+@insertcopying
+@end ifnottex
+
@menu
* Gnus Coding Style:: Gnus Coding Style
* Gnus Maintainance Guide:: Gnus Maintainance 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}
+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
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
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
conflict @emph{anyway}, it's often easier for me to resolve it simply if
@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
@c mode: texinfo
@c coding: iso-8859-1
@c End:
-
-@ignore
- arch-tag: ab15234c-2c8a-4cbd-8111-1811bcc6f931
-@end ignore
projects / gnus / blobdiff