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
|
Debian Maintainer Bug Tool
==========================
This is intended to be a simple tool to help a (presumably) busy
Debian Package Maintainer to manage his/her high number of bug
reports.
Wished features are:
* get states of one's bug reports from a debbugs database
* locally tag bug reports for various criteria - basically any set of
locally-defined categories.
* send commands to the debbugs DB, such as merging, renaming and such,
while keeping track of requests sent but not yet effective in the
remote DB.
Remote-BTS access library
=========================
DMBT is build atop a general-purpose library for remote access to the
Debian BTS.
Constraints on the whole
========================
GNOME looks like a worthy thing, so here is the occasion for me to
have a try at using it from programmer's side.
Neutral data storage may not be really necessary here, but again here
is the occasion, so let's go for XML. Maybe I could attempt to use
Tangram or Storable ?
There has already been work on connecting to a debbugs server in the
"reportbug" package. So I nearly had a try at python. But I could
not find enough docs for my tastes about the modules I intended to
use, so I just went back to perl5 - I'm not sure it was shorter for me
to write a Debbugs-accessing library in perl5 than learning Python and
finding out how to use its GNOME and XML libraries, but eh, it's done
now :}
Fortunately Ben Collins had implemented in perl LDAP access to the
BTS. His code saved me quite some time getting this part up and
running.
Required and wished functionalities
===================================
Provisional list of classes:
Debbugs::DMBT
Debbugs::DMBT::GUI
Debbugs::RemoteBTS
Debbugs::RemoteBTS::LDAP
Debbugs::RemoteBTS::HTTP
Debbugs::RemoteBTS::SMTP
Debbugs::LocalDB
Debbugs::BugReport
Foreseen milestones [2000-08-21, aka 0.1.2 time]:
0.2
* Interface with debbugs server using LDAP [DONE]
* XML data storage using debbugs-defined bug attributes (bugid,
package, severity, etc.) [DONE]
** List of bugs
<buglist>
<bug>
<bts>
<id>9697</id>
<title>kbd: missing manpages</title>
<package>kbd</package>
...
</bts>
<dmbt>
<fetchdate>966808436</fetchdate>
...
</dmbt>
<user>
...
</user>
</bug>
</buglist>
* Minimal GUI
** Display list of bugs [done]
** Simple display of bug details
0.4
* customization of bug summary list
** dialog with:
- list of available attribs
- list of selected attribs
- buttons to move an attrib between those lists
- buttons to move an attrib up/down in selected set
* filter summary list by sets of criteria
Wished expressive power:
- OR between possible values of a single attrib
- OR/AND combinations of the above for all attribs
Maybe keep this for an "advanced filter" dialog, and use a
simpler thing for quick everyday use ? This would require to
understand what will be used most often...
A "all OR" interface with a multi-select list for each attrib
may be a good start ? A "convert to advanced" feature could be
used when not expressive enough.
Still not sure how to do a simple UI for the OR/AND above, without
using a script-like expression.
* better layout for bug summary list (Clist ? Table ? Sheet ?)
0.6
* Custom-defined key/value pairs
-> dynamically-created XML tags ?
List of custom-defined catagories fits well in XML:
<categorylist>
<categ>
<key>Type</key>
<value>Data fix</value>
<value>New data file</value>
<value>Debian packaging issue</value>
...
</categ>
...
</categorylist>
0.8
* Multiple views of the list (that is, different sets of criteria)
0.10
* A way to only have a specific category available when a
specific key has a specific value (eg. for one/several packages)
1.0
* HTTP and SMTP interface with debbugs server, as LDAP access is not
offical and may disappear some day without notice.
* Multiple sets of bugs (eg: attributed to myself, those I reported,
the RC bugs, etc.)
|
