X-Git-Url: http://cgit.sxemacs.org/?a=blobdiff_plain;f=texi%2Fgnus-coding.texi;h=f513bc15a24dcf74fabc24e2bb0649f7136c1bfd;hb=8a072414637ed82f77a7ee7d726570a9a2fa52cb;hp=a1ab6851fa684bb31401b42ec3aa296014d74329;hpb=747aac245cdb9c4809ea677eea4a7e53eca1a288;p=gnus diff --git a/texi/gnus-coding.texi b/texi/gnus-coding.texi index a1ab6851f..f513bc15a 100644 --- a/texi/gnus-coding.texi +++ b/texi/gnus-coding.texi @@ -7,20 +7,21 @@ @syncodeindex pg cp @copying -Copyright (c) 2004, 2005, 2007 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.1 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 license is included in the section entitled ``GNU Free Documentation -License'' in the Emacs manual. +License'' in the Gnus manual. -(a) The FSF's Back-Cover Text is: ``You have freedom to copy and modify -this GNU Manual, like GNU software. Copies published by the Free -Software Foundation raise funds for GNU development.'' +(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 @@ -31,20 +32,25 @@ license to the document, as described in section 6 of the license. @titlepage -@title Gnus Coding Style and Maintainance Guide +@title Gnus Coding Style and Maintenance Guide @author by Reiner Steib @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 @@ -76,6 +82,10 @@ Functions for formatting arbitrary formatting strings. @c As of 2005-10-21... There are no Gnus dependencies in this file. +@item hex-util.el +Functions to encode/decode hexadecimal string. +@c As of 2007-08-25... +There are no Gnus dependencies in these files. @end table @subsection Encryption and security @@ -105,11 +115,6 @@ There are no Gnus dependencies in these files. SHA1 Secure Hash Algorithm. @c As of 2007-08-25... There are no Gnus dependencies in these files. - -@item hex-util.el -Functions to encode/decode hexadecimal string. -@c As of 2007-08-25... -There are no Gnus dependencies in these files. @end table @subsection Networking @@ -202,7 +207,10 @@ There are no Gnus dependencies in these files. All message composition from Gnus (both mail and news) takes place in Message mode buffers. Message mode is intended to be a replacement for Emacs mail mode. There should be no Gnus dependencies in -@file{message.el}. +@file{message.el}. Alas it is not anymore. Patches and suggestions to +remove the dependencies are welcome. + +@c message.el requires nnheader which requires gnus-util. @subsection Emacs @acronym{MIME} @@ -247,15 +255,17 @@ XEmacs 21.1 and up. @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.7, @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 @@ -278,14 +288,21 @@ Emacs repository might have been lost. 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 @@ -301,9 +318,9 @@ 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 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. @@ -311,12 +328,12 @@ 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 @@ -325,8 +342,9 @@ 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 @@ -364,7 +382,7 @@ 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 was added for Emacs 22.2 and Gnus 5.10.10. @c -If the variable is new in No Gnus use @code{:version "23.0" ;; No Gnus}. +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. @@ -373,7 +391,3 @@ changed. @c mode: texinfo @c coding: iso-8859-1 @c End: - -@ignore - arch-tag: ab15234c-2c8a-4cbd-8111-1811bcc6f931 -@end ignore