diff options
Diffstat (limited to 'open_issues/issue_tracking.mdwn')
| -rw-r--r-- | open_issues/issue_tracking.mdwn | 196 |
1 files changed, 196 insertions, 0 deletions
diff --git a/open_issues/issue_tracking.mdwn b/open_issues/issue_tracking.mdwn new file mode 100644 index 00000000..72bb3b77 --- /dev/null +++ b/open_issues/issue_tracking.mdwn @@ -0,0 +1,196 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!toc]] + + +# Savannah Trackers, Open Issues, debbugs + +There are the Savannah trackers. Nobody really likes them. + +There is a proposal to add/move to <http://debbugs.gnu.org/>. It can be +operated by email, Debian people (developers and users) already know how to use +it. + +There are the [[Open_Issues]] pages. This is basically just free-form text +enriched by some tags for grouping, editable via the web and through Git +commit. [[tschwinge]] added this to the set, and/but mostly is the sole user +of it, even though casually there are a few other people contributing, and +surely these pages do show up in web searches. A more traditional system (like +the Savannah trackers or the new debbugs) do have their advantages, too, so +perhaps there's a niche for both these and the [[Open_Issues]]. + +IRC, freenode, #hurd, 2011-08-31: + + <tschwinge> So. Savannah trackers vs. Open Issues vs. debbugs. Any input? + <youpi> I like *both* open issues and debbugs + <youpi> open issues is good for exposing things that people may encounter + in other situations + <youpi> while debbugs is useful to actually work on a bug + <tschwinge> youpi: The advantage of debbugs being the email interface and + the well-known procedure, or something else? + <youpi> email interface, which nicely flows into a mailing list + <youpi> the savannah bug updates suffer from the additional layout + <tschwinge> How does one decide what to put in a debbug and what in an Open + Issue page? + <youpi> I'd say it's not exclusive at all + <youpi> like, a bug on a specific case can start as debbug, and as we + discover it's more general and will not be fixed immediately, get an open + issue page + <youpi> and conversely, when we know some shortcoming, start with an open + issue, and if some bugs are submitted which are actually due to it, + cross-link + <tschwinge> OK. + <youpi> (some general short coming I mean, like SIGINFO) + <tschwinge> And we would keep the current stuff in the trackers, and let + these ``get empty'' gradually (it'll be years...) ;-) or migrate the + remaining issues? + <tschwinge> What we can do is inhibiting the creation of new issues in the + trackers. + <youpi> I'd say move + <youpi> else they will be forgotten + <tschwinge> Hrm. + <antrik> actually, I considered creating a track-like plugin for ikiwiki, + as both the popularity of trac and the usefulness of open_issues show + that something wiki-like is actually more useful than a rigid traditional + bugtracker. but I'm not really willing to do the work, which is why I + didn't propose it before :-) + <antrik> err... trac-like + <youpi> yes, the wiki part is really useful to keep a good summary of the + issue + <tschwinge> antrik: Same for me. I always hoped that someone would do + it... :-) + <antrik> hehe + <tschwinge> antrik: But, as you surely know, this email parsing business is + just too ugly to do realiable, etc. + <antrik> youpi: my point is that adding a few additional bits (like a + comfortable tagging functionality, and some mail interface) could turn + into a full-blown tracker unifying the advantages of both... but as I + said, I'm not really willing to do the work :-) + <youpi> additional to open_issue you mean? + <youpi> yes, but like you say :) + <antrik> tschwinge: hm... seems to work well enough it debbugs + <youpi> debbugs just piles things + <youpi> and has a few commands + <youpi> you'd still need the web interface to edit the wiki part for + instance + <antrik> of course. that wouldn't change at all + <antrik> (except for adding a tagging GUI perhaps) + <antrik> (debbugs of course is not the only mail-operable bugtracking + system... there are a number of others -- and I heard rumors even + bugzilla grew a mail interface now...) + <youpi> antrik: a .mdwn diff should however be sent to the bug for + information + <youpi> atm, what happens sometimes is somebody saying something here on + #hurd, tschwinge turning that into an open_issue, and it does not show up + on the mailing list + <tschwinge> debbugs surely has the advantage that it is available (nearly) + right now. + <mattl> RT (request tracker) and ikiwiki play quite nicely together. + <tschwinge> mattl: You'Re using that at GNU/FSF/somewhere, right? + <mattl> you can close tickets from the wiki, and RT has a good command line + interface, email interface and web interface. + <mattl> tschwinge: yeah, we use RT and ikiwiki. + <mattl> RT for all FSF communications, and ikiwiki for internal organising. + <mattl> RT is not the easiest thing to set up, but works pretty well once + it's running. + +IRC, freenode, #hurd, 2011-10-19: + + <antrik> tschwinge: BTW, what happened to the plan of killing help-hurd? + <antrik> (and possibly some other lists) + <tschwinge> antrik: That plan got stalled, obviously. ;-) + <tschwinge> antrik: Now, I had proposed to use hurd-dev for development, + and turn bug-hurd into a debbugs bug reportling list. That proposal has + not heard any supportive/unsupportive votes yet. + <tschwinge> hurd-devel. That's the name. + <tschwinge> And turn off hurd-devel-readers. And turn off help-hurd. + <tschwinge> And web-hurd. + <tschwinge> Keep l4-hurd. + <antrik> yeah, I haven't replied regarding bug-hurd vs. hurd-devel, as I'm + not quite sure myself + <antrik> on one hand, a dedicated bug list can be convenient; on the other + hand, this kind of splits always causes unnecessary overhead IMHO + <antrik> also, hurd-devel would obviously be *only* for development, so in + this scenario we actually would *need* to keep something like help-hurd + as well... + <antrik> I think I'd prefer the non-exclusive mode for debbugs... would + have to check again how it works exactly though :-) + <tschwinge> antrik: I quite liked that exclusive mode for it automatically + archives discussions grouped by threads for easy reference. + <tschwinge> antrik: And, the very most of bug-hurd emails are ``issues'' of + some sort: bug report, patch (that needs to be tracked until it is + applied, etc. + <antrik> tschwinge: exclusive mode would just mean that people would take + most of these discussion elsewhere, and the bug list would only be used + when someone explicitly wants something tracked as a bug... + <antrik> ideally, the bug tracker should only track things if explicitly + CCed. ideally, it should be possible to forward mails that have been + posted without CC, so they can be tracked retroactively... + <tschwinge> antrik: Why do you think that people would take discussions + elsewhere? + <antrik> because most people don't consider it useful to put every random + question or remark in an issue tracker + <antrik> IMHO it should be easy to turn messages into tickets/followups; + but it should not happen automatically + <tschwinge> What if people wouldn't even notice that their issues is kept + in a tracker, too? + <draculus> It might send a notification of some sort? + <antrik> I once posted to a list with RT in exclusive mode, and quite + frankly, I considered it rather strange to get a ticket created for my + message :-) + <antrik> tschwinge: that would only be useful if you always close tickets + for irrelevant or finished discussions, mark duplicates etc. -- and this + would have to happen silently, without noise for most other people + following the list... + <antrik> tschwinge: are you sure you want to do that?... :-) + <tschwinge> Yes. + <tschwinge> Because that way we don't lose so much stuff as we currently + do. + <antrik> well, the decision is up to you in that case... + <tschwinge> In fact, probably less than manually archiving the content, as + I'm doing now, partially. + <tschwinge> antrik: Well, I'm just out for getting some comments. + <antrik> it would further reduce our bus factor though :-( + <tschwinge> That already is low enough that it doesn't matter anymore... + <tschwinge> antrik: So, to sum up, you'd use non-exclusive mode, but are + not actively opposed to exclusive mode as long as it doesn't too much + disturbe any procedures you're currently using? + <antrik> well, if it happens mostly in the background, I don't see why + anyone should be opposed... + <antrik> just make sure people posting to the list don't get a "ticket + created" message in response :-) + <antrik> it would make it harder though for people to explicitly track + issue they are interested in I fear + <antrik> when using non-exclusive mode, and people explicitly CC things to + the tracker, which sends a notice about a ticket being created, everyone + sees that and can act accordingly. if everything happens in the + background, few people would even think about it... + <antrik> so non-exclusive mode probably needs more effort to keep in order; + but it would be more useful too... + <tschwinge> Well, but with exclusive mode, people don't lose anything + compared to the current state, do they? + <antrik> tschwinge: probably not compared to the current state... but + possibly compared to a well-used non-exclusive mode :-) + + +# Further Systems + + * ikiwiki + + * <http://ikiwiki.info/tips/integrated_issue_tracking_with_ikiwiki/> + + * <http://ikiwiki.info/todo/Better_bug_tracking_support/> + + * <http://ikiwiki.info/todo/tracking_bugs_with_dependencies/> + + * <http://ikiwiki.info/todo/Updated_bug_tracking_example/> + + * <http://bugseverywhere.org/> |