git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: For real now: bug tracking and secretary tasks in git

From
Jeff King <peff@peff.net>
Date
Jan 26, 2010, 12:26 UTC
Message-ID
<20100126122654.GA28179@coredump.intra.peff.net>
In-Reply-To
<20100109013850.16f82412@perceptron>

[This reply is a bit late, but there doesn't seem to have been much discussion, so...]

On Sat, Jan 09, 2010 at 01:38:50AM +0100, Jan Krüger wrote:
Show 15 quoted lines
> Mass consensus in previous discussions[1][2] goes a bit like this:
> 
> 1. It would be desirable to have people who do the work of interfacing
>    between bug reporters and developers. These same people could make
>    sure reports didn't get lost. These people are the *secretaries*.
>    They should be pretty reliable.
> 
> 2. People who contribute to git shouldn't be forced to work with the
>    tracker. Having a tracker that isn't actively maintained by dedicated
>    secretaries is pretty much worthless anyway, so there's no need to
>    pretend that forcing developers to use a tracker interface is any
>    kind of improvement.
> 
> 3. The "human element" is important. For example, automatic reminders
>    are a lot less valuable than reminders from an actual person.

I more or less agree with your approach, though I am a bit concerned that because the process of moving information between the list and the bug tracker is manual, bits of information will be lost unless the secretaries are on their toes. Which means that people who submit bugs will see no activity on their bug, even though it may have been discussed on the list, and will consider the tracker to be crufty and useless.

But that is not so much a criticism of your proposal, as a possible thing that might go wrong. It's worth giving it a try and seeing what happens.

I notice that there are not too many bugs in the tracker right now. If this is going to be useful for ordinary users to submit bugs, it needs to be publicized. JH suggested hosting it at kernel.org. I think that is a reasonable idea, and certainly it needs a link from other git sites (the wiki, and probably git-scm.org).

As far as the choice of flyspray, I'm not strongly against it, though I suspect you would get more up-take from git developers (well, me, anyway) if it was something that had a more git-ish interface. It would be really nice to clone the bug db, edit, commit, and push bug updates. Many of the distributed trackers support that. I recognize that for ordinary users, we do still want some kind of web-based submitting and bug reading interface. Surely somebody has built a git backend on one of the existing trackers, or somebody has built a nice web interface on one of the distributed trackers? It has been a while since I looked seriously at this area, and I remember being a bit disappointed last time.

And finally, thanks for starting a discussion on this issue. We talked a little about it at the GitTogether, and what you proposed is in line with what was said there, I think. My plan going forward from that discussion (which I hadn't actually started implementing, though) was to clean up my own personal todo list and start making it a bit more public. The reason being that my list is not simply personal features, but lots of bugs posted to the list that have not been dealt with, and that I have either decided are probably actual bugs that need fixing, or even ones that I have reproduced but need prodding to move forward on. So sometime in the near future I'd like to clean up that list and dump it into whatever sort of bug tracking we end up with.

-Peff
Previous: Thiago Farina
Message 4 of 4 in “For real now: bug tracking and secretary tasks in git”
  1. Jan KrügerJan 9, 2010
  2. J.H.Jan 9, 2010
  3. Thiago FarinaJan 9, 2010
  4. Jeff KingJan 26, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.