incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brondsema <>
Subject Re: Trac Ticket importer & html2text
Date Wed, 20 Nov 2013 18:41:55 GMT
For reference, we had a thread about optional GPL deps a while ago.  The thread
is kinda long (also discusses default SCM support).
is a good single message to look at.

Both points are pretty good, so I personally I could go either way (optional in
this repo, or separate package) with this particular feature.  It's a little
more overhead to maintain a separate package, but you also save some effort by
not needing to maintain lots of "if html2text" checks.

At the end of the day I guess I'd slightly favor an external package, since this
isn't widely used.  It makes it clearly separate, and we already manage the trac
wiki importer separately without much trouble.

On 11/20/13 12:17 PM, Wayne Witzel III wrote:
> That seems reasonable for tools that are generic and have a broad audience, but I don’t
think the Trac Ticket importer tool is going to lose users because it isn’t part of the
core distro, since the users are the people who need to import Trac Tickets.  
> --  
> Wayne Witzel III (@wwitzel3)
> On Wednesday, November 20, 2013 at 11:56 , Cory Johns wrote:
>> Rich had raised the point that libraries that are packaged outside the core
>> have a much harder time maintaining visibility, and thus are much more
>> likely to lose developers and users.
>> On Wed, Nov 20, 2013 at 11:32 AM, Wayne Witzel III < (>wrote:
>>> 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)
>>> (
>>> 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/ 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 ( and
>>>> 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.

Dave Brondsema : : personal : programming

View raw message