[openstack-dev] Osl and dangerous code merging
markmc at redhat.com
Thu Aug 8 11:21:03 UTC 2013
On Thu, 2013-08-08 at 15:11 +0400, Boris Pavlovic wrote:
> >> 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
> 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..)
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
> >> 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
> >> I'd be happy to look at a demo of a submodule based system for
> >> 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.
More information about the OpenStack-dev