Gnus development mailing list
 help / color / mirror / Atom feed
From: "Miles Bader" <miles@gnu.org>
To: "Reiner Steib" <reiner.steib@gmx.de>
Cc: "Lars Magne Ingebrigtsen" <larsi@gnus.org>, "Ding List" <ding@gnus.org>
Subject: Re: etc/refcards/ and new-style backquotes (was: Gnus and GPLv3)
Date: Thu, 30 Aug 2007 11:25:33 +0900	[thread overview]
Message-ID: <fc339e4a0708291925u5f51fdfen1985b49097d6492@mail.gmail.com> (raw)
In-Reply-To: <v9lkbwacga.fsf@marauder.physik.uni-ulm.de>

On 8/28/07, Reiner Steib <reiner.steib@gmx.de> wrote:
> > and the refcards getting moved into etc/refcards (I don't know if
> > this move is desirable for Gnus; if not, then just move them back,
> > but if so, I guess the Makefiles etc will need adjusting?).  As this
> > is the 5.10 branch, people might want to keep an eye out for
> > problems.
>
> Hm, the etc/ reorganization is only in Emacs trunk, isn't it.  Did you
> sync from Emacs/trunk to Gnus/v5-10?

Yeah, though only because this is what I've always done.  Now that you
mention it, I guess that creates an inadvertent back-channel from the
emacs-trunk to the emacs-rel-22 branch, which probably isn't a good
thing.

[The gnus relevant merges I do are:

  gnus-5.10 -> emacs-rel-22
  emacs-trunk -> gnus-5.10
  gnus-5.10 -> gnus-trunk
  emacs-rel-22 -> emacs-trunk
]

So... I suppose that it would be better to only sync changes from the
emacs-rel-22 emacs branch to the gnus-5.10 branch?  Or alternatively,
it could be decided that the gnus-5.10 branch should be linked with
the emacs trunk instead of the rel-22 branch.  [I _tentatively_ favor
the latter, as it's always seemed to me that the changes to the 5.10
branch are sometimes a wee bit aggressive considering it's a release
branch.]

If it's decided to keep the 5.10 branch associated with the emacs
rel-22 branch, I'd favor reverting the changes mentioned previously
which aren't on the emacs rel-22 branch.

However if that's decided, there will be no merge channel from the
emacs trunk to gnus, which is not good I think.  In that case, I could
start merging from the emacs-trunk to the gnus-trunk ... but with
multiple merge channels between emacs and gnus, things are starting to
get a bit hairy.... I'm not sure how well it would work out in
practice.

What do people think?

Thanks,

-Miles

-- 
Do not taunt Happy Fun Ball.



       reply	other threads:[~2007-08-30  2:25 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <v96433px8i.fsf@marauder.physik.uni-ulm.de>
     [not found] ` <fc339e4a0708262100w957c4b3l5304f0ec34a63009@mail.gmail.com>
     [not found]   ` <v9lkbwacga.fsf@marauder.physik.uni-ulm.de>
2007-08-30  2:25     ` Miles Bader [this message]
2007-08-30 19:51       ` Leo
2007-08-31  1:42         ` etc/refcards/ and new-style backquotes Miles Bader
2007-08-31  6:39           ` Leo
2007-08-31  7:36             ` Miles Bader
2007-08-30 23:07       ` Reiner Steib
2007-08-30 23:16       ` Reiner Steib
2007-08-31  1:54         ` Miles Bader

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=fc339e4a0708291925u5f51fdfen1985b49097d6492@mail.gmail.com \
    --to=miles@gnu.org \
    --cc=ding@gnus.org \
    --cc=larsi@gnus.org \
    --cc=reiner.steib@gmx.de \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).