[[!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]]."]]"""]] There are the Savannah trackers. Nobody really likes them. There is a proposal to add/move to . 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: So. Savannah trackers vs. Open Issues vs. debbugs. Any input? I like *both* open issues and debbugs open issues is good for exposing things that people may encounter in other situations while debbugs is useful to actually work on a bug youpi: The advantage of debbugs being the email interface and the well-known procedure, or something else? email interface, which nicely flows into a mailing list the savannah bug updates suffer from the additional layout How does one decide what to put in a debbug and what in an Open Issue page? I'd say it's not exclusive at all 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 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 OK. (some general short coming I mean, like SIGINFO) 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? What we can do is inhibiting the creation of new issues in the trackers. I'd say move else they will be forgotten Hrm. 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 :-) err... trac-like yes, the wiki part is really useful to keep a good summary of the issue antrik: Same for me. I always hoped that someone would do it... :-) hehe antrik: But, as you surely know, this email parsing business is just too ugly to do realiable, etc. 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 :-) additional to open_issue you mean? yes, but like you say :) tschwinge: hm... seems to work well enough it debbugs debbugs just piles things and has a few commands you'd still need the web interface to edit the wiki part for instance of course. that wouldn't change at all (except for adding a tagging GUI perhaps) (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...) antrik: a .mdwn diff should however be sent to the bug for information 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 debbugs surely has the advantage that it is available (nearly) right now. RT (request tracker) and ikiwiki play quite nicely together. mattl: You'Re using that at GNU/FSF/somewhere, right? you can close tickets from the wiki, and RT has a good command line interface, email interface and web interface. tschwinge: yeah, we use RT and ikiwiki. RT for all FSF communications, and ikiwiki for internal organising. RT is not the easiest thing to set up, but works pretty well once it's running.