[oe] Switching SCM to git and commit/review policy
Otavio Salvador
otavio at debian.org
Mon Jun 16 13:16:18 UTC 2008
Rolf Leggewie <no2spam at nospam.arcornews.de> writes:
> Otavio Salvador wrote:
>> - an oe-next tree could be done that grabs from usual contributors
>> and merge daily to check for conflicts and warn the developers
>> (mostly the same concept of linux-next)
>
> This is an extension of an idea from Florian Boor, which at first I was
> sceptical about, but which I'd like to put out here in the open because
> I can start to see how it might work. It also has the potential to
> reconcile "no human intervention/automation" with "maximum review possible".
>
> We have a stable tree which remains as is. We create an unstable tree
> which is where stuff is being committed to. There is a review period of
> say 2 days after which changes from .unstable are automatically moved to
> .dev unless there is an objection from a developper. NACK'ed changesets
> need to be flagged as such to prevent them from moving from .unstable to
> .dev
>
> This is very similar and inspired by the Debian release process
> (unstable -> testing -> stable). The big difference is that we are
> dealing with code changesets where debian's objects are released binary
> packages.
>
> Would that be feasible and helpful?
In my opinion it will not work fine. I see following prolems:
- the tree will be a moving target, without stable revision numbers
and difficult to merge, base work in and like
- most of the pros can be done using the oe-next tree. Doing a full
compilation of changed modules before and after each merge gives a
nice feedback for trivial problems
- Being available on unstable doesn't mean it'll be tested
- 2 days is a too short testing window
--
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