incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wayne Witzel III <wwitz...@gmail.com>
Subject Re: Trac Ticket importer & html2text
Date Wed, 20 Nov 2013 16:32:34 GMT
I think having the ticket import be separate is a know solution to this existing problem. I
think for something as specific as a Trac Ticket import, I like it being a separate tool outside
of Allura core. Not only does it address the licensing but it follows existing conventions.
I think we should continue setting the standard that things like custom importers, that only
a select group will need, should not part of the core Allura distribution. 

Also I feel that having these tools be outside of the core distro makes the idea of contributing
a tool for Allura more attractive and approachable. I feel that the more examples of tools
we have the easier it will for contributors to make their own.

-- 
Wayne Witzel III (@wwitzel3)
wayne@pieceofpy.com
http://pieceofpy.com


On Wednesday, November 20, 2013 at 10:58 , Cory Johns wrote:

> The recent build failure has highlighted an issue with the Trac ticket
> importer. Namely, it relies on code in
> Allura/allura/scripts/trac_export.py which uses html2text, which is a GPL
> module and thus not a required library for Allura. However, even though
> the Trac ticket importer is optional and can be disabled, I believe it is
> enabled and exposed to the user by default.
> 
> We've dealt with this in the other importers by moving the importers that
> depend on html2text to a separate, externally packaged library, e.g.,
> TracWikiImporter (http://sf.net/p/tracwikiimporter/) and
> GoogleCodeWikiImporter (http://sf.net/p/googlecodewikiimporter/).
> 
> Personally, I'm not really a fan of having the importers packaged
> separately, since we had the discussion that it's better to keep tools in
> the core distribution if possible to help them stay maintained, but if
> that's the only option from a licensing standpoint, then there's nothing we
> can do. However, since we have the ability to selectively disable
> importers, I wonder if we've considered the option of having the importers
> live in the core distribution, but disable themselves by default if their
> requirements aren't met? Otherwise, we need to refactor the Trac ticket
> importer code out to a separate package. Either way, something will have
> to be done before our next release.




Mime
View raw message