* bug tracking @ 2010-04-22 15:47 Jameson Rollins 2010-04-22 17:37 ` David Bremner 0 siblings, 1 reply; 14+ messages in thread From: Jameson Rollins @ 2010-04-22 15:47 UTC (permalink / raw) To: Notmuch Mail [-- Attachment #1: Type: text/plain, Size: 670 bytes --] I now think it is essential that we put together a bug tracker for notmuch. Things are moving pretty quickly now, which is great, but as the UI is frequently changing, I'm stumbling upon lots of little bugs. As I don't have the time to stop what I'm doing and figure out patches for them all, we really need some way to report and track issues. I really think this is essential moving forward. I have used things like trac and redmine in the past and they work quite well. I don't have any other useful suggestions. One of the newfangled git-based distributed bug trackers could be cool, but I've never used one, or gotten any feedback from anyone who has. jamie. [-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug tracking 2010-04-22 15:47 bug tracking Jameson Rollins @ 2010-04-22 17:37 ` David Bremner 2010-04-26 18:31 ` Carl Worth 0 siblings, 1 reply; 14+ messages in thread From: David Bremner @ 2010-04-22 17:37 UTC (permalink / raw) To: Jameson Rollins, Notmuch Mail On Thu, 22 Apr 2010 11:47:13 -0400, Jameson Rollins <jrollins@finestructure.net> wrote: > I now think it is essential that we put together a bug tracker for > notmuch. Things are moving pretty quickly now, which is great, but as > the UI is frequently changing, I'm stumbling upon lots of little bugs. > As I don't have the time to stop what I'm doing and figure out patches > for them all, we really need some way to report and track issues. I > really think this is essential moving forward. > > I have used things like trac and redmine in the past and they work quite > well. I don't have any other useful suggestions. One of the newfangled > git-based distributed bug trackers could be cool, but I've never used > one, or gotten any feedback from anyone who has. > It was thinking along these lines that got me to make the following list http://www.cs.unb.ca/~bremner/blog/posts/git-issue-trackers/ If people think the general concept of a distributed bug tracker is worthwhile, I'm willing to investigate a more. Feel free to cc bremner-comment-blog~posts~git-issue-trackers@pivot.cs.unb.ca If you have comments about distributed bug trackers; this semi-automatically gets added to the comments page. So far, a few Debian people have endorsed "simple defects". d ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug tracking 2010-04-22 17:37 ` David Bremner @ 2010-04-26 18:31 ` Carl Worth 2010-04-26 18:42 ` Arvid Picciani 2010-04-28 12:58 ` Jameson Rollins 0 siblings, 2 replies; 14+ messages in thread From: Carl Worth @ 2010-04-26 18:31 UTC (permalink / raw) To: David Bremner, Jameson Rollins, Notmuch Mail [-- Attachment #1: Type: text/plain, Size: 2062 bytes --] On Thu, 22 Apr 2010 14:37:26 -0300, David Bremner <bremner@unb.ca> wrote: > It was thinking along these lines that got me to make the following list > > http://www.cs.unb.ca/~bremner/blog/posts/git-issue-trackers/ I'm not sure what it is you think of as a "git-based issue tracker". Or rather, I'm not sure if we have the same ideas about what would make a git-based issue tracker interesting. > If people think the general concept of a distributed bug tracker is > worthwhile, I'm willing to investigate a more. Feel free to cc For me, having an issue tracker be git-based might help with what really matters, but wouldn't necessarily. One realization is that since we have distributed code, we necessarily have distributed bug state. (The bugs that exist in my repository are distinct from the bugs that exist in your repository.) So if bug state can follow the way code moves, then that is interesting. For example, if dme commits a fix and marks "issue #217 closed" with that fix, then I'd like my repository of bugs to also know to close that issue when I later merge his fix. To me, that's really a user-interface issue, more than a storage issue. I don't care if the issue tracker stores its state in a git database. But I do care that it be able to watch what we are already doing, (creating git commits and sharing them), in order for us to easily track state. It seems to me that almost all issues of interest are already raised on this mailing list, and later followed up with a message from me, (along the lines of "thanks, this is pushed"). So I'd be happy with a system that relied on an email interface as well. What I don't want is something that would make me go push buttons in a web form in addition to the "git push" and sending of email that I'm already doing. My primary metric for adopting a new issue tracker is "how little extra work will I have to do to use this compared to what I'm already doing?". That's a lot more important to me than how the system stores its data. -Carl [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug tracking 2010-04-26 18:31 ` Carl Worth @ 2010-04-26 18:42 ` Arvid Picciani 2010-04-28 12:58 ` Jameson Rollins 1 sibling, 0 replies; 14+ messages in thread From: Arvid Picciani @ 2010-04-26 18:42 UTC (permalink / raw) To: Carl Worth, David Bremner, Jameson Rollins, Notmuch Mail On Mon, 26 Apr 2010 11:31:05 -0700, Carl Worth <cworth@cworth.org> wrote: > For example, if dme commits a fix and marks "issue #217 closed" with > that fix, then I'd like my repository of bugs to also know to close that > issue when I later merge his fix. bitbucket does that, and i would bet its quite a common feature on the large git hosters too. -- Arvid ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug tracking 2010-04-26 18:31 ` Carl Worth 2010-04-26 18:42 ` Arvid Picciani @ 2010-04-28 12:58 ` Jameson Rollins 2010-04-28 14:34 ` David Bremner 2010-05-03 19:06 ` Carl Worth 1 sibling, 2 replies; 14+ messages in thread From: Jameson Rollins @ 2010-04-28 12:58 UTC (permalink / raw) To: Carl Worth, David Bremner, Notmuch Mail [-- Attachment #1: Type: text/plain, Size: 2323 bytes --] Hi, Carl. Thanks for the reply on this issue. Please permit me counter with a couple points. On Mon, 26 Apr 2010 11:31:05 -0700, Carl Worth <cworth@cworth.org> wrote: > It seems to me that almost all issues of interest are already raised on > this mailing list, and later followed up with a message from me, (along > the lines of "thanks, this is pushed"). So I'd be happy with a system > that relied on an email interface as well. Issues are raised on the mailing list, because there's no where else to raise them (other than irc, where they're not actually logged). But there's currently no way to track issues. We can't tell if they've been dealt with, and we have no way of browsing through them. Folks who send issues to the list have no feedback that their issue has even been acknowledged. Saying that issues sent to the list are usually followed by a "thanks, pushed" implies that only issues that include patches are acknowledged. While I certainly appreciate that this is a Free software project and that users should be encouraged to contribute, I don't think it's wise to imply that "only issues with patches will be acknowledged". I think that all users should be encouraged to report issues, even those that are not capable or currently able to supply patches. > What I don't want is something that would make me go push buttons in a > web form in addition to the "git push" and sending of email that I'm > already doing. I agree that purely web-based solutions are crappy. But many now include email interfaces as well. In any event, this is why I was suggesting one of the new distributed issue trackers that can live inside the repo of the source code and integrate well with our/your current workflow. I just haven't used any of them to be able to vouch for them. > My primary metric for adopting a new issue tracker is "how little extra > work will I have to do to use this compared to what I'm already > doing?". That's a lot more important to me than how the system stores > its data. I don't think I agree that that's the right question to ask. We're currently not tracking issues at, particularly ones not accompanied by patches, so I claim that we have to do something different. Doing nothing at all leaves us with a continued problem. Anyway, thanks for the discussion. jamie. [-- Attachment #2: Type: application/pgp-signature, Size: 835 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug tracking 2010-04-28 12:58 ` Jameson Rollins @ 2010-04-28 14:34 ` David Bremner 2010-04-29 17:48 ` Servilio Afre Puentes 2010-05-03 19:06 ` Carl Worth 1 sibling, 1 reply; 14+ messages in thread From: David Bremner @ 2010-04-28 14:34 UTC (permalink / raw) To: Jameson Rollins; +Cc: notmuch On Wed, 28 Apr 2010 08:58:13 -0400, Jameson Rollins <jrollins@finestructure.net> wrote: > > Saying that issues sent to the list are usually followed by a "thanks, > pushed" implies that only issues that include patches are acknowledged. > While I certainly appreciate that this is a Free software project and > that users should be encouraged to contribute, I don't think it's wise > to imply that "only issues with patches will be acknowledged". I think > that all users should be encouraged to report issues, even those that > are not capable or currently able to supply patches. > Meanwhile Jesse Rosenthal and I started chatting about, and Jesse started implementing, some tools for grabbing remote collections of tags and merging them into their own namespace. This may give us a notmuch-oriented way of managing the mailing list a bit better as a kind of bug tracker. I don't want to promise things on Jesse's behalf, but I personally am holding off on further bug tracker experiments until I see how this works out. d ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug tracking 2010-04-28 14:34 ` David Bremner @ 2010-04-29 17:48 ` Servilio Afre Puentes 2010-04-29 20:01 ` Mark Anderson 0 siblings, 1 reply; 14+ messages in thread From: Servilio Afre Puentes @ 2010-04-29 17:48 UTC (permalink / raw) To: David Bremner; +Cc: notmuch On 28 April 2010 16:34, David Bremner <bremner@unb.ca> wrote: [...] > Meanwhile Jesse Rosenthal and I started chatting about, and Jesse > started implementing, some tools for grabbing remote collections of tags > and merging them into their own namespace. This may give us a > notmuch-oriented way of managing the mailing list a bit better as a kind > of bug tracker. I don't want to promise things on Jesse's behalf, but I > personally am holding off on further bug tracker experiments until I see > how this works out. I have been playing in my head with the idea of using notmuch to track bugs, thinking of ways it could be done. Using tags and searches this should be fine, and even (if not right now, I am sure in the future we will) easily see what bugs have patches/pull requests proposed[1]. While reading your message, David, I think I've found and idea might enable this: enabling the dump command to accept a search term. With this in place, our bug database can be composed of the mail archive + a dump of the tags used for bug management. There another wrinkle with this approach, but a solvable one I think: the current implementation of the restore command will wipe all local state for the related messages. This is really bad for people tracking individually bugs/features in their local notmuch databases, e.g.: using tags such as TODO, REVIEW, etc. But with a way of non-destructively applying a set of tags to a messages we could have a distributed issue/feature/etc tracking system that is 100% notmuch-based and message driven (PR for the feature, we have to think forward!). IMHO this will allow for totally awesome workflows. And we should name it "notmuch issues" or "notmuch bugs". Servilio [1] I like pull request because they are easier to manage: you don't need to resend the patch series when you need to update your work. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug tracking 2010-04-29 17:48 ` Servilio Afre Puentes @ 2010-04-29 20:01 ` Mark Anderson 2010-05-03 19:44 ` Jesse Rosenthal 0 siblings, 1 reply; 14+ messages in thread From: Mark Anderson @ 2010-04-29 20:01 UTC (permalink / raw) To: Servilio Afre Puentes, David Bremner; +Cc: notmuch@notmuchmail.org On Thu, 29 Apr 2010 12:48:38 -0500, Servilio Afre Puentes <servilio@gmail.com> wrote: > On 28 April 2010 16:34, David Bremner <bremner@unb.ca> wrote: > [...] > > Meanwhile Jesse Rosenthal and I started chatting about, and Jesse > > started implementing, some tools for grabbing remote collections of tags > > and merging them into their own namespace. This may give us a > > notmuch-oriented way of managing the mailing list a bit better as a kind > > of bug tracker. I don't want to promise things on Jesse's behalf, but I > > personally am holding off on further bug tracker experiments until I see > > how this works out. > > I have been playing in my head with the idea of using notmuch to track > bugs, thinking of ways it could be done. Using tags and searches this > should be fine, and even (if not right now, I am sure in the future we > will) easily see what bugs have patches/pull requests proposed[1]. > > While reading your message, David, I think I've found and idea might > enable this: enabling the dump command to accept a search term. With > this in place, our bug database can be composed of the mail archive + > a dump of the tags used for bug management. > > There another wrinkle with this approach, but a solvable one I think: > the current implementation of the restore command will wipe all local > state for the related messages. This is really bad for people tracking > individually bugs/features in their local notmuch databases, e.g.: > using tags such as TODO, REVIEW, etc. > > But with a way of non-destructively applying a set of tags to a > messages we could have a distributed issue/feature/etc tracking system > that is 100% notmuch-based and message driven (PR for the feature, we > have to think forward!). > > IMHO this will allow for totally awesome workflows. > > And we should name it "notmuch issues" or "notmuch bugs". > > Servilio Wouldn't it be good to have a timestamp associated with the application of a tag, especially if you're going to manage a bug workflow with tags? You'll be going cross geography, so UTC sounds nice. But what happens if a bug goes from OPEN->CLOSED->REOPENED->CLOSED->..., can you track that state with a simple tag cloud? How would you handle conflicts for the bug tracker? Suppose two people close the bug in different ways, and one fix goes through several state switches before being committed to a globally visible repository. Does this really work with distributed development? Although a permutation of that question might be: What does a distributed bug tracker look like? You will have multiple bug DB's in different states, so do we default to having a tie-breaker "master" DB designated by the community? Distributed bug tracking - I'm certain it means different things to different people, perhaps we ought to specify what it means with a bit more clarity before jumping off and developing it. Nah, too much central control, just develop what you want, we'll bend it and the conversation about what it means until they fit. ;} Enjoy, -Mark ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug tracking 2010-04-29 20:01 ` Mark Anderson @ 2010-05-03 19:44 ` Jesse Rosenthal 0 siblings, 0 replies; 14+ messages in thread From: Jesse Rosenthal @ 2010-05-03 19:44 UTC (permalink / raw) To: Mark Anderson, Servilio Afre Puentes, David Bremner Cc: notmuch@notmuchmail.org Just a response to some of Mark's points, re. the very rough prototype I mentioned in another email in this thread: id:m1k4rkkchy.fsf@watt.gilman.jhu.edu All of my answers are based on my current implementation, and don't necessarily reflect the best possible way to address these problems. On Thu, 29 Apr 2010 14:01:59 -0600, Mark Anderson <MarkR.Anderson@amd.com> wrote > Wouldn't it be good to have a timestamp associated with the application > of a tag, especially if you're going to manage a bug workflow with > tags? I sort of fake this by having timestamps come with pushing. Of course then it doesn't reflect the time of the tagging, but the time of the pushing. But if there were an internal db timestamp on the tag, that might be even better. > You'll be going cross geography, so UTC sounds nice. Yeah, I should change it to that. > But what happens if a bug goes from OPEN->CLOSED->REOPENED->CLOSED->..., > can you track that state with a simple tag cloud? Depends if you push in intermediate states. It will be recorded as prefaced with a + or - depending. See the link I give to a sample public log in the announcement email. The file that you push to/pull from will thus have a whole history for each tag in the namespace. Note that it will be "reduced" before being applied to your current db, when you pull. > How would you handle conflicts for the bug tracker? Suppose two people > close the bug in different ways, and one fix goes through several state > switches before being committed to a globally visible repository. The tag would only be in your inbox in its latest state. (See above about "reducing" before applying.) But you can see the history for any msg-id. > Does this really work with distributed development? No idea. Worth a try. Best, Jesse ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug tracking 2010-04-28 12:58 ` Jameson Rollins 2010-04-28 14:34 ` David Bremner @ 2010-05-03 19:06 ` Carl Worth 2010-05-03 19:32 ` Jesse Rosenthal 1 sibling, 1 reply; 14+ messages in thread From: Carl Worth @ 2010-05-03 19:06 UTC (permalink / raw) To: Jameson Rollins, David Bremner, Notmuch Mail [-- Attachment #1: Type: text/plain, Size: 3460 bytes --] On Wed, 28 Apr 2010 08:58:13 -0400, Jameson Rollins <jrollins@finestructure.net> wrote: > Issues are raised on the mailing list, because there's no where else to > raise them (other than irc, where they're not actually logged). But > there's currently no way to track issues. We can't tell if they've been > dealt with, and we have no way of browsing through them. Folks who send > issues to the list have no feedback that their issue has even been > acknowledged. Right. I agree with all of these points. I wasn't trying to claim that what we are currently doing is sufficient. What I was trying to say is that our new "bug tracking system" (which I agree that we do need) would ideally involve as little change to my workflow as possible. Here's a rough sketch along the lines of something that I would like: 1. Particular messages could be tagged as indicating a bug. I can do this for my own private use now, but we need better visibility of that. Such as publication of "unresolved bugs" to a web page. 2. Users could indicate that an email they are sending indicates a bug. Perhaps an extra header would cause the mail to automatically acquire a tag when I incorporated it. 3. I could tag bug messages as "resolved" or "invalid" or whatever. Again, as in (1) for this to be useful we need a new way for users to get visibility to these tag manipulations. And I'd also like to have some associations between git commits and bug resolution. It looks to me like the ability to share tags, (and then the ability to turn a notmuch search into a web page) would go a long way toward giving us a "bug tracker". Since we already want both of those features *anyway* I think we should definitely pursue this. In the meantime, if people want to explore existing bug trackers, I would be fine with adopting something sane. > Saying that issues sent to the list are usually followed by a "thanks, > pushed" implies that only issues that include patches are acknowledged. > While I certainly appreciate that this is a Free software project and > that users should be encouraged to contribute, I don't think it's wise > to imply that "only issues with patches will be acknowledged". I think > that all users should be encouraged to report issues, even those that > are not capable or currently able to supply patches. You're absolutely right. I wasn't trying to imply that. I just meant that I'm already following up via email on any reported issue. This could be "I've committed a fix for this bug" just as much as "I've committed your patch". > > My primary metric for adopting a new issue tracker is "how little extra > > work will I have to do to use this compared to what I'm already > > doing?". That's a lot more important to me than how the system stores > > its data. > > I don't think I agree that that's the right question to ask. We're > currently not tracking issues at, particularly ones not accompanied by > patches, so I claim that we have to do something different. Doing > nothing at all leaves us with a continued problem. But I *am* tracking things. The only real problems are: 1. People don't have visibility into my tracking efforts 2. We can't collaborate on the tracking efforts. So I think the various tag-sharing prototypes being worked on right now are extremely interesting. -Carl [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug tracking 2010-05-03 19:06 ` Carl Worth @ 2010-05-03 19:32 ` Jesse Rosenthal 2011-01-13 14:43 ` Thomas Schwinge 0 siblings, 1 reply; 14+ messages in thread From: Jesse Rosenthal @ 2010-05-03 19:32 UTC (permalink / raw) To: Carl Worth, Jameson Rollins, David Bremner, Notmuch Mail On Mon, 03 May 2010 12:06:04 -0700, Carl Worth <cworth@cworth.org> wrote: > But I *am* tracking things. The only real problems are: > > 1. People don't have visibility into my tracking efforts > > 2. We can't collaborate on the tracking efforts. > > So I think the various tag-sharing prototypes being worked on right now > are extremely interesting. Well, this is as good a time to make an announcement as any. I have a prototype, nm-remote, in its early stages available here: git clone http://jkr.acm.jhu.edu/git/nm-remote.git It requires the notmuch python bindings. You should be able to just run it from its directory. Right now, nm-remote has 4 subcommands: `add', `push', `pull', `history'. 1) `nm-remote add --(src|dest) <name> <path>': "name" is the namespace you give to a certain source (for pulling) or destination (for pushing). The path can either be a file path or, for pulling, a http url. Note that this alters ~/.notmuch-config. It will write a backup of your original file, just in case. 2) `nm-remote push <name>', `nm-remote push <name> <file>' This will push all tags under the "name" namespace to the file you have set in you have set in your config file by `add --dest' (or by hand). If you specify the file here, it will not check the config file. The tags it writes to the file will be all those under the namespace "name". So if Carl keeps some tags under "public.bug", "public.queue", etc, it will write those to a file, without the namespace. The file format will keep track of bugs both added and removed for message ids, the time they were added, and by whom. See here for an example: http://jkr.acm.jhu.edu/practice.tags I'd like to add the ability to push over ssh. 3) `nm-remote pull <name>', `nm-remote pull <name> <path>' This will pull from the "name" you have set in your config file by `add --src' (or by hand). Whatever name you set will be the namespace for the tags. So, if you've named the public tags that Carl pushed above "cworth", they will show up as "cworth.bug", "cworth.queued", etc. If you've explicitly specified the path, it won't check your config file. Note, though, that pulling from different files to the same namespace could have strange results. Best to keep it consistent for now. NOTE: pull opens your notmuch db up for writing. Make sure to dump first. Note also that the numbers that it announces of how many tags have been added or removed are not exactly accurate at the moment. This has no effect on operation. I'd like to add the ability to pull over ssh. 4) `nm-remote history <name> <msg-id>' I just added this. "name" has to be a pulling source. So, if I have set up Carl's public tags as my "cworth" name-space, typing `nm-remote history cworth <msg-id>' should give me all the changes to the tag. PLEASE NOTE: This is just a prototype, based on some discussions with David B. and a bit of playing around online. I'd expect the commands and the file format to change. Ideally, once we get it straightened out, the functionality could be rewritten in C down the line and included in "notmuch" under the "remote" command. If you're interested, I'd be happy to chat about my further ideas for it in this thread, or over IRC. All best, Jesse ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug tracking 2010-05-03 19:32 ` Jesse Rosenthal @ 2011-01-13 14:43 ` Thomas Schwinge 2011-01-13 20:49 ` Jesse Rosenthal 0 siblings, 1 reply; 14+ messages in thread From: Thomas Schwinge @ 2011-01-13 14:43 UTC (permalink / raw) To: Jesse Rosenthal; +Cc: David Bremner, Notmuch Mail [-- Attachment #1: Type: text/plain, Size: 387 bytes --] Hallo! On Mon, 03 May 2010 15:32:09 -0400, Jesse Rosenthal <jrosenthal@jhu.edu> wrote: > Well, this is as good a time to make an announcement as any. I have a > prototype, nm-remote, in its early stages available here: > > git clone http://jkr.acm.jhu.edu/git/nm-remote.git I wanted to have a look at this, but the repository is no longer accessible. Grüße, Thomas [-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug tracking 2011-01-13 14:43 ` Thomas Schwinge @ 2011-01-13 20:49 ` Jesse Rosenthal 2011-01-14 11:46 ` Andreas Amann 0 siblings, 1 reply; 14+ messages in thread From: Jesse Rosenthal @ 2011-01-13 20:49 UTC (permalink / raw) To: Thomas Schwinge; +Cc: David Bremner, Notmuch Mail Hi Thomas, On Thu, 13 Jan 2011 15:43:40 +0100, Thomas Schwinge <thomas@schwinge.name> wrote> > > git clone http://jkr.acm.jhu.edu/git/nm-remote.git > > I wanted to have a look at this, but the repository is no longer > accessible. Oh yeah -- completely forgot about that. I moved it to someplace that works, so you should be able to get it by: git clone http://commonmeasure.org/~jkr/git/nm-remote.git Best, Jesse ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: bug tracking 2011-01-13 20:49 ` Jesse Rosenthal @ 2011-01-14 11:46 ` Andreas Amann 0 siblings, 0 replies; 14+ messages in thread From: Andreas Amann @ 2011-01-14 11:46 UTC (permalink / raw) To: Jesse Rosenthal, Thomas Schwinge; +Cc: David Bremner, Notmuch Mail [-- Attachment #1: Type: text/plain, Size: 524 bytes --] On Thu, 13 Jan 2011 15:49:07 -0500, Jesse Rosenthal <jrosenthal@jhu.edu> wrote: > Oh yeah -- completely forgot about that. I moved it to someplace that > works, so you should be able to get it by: > > git clone http://commonmeasure.org/~jkr/git/nm-remote.git > The same seems to apply to the notmuch_addresses script, which is mentioned in the NEWS file. I therefore suggest to apply the patch below to the notmuch repository (or alternatively include the script itself in the main notmuch repository) Andreas [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-Correct-location-of-notmuch_addresses-repository.patch --] [-- Type: text/x-patch, Size: 949 bytes --] From ad159c1806a2ae6ea6d13b99bb56a61d20bd300a Mon Sep 17 00:00:00 2001 From: Andreas Amann <andreas.amann@web.de> Date: Fri, 14 Jan 2011 11:33:44 +0000 Subject: [PATCH] Correct location of notmuch_addresses repository The git repository of the notmuch_addresses script has moved to http://commonmeasure.org/~jkr/git/notmuch_addresses.git/ --- NEWS | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/NEWS b/NEWS index 5a1778e..62bd04e 100644 --- a/NEWS +++ b/NEWS @@ -496,7 +496,7 @@ Support for doing tab-completion of email addresses One such program (implemented in python with the python bindings to notmuch) is available via: - git clone http://jkr.acm.jhu.edu/git/notmuch_addresses.git + git clone http://commonmeasure.org/~jkr/git/notmuch_addresses.git Install that program as notmuch-addresses on your PATH, and then hitting TAB on a partial email address or name within the To: or Cc: -- 1.7.3.3 ^ permalink raw reply related [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-01-14 12:20 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-04-22 15:47 bug tracking Jameson Rollins 2010-04-22 17:37 ` David Bremner 2010-04-26 18:31 ` Carl Worth 2010-04-26 18:42 ` Arvid Picciani 2010-04-28 12:58 ` Jameson Rollins 2010-04-28 14:34 ` David Bremner 2010-04-29 17:48 ` Servilio Afre Puentes 2010-04-29 20:01 ` Mark Anderson 2010-05-03 19:44 ` Jesse Rosenthal 2010-05-03 19:06 ` Carl Worth 2010-05-03 19:32 ` Jesse Rosenthal 2011-01-13 14:43 ` Thomas Schwinge 2011-01-13 20:49 ` Jesse Rosenthal 2011-01-14 11:46 ` Andreas Amann
Code repositories for project(s) associated with this public inbox https://yhetil.org/notmuch.git/ 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 read-only IMAP folder(s) and NNTP newsgroup(s).