incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Bowen <rbo...@rcbowen.com>
Subject Re: what goes in the core Allura repo (was Re: Presentation and Metrics work in Allura)
Date Wed, 31 Oct 2012 15:23:15 GMT

On Oct 30, 2012, at 2:26 PM, Dave Brondsema wrote:

> 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.


Sorry if I'm coming late to the conversation. It appears that I misunderstood the direction
that it was heading.

I'd like to understand specifically what is meant here by "separate".

I'm a strong believer in small core, everything as extensions. However, it seems that those
extensions should be in the Allura repo, not off on some third-party site, where they won't
get the love, testing, and cross-polination that they'd get if they were part of our main
repo. If the code in question is licensed in such a way that makes it possible, why would
we not have it in an extensions directory within our repo?

I feel like we're going to build the maximum amount of synergy around our platform if we welcome
folks to all play in the same sandbox, and to play with one another's toys. At release time,
if something is still considered broken, or experimental, or incomplete, it doesn't go into
the release. I'm very concerned that if we tell folks to go develop elsewhere, we're going
to lose opportunities for contributions in other parts of the code.

Are we on the same page here, or is the intent in fact that these be developed elsewhere?

-- 
Rich Bowen
rbowen@rcbowen.com
Shosholoza



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