Open Stack

On Thu, 2013-08-08 at 15:11 +0400, Boris Pavlovic wrote:
> Mark, 
> 
> 
> >> What do you mean by "dangerous code merging" in the subject? The
> body of
> >> your mail doesn't make any reference to whatever "danger" you're
> seeing.
> 
> 
> 
> I mean that cut and paste approach is really unsafe. For example some
> new member is able to change oslo code directly during syncing with
> some project,
>  and nobody will be able to catch such things.
> 
> 
> I didn't catch any of such situation, but I saw a lot of attempts to
> change openstack/common/* directly.
> (and it is really close situation..)

Got examples?

It's a reviewer's responsibility to enforce that openstack/commmon/*
code is just synced from oslo-incubator without modifications, but
there's always an element of trust in reviewing - you can't completely
guard against people doing dumb or nefarious things.

We could come up with some automation where the oslo-incubator git
commit ID corresponding to each file is included in each project's repo
and a test checks that the file does in fact correspond to that commit
ID. Needs someone willing to implement it.

> >> The idea of using submodules has come a few times. I don't have a
> >> fundamental objection to it, except any time I've seen submodules
> used
> >> in a project they've been extremely painful for everyone involved.
> 
> 
> 
> oslo-incubator sync util and submodules solves the same problem,
> almost in same way: 
> sync util -> copy paste code from <hash>
> submodules -> just set <hash> of commit from what to use code
> 
> 
> So I think the problem is not in submodules, problem is in approach of
> common code for different projects.
> But IMHO it is much better to have problems around creating common
> code that is used by all projects, then to make
> N different solutions for N different projects doing almost the same
> things. 
> 
> 
> 
> 
> >> I'd be happy to look at a demo of a submodule based system for
> projects
> >> to use code from oslo-incubator.
> 
> 
> 
> Probably we should just try, and analyze what approach is better?

Sounds good. Just needs someone willing to implement it.

Cheers,
Mark.