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

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

[Jason Spiro]

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

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

[Junio C Hamano]

Jason Spiro <jasonspiro4@gmail.com> writes:

> 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.  :)

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.

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

[Johannes Gilger]

On 2009-02-16, Junio C Hamano <gitster@pobox.com> wrote:
> 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.

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>
http://hackvalue.de/heipei/
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81  882C 58EE B178 42F6 DE81

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

[Junio C Hamano]

Johannes Gilger <heipei@hackvalue.de> writes:

> On 2009-02-16, Junio C Hamano <gitster@pobox.com> wrote:
>> 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.
> ...
> 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.

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 ;-)).

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

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.