[Reportbug-maint] Modularization work in progress
lawrencc at debian.org
Tue Jun 24 18:03:02 UTC 2008
As I've alluded to, I've been working on a modularized reportbug tree
for the past few weeks in a git repository. I'll probably (once I
figure out how to make this happen) create a Subversion branch then
commit the tree into that and keep it up to date with svn trunk, but
for now it's been a bit easier just to track the trunk locally and
rebase occasionally on the git end of things so it doesn't diverge
from the 3.42 development.
I'm attaching what I've got so far, which *mostly* works, but I
haven't tested everything and haven't adapted the unit test framework
to it yet or updated README.developers; nor have I separated out the
module in debian/control or done anything with adding SOAP support
from reportbug-ng to debianbts.py (which still is probably the most
wart-filled part of the code anyway).
Note that the diffs are a bit messy and reflect some changes in design
along the way (notably the "dreportbug" -> "reportbug" renaming). The
easiest way to run reportbug in-tree now seems to be:
PYTHONPATH='.' bin/reportbug (options)
If I get really lazy I may put that one-liner in a file in the root directory.
BTW, as a general policy I'm making use of Python 2.5-2.6 compatible
syntax (e.g. relative imports); there's no pressing need to update
older code to use 2.5+ idioms, but since the modularized design will
probably not be in Debian until lenny+1 we don't need to be too
worried about compatibility with Python 2.4 or earlier even for
backporting freaks since 2.5 ships as /usr/bin/python in lenny.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 84936 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/reportbug-maint/attachments/20080624/f7bc0418/attachment-0001.obj
More information about the Reportbug-maint