incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Bollweg <nick.boll...@gmail.com>
Subject Re: what goes in the core Allura repo (was Re: Presentation and Metrics work in Allura)
Date Tue, 23 Oct 2012 20:08:54 GMT
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.

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