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

[Cliff Brake]

On Fri, Jun 13, 2008 at 6:06 AM, pHilipp Zabel <philipp.zabel at gmail.com> wrote:
> On Fri, Jun 13, 2008 at 10:20 AM, Richard Purdie <rpurdie at rpsys.net> wrote:
>> As always, there is a but. This change is conditional on being able to
>> come up with a sensible commit and review policy for OE.dev. The core
>> team does feel that the metadata quality has dropped over time in some
>> areas and we need to have a better review process. The change to an SCM
>> with good branch support is a vital part of this but not the only part.
>>
>> 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.
>
> Personally, I'd like to see every patch to OE being sent to and
> reviewed on the mailing list.
> About a pull based model, wouldn't we need something like the kernels'
> subsystem maintainers to share the load? Seeing that there already
> seems to be a serious manpower problem, who would have the time to do
> that?

One of the differences with the OE meta data is that its structure is
rather flat instead of a nice hierarchy like the kernel.  Another
problem is an update in one of the core components can often have
unforeseen consequences in other packages.  So I don't think there is
any substitute for a lot of testing.  A lot of the work to keep it all
going is simply busy-work -- updating URI's, adding new versions of
packages, etc, so I would hate to slow that down.  How about coming up
with a list of directories/files that need mail list review:

- classes
- conf/bitbake.conf
- conf/distro
- packages/images
- packages/tasks
- packages/linux/linux.inc
- packages/glibc/
....

Perhaps with everything else (machines, random packages), it would be
strongly advised that you get sign-off from the maintainer of that
recipe if listed.  This would help encourage the maintainers to stay
involved.

Cliff

-- 
=======================
Cliff Brake
http://bec-systems.com