* 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.
This commit is contained in:
Glenn Morris
parent
940e6c2872
commit
1a231f2026
1 changed files with 0 additions and 147 deletions
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue