IMO, perform as little core re-engineering as possible, and move rapidly towards a release. So, strip Hg rather than rebuild.
Second, as a consumer of this project, having *no* SCM is simply ridiculous and a non-starter. I cannot imagine any possible installation or use-case without SCM. My view is that you start with SCM, and build on top of that with something like Allura. Cheers, -g On Aug 10, 2012 4:44 PM, "Peter Hartmann" <[email protected]> wrote: > W dniu 07.08.2012 03:22, Dave Brondsema pisze: > > Yep. Each "tool" is a separate pluggable discoverable python package. We >> could just bring it back into the main repo then. (The work Peter's doing >> on #3883 is to remove some unnecessary coupling between the core package >> and the scm tools - tests mostly iirc) >> > > As I mentioned on IRC, coupling proved to be more tight than tests and > I've started looking into separating SCM support altogether. Which brings > up the question: how much separated do we want it to be? For example, > should Allura's vanilla install not mention any SCM at all, or should it > point that "SCM support is available once you install a Tool of your > choosing", or something else? > > In my opinion, it would be more pragmatic to leave any notion of SCM to > individual Tools, so that Allura's core becomes less "opinionated" about > the choice of tools to use. But that would of course be much harder (if > possible at all) and perhaps require api changes :) But then again, perhaps > it's better to do it now, when most (all?) of publicly available tools are > maintained in Allura's repo source tree and can be adjusted at will. > > Hence i'm asking for input here. >
