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. _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
