Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

Hi Jonathan,

On Tue, 19 Sep 2017, Jonathan Nieder wrote:

Johannes Schindelin wrote:

quoted

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