all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Miles Bader <miles@lsi.nec.co.jp>
Cc: emacs-devel@gnu.org
Subject: Re: encrypt.el
Date: Tue, 19 Oct 2004 10:52:43 +0900	[thread overview]
Message-ID: <buovfd71nkk.fsf@mctpc71.ucom.lsi.nec.co.jp> (raw)
In-Reply-To: <buo1xfv339b.fsf@mctpc71.ucom.lsi.nec.co.jp> (Miles Bader's message of "Tue, 19 Oct 2004 10:28:32 +0900")

Miles Bader <miles@lsi.nec.co.jp> 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.

  reply	other threads:[~2004-10-19  1:52 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4n7jpu4o7d.fsf@lifelogs.com>
     [not found] ` <iluwtxtxis9.fsf@latte.josefsson.org>
2004-10-14 18:37   ` pop3.el itegration with netrc.el Ted Zlatanov
2004-10-14 18:56     ` Simon Josefsson
     [not found]   ` <v9mzypb0ea.fsf@marauder.physik.uni-ulm.de>
     [not found]     ` <iluhdoxxgwv.fsf@latte.josefsson.org>
     [not found]       ` <v94qkx9ix5.fsf@marauder.physik.uni-ulm.de>
     [not found]         ` <ilu8ya8yleo.fsf@latte.josefsson.org>
     [not found]           ` <4nis9baoz3.fsf@lifelogs.com>
     [not found]             ` <v93c0fq2ij.fsf@marauder.physik.uni-ulm.de>
2004-10-15 19:14               ` encrypt.el (was: pop3.el itegration with netrc.el) Ted Zlatanov
2004-10-15 19:41                 ` encrypt.el Simon Josefsson
2004-10-16 13:52                   ` encrypt.el Richard Stallman
2004-10-18 17:48                     ` encrypt.el Ted Zlatanov
2004-10-19  1:28                       ` encrypt.el Miles Bader
2004-10-19  1:52                         ` Miles Bader [this message]
2004-10-19 16:45                       ` encrypt.el Richard Stallman
2004-10-21 18:47                         ` encrypt.el Ted Zlatanov
2004-10-21 23:00                           ` encrypt.el Miles Bader
2004-10-21 23:05                             ` encrypt.el Miles Bader
2004-10-21 23:25                             ` encrypt.el Andreas Schwab
2004-10-22  0:35                               ` encrypt.el Miles Bader
2004-10-23  4:48                                 ` encrypt.el Richard Stallman
2004-10-23 10:44                                 ` encrypt.el Eli Zaretskii
2004-12-01 18:55                           ` encrypt.el Ted Zlatanov
2004-12-01 22:05                             ` encrypt.el Simon Josefsson
2004-12-01 22:12                             ` encrypt.el Reiner Steib
2004-12-02 16:36                               ` encrypt.el Ted Zlatanov
2004-12-02 20:56                                 ` encrypt.el Reiner Steib
2004-12-07 17:50                                 ` encrypt.el Ted Zlatanov
2004-12-07  4:24                             ` encrypt.el Richard Stallman
2004-12-07  9:42                               ` encrypt.el Kim F. Storm
2004-12-08  1:49                                 ` encrypt.el Miles Bader
2004-12-08  2:49                                   ` encrypt.el Kenichi Handa
2004-12-08  4:41                                 ` encrypt.el Richard Stallman
2004-12-03 19:45 encrypt.el Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=buovfd71nkk.fsf@mctpc71.ucom.lsi.nec.co.jp \
    --to=miles@lsi.nec.co.jp \
    --cc=emacs-devel@gnu.org \
    --cc=miles@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.