Hi Jonathan, On Tue, 19 Sep 2017, Jonathan Nieder wrote:
> 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. No, I don't. I know how cumbersome it would be to move tons of people over from one type of project management to another. However, the current situation is not really tenable, is it? It is tedious for everybody involved. I know Junio defends the status quo, but I cannot imagine that he really likes it, as too much is too manual and labor-intensive. As I mentioned at the GitMerge (which was a bit pointless, because Junio was not there, not even via Skype), I do not advocate one radical change, ever. > 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. I agree that a bug tracker goes a long way. Personally, I feel Bugzilla is way too clunky to use, but I am pampered. However, I could imagine that allowing issues to be opened at https://github.com/git/git, and encouraging bug submissions there for people who really need to be able to find out very, very quickly what the current state of their bug report is, would go a long way. Of course, this would require a commitment by Junio and others to allow discussions to move to that bug tracker from the mailing list. Once that willingness is there, this should be a viable alternative to reporting bugs on the mailing list (and have those reports go unanswered because they fell off the radar...). > 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. My experience with Git for Windows, where I try to live Postel's Law by accepting bug reports via mailing list and GitHub issues (and earlier Google Code, when that was still alive and kicking), and to a certain extent even via Twitter: next to nobody likes sending bug reports via mail. So to add to your sentiment, I like Bugzilla *less* than GitHub issues, and the worst bug tracker is a mailing list. Or maybe you have written a shell script that can answer the question "which of my reported bugs/submitted patch series are still open?" for the Git mailing list? > 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. Yes, I agree. The willingness to see the problem, followed by the willingness to discuss possible solutions, those two need to be the first steps. Ciao, Dscho
