Setting up a bug tracking system where users can file bug reports and feature requests for Git

Hi,

Is there a bug tracking system where I can file bug reports and feature requests for Git? If not, could you please set up such a system? I am more likely to send bug reports and feature requests to a bug tracking system than a mailing list, since I know that they can't be lost in the mists of time and forgotten forever. :)

And if you really hate the web, and you insist on an email-centric bug tracking system, I know of an option for you: "debbugs". Both the Debian Linux distribution developers, and the GNU Emacs developers[1], use this system. To submit a bug to debbugs, you simply send an email to the "submit@" address. To add comments to a bug report, you email the "${bugnumber}@" address. To make other changes, you email the "control@" address.

^ [1]. see http://emacsbugs.donarmstrong.com/emacs for a list of bugs in Emacs

Cheers, -- Jason Spiro: software/web developer, packager, trainer, IT consultant. I support Linux, UNIX, Windows, and more. Contact me to discuss your needs. +1 (416) 992-3445 / www.jspiro.com

Jason Spiro <jasonspiro4@gmail.com> writes:

This come up on the list from time to time.

I am not fundamentally opposed to using an automated way to help tracking issues, but a tracking system is not a panacea.

A tracking system is just a tool. You need to have a competent and stable project secretary whose job is to look after the issues database. The tasks involved are to expire the stale ones, to reject invalid entries, to prod the bug reporter for additional information, to find a volunteer to take up on an individual issue, to prod the bug reporter for confirmation on the fix once it is ready, and to close completed issues.

And do not tell me that debbugs can route messages. People do not respond to automated messages the same way as they would to messages from a warm and respected body.

We handle the "to expire the stale ones and to reject the invalid ones" part by losing the ones that even the original complainer does not feel motivated enough to be persistent in the mists of time (yes, it is a *feature* of mailing list based community, not a deficiency).

A mailing list based workflow lacks support for other tasks a competent project secratary performs: finding a taker for a task and prodding the party whose court the ball currently is in. That is currently done purely on voluntary basis. Often the person who introduced the bug originally feels ashamed enough to look into the issue. A diligent bug reporter asks if the issue previously reported has a resolution when a certain period of silence passes, and such a "prodding" raises the awareness of the issue in the group of volunteer developers and gives the issue a higher priority.

I would agree 100% with you if you said relying on such a purely volunteer based system would not be ideal. It is not. But given that the ratio between gimme-whiners and can-do-contributors is not so great, that's the best we can currently do.

It would be great to have a competent and stable project secretary to fill the gap. From time to time, we do see some people playing that role, summarizing the issues raised, discussed and then left unresolved, but that too is purely on voluntary basis. I do that as a part of the task for the maintainer, but obviously I have to do other things as well.

If you are volunteering to be the lead for the project secretaries group, that would be great.

Such a person may choose a tracking system he or she is the most familiar with, and if that helps the progress of the project, that would be even better.

On 2009-02-16, Junio C Hamano <gitster@pobox.com> wrote:

As I've been against web-based bug-trackers before I'd like to present an idea which, imho, is a good compromise. I'm afraid that the number of false bug-reports will increase dramatically with the introduction of such a bug-tracker, eating up time of the volunteers. Also, as I mentioned, I really dislike using web-based tools.

If we had such a secretary who's not only familiar with the bugtracker but also familiar enough with git and it's development organization, he/she could work with the system, filter out the noise and mail real bugs or well-thought-through feature-requests to this mailing-list (with a link back to the bugtracker) with the full text of the bug and maybe his/her oppinion about it.

But maybe that's just duplication of work, in your eyes.

Greetings, Jojo

Johannes Gilger <heipei@hackvalue.de> writes:

If there were such a person or a group of people to help the project that way, it would be great. What you just said is in total agreement of the paragraph you quoted above (which I omitted ;-)).

As you culled the To/Cc list and sent it only to the mailing list, I cannot quite tell if you were referring to me, so this is an unsolicited comment to your statement, but I do not think it is duplication of work at all.

Sifting chaffs and interfacing with people are what I would love to see from a capable project secretary. It is already a large part of what the maintainer does (see Documentation/howto/maintain-git.txt), but as the project grows larger, you'll see bottleneck at the maintainer and the major contributors. Three things you can do to help are to filter noise, to summarize useful inputs, and to offload the routine prodding (in both direction -- querying the status of unfilled requests to developers, and asking for confirmation of an already implemented fix/enhancement to requestors) from the maintainer and major contributors, which I listed as the project secretary tasks.

There are other ways to help: by answering user questions, spotting and correcting wrong answers and FUDs given in response to inquiries from new people, dowsing flames before they get out of control, reducing recurring topics by pointing out previous discussions, etc.