Very good point about versions. I'm thinking that we should keep the core small, and additional tools should be separate codebases, but still encourage & promote them as part of the Allura community. I've created a simple starting page at https://sourceforge.net/p/allura/wiki/Extensions/ to start listing them.
So if this is the direction that we do go (haven't heard any dissent), that would mean not merging the Bitergia Metrics app into the Allura main codebase but keep it separate. Regarding brittleness between tools, we need to start moving away from the magic globals c and g anyway. Too much implicit shared state. At some point, we can set up Allura test builds on https://builds.apache.org/ and I think it'd be great to set up more builds to run "external" tools' test suites with each change to Allura to make sure core changes don't break other tools. -Dave On 10/23/12 4:08 PM, Nicholas Bollweg wrote: > My 2c, based on doing some heavy customization of Allura: > Given the robustness of the setuptools-based system, I would see it as > beneficial to deployers to have as much choice as possible in selecting > tools with real versions on them. This would allow managing their > installation via pip, with their configuration in their production.ini. We > were bit more than once by just working off production tags > (allura_20xxxxxx). > > For example: others have already expressed dissatisfaction with the > complexity that ForgeSVN introduces at setup time, and an organization that > embraces git/hg is unlikely to have svn around except perhaps for legacy > codebases and mirrors of external code (though the DVCSs can handle that, > too). > > Of course the challenge, especially with the VCS tools, is the level of > hoop jumping that must occur to get all of the content exposed through the > SSH host, which has got to be my least favorite part of the exercise: I > could see how refactoring this out to be aware in a separate environment > would complicate things. > > I think "small core" would allow focusing on improving infrastructure that > differentiates Allura from other more general web frameworks: opt-in > elements on Artifact (like comments and voting), generalized diffing, > neighborhoods and projects, robust permissions, indexed search, API > specifications, async tasks, reusable themed widgets, analytics, asset > optimization and other stuff that doesn't work right if everyone does it > differently. Further, the version of core would become more meaningful (and > stable), which helps give create clarity and common purpose. The > unfortunate thing would be the increased brittleness across many tools: > who's doing what to magic `c` and magic `g`? This would require some pretty > serious automated, matrixed testing of install, operation and migration. > -- Dave Brondsema : [email protected] http://www.brondsema.net : personal http://www.splike.com : programming <><
