Re: encrypt.el

[Miles Bader]

Miles Bader <address@hidden> writes:
> However, you probably need Emacs CVS access anyway, because surely some
> Emacs files will use encrypt.el which aren't in the Gnus tree.

BTW, just to add even more verbose explanation about the syncing thing:

Basically my idea is that the Emacs-Gnus 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 "5.11", but the
v5-10 version string remains "5.10.whatever").  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
(typically so far the only exception has been that the changes already
exist in the trunk in modified form).  Because of this, when the next
Emacs Gnus upgrade comes, 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:

  1) If it's a file which is thought of as being outside of Gnus (e.g.,
     the new "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
     change such a file in the v5-10 branch, and it should propagate to
     Emacs CVS -- however, it will get some extra scrutiny (by me) 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.]

  2) If it's to a Gnus file, and it's important enough that it should be
     part of Emacs/v5-10, 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 later).

     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 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 _anyway_, it's often easier for me
     to resolve it simply if I see two "identical" changes, and can just
     choose the proper one, rather than having to actually fix the code.

  3) 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
     later... :-)

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 ;-).

-Miles
-- 
P.S.  All information contained in the above letter is false,
      for reasons of military security.