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 <wwitz...@gmail.com>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) > wa...@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. > > > >
