Open Stack

Excerpts from Boris Pavlovic's message of 2015-06-02 16:36:20 -0700:
> Jeremy,
> 
> >  the Infrastructure Project is now past 120 repos with more
> > than 70 core reviewers among those.
> 
> 
> I dislike the idea of having 120 repos for single tool. It makes things
> complicated for everybody:
> documentation stuff, installation, maintaing, work that touches multiple
> repos and so on..
> 
> So I would prefer to have single repo with many subcores.
> 
> 
> Robert,
> 
> We *really* don't need a technical solution to a social problem.
> 
> 
> We really need... It's like non voting jobs in our CI (everybody just
> ignores).
> Btw it will be hard for large core team to know each other.
> Especially if we are speaking about various groups of cores that are
> mantaining
> only parts of systems. Keeping all this in heads will be hard task (it
> should be automated)
> 

I can see how it might seem similar to gating. However, there is a major
difference.

Gating is there to prevent automatically detectable problems from
hampering developers. We do it because fixing such things is stressful
and tedious. However, the ACL's you suggest developing aren't entirely
knowable, and in fact, if they were, this wouldn't even be a debate,
we'd just split things up and make smaller teams.

I love the idea of having a nice clean hierarchy. However, the reality
is that such hierarchies are as likely to be dead wrong as they are to
be correct. I'm willing to make a judgement call as a core on a project
and say "Yes I think $PROSPECTIVE_SUBTEAM_CORE is capable of considering
whether or not this is entirely contained in their subsystem or not."
I'm not so sure I'm willing to spend any time trying to think hard about
which files that subteam has access to, nor do I want to maintain such
a list in perpetuity.