Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests

From: Andrew Ardill <andrew.ardill@gmail.com>
Date: Mar 1, 2012, 12:28 UTC
Message-ID: <CAH5451mmvxQZc1JEZe+W8WD_QwikpELhxG1WHJAKfp6rW3DCHw@mail.gmail.com>
In-Reply-To: <8762eoimp0.fsf@thomas.inf.ethz.ch>

On 1 March 2012 22:29, Thomas Rast <trast@inf.ethz.ch> wrote:

Show 20 quoted lines

> Andrew Ardill <andrew.ardill@gmail.com> writes:
>
>> I have set up a JIRA instance using Atlassian's OnDemand service,
>> available at https://git-scm.atlassian.net/
> [...]
>> As I see it (and Junio has mentioned before) we are going to need
>> people who are able to manage the issues in this system
>
> Note that you are not the first one to try.  The most elaborate plan and
> writeup that I know of sits at
>
>  http://article.gmane.org/gmane.comp.version-control.git/136500  [1]
>
> Jan "jast" Krüger also mentioned server issues today, so *.jk.gs is
> presumably down because of that, not because gitbugs.jk.gs is no longer
> valid.
>
> Nevertheless, AFAIK it has never been used for "real work", so you may
> want to look into why that happened, and do something different.
>

Thanks for the links Thomas, I think the general sentiments summarised there are echoed every time someone mentions an issue tracker on the list. It is good to have the summary though!

I think that, to some degree, the model that most quickly arises from the ideals of that list is inherently flawed. The git list is, almost by definition, a fairly chaotic place. Issues get looked into because either someone makes a loud enough noise, or someone is interested enough in the problem. An issue tracker is a much more structured beast, and trying to tether the two is obviously going to be difficult. One of the benefits of an issue tracker is that it keeps all discussion around an issue in the one place. The driving wedge here is that we *already* have somewhere that issues are tracked, albeit in a less structured sense. Anything that reduces the duplication efforts needed is a desirable thing, but more on that later.

The one thing we need to avoid is single points of failure. In my experience, this is achieved by ensuring that people contributing issues are able to do as much of the leg work as possible. Typically they want to help, and are limited most by unnecessary restrictions and lack of understanding. If the process is simple enough it becomes much easier for new people to step in and make valuable contributions (the mailing list is in some ways the embodiment of this). We also need to encourage those who are willing and empower each other to be time-effective.

I feel that is enough pontificating from me, and I am really enjoying the discussion. Please, if you think it will work or not, visit the site [1] - sign up if you want to - and provide feedback. I am going to open a project to capture feedback, and anything else related that is not directly relevant to the list, and that will probably be a good place to test the ropes if you want to get your hands dirty. In general, it is very hard to break things so if you would like to have a play around with the system please let me know and get involved!

Regards,

Andrew Ardill

[1] git-scm.atlassian.net