[oe] Switching SCM to git and commit/review policy

Graeme Gregory dp at xora.org.uk
Tue Jun 24 09:57:35 UTC 2008


> We've not made any decisions on what the commit/review policy should be,
> this is open for discussion. We're thinking it may take the form of some
> kind of kernel style Signed-off-by: tags and a switch to a partially
> pull based model rather than just push based as we use monotone so more
> than one developer handles any given change.
> 
I have been thinking on this and here is my suggestion.

One thing that has been noted has been the high level of work required
to review every change to every package.

Every time more than two OE people get together we keep talking about
splitting OE into two. Maybe it is time to consider actually doing it.
My suggestion would be along the rough lines of the following.

1) OE-core - everything needed to get upto a successful glibc build
completed so gcc, gcc-cross, binutils and support packages. Also most
stuff in classes/. Breakages in these two areas are what hurts the most
and the area we have the least manpower in.

In this section we would have proper reviews and I would suggest no
change without two OE-core developers signing off on it. (OE-core
developers being possible a different group than the political OE core).

2) OE-universe - all the other stuff, the recipes and distro configs.
The stuff where breakage tends to be less painful we keep as is. With
people not being afraid to got git-revert on stupid changes. Yes you do
need to test building all users of a .inc file or patch when you change
them.

If we find this system is working and we think we can handle the extra
load we can always start to raise the bar. For example we could change
core to 3 signoffs and universe to 2. But I think a little of this
trying a new SCM will be seeing how peoples workflow changes. I know
from OM git usage I was suddenly spending less time on complex merges
and had more time to think.

Anyway thats my 2p.

Graeme





More information about the Openembedded-devel mailing list