Re: bug#5284: 23.1; gnus-summary-expire-thread does not work

Re: bug#5284: 23.1; gnus-summary-expire-thread does not work

[Ted Zlatanov]

The following message is a courtesy copy of an article
that has been posted to gnu.emacs.bug as well.

On Thu, 13 May 2010 15:20:20 -0400 Glenn Morris <rgm@gnu.org> wrote: 

GM> Andreas Seltenreich wrote:
>> I fixed this in the Gnus repository.  I'll leave this bug open till it
>> is merged into Emacs.

GM> I suggest that in future you just close things when they are fixed in
GM> Gnus. It is frequently merged to Emacs, and it seems more likely that
GM> a bug will get left open by mistake.

(CC to Gnus mailing list)

Maybe we should close the bug when the merge happens.  As long as
there's a consistent way to associate the bug with the commit message.

Ted

synchronizing with Emacs, take two

[Ted Zlatanov]

On Wed, 30 Jun 2010 16:35:35 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> Maybe we should close the bug when the merge happens.  As long as
TZ> there's a consistent way to associate the bug with the commit message.

On Thu, 01 Jul 2010 00:08:51 +0300 Eli Zaretskii <eliz@gnu.org> wrote: 

EZ> As long as you are committing to the Emacs repository many unrelated
EZ> changes, there really is no way of making the commit messages more
EZ> useful.  But at least in several cases, it looks like the committed
EZ> changes belong to a single changeset.  Examples:
...
EZ> For such changes, it would be more useful if the first line of the
EZ> commit message summarized the change, instead of saying just "Synch
EZ> with Gnus trunk".  That would allow to, e.g., find the merge which
EZ> introduced some specific change in Gnus by just looking at the output
EZ> of "bzr log --line", which shows only those first lines from the
EZ> commit messages.

>> I plan to eventually set up a more automatic synchronization method.

EZ> Thanks.  For that, I hope the original commit message would become the
EZ> commit message in the Bazaar repository.

I'm aggregating two threads here and limiting the discussion to just the
Ding list.

Yamaoka-san, how do you synchronize Gnus and Emacs?  Do you use a script
or do it manually?  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)

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

Ted

Re: synchronizing with Emacs, take two

[Katsumi Yamaoka]

Ted Zlatanov wrote:
[...]
> Yamaoka-san, how do you synchronize Gnus and Emacs?  Do you use
> a script or do it manually?

I use a sh script which does:

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

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

3. diff -aruN Gnus/ EmacsGnus/

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

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

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

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

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

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

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

Re: synchronizing with Emacs, take two

[Dave Goldberg]

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

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

Thanks,
-- 
Dave Goldberg
david.goldberg6@verizon.net

Re: synchronizing with Emacs, take two

[Ted Zlatanov]

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

Re: synchronizing with Emacs, take two

[Katsumi Yamaoka]

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.

Re: synchronizing with Emacs, take two

[Mike Kupfer]

Katsumi Yamaoka wrote:

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

Hi, we haven't updated to 5.10.10 because it's GPLv3, and we've been
avoiding GPLv3 code until we can move XEmacs as a whole to GPLv3.  My
understanding is that there's not much work left before that can happen,
but it hasn't happened yet.

cheers,
mike
(XEmacs' Gnus maintainer)

Re: synchronizing with Emacs, take two

[Ted Zlatanov]

On Fri, 02 Jul 2010 12:57:32 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote: 

KY> Ted Zlatanov wrote:
>> 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.

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

I think it's reasonable.  It should look nice in this format:

git log --oneline

e.g.

...
77a9b0f Minor bug fixes for gnus-sync.el.
2a6fa29 Make saving and restoring of hidden threads work with overlays. Patch applied by Ted Zlatanov.
e1bba25 Add new gnus-sync.el library.
...

That's very handy when you're reviewing changes.

Ted

Re: synchronizing with Emacs, take two

[Ted Zlatanov]

On Thu, 12 Aug 2010 15:50:05 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Fri, 02 Jul 2010 12:57:32 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote: 
KY> Ted Zlatanov wrote:
>>> 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.

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

TZ> I think it's reasonable.  It should look nice in this format:

TZ> git log --oneline

TZ> e.g.

TZ> ...
TZ> 77a9b0f Minor bug fixes for gnus-sync.el.
TZ> 2a6fa29 Make saving and restoring of hidden threads work with overlays. Patch applied by Ted Zlatanov.
TZ> e1bba25 Add new gnus-sync.el library.
TZ> ...

TZ> That's very handy when you're reviewing changes.

I wanted to give my .gitconfig file in case anyone finds it useful.  The
lg and lg2 aliases in particular can make life easier.  I've collected
them from many places so I can't give credit where it's due.

Ted

[color]
	diff = auto
	status = auto
	branch = auto
	interactive = auto

[alias]
	st = status
	ci = commit
	co = checkout
	staged = "diff --cached"
	unstaged = diff
	both = "diff HEAD"
	oneline = "log --pretty=oneline"
	amend = "commit --ammend"
	am = "commit --ammend"
        lg = "log --graph --all --pretty=format:'%Cred%h%Creset - %Cgreen(%cr)%Creset %s%C(yellow)%d%Creset' --abbrev-commit --date=relative"
        lg2 = "log --oneline --date-order --graph --all --decorate"
	l = pull
	h = push
	hard = "reset --hard HEAD"
	r = "reset HEAD"
        ca = "commit -a"
        aa = "add -A"