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

From: Phil Hord <phil.hord@gmail.com>
Date: Mar 7, 2012, 17:18 UTC
Message-ID: <CABURp0q7fJLBHGGdD7EQ6pwEu=zErKHz+ZZJ5HLVe5VO2Y66gQ@mail.gmail.com>
In-Reply-To: <7vsjhrfprz.fsf@alter.siamese.dyndns.org>

On Fri, Mar 2, 2012 at 2:03 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 9 quoted lines

> Neal Kreitzinger <nkreitzinger@gmail.com> writes:
>
>> I realize this is not an exact match of the git-workflow, but you get
>> the idea.  I'm also new to mailinglists so I'm not sure if you can
>> change part of the subject line.  If not, a header in the body could
>> possibly be used.
>
> The most important information is missing from your discussion: who are
> you trying to help, and what problem are you trying to solve?

Problems this could help solve (regardless of whether it's an appropriate tool for the job):

1. Collects issues into a more concise list than the mailing list provides.

2. Collects issues (and discussion) conveniently bundled with the git
source code.

3. Collects issues for off-line reference and searching.

4. Reduction of list noise, if issues in git.git turn out to be better
grep-targets than the mailing list.

5. Serves as an incubator for a git-based distributed issues tracker
Best Practice or Dire Warning, depending on how it goes.

The current mailing list bug tracker, where finding existing issues and previous discussions is "crowd-sourced" to the list, is very efficient for the new users, but not so efficient for the core developers and respondents.

I doubt this idea is really workable or appropriate for git.git, for various reasons. But I do think a well-designed, distributed, git-based issue tracker could be useful for many other projects. Many others have tried and failed, so I am probably wrong about this last statement. See [*1*] for a list of mostly stagnating prior art.

Phil

[*1*] http://dist-bugs.branchable.com/software/