On Fri, Mar 2, 2012 at 2:03 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Neal Kreitzinger <nkreitzinger@xxxxxxxxx> 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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html