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

[Koen Kooi]

Graeme Gregory wrote:
>> 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.

I'd expand that area to the stuff task-boot covers (init, udev, busybox, 
etc), and maybe even packages/linux.

>
> 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