[Devel] How to add a new bug tracker to OpenHatch
Asheesh Laroia
asheesh at openhatch.org
Sat Aug 28 02:37:54 UTC 2010
Excerpts from Jack Grigg's message of Fri Aug 27 01:48:38 +0000 2010:
> On 27/08/10 03:31, Asheesh Laroia wrote:
> > Hey all,
> >
> > I wrote some documentation on how to add bug trackers to
> > the OpenHatch codebase:
> >
> > http://openhatch.org/wiki/Bug_tracker_import_code/adding_a_bug_tracker
> >
> Couple of comments:
> - I think it should mention that the number of stale bugs can be
> monitored from http://localhost:8000/+meta/
> - The "simple bit of code per project bug tracker" is not necessarily a
> five-line Python class - that could lead people to leave required bits
> out. At the bottom of the Trac, Bugzilla and Google Code files I have
> left a (disabled) generic class for that tracker type, which can be
> directly copy-and-pasted to make a new one - would that be a better
> thing to point them to? (Much more eloquently than I have just said it
> of course ;D )
That sounds great. Would you make the changes? I'd love to see more
people than me and people submitting bug trackers (and, er, spammers)
editing the wiki. (-;
> I'm still not particularly happy with some of the layout in the Roundup
> tracker file - or rather, there are some disparities between the Roundup
> way and the Trac/etc. way (if/where/when bugs are deleted, bug objects
> directly used vs. dictionaries etc.) that I want to clear up. At some
> point (maybe in late September) I was thinking of going through it and
> the Trac/etc. code and bringing the two in line, so we have a single
> "style" of bug importing - important if we want to get a single web
> interface going for adding projects.
I like that idea. Would you file a bug?
> > I just added OpenHatch itself. (-:
> >
> I'd been meaning to do that for a while =)
(-:
> I just had a look at the bug search and saw that when looking at all
> bugs for a particular project, it lists all the bitesized ones first. If
> a project has a lot of bitesized bugs, it means that recently updated
> non-bitesized ones are masked. Is this an intended feature?
It represents a lack of full thought on our part. We figured bitesize bugs
ought to be seen first, but we didn't really think about non-bitesize bugs
being pushed down.
I guess one sensible option would be to let people change the sort order.
Would you file a bug pointing out that the current behavior is weird, at least?
(I'm asking you to do a lot of little bookkeeping work here and there! Others on
the list could too. Just trying to create more efficient habits among us all.)
-- Asheesh.
--
Among the lucky, you are the chosen one.
More information about the Devel
mailing list