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
|
We want to track some bugs. The set of bugs we are interested in can not
be described in terms of any existing classification: it may include bugs
filed by ourselves, bugs that we have been bitten by but did not file; bugs
filed against our packages. It might not include some bugs caught by those
nets.
We will use a usertag to describe a bug as being tracked by this workflow
system. This usertag will be "debgtd.tracked".
If you tag all the bugs that you are interested in using this usertag, you
can then present that list of bugs to yourself. The web interface sorts the
bugs by severity. With a homebrew tool, you could also sort the list by date
of submission, package name, or something arbitrary like the bug number.
However what if you want a list of bugs that need your attention?
Assume for a moment that all bugs that we are tracking need our attention.
Why would a bug stop needing our attention?
Looking at my tracked bugs, the top one is an RFP. At some point I filed this
because I wanted the package. At this very point in time, does the bug demand
my attention? No.
We therefore want to hide bugs that are not relevant. We can do this with
another usertag, "debgtd.sleeping".
At some point in the future, all such sleeping bugs should be reviewed. Is
that RFP still relevant? Do I still want the package? Does it still exist?
Should I point it out on a few mailing lists, or just close it? Has it been
more than X amount of time that we are awaiting a maintainer response?
We therefore need a way of reviewing such bugs. This is actually quite tough.
If the bug's history includes the usertagging, we could fetch the bug in its
entirety and see if anything had been appended since the usertag was applied.
This could be quite expensive on the BTS.
Maybe a certain bug is only present on a certain machine. I may not be
interested in that bug unless I am using that machine (and could then provide
further diagnosis).
NMU procedural information:
http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu
* file the bug
* wait "a few days" for a response
* submit a patch
* wait "a few more days"
* announce nmu intention
* prepare nmu
* upload to delayed queue
* send final patch to bts, explain 7 day reaction
annotations
-----------
looking at my bug pile right now, I see some bugs that could use some
attention, perhaps to see if they still apply, etc.: I cant' do the actual
work now, but I could do with making a note of the identified "next action"
|
