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)
Best regards,
Boris Pavlovic
On Wed, Jun 3, 2015 at 2:12 AM, Robert Collins <robe...@robertcollins.net>
wrote:
> On 3 June 2015 at 10:34, Jeremy Stanley <fu...@yuggoth.org> wrote:
> > On 2015-06-02 21:59:34 +0000 (+0000), Ian Cordasco wrote:
> >> I like this very much. I recall there was a session at the summit
> >> about this that Thierry and Kyle led. If I recall correctly, the
> >> discussion mentioned that it wasn't (at this point in time)
> >> possible to use gerrit the way you describe it, but perhaps people
> >> were mistaken?
> > [...]
> >
> > It wasn't an option at the time. What's being conjectured now is
> > that with custom Prolog rules it might be possible to base Gerrit
> > label permissions on strict file subsets within repos. It's
> > nontrivial, as of yet I've seen no working demonstration, and we'd
> > still need the Infrastructure Team to feel comfortable supporting it
> > even if it does turn out to be technically possible. But even before
> > going down the path of automating/enforcing it anywhere in our
> > toolchain, projects interested in this workflow need to try to
> > mentally follow the proposed model and see if it makes social sense
> > for them.
> >
> > It's also still not immediately apparent to me that this additional
> > complication brings any substantial convenience over having distinct
> > Git repositories under the control of separate but allied teams. For
> > example, the Infrastructure Project is now past 120 repos with more
> > than 70 core reviewers among those. In a hypothetical reality where
> > those were separate directory trees within a single repository, I'm
> > not coming up with any significant ways it would improve our current
> > workflow. That said, I understand other projects may have different
> > needs and challenges with their codebase we just don't face.
>
> We *really* don't need a technical solution to a social problem.
>
> If someone isn't trusted enough to know the difference between
> project/subsystemA and project/subsystemB, nor trusted enough to not
> commit changes to subsystemB, pushing stuff out to a new repo, or
> in-repo ACLs are not the solution. The solution is to work with them
> to learn to trust them.
>
> Further, there are plenty of cases where the 'subsystem' is
> cross-cutting, not vertical - and in those cases its much much much
> harder to just describe file boundaries where the thing is.
>
> So I'd like us to really get our heads around the idea that folk are
> able to make promises ('I will only commit changes relevant to the DB
> abstraction/transaction management') and honour them. And if they
> don't - well, remove their access. *even with* CD in the picture,
> thats a wholly acceptable risk IMO.
>
> -Rob
>
> --
> Robert Collins <rbtcoll...@hp.com>
> Distinguished Technologist
> HP Converged Cloud
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
