[Reportbug-maint] Reportbug - Status of the union

Sandro Tosi matrixhasu at gmail.com
Sat Jul 12 17:39:28 UTC 2008


Hi all,
it seems to be a rather active period around reportbug & co.

I'm here to recap what's happening about 2 main points and make some
proposals: BTS interaction and GUI.

BTS Interaction
---------------

As of now, in reportbug we do all BTS querying "in house", with a
custom solution. There exists a couple of python package that we
should use instead:

python-btsutils - Python module to interact with debbugs servers
python-debianbts - Python interface to Debian's Bug Tracking System.

Personally, I'd go with the first, since it's there from more time
than python-debianbts, and I'd suggest Bastian (author of rb-ng and
python-debianbts) to leverage python-btsutils instead of use a new
package (that could cause some "political" issue).

There is even a note in TODO file in rb source code (but I'm going to
convert that list in BTS bugs, easier to track and comment; already
done for this: #490548).

Reportbug GUI
-------------

We all know that the text & urwid gui are not the "best" solution for
the normal users. There seems to be a lot of interest in creating a
new GUI for reportbug (ie, Ondrej's email of some weeks ago),
leveraging all the code we developed. Currently, we have these
packages to provide "gui alternatives" for reportbug:

reportbug-ng - An easy to use alternative to Debian's classic reportbug
gnome-reportbug - reports bugs in the Debian distribution (Gnome frontend)

g-rb would be the easiest to merge, since it was already thought to be
merged at its creation, just left outside rb because it was (is) not
fully working; it consist of barely a "reportbug_ui_gnome2.py" file
for a ui ready to be fixed&merged.

rb-ng has a Qt3 frontend, but uses a completely different codebase to
interface/report bugs. While I see things I really like in rb-ng code
(eg the MUA handling and a simpler, better organized/cleaner codebase
(since it started from scratch)) I do think that rb has better
functionalities, and many reporters/maintainers prefer to have them
available. Here the approach could be to merge/adapt missing/better
functionalities in rb-ng into rb, adapt the QT3 ui to work with rb,
maintaint the whole in our rb repository.

I think that maintaining the QT and GTK ui in different binary
packages is the right way to go: this way we can ship a "small"
package with text+urwid gui, and the users that prefer graphical ui
can install rb-gtk and/or rb-qt (that simple enhance the user
experience of reportbug into the modern gui world), avoiding to
introduce many Depends (graphical libs & bindings) that can be useless
to some.

Both of previous packages have RC bugs, which will prevent their
inclusion in lenny, so they need some work: and this can be done
together with the "migration" into rb.

Maybe we can start with g-rb, since easier, and Ondrej already
expressed interest in a GTK solution.

Since this approach could be read like "my package is better then
yours, please adapt and come under my nicer umbrella", the "political"
aspect could be the biggest problem, since we need to engage both
Bastian and Philipp to join (or some other form of contribution) our
team and work on GUI; of course, here Ondrej is welcome to join (when
he will ask, he's rather busy now) and work on GUI too

I'm looking forward to hear back from you really soon, to start the
"political" movements (emailing people and so) needed archive what
mentioned above.

Thanks for your attention,
Sandro

-- 
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi



More information about the Reportbug-maint mailing list