incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: handling optional GPL dependencies
Date Sat, 11 Aug 2012 01:33:40 GMT
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" <mailbox.tec@gmail.com> 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.
>

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