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

Otavio Salvador otavio at debian.org
Fri Jun 13 17:17:42 UTC 2008


"Cliff Brake" <cliff.brake at gmail.com> writes:

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

I guess this together with something like linux-next would be nice.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio at debian.org      UIN: 5906116
 GNU/Linux User: 239058     GPG ID: 49A5F855
 Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
 you the whole house."




More information about the Openembedded-devel mailing list