Commit 1a231f20 authored by Glenn Morris's avatar Glenn Morris

* 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.
parent 940e6c28
Pipeline #926 passed with stage
in 59 minutes and 5 seconds
......@@ -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
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment