bug tracking

bug tracking

[Jameson Rollins]

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

Re: bug tracking

[David Bremner]

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

Re: bug tracking

[Carl Worth]

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

Re: bug tracking

[Arvid Picciani]

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

Re: bug tracking

[Jameson Rollins]

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

Re: bug tracking

[David Bremner]

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

Re: bug tracking

[Servilio Afre Puentes]

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.

Re: bug tracking

[Mark Anderson]

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

Re: bug tracking

[Carl Worth]

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

Re: bug tracking

[Jesse Rosenthal]

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

Re: bug tracking

[Jesse Rosenthal]

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

Re: bug tracking

[Thomas Schwinge]

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

Re: bug tracking

[Jesse Rosenthal]

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

Re: bug tracking

[Andreas Amann]

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