Switching SCM to git and commit/review policy

Switching SCM to git and commit/review policy

[Richard Purdie]

After much discussion the OE core team unanimously agree that a change
of SCM to git would be in the best interests of the project. The main
reasons for this are:

* more powerful merging/branching capabilities in git
* better web facilities to browse changes
* better performance
* larger and more active userbase
* lack of developer momentum with monotone

There has been discussion about this on the developers list in the past
where most viewpoints were well represented and we don't really feel
that opening the choice of SCM for further discussion would be
beneficial although obviously anyone is free to raise serious objections
to this.

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.

The timescales for switching are not yet established and whilst we have
some server infrastructure in place, its not all there yet. Lets starts
the discussion on commit and review policy and in the meantime we'll
establish some timescales. I'd expect we'll aim to switch quite quickly
now the hard decision is made.

Finally, we'd like to mention that whilst some people have had issues
with it, on balance, monotone has served us well and want to thank the
monotone guys for the help and support they've given us.

The OE Core Team

Re: Switching SCM to git and commit/review policy

[pHilipp Zabel]

On Fri, Jun 13, 2008 at 10:20 AM, Richard Purdie <rpurdie@rpsys.net> wrote:
> After much discussion the OE core team unanimously agree that a change
> of SCM to git would be in the best interests of the project. The main
> reasons for this are:
>
> * more powerful merging/branching capabilities in git
> * better web facilities to browse changes
> * better performance
> * larger and more active userbase
> * lack of developer momentum with monotone
>
> There has been discussion about this on the developers list in the past
> where most viewpoints were well represented and we don't really feel
> that opening the choice of SCM for further discussion would be
> beneficial although obviously anyone is free to raise serious objections
> to this.

Good news.

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

> The timescales for switching are not yet established and whilst we have
> some server infrastructure in place, its not all there yet. Lets starts
> the discussion on commit and review policy and in the meantime we'll
> establish some timescales. I'd expect we'll aim to switch quite quickly
> now the hard decision is made.
>
> Finally, we'd like to mention that whilst some people have had issues
> with it, on balance, monotone has served us well and want to thank the
> monotone guys for the help and support they've given us.
>
> The OE Core Team

regards
Philipp

Re: Switching SCM to git and commit/review policy

[Cliff Brake]

On Fri, Jun 13, 2008 at 6:06 AM, pHilipp Zabel <philipp.zabel@gmail.com> wrote:
> On Fri, Jun 13, 2008 at 10:20 AM, Richard Purdie <rpurdie@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

Re: Switching SCM to git and commit/review policy

[Koen Kooi]

pHilipp Zabel wrote:
> On Fri, Jun 13, 2008 at 10:20 AM, Richard Purdie<rpurdie@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.

> 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

Re: 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@gmail.com>  wrote:
>> On Fri, Jun 13, 2008 at 10:20 AM, Richard Purdie<rpurdie@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.

Re: Switching SCM to git and commit/review policy

[pHilipp Zabel]

On Fri, Jun 13, 2008 at 4:09 PM, Koen Kooi <k.kooi@student.utwente.nl> wrote:
> pHilipp Zabel wrote:
>>
>> On Fri, Jun 13, 2008 at 10:20 AM, Richard Purdie<rpurdie@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@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

regards
Philipp

Re: Switching SCM to git and commit/review policy

[Otavio Salvador]

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

> On Fri, Jun 13, 2008 at 6:06 AM, pHilipp Zabel <philipp.zabel@gmail.com> wrote:
>> On Fri, Jun 13, 2008 at 10:20 AM, Richard Purdie <rpurdie@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@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."

Re: Switching SCM to git and commit/review policy

[Koen Kooi]

pHilipp Zabel wrote:

>>> 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?)

That is probably a good idea.

regards,

Koen

Re: Switching SCM to git and commit/review policy

[Tom Rini]

On Fri, Jun 13, 2008 at 08:43:49AM -0400, Cliff Brake wrote:

[snip]
> 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:

Here's my 2 cents, as occasional contributor without write access and
without a good friend with write access.  Whatever the process, things
need to not get "lost" either in the ML noise or in the bugzilla,
possibly waiting for the "maintainer" to speak up.

-- 
Tom Rini

Re: Switching SCM to git and commit/review policy

[Otavio Salvador]

Koen Kooi <k.kooi@student.utwente.nl> writes:

> pHilipp Zabel wrote:
>
>>>> 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?)
>
> That is probably a good idea.

I don't know how kernel people do to amend the patch to add the
acked-by/whatever data into each patch. It can be a big amount of work
to do an iteractive rebase for every ack given on ml for each patch
and with a high risk of human mistake while doing it.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@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."

Re: Switching SCM to git and commit/review policy

[Holger Freyther]

On Friday 13 June 2008 20:38:23 Otavio Salvador wrote:

> I don't know how kernel people do to amend the patch to add the
> acked-by/whatever data into each patch. It can be a big amount of work
> to do an iteractive rebase for every ack given on ml for each patch
> and with a high risk of human mistake while doing it.

For (qt)webkit we have a script to merge a git branch. It is amending the 
commit with such a line. To grab patches from the ML one could use 
git-am/git-apply and then use the script to merge/cherry-pick the changes.

z.

Re: Switching SCM to git and commit/review policy

[Otavio Salvador]

Holger Freyther <zecke@selfish.org> writes:

> On Friday 13 June 2008 20:38:23 Otavio Salvador wrote:
>
>> I don't know how kernel people do to amend the patch to add the
>> acked-by/whatever data into each patch. It can be a big amount of work
>> to do an iteractive rebase for every ack given on ml for each patch
>> and with a high risk of human mistake while doing it.
>
> For (qt)webkit we have a script to merge a git branch. It is amending the 
> commit with such a line. To grab patches from the ML one could use 
> git-am/git-apply and then use the script to merge/cherry-pick the changes.

Yes, if it's done using maintainers, it works fine. Since you can add
the --signoff but if we don't have this kind of workflow it'll be a
big hassle to be done.

In linux I guess most maintainers grab the patches from ml and use
git-am -s to apply them. This makes easy for them ... in our case, if
we don't communicate thought ml, add sign-of-by can be difficult since
we'd need to do it patch by patch.

From my POV, the policy could be:

 - individual patches / small patchsets should go throught ml; someone
   at OE core team could apply them and use git-am -s for it

 - big changes should be done using external trees; people discuss the
   patches using ml but a pull request should be done and merged by
   someone at OE core team

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

What people think about that?

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@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."

Re: Switching SCM to git and commit/review policy

[Rolf Leggewie]

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?

Re: Switching SCM to git and commit/review policy

[Mark Brown]

On Fri, Jun 13, 2008 at 03:38:23PM -0300, Otavio Salvador wrote:

> I don't know how kernel people do to amend the patch to add the
> acked-by/whatever data into each patch. It can be a big amount of work
> to do an iteractive rebase for every ack given on ml for each patch
> and with a high risk of human mistake while doing it.

For the most part everything except the Signed-off-by is added by the
patch submitter as they submit and resubmit the patch - often that
information will just get dropped on the floor otherwise.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

Re: Switching SCM to git and commit/review policy

[Otavio Salvador]

Rolf Leggewie <no2spam@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@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."

Re: Switching SCM to git and commit/review policy

[Rolf Leggewie]

[resending mail from 13:02 MESZ which apparently got lost somewhere]


Otavio Salvador wrote:
> What people think about that?

Sounds good to me, at least the most realistic proposal I saw so far.
Because it deals better with some short-comings in the "have every patch
touched by two devs"

1) we already have a *HUGE* backlog of patches in our bug tracker[1].
   This will only grow bigger if we require even more human intervention
2) it does not treat every patch the same, differentiation is needed
   IMHO, as well as efficiency and (semi)-automatic processes

Basically, I am fine with "commit to dev, test out, fix regressions if
present".  OTOH, "prevent regressions up front by reviewing everything"
will slow down .dev to a crawl, I am afraid.  Don't we have stable for
that very reason (less volatile code) and with exactly the "2 ACKs per
commit"-policy?   I am all for review for big changes and where
efficiently possibly, but I fail to see the value of it for example for
the type of work that I often do (the busy-work that Cliff Brake so
eloquently described on June 13th).

With the huge number of open bugs and things that need fixing which have
been untouched for ages, I am not convinced that slowing things down
even further is a step in the right direction.


Footnotes:
==========
[1]http://bugs.openembedded.net/buglist.cgi?keywords=patch&resolution=---

Re: Switching SCM to git and commit/review policy

[Rolf Leggewie]

Otavio Salvador wrote:
>  - the tree will be a moving target, without stable revision numbers
>    and difficult to merge, base work in and like

OE is always a moving target.  I don't see how the policy would change that.

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

Modules?  Are you talking kernel?  Or are you using modules as a synonym
for recipe?

>  - Being available on unstable doesn't mean it'll be tested

Neither does any of the other proposals ensure that.  "tested" sounds
like 0 or 1, but in fact it is a continuum.  I can at least think of the
following

- compiles fine
- compiles fine from scratch
- compiles fine from scratch for MACHINE/DISTRO X and Y
- tested to run on MACHINE X
- tested to run on all supported MACHINEs
- does not interfere with another package

What do you mean by "tested"?  How will other processes and policies
ensure that?

>  - 2 days is a too short testing window

well, that is of course just a proposal and thus easy to fix if necessary.

PS: This is not a rebuttal or a claim that the proposed policy is even a
desirable one.  But I feel there is more need for clarification.

Re: Switching SCM to git and commit/review policy

[Otavio Salvador]

Rolf Leggewie <no2spam@nospam.arcornews.de> writes:

> Otavio Salvador wrote:
>>  - the tree will be a moving target, without stable revision numbers
>>    and difficult to merge, base work in and like
>
> OE is always a moving target.  I don't see how the policy would change that.

The revisions will be a moving target. To tag a commit as "not-ok"
you'd need to amend it and  them change it rev number.

>>  - 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
>
> Modules?  Are you talking kernel?  Or are you using modules as a synonym
> for recipe?

recipe, sorry.

>>  - Being available on unstable doesn't mean it'll be tested
>
> Neither does any of the other proposals ensure that.  "tested" sounds
> like 0 or 1, but in fact it is a continuum.  I can at least think of the
> following
>
> - compiles fine
> - compiles fine from scratch
> - compiles fine from scratch for MACHINE/DISTRO X and Y
> - tested to run on MACHINE X
> - tested to run on all supported MACHINEs
> - does not interfere with another package
>
> What do you mean by "tested"?  How will other processes and policies
> ensure that?

We can't ensure that also because most of tests need to be done by an
human. I think that a sort of compile tests are enough to kill most of
problems.

We can also think about make a specific distro that is need to be
booted, using qemu or whatever, that ensures that basic stuff isn't
break due the change.

>>  - 2 days is a too short testing window
>
> well, that is of course just a proposal and thus easy to fix if necessary.
>
> PS: This is not a rebuttal or a claim that the proposed policy is even a
> desirable one.  But I feel there is more need for clarification.

Sure. I also believe this all need more discussion and
clarification. Mostly because I'm a begginer at OE world and then I
can miss understand a lot of things, sure.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@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."

Re: Switching SCM to git and commit/review policy

[Rolf Leggewie]

Otavio,

thank you for clarifying.

Otavio Salvador wrote:
> The revisions will be a moving target. To tag a commit as "not-ok"
> you'd need to amend it and  them change it rev number.

I was talking about a possible workflow with absolute disregard as to
how it is supported by tools out there, git in particular.  I think, at
this point in time it is OK to build your castle in the sky and worry
about how to implement that with tools later (and possibly make
necessary adjustments, then)

>> Modules?  Are you talking kernel?  Or are you using modules as a synonym
>> for recipe?
> 
> recipe, sorry.

Well, that is certainly nice, but not sufficient.  bitbake will not
necessarily rebuild an app if a lib changes IIRC.

> human. I think that a sort of compile tests are enough to kill most of
> problems.

NACK.  I don't agree.  They are necessary and good to be done.  They are
still insufficient.  Otherwise, we could fully automate the review
process and have a compile firm to automatically reject changesets that
lead to compile failures.

Regards

Rolf

Re: Switching SCM to git and commit/review policy

[Rolf Leggewie]

Koen Kooi wrote:
> That won't work, since people will 'accidentally' misread the list to
> avoid review.

That implies ill-will.  I don't agree with that assumption.

I'd also assume that somebody who misread the list (accidentally or
otherwise) and who then actually breaks something will get a powerful
reminder ;-)  Repeat offenders should also be easy to spot.

We should not reject a white/blacklist prematurely.

As far as getting maintainers involved, I agree that probably this will
be a difficult part since it can become complicated quickly (too many
things to check before making a commit)

Re: Switching SCM to git and commit/review policy

[Otavio Salvador]

Rolf Leggewie <no2spam@nospam.arcornews.de> writes:

> Otavio,
>
> thank you for clarifying.
>
> Otavio Salvador wrote:
>> The revisions will be a moving target. To tag a commit as "not-ok"
>> you'd need to amend it and  them change it rev number.
>
> I was talking about a possible workflow with absolute disregard as to
> how it is supported by tools out there, git in particular.  I think, at
> this point in time it is OK to build your castle in the sky and worry
> about how to implement that with tools later (and possibly make
> necessary adjustments, then)

I don't think so. What's the point in thinking a perfect solution that
will be problematic with the available tools?

>>> Modules?  Are you talking kernel?  Or are you using modules as a synonym
>>> for recipe?
>> 
>> recipe, sorry.
>
> Well, that is certainly nice, but not sufficient.  bitbake will not
> necessarily rebuild an app if a lib changes IIRC.

Sure but will rebuild the lib ... and a from scratch build when all
trees are merged in oe-next can be an nice way to find those problems
out too.

>> human. I think that a sort of compile tests are enough to kill most of
>> problems.
>
> NACK.  I don't agree.  They are necessary and good to be done.  They are
> still insufficient.  Otherwise, we could fully automate the review
> process and have a compile firm to automatically reject changesets that
> lead to compile failures.

Well, this is the most important part of my proposal. oe-next would be
an auto-nack process. If it fails to compile, nack and notify the
commiter.

Any other test will be need to be done case by case. Obviously that
something that touches a class is much more important to be carefully
tested then another patch that includes a new version of package
foobar used by a single user.

-- 
        O T A V I O    S A L V A D O R
---------------------------------------------
 E-mail: otavio@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."

Re: Switching SCM to git and commit/review policy

[Florian Boor]

Hi,

Rolf Leggewie wrote:
> With the huge number of open bugs and things that need fixing which have
> been untouched for ages, I am not convinced that slowing things down
> even further is a step in the right direction.

thanks! :) I share this opinion. In fact we had a lot of good ideas how to
improve the OE quality, but in my opinion this all is not realistic. Things in
the development branch can break - this is one reason why we have such a branch.
I would not want to trade OE's main advantages (agility, development speed and
the huge contributor community) for a semi-stable development branch.

If we have enough resources some time we could create such a semi-stable
'testing' branch with its own QA and commit policies. But for people with write
access no additional policies or review rules should apply. (Except for some
critical pieces such as classes and libc maybe.)

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76

Re: Switching SCM to git and commit/review policy

[Michael 'Mickey' Lauer]

Am Montag 16 Juni 2008 16:17:30 schrieb Rolf Leggewie:
> Sounds good to me, at least the most realistic proposal I saw so far.
> Because it deals better with some short-comings in the "have every patch
> touched by two devs"
>
> 1) we already have a *HUGE* backlog of patches in our bug tracker[1].
>    This will only grow bigger if we require even more human intervention
> 2) it does not treat every patch the same, differentiation is needed
>    IMHO, as well as efficiency and (semi)-automatic processes
>
> Basically, I am fine with "commit to dev, test out, fix regressions if
> present".  OTOH, "prevent regressions up front by reviewing everything"
> will slow down .dev to a crawl, I am afraid.  Don't we have stable for
> that very reason (less volatile code) and with exactly the "2 ACKs per
> commit"-policy?   I am all for review for big changes and where
> efficiently possibly, but I fail to see the value of it for example for
> the type of work that I often do (the busy-work that Cliff Brake so
> eloquently described on June 13th).
>
> With the huge number of open bugs and things that need fixing which have
> been untouched for ages, I am not convinced that slowing things down
> even further is a step in the right direction.

I have to agree here. Rather than becoming overbeaurocratic I'd like us to use 
the less painful branching and merging to implement changes to critical 
sections in the metadata.

-- 
:M:

Re: Switching SCM to git and commit/review policy

[Jan Lübbe]

On Mon, 2008-06-16 at 14:09 +0100, Mark Brown wrote:
> On Fri, Jun 13, 2008 at 03:38:23PM -0300, Otavio Salvador wrote:
> 
> > I don't know how kernel people do to amend the patch to add the
> > acked-by/whatever data into each patch. It can be a big amount of work
> > to do an iteractive rebase for every ack given on ml for each patch
> > and with a high risk of human mistake while doing it.
> 
> For the most part everything except the Signed-off-by is added by the
> patch submitter as they submit and resubmit the patch - often that
> information will just get dropped on the floor otherwise.

Instead of having the "acked-by" in the changeset, we could have it
implicit in the history:

* Everyone with commit access has their own branch
  - org.openembedded.dev.<username>
* Someone else reviewes/compiletestes the changes and then merges the 
  branch into .dev
  - The name of the reviewer then appears in the merge

Trivial changes might go into .dev directly...

-- 
Jan Lübbe <jluebbe@lasnet.de>            http://sicherheitsschwankung.de
 gpg-key      1024D/D8480F2E 2002-03-20
 fingerprint  1B25 F91F 9E7B 5D4F 1282  02D6 8A83 8BE4 D848 0F2E

Re: Switching SCM to git and commit/review policy

[Graeme Gregory]

> 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.
> 
I have been thinking on this and here is my suggestion.

One thing that has been noted has been the high level of work required
to review every change to every package.

Every time more than two OE people get together we keep talking about
splitting OE into two. Maybe it is time to consider actually doing it.
My suggestion would be along the rough lines of the following.

1) OE-core - everything needed to get upto a successful glibc build
completed so gcc, gcc-cross, binutils and support packages. Also most
stuff in classes/. Breakages in these two areas are what hurts the most
and the area we have the least manpower in.

In this section we would have proper reviews and I would suggest no
change without two OE-core developers signing off on it. (OE-core
developers being possible a different group than the political OE core).

2) OE-universe - all the other stuff, the recipes and distro configs.
The stuff where breakage tends to be less painful we keep as is. With
people not being afraid to got git-revert on stupid changes. Yes you do
need to test building all users of a .inc file or patch when you change
them.

If we find this system is working and we think we can handle the extra
load we can always start to raise the bar. For example we could change
core to 3 signoffs and universe to 2. But I think a little of this
trying a new SCM will be seeing how peoples workflow changes. I know
from OM git usage I was suddenly spending less time on complex merges
and had more time to think.

Anyway thats my 2p.

Graeme

Re: Switching SCM to git and commit/review policy

[Alain M.]

Hi, I am really new here but I have one suggestion:

Graeme Gregory escreveu:
>> We've not made any decisions on what the commit/review policy should be,
> I have been thinking on this and here is my suggestion.
> 
> 1) OE-core - everything needed to get upto a successful glibc build
> completed so gcc, gcc-cross, binutils and support packages. Also most
> stuff in classes/. Breakages in these two areas are what hurts the most
> and the area we have the least manpower in.

I like this

> 2) OE-universe - all the other stuff, the recipes and distro configs.
> The stuff where breakage tends to be less painful we keep as is. With
> people not being afraid to got git-revert on stupid changes. Yes you do
> need to test building all users of a .inc file or patch when you change
> them.

Is it concievable this being divided by packages, or even groups of 
packages? Somewhat like Linux packages... It would surely make reviews 
simpler.

I have been impressed by the huge size of OpenEmbedded. But I don't 
really understand it's inner workings enough to know if this is at all 
possible, but it sounds desirable :)

> Anyway thats my 2p.
2p more...

Alain

Re: Switching SCM to git and commit/review policy

[Koen Kooi]

Graeme Gregory wrote:
>> 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.
>>
> I have been thinking on this and here is my suggestion.
>
> One thing that has been noted has been the high level of work required
> to review every change to every package.
>
> Every time more than two OE people get together we keep talking about
> splitting OE into two. Maybe it is time to consider actually doing it.
> My suggestion would be along the rough lines of the following.
>
> 1) OE-core - everything needed to get upto a successful glibc build
> completed so gcc, gcc-cross, binutils and support packages. Also most
> stuff in classes/. Breakages in these two areas are what hurts the most
> and the area we have the least manpower in.

I'd expand that area to the stuff task-boot covers (init, udev, busybox, 
etc), and maybe even packages/linux.

>
> In this section we would have proper reviews and I would suggest no
> change without two OE-core developers signing off on it. (OE-core
> developers being possible a different group than the political OE core).
>
> 2) OE-universe - all the other stuff, the recipes and distro configs.
> The stuff where breakage tends to be less painful we keep as is. With
> people not being afraid to got git-revert on stupid changes. Yes you do
> need to test building all users of a .inc file or patch when you change
> them.
>
> If we find this system is working and we think we can handle the extra
> load we can always start to raise the bar. For example we could change
> core to 3 signoffs and universe to 2. But I think a little of this
> trying a new SCM will be seeing how peoples workflow changes. I know
> from OM git usage I was suddenly spending less time on complex merges
> and had more time to think.
>
> Anyway thats my 2p.
>
> Graeme

Re: Switching SCM to git and commit/review policy

[Leon Woestenberg]

Hello all,

On Tue, Jun 24, 2008 at 4:01 PM, Alain M. <alainm@pobox.com> wrote:
> Hi, I am really new here but I have one suggestion:
> Graeme Gregory escreveu:
>> 1) OE-core - everything needed to get upto a successful glibc build
>> 2) OE-universe - all the other stuff, the recipes and distro configs.

Yes, but make this split only by means of convention, not in the scm
(name)space please.
Having a gentlemen's agreements that non-core developers should not
"commit changes to classes/conf and all the core packages (udev,
busybox, kernels)" is close to what we do nowadays and works fine.

I agree with Michael that intrusive changes should be done in branches.

My personal strong meaning is that we should first convert to GIT,
without changing our current policy TOO much.

Really, the change to GIT alone will already impact the productivity
negatively, due to the dip in the developer commits resulting from
that (people setting up their environment and workflow instead of
maintaining stuff).
If we crawled back up, let's improve on things.

For later, -next is a good idea to merge new branches first, and see
where the autobuilder/tests fail, and nack stuff if it got broken

Regards,
-- 
Leon

Re: Switching SCM to git and commit/review policy

[Tom Rini]

On Tue, Jun 24, 2008 at 08:33:06PM +0200, Koen Kooi wrote:
> Graeme Gregory wrote:
> >>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.
> >>
> >I have been thinking on this and here is my suggestion.
> >
> >One thing that has been noted has been the high level of work required
> >to review every change to every package.
> >
> >Every time more than two OE people get together we keep talking about
> >splitting OE into two. Maybe it is time to consider actually doing it.
> >My suggestion would be along the rough lines of the following.
> >
> >1) OE-core - everything needed to get upto a successful glibc build
> >completed so gcc, gcc-cross, binutils and support packages. Also most
> >stuff in classes/. Breakages in these two areas are what hurts the most
> >and the area we have the least manpower in.
> 
> I'd expand that area to the stuff task-boot covers (init, udev, busybox, 
> etc), and maybe even packages/linux.

Maybe this is too big a wish, but how about we go so far as to say a set
of distributions, machines and image targets That Will Build is the
core and everything else is the universe.  It might take a little work
to get there of course.

-- 
Tom Rini

Re: Switching SCM to git and commit/review policy

[Philip Balister]

[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]

Leon Woestenberg wrote:
> Hello all,
> 
> On Tue, Jun 24, 2008 at 4:01 PM, Alain M. <alainm@pobox.com> wrote:
>> Hi, I am really new here but I have one suggestion:
>> Graeme Gregory escreveu:
>>> 1) OE-core - everything needed to get upto a successful glibc build
>>> 2) OE-universe - all the other stuff, the recipes and distro configs.
> 
> Yes, but make this split only by means of convention, not in the scm
> (name)space please.
> Having a gentlemen's agreements that non-core developers should not
> "commit changes to classes/conf and all the core packages (udev,
> busybox, kernels)" is close to what we do nowadays and works fine.
> 
> I agree with Michael that intrusive changes should be done in branches.
> 
> My personal strong meaning is that we should first convert to GIT,
> without changing our current policy TOO much.

I agree. I also know we need to strengthen the gentlemen's agreement and 
this is a very good time to do it.

> Really, the change to GIT alone will already impact the productivity
> negatively, due to the dip in the developer commits resulting from
> that (people setting up their environment and workflow instead of
> maintaining stuff).
> If we crawled back up, let's improve on things.
> 
> For later, -next is a good idea to merge new branches first, and see
> where the autobuilder/tests fail, and nack stuff if it got broken

I'd like to see us have a set of machine/distro/image's that must build 
after changes to "core OE". Breakage in .dev hurts a lot of people's 
productivity.

Do we have the resources and volunteers to help test changes to core?

Philip

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3303 bytes --]

Re: Switching SCM to git and commit/review policy

[Florian Boor]

Hi,

Tom Rini wrote:

> Maybe this is too big a wish, but how about we go so far as to say a set
> of distributions, machines and image targets That Will Build is the
> core and everything else is the universe.  It might take a little work
> to get there of course.

I think we are moving into mixing up a development branch with a semi-stable
testing branch again. You can't replace motivated developers with strict policies.

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76

Re: Switching SCM to git and commit/review policy

[Tom Rini]

On Tue, Jun 24, 2008 at 10:51:17PM +0200, Florian Boor wrote:

> Hi,
> 
> Tom Rini wrote:
> 
> > Maybe this is too big a wish, but how about we go so far as to say a set
> > of distributions, machines and image targets That Will Build is the
> > core and everything else is the universe.  It might take a little work
> > to get there of course.
> 
> I think we are moving into mixing up a development branch with a semi-stable
> testing branch again. You can't replace motivated developers with strict policies.

I don't know..  I guess it's a question, and it can (should even) be
addressed after the git switch.  Just how wild and unstable are we still
willing to have the "main" tree be.  It sounds like there's already
agreement that big changes (thinking of packaged-staging, which is quite
nice!) will be done in a branch first.  And there's already an
autobuilder.  It seems like the next logical step would be to say what
has to be working, in order for a big changing-lots-of-things merge to
go in.  That to me would be the "core" of distros/machines/images that
need to still function.

Also, I'm not saying that for every commit to the core you need to do a
from scratch build of all combinations, but you should reasonably
confident that things work.

-- 
Tom Rini

Re: Switching SCM to git and commit/review policy

[Leon Woestenberg]

Hello,

On Tue, Jun 24, 2008 at 11:29 PM, Tom Rini <trini@kernel.crashing.org> wrote:
> On Tue, Jun 24, 2008 at 10:51:17PM +0200, Florian Boor wrote:
> Also, I'm not saying that for every commit to the core you need to do a
> from scratch build of all combinations, but you should reasonably
> confident that things work.
>
We can direct an autobuilder to some branch and make it build a
variety of machines, besides testing by the branch maintainer(s)
themselves.

But again, I think this is of *later* concern.

First up is GIT IMHO, and getting the ball rolling again for everyone.

Regards,
-- 
Leon

Re: Switching SCM to git and commit/review policy

[Luís Vitório Cargnini]

People we are starting to diverge in this issue.
Just change the SCM to git only the rest keep the same.

On Tue, Jun 24, 2008 at 7:51 PM, Leon Woestenberg
<leon.woestenberg@gmail.com> wrote:
> Hello,
>
> On Tue, Jun 24, 2008 at 11:29 PM, Tom Rini <trini@kernel.crashing.org> wrote:
>> On Tue, Jun 24, 2008 at 10:51:17PM +0200, Florian Boor wrote:
>> Also, I'm not saying that for every commit to the core you need to do a
>> from scratch build of all combinations, but you should reasonably
>> confident that things work.
>>
> We can direct an autobuilder to some branch and make it build a
> variety of machines, besides testing by the branch maintainer(s)
> themselves.
>
> But again, I think this is of *later* concern.
>
> First up is GIT IMHO, and getting the ball rolling again for everyone.
>
> Regards,
> --
> Leon
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



-- 
------------------------------------------------------------------------------
Thanks && Regards
M.Sc. B.Sc. Luís Vitório Cargnini
IEEE Member
Electrical Engineer Faculty @ PUCRS
Ipiranga Avenue, 6681 – Building 30
P.O. Box: 90619-900 – Porto Alegre/RS
Phone: +55 51 3320 3500 extension: 7696
---------------------------------------------------------------------------------

Re: Switching SCM to git and commit/review policy

[Rolf Leggewie]

Hi,

the discussion has dried up a bit.  I guess everbody has said what
needed to be said.  Now comes the hard time of trying to find a consensus.

I am having a go at it, starting with Leon's suggestion of continuing
with the gentlemen's agreement plus a definition of "OE core" as
suggested by Tom Rini.  My feeling was this kind of struck a chord and
would be acceptable to most, if not all members of the community.

http://wiki.openembedded.net/index.php/Category_talk:Policy is my
attempt to make explicit what the gentlemen's agreement is (and isn't)
about, what parts belong to OE core and how we verify its consistency.
I suggest we clarify anything that still needs discussion with respect
to these points and then have a vote soon (unless we have unanimity,
which I hope).  Unless any major disagreements come up, I think we
should be able to complete that by Friday.

Regards

Rolf

Re: Switching SCM to git and commit/review policy

[Koen Kooi]

Rolf Leggewie wrote:
> Hi,
>
> the discussion has dried up a bit.  I guess everbody has said what
> needed to be said.  Now comes the hard time of trying to find a consensus.
>
> I am having a go at it, starting with Leon's suggestion of continuing
> with the gentlemen's agreement plus a definition of "OE core" as
> suggested by Tom Rini.  My feeling was this kind of struck a chord and
> would be acceptable to most, if not all members of the community.
>
> http://wiki.openembedded.net/index.php/Category_talk:Policy is my
> attempt to make explicit what the gentlemen's agreement is (and isn't)
> about, what parts belong to OE core and how we verify its consistency.
> I suggest we clarify anything that still needs discussion with respect
> to these points and then have a vote soon (unless we have unanimity,
> which I hope).  Unless any major disagreements come up, I think we
> should be able to complete that by Friday.

The core-team will set the policy, so there's no need to vote. We are 
waiting for people to get back from guadec/holidays to polish up the 
announcement.

regards,

Koen

Core team (was: Switching SCM to git and commit/review policy)

[Rolf Leggewie]

Dear OE core, dear fellow OE members,

Koen Kooi wrote:
> The core-team will set the policy, so there's no need to vote.

Well, after this dragged on for well over half a year now and things got
stalled several times this was not the kind of response I was expecting.
 But I'll gladly pick up the ball you passed here to ask a more general
question or raise a more general concern I've been having lately.

Quite frankly, as of late, when it comes to OE governance, I've been
uneasy a lot.  For one, there's this ominous group of OE core that does
a lot of things behind closed doors.  It is not completely clear when
and why it was established, why the communication is not open, who is a
member and how it relates to ordinary members of the community.  Is OE
still an open project?  Is anybody outside core just a little-valued
monkey from which we gladly take code but leave out of any kind of
steering decision?

I am sure everything is alright, but I think some clarifications are in
order.  Looking forward to it.

Regards

Rolf

Core team (was: Switching SCM to git and commit/review policy)

[Rolf Leggewie]

Dear OE core, dear fellow OE members,

Koen Kooi wrote:
> The core-team will set the policy, so there's no need to vote.

Well, after this dragged on for well over half a year now and things got
stalled several times this was not the kind of response I was expecting.
 But I'll gladly pick up the ball you passed here to ask a more general
question or raise a more general concern I've been having lately.

Quite frankly, as of late, when it comes to OE governance, I've been
uneasy a lot.  For one, there's this ominous group of OE core that does
a lot of things behind closed doors.  It is not completely clear when
and why it was established, why the communication is not open, who is a
member and how it relates to ordinary members of the community.  Is OE
still an open project?  Is anybody outside core just a little-valued
monkey from which we gladly take code but leave out of any kind of
steering decision?

I am sure everything is alright, but I think some clarifications are in
order.  Looking forward to it.

Regards

Rolf

Re: Core team (was: Switching SCM to git and commit/review policy)

[Richard Purdie]

On Tue, 2008-07-15 at 01:24 +0200, Rolf Leggewie wrote:
> Well, after this dragged on for well over half a year now and things got
> stalled several times this was not the kind of response I was expecting.
>  But I'll gladly pick up the ball you passed here to ask a more general
> question or raise a more general concern I've been having lately.

Several of us feel bad that this has dragged on. There are various
reasons for that with no one thing or person being responsible. We were
kind of hoping the OE e.V. would solve some of the problems but whilst
that is moving forwards its not going to happen soon enough so we're
trying to move the SCM issue forwards without it. There are also large
time pressures on the people involved. Personally, I know I'm at risk of
totally cracking up if I try and do too much at once so I'm moving
slowly. I'd prefer to do that than totally burn out, sorry ;-).

> Quite frankly, as of late, when it comes to OE governance, I've been
> uneasy a lot.  For one, there's this ominous group of OE core that does
> a lot of things behind closed doors.

Firstly, there isn't that much discussion "behind closed doors". Some
discussion did happen there simply because we couldn't reach a consensus
on the -devel mailing list but there has been much less that you
probably think, see the time issues mentioned above.

The results of that discussion have been made clear - we want to switch
to git, that is unanimous. The question is what kind of commit policy
goes with the change. Even reaching that much of a decision is a major
step forwards but we need to finish things off.

> It is not completely clear when
> and why it was established, why the communication is not open, who is a
> member and how it relates to ordinary members of the community.  Is OE
> still an open project?  Is anybody outside core just a little-valued
> monkey from which we gladly take code but leave out of any kind of
> steering decision?

For the record, as I understand it, the OE core team consists of:

 - Holger Freyther
 - Marcin Juszkiewicz
 - Koen Kooi
 - Richard Purdie
 - Dr. Michael Lauer
 - Graeme Gregory
 - Philip Balister

Why was this established and when? Good questions. When, I'm not sure
about, the above group of people are long standing devs who've tried to
guide the project at various times. Bar the last two people that group
of people have been guiding the project for several years. The last two
people were "invited" more recently to try and add more opinions and
remove any claims of bias.

Why? The problem is how does OE make a decision? The above group has
tried to guide the project a bit and put some kind of organisation and
decicion making process in place. The plan is to hand over to the e.V.
and maybe elect a core team properly once we're in a position to do so.
We're not trying to grab power, steal the project or do anything else
"evil", we just want to move OE forwards and try and resolve some
ongoing problematic issues.

> Is OE still an open project? 

Yes. No decisions have been made without discussion on the -devel
mailing list.

> Is anybody outside core just a little-valued
> monkey from which we gladly take code but leave out of any kind of
> steering decision?

See above. Nobody is under valued and we do try to listen to all view
points. The main reason the core team exists is to give some method of
actually making a final decision.

Personally, in time I expect the core team to be replaced with something
elected by the e.V. with clear policies on what its responsible for.
This stuff does take time though...

Cheers,

Richard

Re: Core team (was: Switching SCM to git and commit/review policy)

[Shane Volpe]

For what its worth, I think projects do much better with a core team.
It seems projects that try to appease to everyone all the time never
make much progress.  I'm not even close to being part of the core team
and I feel any view point I have had in the past has been listened to,
wether it was IRC conversations or email posts.  Quite a few times it
has been the *core* members responding to my concerns and or
questions.  I have been involved with several open source projects and
I think OE is one of the better run ones and has the most interaction
between the core developers and all other developers.
Regards,
Shane
irc: svolpe: the one with a bad network connection and always drops on/off :-)

On Tue, Jul 15, 2008 at 5:45 AM, Richard Purdie <rpurdie@rpsys.net> wrote:
> On Tue, 2008-07-15 at 01:24 +0200, Rolf Leggewie wrote:
>> Well, after this dragged on for well over half a year now and things got
>> stalled several times this was not the kind of response I was expecting.
>>  But I'll gladly pick up the ball you passed here to ask a more general
>> question or raise a more general concern I've been having lately.
>
> Several of us feel bad that this has dragged on. There are various
> reasons for that with no one thing or person being responsible. We were
> kind of hoping the OE e.V. would solve some of the problems but whilst
> that is moving forwards its not going to happen soon enough so we're
> trying to move the SCM issue forwards without it. There are also large
> time pressures on the people involved. Personally, I know I'm at risk of
> totally cracking up if I try and do too much at once so I'm moving
> slowly. I'd prefer to do that than totally burn out, sorry ;-).
>
>> Quite frankly, as of late, when it comes to OE governance, I've been
>> uneasy a lot.  For one, there's this ominous group of OE core that does
>> a lot of things behind closed doors.
>
> Firstly, there isn't that much discussion "behind closed doors". Some
> discussion did happen there simply because we couldn't reach a consensus
> on the -devel mailing list but there has been much less that you
> probably think, see the time issues mentioned above.
>
> The results of that discussion have been made clear - we want to switch
> to git, that is unanimous. The question is what kind of commit policy
> goes with the change. Even reaching that much of a decision is a major
> step forwards but we need to finish things off.
>
>> It is not completely clear when
>> and why it was established, why the communication is not open, who is a
>> member and how it relates to ordinary members of the community.  Is OE
>> still an open project?  Is anybody outside core just a little-valued
>> monkey from which we gladly take code but leave out of any kind of
>> steering decision?
>
> For the record, as I understand it, the OE core team consists of:
>
>  - Holger Freyther
>  - Marcin Juszkiewicz
>  - Koen Kooi
>  - Richard Purdie
>  - Dr. Michael Lauer
>  - Graeme Gregory
>  - Philip Balister
>
> Why was this established and when? Good questions. When, I'm not sure
> about, the above group of people are long standing devs who've tried to
> guide the project at various times. Bar the last two people that group
> of people have been guiding the project for several years. The last two
> people were "invited" more recently to try and add more opinions and
> remove any claims of bias.
>
> Why? The problem is how does OE make a decision? The above group has
> tried to guide the project a bit and put some kind of organisation and
> decicion making process in place. The plan is to hand over to the e.V.
> and maybe elect a core team properly once we're in a position to do so.
> We're not trying to grab power, steal the project or do anything else
> "evil", we just want to move OE forwards and try and resolve some
> ongoing problematic issues.
>
>> Is OE still an open project?
>
> Yes. No decisions have been made without discussion on the -devel
> mailing list.
>
>> Is anybody outside core just a little-valued
>> monkey from which we gladly take code but leave out of any kind of
>> steering decision?
>
> See above. Nobody is under valued and we do try to listen to all view
> points. The main reason the core team exists is to give some method of
> actually making a final decision.
>
> Personally, in time I expect the core team to be replaced with something
> elected by the e.V. with clear policies on what its responsible for.
> This stuff does take time though...
>
> Cheers,
>
> Richard
>
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



-- 
Registered Linux User: #293401