1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
|
[[!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 <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.
|
