I wrote some stuff to deal with defect.o.o : http://cr.opensolaris.org/~error404/doobug.diff
couple questions on it though: how important is it that the mappings are the same for names. That is, 'synopsis' in bugster terminology translates to short_desc in bugzilla terminology Anyone have ideas on how to make BugDB's constructor look up in the correct database sanely? Thanks -JohnS On 10-Sep-08, at 1:51 PM, Mark J. Nelson wrote: > S-M-D folks-- > > Bonnie was looking for a "reasonably sized" chunk of work for John > to chew on. Since he lists Python on his resume, I suggested a > whack at the bug lookup classes in DbLookups. We don't get John to > abuse as a dedicated member of the project team, but rather he's on > loan, and we should treat him well to trick him into liking us and > wanting to continue helping us out. ;) > > > > John-- > > If you're not already on it, please subscribe to scm-migration-dev at > opensolaris.org > . > > Then take a look at the "usr/src/tools/onbld/Checks/DbLookups.py" > list under the "Post-tools-integration followup issues" section of > http://www.genunix.org/wiki/index.php/ToolsReviewFeedback page. > It's not a thorough problem statement, but if you look in the tools > code underneath usr/src/tools/onbld, you can probably figure out the > gist of what we want/need. > > The "work with defects.opensolaris.org" part is to get us ready for > tools eventually working with an external defect tracking system. > The "share a common interface" part applies to BooBug, Monaco, and > the not-yet-written DooBug code; they really should be properly > subclassed. > > Then make sure you're registered on the Bugzilla instance at > http://bugs.grommit.com/ > , and take a look at these marginally related bugs: > > 140 DbLookups.ARC & Comments should coalesce ARC queries > 495 rti check logic could be enhanced to deal with multiple returns > 496 DbLookups should consider following RTIstatus with RTIget > > Thanks, and please ask the alias for questions/clarifications/ > review. I obviously left out a fair amount of info, but those are > good starting points. (Hint: if the above doesn't get you to a > clear statement of the problem(s) you're trying to solve, give me a > call or e-mail the team.) > > --Mark
