head	1.2;
access;
symbols;
locks; strict;
comment	@# @;


1.2
date	2000.08.21.22.04.39;	author dwitch;	state Exp;
branches;
next	1.1;

1.1
date	2000.08.13.22.26.14;	author dwitch;	state Exp;
branches;
next	;


desc
@@


1.2
log
@- Small general and 0.2 updates
- First UI design considerations for 0.4
@
text
@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.)
@


1.1
log
@Initial revision
@
text
@d34 2
a35 1
is the occasion, so let's go for XML.  Or maybe Tangram ?
d40 4
a43 3
use, so I just went back to perl5 - I still believe 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.
d55 8
a62 6
DebBugs::RemoteBTS
DebBugs::RemoteBTS::LDAP
DebBugs::RemoteBTS::HTTP
DebBugs::RemoteBTS::SMTP
DebBugs::LocalDB
DebBugs::BugReport
d65 1
a65 1
Foreseen milestones [2000-06-29, ie. day0 + 1]:
d72 1
a72 1
package, severity, etc.)
d78 13
a90 4
		<id>9697</id>
		<title>kbd: missing manpages</title>
		<package>kbd</package>
		...
d97 3
a99 1
** Display list of bugs
d104 28
a131 1
* GUI: filter by sets of criteria
@
