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
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
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 [[Service_solahart_jakarta_selatan__082122541663]] 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 [[Service_solahart_jakarta_selatan__082122541663]].
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/>
|
