Hi,
Johannes Schindelin wrote:
> To relate that, you are using a plain text format that is not well defined
> and not structured, and certainly not machine-readable, for information
> that is crucial for project management.
>
> What you need is a tool to aggregate this information, to help working
> with it, to manage the project, and to be updated automatically. And to
> publish this information continuously, without costing you extra effort.
>
> I understand that you started before GitHub existed, and before GitHub was
> an option, the script-generated What's cooking mail was the best you could
> do.
I think you are subtly (but not directly, for some reason?) advocating
moving project management for the Git project to GitHub Issues.
For what it's worth:
1. I would be happy to see Git adopt a bug tracker. As we've
discussed on the list before, I suspect the only way that this is
going to happen is if some contributors start using a bug tracker
and keep up with bugs there, without requiring everyone to use it.
That is how the Linux Kernel project started using
bugzilla.kernel.org, for example.
2. GitHub Issues is one of my least favorite bug trackers, for what
it's worth. If some sub-project of Git chooses to use it, then
that's great and I won't get in their way. I'm just providing
this single data point that approximately any other tracker
(Bugzilla, JIRA, debbugs, patchwork) is something I'd be more
likely to use.
3. This advice might feel hopeless, because if the maintainer is not
involved in the initial pilot, then how does the bug tracker get
notified when a patch has been accepted? But fortunately this is
a problem other people have solved: e.g. most bug trackers have an
API that can be used to automatically notify the bug when a patch
with a certain subject line appears on a certain branch.
Thanks and hope that helps,
Jonathan
