From: Junio C Hamano <hidden> Date: 2016-06-15 22:53:12
Neal Kreitzinger [off-list ref] 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.
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:53:12
On 03/02/2012 08:03 AM, Junio C Hamano wrote:
... a very concise and exact response.
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.
It works very well when there's the incentive of roof over one's head
and food on one's table to take care of the assigned issues. However,
nothing stops a git developer from saying "sorry, I'm busy" when being
assigned really, really boring tasks that they really don't feel like
doing.
One thing I could see a bugtracker would be good for is to get companies
that use git to vote on issues or features using real money. Developers
can then pick up the issue and do something with them.
Apart from that, I doubt there's much incentive for the people who do
any of the work to pick up issues nobody cares about. The number of bugs
falling through the cracks is too small to go through a lot of work just
to keep track of them, and the ones that do are ones that are primarily
of the bikeshedding variant or such weird corner-cases that they don't
happen in 99.999% of all use-cases git was designed for and is bid to
handle.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
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.
Sorry for the full quote.
I think the main problems with all issue trackers I know about are
- they are centralized, i.e. like SVN
- they all have a more or less clumsy web interface. All of them different, most of them configurable.
To get accepted in this community, an issue tracker would need to be decentralized (obviously including the ability to merge issue state and so on, likely git-based, probably simply included in the normal git repository of a project or in a separate issues-branch) and require a proper command line interface so it is properly scriptable (to feed it with threads from this mailing list, for example).
I'd love such a system.
I disagree with your assumption in 1. and *1*. A proper issue tracker has the ability to attach additional info (like stack traces or even a workaround) and files. Those would be searched, too, and would most likely not show up in the 'git log'.
An issue tracker could therefore remove noise from the mailing list which would automatically reduce workload on the core developers.
Your points 1. 2. and 3. all include "People who are familiar", i.e. it always involves some action from more or less cory developers. In case of an issue tracker, even duplicates and already solved issues (1. and 2.) serve a purpose since they'd indicate that either the previous solution hasn't been communicated good enough or that the duplicated issue has a high enough impact to creep up again.
Somebody needs to keep in mind all issues, in some way. I really wonder how you are able to cope with this task.
I'm not trying to lecture you that you are "doing it wrong". Your mailing-list based workflow seems to work incredibly well for you. But it doesn't really help to entice people into the community, either.
I'm (mostly) a silent observer of this list and just a (super-happy) user of git - but I really have a hard time getting a grip on the changes introduced in the different versions. You could obviously argue that I'm not trying hard enough since I'm not reading the 'git log' and all the diffs but I suspect that I'm already trying harder than most users.
For example, what happened to the git generation numbers discussed (in part) over here: http://comments.gmane.org/gmane.comp.version-control.git/177146
Are they already included in a released git version? If so, how would I find them? If not, why not? An issue tracker would be able to answer me, as a little-above-casual user, this question without resorting to asking you.
So I guess it all boils down to waiting until somebody is sufficiently annoyed by the current state of issue trackers and thus tries to implement a properly decentralized one that is likely based on plain text files (for easy merges) and features a proper way to query issues.
Just like Linus was sufficiently annoyed by the state of VCS.
Cheers,
Joern.
To get accepted in this community, an issue tracker would need to be
decentralized
No, I don't think that's a requirement.
I didn't mean to imply that this would be a matter of principle. A decentralized tracker would just offer the same advantages that a decentralized VCS has to offer. One could work on issues while not connected to the internet, for example. So this would be a VeryGoodThing™.
I don't think that it would be a good idea to "teach" git issue tracker functionality. I simply wanted to voice my opinion that something like the ideas Neal suggested down the thread, a cli issue tracker with git in the backend, are very worthwhile to evaluate. But it should have an additional layer so it's really easy to use. It has to be so it *is* actually used. It needs to reduce workload instead of increasing it.
Cheers,
Joern.
From: Pau Garcia i Quiles <hidden> Date: 2016-06-15 22:53:14
On Wed, Mar 7, 2012 at 2:04 PM, Joern Huxhorn [off-list ref] wrote:
To get accepted in this community, an issue tracker would need to be decentralized (obviously including the ability to merge issue state and so on, likely git-based,
probably simply included in the normal git repository of a project or in a separate issues-branch) and require a proper command line interface so it is properly
scriptable (to feed it with threads from this mailing list, for example).
I'd love such a system.
Take a look at Veracity ( http://veracity-scm.com/ )
Also, do not forget issue tracking must be possible for people who do
not use git. That's why we use git hosted at Assembla (
http://www.assembla.com ) at work: 2/3 of the people in the project
are not developers but marketing, verification, validation, support,
trainers, management, etc.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
From: Phil Hord <hidden> Date: 2016-06-15 22:53:14
On Fri, Mar 2, 2012 at 2:03 AM, Junio C Hamano [off-list ref] wrote:
Neal Kreitzinger [off-list ref] writes:
quoted
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/