[OH-Dev] Moving bug scrapers out of the main code: thoughts?

[Will Kahn-Greene]

If the code gets factored out of OH and we end up with more libraries like 
redminelib (feel free to tell me to rename it), it would be helpful if 
there was some kind of "specification" or "standard" that defines the API 
requirements the library needs to maintain.  Then if these bug 
scraping/acquiring/querying libraries continue to meet those API 
requirements, it would make it easier to use in OH.

Having said that, I'm not 100% positive that that's the right direction to 
approach this.  But the goal would be to reduce someone's work at some 
point because of some kind of standardized something or other.

/will


On Mon, 12 Sep 2011, Asheesh Laroia wrote:

> Hey all,
>
> Right now, we have some code in the main OpenHatch codebase that downloads 
> bug data from remote bug trackers.
>
> Will Kahn-Greene started working on a library to pull data out of 
> Redmine-based bug trackers here: https://github.com/willkg/redminelib/ and it 
> got me thinking.
>
> Maybe the OpenHatch bug tracker download code should be factored out of the 
> main website, and made available as a separate module for others to use. Here 
> are some advantages:
>
> * When (if) a bug arises in bug tracker import code, you don't have to set up 
> the entire website to fix the bug. New contributors (and old ones) can just 
> download that one module, run the test suite, discover it does not pass, fix 
> the bug, and send a patch.
>
> * By putting that code into a more clear place, it means it's easier to find 
> that code *and* easier to find other code in the rest of the codebase, 
> because you won't be distracted by bug tracker download code.
>
> * When people want to write support for more bug trackers (like the 
> discussions about adding Lighthouse and Github and Sourceforge as supported 
> bug trackers), it will be easier to add them.
>
> * Other people can use our bug tracker scraping code, which would increase 
> the number of prospective contributors to it.
>
> * Someone on this list (!) could step up as the bug tracker scraper 
> maintainer, if he or she wants, and it would be easy to see where your 
> responsibility starts and stops.
>
> * When people make changes to the web app, we can skip running the bug 
> tracker import tests.
>
> I'd be curious to hear if people have any thoughts on this: worth the time to 
> separate them out? Anyone want to be the maintainer of the bug tracker import 
> code? (I would happily co-maintain with you, and make suggestions.) (-:
>
> I especially am curious what people like Mark Cahill and Jessica Ledbetter 
> think, as people who have been interested in adding support for more bug 
> trackers.
>
> -- Asheesh.
>
> P.S. If we're interested in the idea, we can then argue about the details as 
> to how we'll separate it out -- one bug tracker per Python package? Who 
> knows.
>
> _______________________________________________
> Devel mailing list
> Devel at lists.openhatch.org
> http://lists.openhatch.org/mailman/listinfo/devel
>