Re: synchronizing with Emacs, take two

[Katsumi Yamaoka <yamaoka@jpl.org>]

Ted Zlatanov wrote:
[...]
> OK.  Do you want me to look at your script and patch or write a whole
> new set?

A minimal function the script provides is so-so for me, but another
good approach if any is welcome.  The script `gnus-diff' and the
offset patch `Gnus-diff' (I use it as ~/.Gnus-diff actually) are
now in: ftp://ftp.jpl.org/pub/tmp/ or http://www.jpl.org/ftp/pub/tmp/

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

I hope the synchronization is being done by any person who has a
write access.  It never disturbs that of me.  I'm familiar with
only some Gnus features and XEmacs coding, but not good at imap,
maildir, and many others.  So, it will probably be hard to me even
to abstract into a single line statement what people did.  The best
will be that those who change Gnus commit changes to both repos.

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.

That's wonderful if achieved.  It might be needless that I
considered the integration of two Gnus repos (i.e. abolishing
No Gnus).

>>> 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>     (gnus-mime-buttonized-part-id): New internal variable.
[...]

> 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.
[...]

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

Oh, I see.  I learned that that empty line is significant.

>>> - 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?

OK, of course.

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

>>> BTW, is `No Gnus' really necessary?
[...]

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 keep it in mind that No Gnus is indispensable at least to
sophisticated XEmacs users.  I wonder why the XEmacs team don't
update the package, though.

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