Andrew Ardill [off-list ref] writes:
I have set up a JIRA instance using Atlassian's OnDemand service,
available at https://git-scm.atlassian.net/
[...]
As I see it (and Junio has mentioned before) we are going to need
people who are able to manage the issues in this system
Note that you are not the first one to try. The most elaborate plan and
writeup that I know of sits at
http://article.gmane.org/gmane.comp.version-control.git/136500 [1]
Jan "jast" Krüger also mentioned server issues today, so *.jk.gs is
presumably down because of that, not because gitbugs.jk.gs is no longer
valid.
Nevertheless, AFAIK it has never been used for "real work", so you may
want to look into why that happened, and do something different.
--
Thomas Rast
trast@{inf,student}.ethz.ch
On Thu, Mar 1, 2012 at 12:29, Thomas Rast [off-list ref] wrote:
Andrew Ardill [off-list ref] writes:
quoted
I have set up a JIRA instance using Atlassian's OnDemand service,
available at https://git-scm.atlassian.net/
[...]
quoted
As I see it (and Junio has mentioned before) we are going to need
people who are able to manage the issues in this system
Note that you are not the first one to try. The most elaborate plan and
writeup that I know of sits at
http://article.gmane.org/gmane.comp.version-control.git/136500 [1]
Jan "jast" Krüger also mentioned server issues today, so *.jk.gs is
presumably down because of that, not because gitbugs.jk.gs is no longer
valid.
Nevertheless, AFAIK it has never been used for "real work", so you may
want to look into why that happened, and do something different.
As someone who submits patches every once in a while I can echo other
sentiments in this thread, just because you have a list of issues that
doesn't mean anyone is working on them.
However I'd also sometimes like to work on some random issue because
I'm bored, and having a collection of issues ordered by priority (or
popularity) would be useful when that happens.
But I think any proposal to set up a wholly external system is going
to fail, we do most of our bug submission / commenting etc. on this
mailing list, and that isn't going to change, so there's always going
to be a large chasm between the list and any external system.
What I think *would* work however is a system that feeds off the
mailing list. This could be as simple as a mailing list aggregator
that allowed you to star certain messages, and the most starred
messages would be the popular issues.
A more fancy solution would:
* Consume every single message that gets sent to the list
* Group each thread and allow it to be categorized as a
bug/issue/enhancement/complaint
* Allow you to mark a collection of threads as describing the same
issue, so you'd have duplicates marked & the full history of a
discussion on some issue.
* Allow you to mark an issue as outstanding / resolved / allow voting
on it.
Thus you'd automatically build up an issue database without anyone
going out of their way, all it would need is the same people who
complain that they can't file bugs either categorizing existing posts,
or categorizing a post they just made.
Many bug trackers can be made to work with E-Mail (e.g. Jira, RT
etc.), although I don't know if they're well set up to follow a
mailing list like this. I think e.g. Jira assumes that you have a the
bug id in the subject, and might not be smart enough to group things
by In-Reply-To headers.
On 1 March 2012 22:29, Thomas Rast [off-list ref] wrote:
Andrew Ardill [off-list ref] writes:
quoted
I have set up a JIRA instance using Atlassian's OnDemand service,
available at https://git-scm.atlassian.net/
[...]
quoted
As I see it (and Junio has mentioned before) we are going to need
people who are able to manage the issues in this system
Note that you are not the first one to try. The most elaborate plan and
writeup that I know of sits at
http://article.gmane.org/gmane.comp.version-control.git/136500 [1]
Jan "jast" Krüger also mentioned server issues today, so *.jk.gs is
presumably down because of that, not because gitbugs.jk.gs is no longer
valid.
Nevertheless, AFAIK it has never been used for "real work", so you may
want to look into why that happened, and do something different.
Thanks for the links Thomas, I think the general sentiments summarised
there are echoed every time someone mentions an issue tracker on the
list. It is good to have the summary though!
I think that, to some degree, the model that most quickly arises from
the ideals of that list is inherently flawed. The git list is, almost
by definition, a fairly chaotic place. Issues get looked into because
either someone makes a loud enough noise, or someone is interested
enough in the problem. An issue tracker is a much more structured
beast, and trying to tether the two is obviously going to be
difficult.
One of the benefits of an issue tracker is that it keeps all
discussion around an issue in the one place. The driving wedge here is
that we *already* have somewhere that issues are tracked, albeit in a
less structured sense. Anything that reduces the duplication efforts
needed is a desirable thing, but more on that later.
The one thing we need to avoid is single points of failure. In my
experience, this is achieved by ensuring that people contributing
issues are able to do as much of the leg work as possible. Typically
they want to help, and are limited most by unnecessary restrictions
and lack of understanding. If the process is simple enough it becomes
much easier for new people to step in and make valuable contributions
(the mailing list is in some ways the embodiment of this). We also
need to encourage those who are willing and empower each other to be
time-effective.
I feel that is enough pontificating from me, and I am really enjoying
the discussion. Please, if you think it will work or not, visit the
site [1] - sign up if you want to - and provide feedback. I am going
to open a project to capture feedback, and anything else related that
is not directly relevant to the list, and that will probably be a good
place to test the ropes if you want to get your hands dirty. In
general, it is very hard to break things so if you would like to have
a play around with the system please let me know and get involved!
Regards,
Andrew Ardill
[1] git-scm.atlassian.net
On 1 March 2012 22:54, Ævar Arnfjörð Bjarmason [off-list ref] wrote:
As someone who submits patches every once in a while I can echo other
sentiments in this thread, just because you have a list of issues that
doesn't mean anyone is working on them.
However I'd also sometimes like to work on some random issue because
I'm bored, and having a collection of issues ordered by priority (or
popularity) would be useful when that happens.
JIRA is particularly good at categorising backlogs and filtering out
issues, so this is a very achievable outcome.
But I think any proposal to set up a wholly external system is going
to fail, we do most of our bug submission / commenting etc. on this
mailing list, and that isn't going to change, so there's always going
to be a large chasm between the list and any external system.
I agree wholeheartedly.
What I think *would* work however is a system that feeds off the
mailing list. This could be as simple as a mailing list aggregator
that allowed you to star certain messages, and the most starred
messages would be the popular issues.
This is an interesting idea, not sure how that would be implemented
though. Seems like you would need some client or webservice email
reader that could be extended like that.
A more fancy solution would:
* Consume every single message that gets sent to the list
* Group each thread and allow it to be categorized as a
bug/issue/enhancement/complaint
* Allow you to mark a collection of threads as describing the same
issue, so you'd have duplicates marked & the full history of a
discussion on some issue.
* Allow you to mark an issue as outstanding / resolved / allow voting
on it.
Thus you'd automatically build up an issue database without anyone
going out of their way, all it would need is the same people who
complain that they can't file bugs either categorizing existing posts,
or categorizing a post they just made.
Many bug trackers can be made to work with E-Mail (e.g. Jira, RT
etc.), although I don't know if they're well set up to follow a
mailing list like this. I think e.g. Jira assumes that you have a the
bug id in the subject, and might not be smart enough to group things
by In-Reply-To headers.
JIRA allows creation of issues by sending emails to a special email
address. The process that is used is as follows (take from [1]):
The subject of an email message is examined for an existing issue key:
- If an issue key is found in the subject, the content of the email
message's body is processed and added as a comment to the issue with
that issue key.
- If an issue key is NOT found in the subject, the in-reply-to header
is examined:
- If the email message is found to be a reply to another email
message from which an issue was previously created, the body is
processed and added as a comment to that issue.
- If the email message is NOT found to be a reply, a new issue is created.
As you can see, it _should_ respect in-reply-to headers, however we
should probably test this :)
Currently only emails that contain issue keys are being captured,
however I will enable issue creation in a throwaway project so we can
test them. I might even set up a forwarder to capture all or most of
the list traffic to see what happens. If we capture any useful issues
in that throwaway project, a valid workflow might be to move them over
to the 'real' project to which they belong. Perhaps the volume will be
low enough in reality that we can enable issues being created directly
in that project, without the move step.
One thing to consider is the notifications sent out by JIRA on
different events. We could potentially send an email to the list
whenever an issue is commented on, resolved, or something else. The
possibilities (and permissions around those possibilities) are quite
versatile, and well worth investigating. For now I will try my best to
stop _all_ automated responses going to the list, until we can be
certain that it won't be just more spam.
Thanks for your thoughts, I think your ideas give a really strong
direction for us to investigate further.
Regards,
Andrew Ardill
[1] http://confluence.atlassian.com/display/JIRA/Creating+Issues+and+Comments+from+Email#CreatingIssuesandCommentsfromEmail-Issuecommentcreation