* Re: bug#5284: 23.1; gnus-summary-expire-thread does not work [not found] ` <mailman.7.1273778942.8369.bug-gnu-emacs@gnu.org> @ 2010-06-30 21:35 ` Ted Zlatanov 2010-06-30 21:46 ` synchronizing with Emacs, take two Ted Zlatanov 0 siblings, 1 reply; 9+ messages in thread From: Ted Zlatanov @ 2010-06-30 21:35 UTC (permalink / raw) Cc: Ding Mailing List 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* synchronizing with Emacs, take two 2010-06-30 21:35 ` bug#5284: 23.1; gnus-summary-expire-thread does not work Ted Zlatanov @ 2010-06-30 21:46 ` Ted Zlatanov 2010-07-01 2:11 ` Katsumi Yamaoka 0 siblings, 1 reply; 9+ messages in thread From: Ted Zlatanov @ 2010-06-30 21:46 UTC (permalink / raw) To: Ding Mailing List 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: synchronizing with Emacs, take two 2010-06-30 21:46 ` synchronizing with Emacs, take two Ted Zlatanov @ 2010-07-01 2:11 ` Katsumi Yamaoka 2010-07-01 2:34 ` Dave Goldberg 2010-07-01 13:59 ` Ted Zlatanov 0 siblings, 2 replies; 9+ messages in thread From: Katsumi Yamaoka @ 2010-07-01 2:11 UTC (permalink / raw) To: Ted Zlatanov; +Cc: ding 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). ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: synchronizing with Emacs, take two 2010-07-01 2:11 ` Katsumi Yamaoka @ 2010-07-01 2:34 ` Dave Goldberg 2010-07-01 13:59 ` Ted Zlatanov 1 sibling, 0 replies; 9+ messages in thread From: Dave Goldberg @ 2010-07-01 2:34 UTC (permalink / raw) To: ding > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: synchronizing with Emacs, take two 2010-07-01 2:11 ` Katsumi Yamaoka 2010-07-01 2:34 ` Dave Goldberg @ 2010-07-01 13:59 ` Ted Zlatanov 2010-07-02 3:57 ` Katsumi Yamaoka 1 sibling, 1 reply; 9+ messages in thread From: Ted Zlatanov @ 2010-07-01 13:59 UTC (permalink / raw) To: Katsumi Yamaoka; +Cc: ding 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: synchronizing with Emacs, take two 2010-07-01 13:59 ` Ted Zlatanov @ 2010-07-02 3:57 ` Katsumi Yamaoka 2010-07-04 22:26 ` Mike Kupfer 2010-08-12 20:50 ` Ted Zlatanov 0 siblings, 2 replies; 9+ messages in thread From: Katsumi Yamaoka @ 2010-07-02 3:57 UTC (permalink / raw) To: Ted Zlatanov; +Cc: ding 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: synchronizing with Emacs, take two 2010-07-02 3:57 ` Katsumi Yamaoka @ 2010-07-04 22:26 ` Mike Kupfer 2010-08-12 20:50 ` Ted Zlatanov 1 sibling, 0 replies; 9+ messages in thread From: Mike Kupfer @ 2010-07-04 22:26 UTC (permalink / raw) To: Katsumi Yamaoka; +Cc: Ted Zlatanov, ding 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) ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: synchronizing with Emacs, take two 2010-07-02 3:57 ` Katsumi Yamaoka 2010-07-04 22:26 ` Mike Kupfer @ 2010-08-12 20:50 ` Ted Zlatanov 2011-02-25 22:07 ` Ted Zlatanov 1 sibling, 1 reply; 9+ messages in thread From: Ted Zlatanov @ 2010-08-12 20:50 UTC (permalink / raw) To: ding 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: synchronizing with Emacs, take two 2010-08-12 20:50 ` Ted Zlatanov @ 2011-02-25 22:07 ` Ted Zlatanov 0 siblings, 0 replies; 9+ messages in thread From: Ted Zlatanov @ 2011-02-25 22:07 UTC (permalink / raw) To: ding 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" ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-02-25 22:07 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <m3zl51tzgl.fsf@fleche.redhat.com> [not found] ` <87zl07ynxi.fsf@gate450.dyndns.org> [not found] ` <mailman.7.1273778942.8369.bug-gnu-emacs@gnu.org> 2010-06-30 21:35 ` bug#5284: 23.1; gnus-summary-expire-thread does not work Ted Zlatanov 2010-06-30 21:46 ` synchronizing with Emacs, take two Ted Zlatanov 2010-07-01 2:11 ` Katsumi Yamaoka 2010-07-01 2:34 ` Dave Goldberg 2010-07-01 13:59 ` Ted Zlatanov 2010-07-02 3:57 ` Katsumi Yamaoka 2010-07-04 22:26 ` Mike Kupfer 2010-08-12 20:50 ` Ted Zlatanov 2011-02-25 22:07 ` Ted Zlatanov
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).