diff options
Diffstat (limited to 'doc/misc/gnus-coding.texi')
| -rw-r--r-- | doc/misc/gnus-coding.texi | 147 |
1 files changed, 0 insertions, 147 deletions
diff --git a/doc/misc/gnus-coding.texi b/doc/misc/gnus-coding.texi index f3e96a0cb63..6affea48724 100644 --- a/doc/misc/gnus-coding.texi +++ b/doc/misc/gnus-coding.texi @@ -227,153 +227,6 @@ ends (probably @file{nnml.el}, @file{nnfolder.el} and @c requires nnheader. -@section Compatibility - -No Gnus and Gnus 5.10.10 and up should work on: -@itemize @bullet -@item -Emacs 21.1 and up. -@item -XEmacs 21.4 and up. -@end itemize - -Gnus 5.10.8 and below should work on: -@itemize @bullet -@item -Emacs 20.7 and up. -@item -XEmacs 21.1 and up. -@end itemize - -@node Gnus Maintenance Guide -@chapter Gnus Maintenance Guide - -@section Stable and development versions - -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 - -@c Some MIDs related to this follow. Use http://thread.gmane.org/MID -@c (and click on the subject) to get the thread on Gmane. - -@c Some quotes from Miles Bader follow... - -@c <v9eklyke6b.fsf@marauder.physik.uni-ulm.de> -@c <buovfd71nkk.fsf@mctpc71.ucom.lsi.nec.co.jp> - -In the past, the inclusion of Gnus into Emacs was quite cumbersome. For -each change made to Gnus in Emacs repository, it had to be checked that -it was applied to the new Gnus version, too. Else, bug fixes done in -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. - -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 -trunk without worrying about lost changes from the Emacs tree. - -The effect of this is that as hacker, you should generally only have to -make changes in one place: - -@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 repository access (or it's inconvenient), you -can change such a file in the v5-10 branch, and it should propagate to -the Emacs repository---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 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 - -Of course in any case, if you just can't wait for me to sync your -change, you can commit it in more than one place and probably there will -be no problem; usually the changes are textually identical anyway, so -can be easily resolved automatically (sometimes I notice silly things in -such multiple commits, like whitespace differences, and unify those ;-). - - -@c I do Emacs->Gnus less often (than Gnus->Emacs) because it tends to -@c require more manual work. - -@c By default I sync about once a week. I also try to follow any Gnus -@c threads on the mailing lists and make sure any changes being discussed -@c are kept more up-to-date (so say 1-2 days delay for "topical" changes). - -@c <buovfd71nkk.fsf@mctpc71.ucom.lsi.nec.co.jp> - -@c BTW, just to add even more verbose explanation about the syncing thing: - -@section Miscellanea - -@heading Conventions for version information in defcustoms - -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 -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 |