[Emacs-diffs] master 1a231f2 5/5: * doc/misc/gnus-coding.texi: Remove no longer relevant sections.

[Glenn Morris]

branch: master
commit 1a231f202628fb9f092258ed1e3ad90364a07e02
Author: Glenn Morris <address@hidden>
Commit: Glenn Morris <address@hidden>

    * doc/misc/gnus-coding.texi: Remove no longer relevant sections.
    ; The whole remaining file is probably no longer relevant.
    ; It's just some basic info from 15 years ago.
---
 doc/misc/gnus-coding.texi | 147 ----------------------------------------------
 1 file changed, 147 deletions(-)

diff --git a/doc/misc/gnus-coding.texi b/doc/misc/gnus-coding.texi
index f3e96a0..6affea4 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.
 
 
address@hidden Compatibility
-
-No Gnus and Gnus 5.10.10 and up should work on:
address@hidden @bullet
address@hidden
-Emacs 21.1 and up.
address@hidden
-XEmacs 21.4 and up.
address@hidden itemize
-
-Gnus 5.10.8 and below should work on:
address@hidden @bullet
address@hidden
-Emacs 20.7 and up.
address@hidden
-XEmacs 21.1 and up.
address@hidden itemize
-
address@hidden Gnus Maintenance Guide
address@hidden Gnus Maintenance Guide
-
address@hidden 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.
-
address@hidden Syncing
-
address@hidden Some MIDs related to this follow.  Use 
http://thread.gmane.org/MID
address@hidden (and click on the subject) to get the thread on Gmane.
-
address@hidden Some quotes from Miles Bader follow...
-
address@hidden <address@hidden>
address@hidden <address@hidden>
-
-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.
-
address@hidden (typically so far the only exception has been that the changes
address@hidden 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:
-
address@hidden
address@hidden
-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.
-
address@hidden
-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.
-
address@hidden
-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... :-)
-
address@hidden 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 ;-).
-
-
address@hidden I do Emacs->Gnus less often (than Gnus->Emacs) because it tends 
to
address@hidden require more manual work.
-
address@hidden By default I sync about once a week.  I also try to follow any 
Gnus
address@hidden threads on the mailing lists and make sure any changes being 
discussed
address@hidden are kept more up-to-date (so say 1-2 days delay for "topical" 
changes).
-
address@hidden <address@hidden>
-
address@hidden BTW, just to add even more verbose explanation about the syncing 
thing:
-
address@hidden Miscellanea
-
address@hidden 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.
address@hidden
-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