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

pHilipp Zabel philipp.zabel at gmail.com
Fri Jun 13 16:25:37 UTC 2008


On Fri, Jun 13, 2008 at 4:09 PM, Koen Kooi <k.kooi at student.utwente.nl> wrote:
> pHilipp Zabel 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.
>
> I'd like to see that every commit has at least 2 SOBs, I care less on how
> they get there. Having the review out in the open should be the end goal,
> though.

>From Documentation/SubmittingPatches:
"The Signed-off-by: tag indicates that the signer was involved in the
development of the patch, or that he/she was in the patch's delivery path."

In the kernel Signed-off-by is primarily used to mark the way a patch
took into the kernel. If we do this, maybe we should use the same
nomenclature and have Acked-by for statements of approval. (And
eventually Tested-by/Reviewed-by, too?)

>> 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?
>
> Not that RP says "*partially* pull based model rather than just push based",
> which means that bigger changes get done on a branch (e.g. libtool update,
> Xorg updates, etc) and get pulled in after a review.
>
> regards,
>
> Koen
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

regards
Philipp




More information about the Openembedded-devel mailing list