From: Junio C Hamano <gitster@pobox.com>
To: Neal Kreitzinger <nkreitzinger@gmail.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
Thomas Rast <trast@inf.ethz.ch>,
Andrew Ardill <andrew.ardill@gmail.com>,
opticyclic <opticyclic@gmail.com>,
git@vger.kernel.org
Subject: Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests
Date: Thu, 01 Mar 2012 23:03:28 -0800 [thread overview]
Message-ID: <7vsjhrfprz.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <4F505F8C.70802@gmail.com> (Neal Kreitzinger's message of "Thu, 01 Mar 2012 23:50:04 -0600")
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?
When somebody posts a bug report to the list, with the current workflow,
one of these things happens:
1. It is an already solved issue. People who are familiar with the
existing fix may immediately answer, after running "git log", with "It
is fixed in v1.7.6". Or somebody not so familiar with the fix may
start "Does not reproduce for me who use the 'master' version. Git
from what era are you using?" conversation. I do not think a bug
tracker will help much in this case [*1*].
2. It is an already answered non-issue. People who are familiar with the
previous discussion may point at the list archive, or somebody may dig
up the answer in the gmane archive. I do not know if a bug tracker
will help much in this case. Having a place to point people at is
better than having to write everything from scratch every time, but
(1) looking for the previous discussion is the more time consuming
part, and (2) once the previous discussion is found in the list
archive, we already have the necessary pointer.
3. People who are familiar with the area of the problem may start "Need
more info" conversation. This may result in either finding the report
a non-issue (#1 or #2), or it may turn out to be a real issue, and
after further analysis, design and coding, may result in a fix. Once
this flow starts rolling, the current workflow works very well.
4. It falls through cracks, because nobody even categorizes it into the
above three.
I think the primary thing people want out of a bug tracker is to reduce
the frequency of #4. The real solution for it is to free up time from
people who can do the later part of #3 so that they can spend more time to
turn #4 into #3.
A way to do so is for members of the community who are capable of doing #1
and #2 but not familiar enough with the code to do the later part of #3 to
help with earlier part of #3 (i.e. triaging).
As I already said. the mailing-list based workflow serves us reasonably
well once the ball is rolling in #3, and that was the reason why I
suggested some heuristics to catch #4 in my previous message. There are
cases where the original reporter disappears during the "need more info"
exchange, and in such a case a tracking system _may_ be able to help us
remember that the issue is unresolved because of reporter inaction, but
the tracker won't respond to "need more info" itself, and people tend to
ignore automated nag mails, so there is still a need for warm body human
bug secretary who interfaces with the reporter in such a case.
In any case, any solution that demands more things to be done by people
near the core developers than they currently are already doing will make
things worse by exacerbating the problem that comes from a bottleneck in
the process. I do not think your "The maintainer triages and assigns
issues to other developers" or "The assigned developer marks the issue as
'done' after fixing it" will fly very well, regardless of the use of any
bug tracker.
[Footnote]
*1* If the symptom is so straightforward that a simple search in a bug
tracker can produce hits for an already solved issue, grepping in
Release Notes should equally work well.
*2* I do not know if this happens too often to be a real problem, though.
next prev parent reply other threads:[~2012-03-02 7:03 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-29 17:19 Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests opticyclic
2012-02-29 18:23 ` Brian Gernhardt
2012-02-29 18:53 ` Junio C Hamano
2012-02-29 22:53 ` Jonathan Nieder
2012-02-29 23:58 ` Andrew Ardill
2012-03-01 0:37 ` Greg Troxel
2012-03-01 0:45 ` Andrew Ardill
2012-03-01 0:50 ` Junio C Hamano
2012-03-01 1:05 ` Andrew Ardill
2012-03-01 1:05 ` Junio C Hamano
2012-03-01 1:20 ` Andrew Ardill
2012-03-01 5:16 ` Miles Bader
2012-03-01 5:40 ` Andrew Ardill
2012-03-01 16:52 ` Scott Chacon
2012-03-01 20:23 ` Junio C Hamano
2012-03-01 11:29 ` Thomas Rast
2012-03-01 11:54 ` Ævar Arnfjörð Bjarmason
2012-03-01 12:46 ` Andrew Ardill
2012-03-01 12:28 ` Andrew Ardill
2012-03-01 17:10 ` Junio C Hamano
2012-03-02 4:03 ` Neal Kreitzinger
2012-03-02 4:19 ` Jonathan Nieder
2012-03-02 4:21 ` Junio C Hamano
2012-03-02 5:50 ` Neal Kreitzinger
2012-03-02 6:25 ` Jonathan Nieder
2012-03-02 7:03 ` Junio C Hamano [this message]
2012-03-02 14:18 ` Andreas Ericsson
2012-03-02 16:45 ` Junio C Hamano
2012-03-07 8:03 ` Andrew Ardill
2012-03-07 9:52 ` Vincent van Ravesteijn
2012-03-07 13:04 ` Joern Huxhorn
2012-03-07 13:53 ` Jonathan Nieder
2012-03-07 14:47 ` Joern Huxhorn
2012-03-07 15:08 ` Pau Garcia i Quiles
2012-03-07 17:18 ` Phil Hord
2012-02-29 19:18 ` Carlos Martín Nieto
2012-02-29 21:37 ` Sitaram Chamarty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vsjhrfprz.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=andrew.ardill@gmail.com \
--cc=git@vger.kernel.org \
--cc=jrnieder@gmail.com \
--cc=nkreitzinger@gmail.com \
--cc=opticyclic@gmail.com \
--cc=trast@inf.ethz.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).