incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cory Johns <>
Subject Re: Trac Ticket importer & html2text
Date Wed, 20 Nov 2013 16:56:03 GMT
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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message