[[!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.