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

[Koen Kooi]

Cliff Brake wrote:
> 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.

That won't work, since people will 'accidentally' misread the list to 
avoid review.