This site is an archive; learn more about 8 years of OpenHatch.

[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