Re: synchronizing with Emacs, take two

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 01 Jul 2010 11:11:29 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote: 

KY> I use a sh script which does:

KY> 1. Rearrange the files of Emacs into the directory structure that
KY>    is the same as Gnus.  For instance, gather lisp/mail/binhex.el,
KY>    lisp/textmodes/dns-mode.el, etc. to lisp/; gather doc/misc/*.texi,
KY>    etc/refcards/gnus-refcard.tex, etc. to texi/, etc.

OK.  This is the part I plan to do semi-automatically with Bazaar-Git
synchronization, which will track the files added or deleted on both
sides.

KY> 2. Apply the offset patch file to the gathered Emacs files.  It
KY>    changes gnus-version-number, the default values of some user
KY>    options (mainly in message.el), etc.

OK.  Do you want me to look at your script and patch or write a whole
new set?  Do you want to keep synchronizing the two trees or would you
rather make it a shared responsibility?  I certainly don't mind if you
do it.

KY> 3. diff -aruN Gnus/ EmacsGnus/

KY> Normally it reports there's no difference.  When it alerts, I check
KY> if new comers work with Emacs 21~24, XEmacs 21.4/5, and SXEmacs 22.1.
KY> And modify changes manually if needed, apply changes from one to
KY> another manually, then commit them to Gnus, Emacs, or both.  I have
KY> no idea for a way to make those manual works automated.

A buildbot setup can do it.  I am discussing such a setup for the Emacs
repo so it wouldn't be too much extra work to do it for Gnus as well.

>> I'd like to help with the process (and automate it, as previously
>> discussed) while adding these two features:

>> - for a single change, make the commit message the same as the change's
>> commit message (with a prefix to indicate it's a synch)

KY> To make it worthwhile, we will need to improve commit messages so
KY> as to say what they are for briefly in a single line.  Easier said
KY> than done, though.  Anyway we should not use the ones such as the
KY> following, that's just a copy of ChangeLog:

KY> commit 08dd9f431367713667b1124e633c2ff97697a390
KY> Author: Katsumi Yamaoka <yamaoka@jpl.org>
KY> Date:   Thu Jun 10 05:32:19 2010 +0000

KY>     (gnus-mime-buttonized-part-id): New internal variable.
KY>     (gnus-article-edit-part): Bind it to make last part that is substituted
KY>      or deleted visible.
KY>     (gnus-mime-display-single): Buttonize part of which id equals to
KY>      gnus-mime-buttonized-part-id.

I think the synchronizer (you or whoever does the process) should write
the one-line abstract if the comitter doesn't.  Let's keep the long
format we already have for commit messages but put the one-line abstract
on the very first line.  So the above commit would be:

"Buttonize part of the ID.

 (gnus-mime-buttonized-part-id): New internal variable.
 (gnus-article-edit-part): Bind it to make last part that is substituted
                            or deleted visible.
 (gnus-mime-display-single): Buttonize part of which id equals to
                             gnus-mime-buttonized-part-id."

Then the Bazaar commit message can be just that first line.  If there's
no newline after the first line in our commit message, we'll know the
comitter didn't provide a one-line summary.

>> - close bugs when they are mentioned in the commit message

>> I'd like this to be as automatic as possible, but never do a push
>> automatically.  So it can't happen on every commit.

You didn't say yes or no; can I assume you're OK with this
responsibility placed on the synchronizer?

On Wed, 30 Jun 2010 22:34:55 -0400 Dave Goldberg <david.goldberg6@verizon.net> wrote: 

>> BTW, is `No Gnus' really necessary?  Though I've been maintaining
>> it so as to work with various version of Emacsen, I don't know
>> whether there are really a lot of people who use it.  People who
>> want the most recent Gnus can upgrade Emacs (if needed, even to
>> use the Emacs head is not so troublesome).  The only point may be
>> that the Gnus XEmacs package is very old (it is now Gnus 5.10.8).

DG> It is for this XEmacs user, for the exact reason you mention.  Of
DG> course I don't care whether you continue to call in No Gnus or turn it
DG> into some other naming scheme if that makes it easier for the
DG> maintainers.  I do take advantage of several of the features, SMIME
DG> related in particular, that are not available in the older versions.

I think the current situation works for everyone.  This is a question
for Reiner, really, but I don't know if he's available and if he wants
to continue doing Gnus releases and maintenance.

Ted