Patchwork [2/5] kernel.bbclass: respect MACHINE_KERNEL_PR

login
register
mail settings
Submitter lumag
Date Sept. 17, 2011, 10:18 p.m.
Message ID <1316297897-698-2-git-send-email-dbaryshkov@gmail.com>
Download mbox | patch
Permalink /patch/11621/
State New, archived
Headers show

Comments

lumag - Sept. 17, 2011, 10:18 p.m.
MACHINE_KERNEL_PR was introduced long ago in org.oe.dev. It's present in
meta-oe kernel.bbclass. Several machines depend on this functionality.

Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
 meta/classes/kernel.bbclass |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)
Otavio Salvador - Sept. 17, 2011, 10:24 p.m.
On Sat, Sep 17, 2011 at 19:18, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> MACHINE_KERNEL_PR was introduced long ago in org.oe.dev. It's present in
> meta-oe kernel.bbclass. Several machines depend on this functionality.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>

Acked-by: Otavio Salvador <otavio@ossystems.com.br>

+1
Bruce Ashfield - Sept. 27, 2011, 1:52 p.m.
On Sat, Sep 17, 2011 at 6:18 PM, Dmitry Eremin-Solenikov
<dbaryshkov@gmail.com> wrote:
> MACHINE_KERNEL_PR was introduced long ago in org.oe.dev. It's present in
> meta-oe kernel.bbclass. Several machines depend on this functionality.

I don' t have a big problem with this, since the change is obviously
harmless if it
doesn't need to be used. But similar to my comment on patch 3/5, is there any
history/technical reasons we can capture here ?

I did a quick search to dig up a bit on this myself, but a summary
would definitely
help, since I see that this has a long and sometimes twisting history. Is it as
simple as ?

 "A machine.conf or local.conf can increase MACHINE_KERNEL_PR to force
 rebuilds for kernel and external modules"

Cheers,

Bruce


>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
> ---
>  meta/classes/kernel.bbclass |    5 +++++
>  1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index c577011..b44e3b5 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -20,6 +20,11 @@ python __anonymous () {
>     image = bb.data.getVar('INITRAMFS_IMAGE', d, True)
>     if image:
>         bb.data.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs', d)
> +
> +    machine_kernel_pr = bb.data.getVar('MACHINE_KERNEL_PR', d, True)
> +
> +    if machine_kernel_pr:
> +        bb.data.setVar('PR', machine_kernel_pr, d)
>  }
>
>  inherit kernel-arch deploy
> --
> 1.7.2.5
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Koen Kooi - Sept. 27, 2011, 11:40 p.m.
Op 27 sep. 2011 om 08:52 heeft Bruce Ashfield <bruce.ashfield@gmail.com> het volgende geschreven:

> On Sat, Sep 17, 2011 at 6:18 PM, Dmitry Eremin-Solenikov
> <dbaryshkov@gmail.com> wrote:
>> MACHINE_KERNEL_PR was introduced long ago in org.oe.dev. It's present in
>> meta-oe kernel.bbclass. Several machines depend on this functionality.
> 
> I don' t have a big problem with this, since the change is obviously
> harmless if it
> doesn't need to be used. But similar to my comment on patch 3/5, is there any
> history/technical reasons we can capture here ?
> 
> I did a quick search to dig up a bit on this myself, but a summary
> would definitely
> help, since I see that this has a long and sometimes twisting history. Is it as
> simple as ?
> 
> "A machine.conf or local.conf can increase MACHINE_KERNEL_PR to force
> rebuilds for kernel and external modules"

It is that simple :) 



> 
> Cheers,
> 
> Bruce
> 
> 
>> 
>> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
>> ---
>>  meta/classes/kernel.bbclass |    5 +++++
>>  1 files changed, 5 insertions(+), 0 deletions(-)
>> 
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index c577011..b44e3b5 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -20,6 +20,11 @@ python __anonymous () {
>>     image = bb.data.getVar('INITRAMFS_IMAGE', d, True)
>>     if image:
>>         bb.data.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs', d)
>> +
>> +    machine_kernel_pr = bb.data.getVar('MACHINE_KERNEL_PR', d, True)
>> +
>> +    if machine_kernel_pr:
>> +        bb.data.setVar('PR', machine_kernel_pr, d)
>>  }
>> 
>>  inherit kernel-arch deploy
>> --
>> 1.7.2.5
>> 
>> 
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>> 
> 
> 
> 
> -- 
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Richard Purdie - Sept. 28, 2011, 2:54 p.m.
On Tue, 2011-09-27 at 18:40 -0500, Koen Kooi wrote:
> 
> Op 27 sep. 2011 om 08:52 heeft Bruce Ashfield <bruce.ashfield@gmail.com> het volgende geschreven:
> 
> > On Sat, Sep 17, 2011 at 6:18 PM, Dmitry Eremin-Solenikov
> > <dbaryshkov@gmail.com> wrote:
> >> MACHINE_KERNEL_PR was introduced long ago in org.oe.dev. It's present in
> >> meta-oe kernel.bbclass. Several machines depend on this functionality.
> > 
> > I don' t have a big problem with this, since the change is obviously
> > harmless if it
> > doesn't need to be used. But similar to my comment on patch 3/5, is there any
> > history/technical reasons we can capture here ?
> > 
> > I did a quick search to dig up a bit on this myself, but a summary
> > would definitely
> > help, since I see that this has a long and sometimes twisting history. Is it as
> > simple as ?
> > 
> > "A machine.conf or local.conf can increase MACHINE_KERNEL_PR to force
> > rebuilds for kernel and external modules"
> 
> It is that simple :) 

I have reservations about this patch given we soon plan to stop needing
to bump PR values. This patch is actually a perfect example of how brain
dead the current manual PR bumping is and why we need something better.
I don't want half the code in the repo to be a mass of PR values which
need to be incremented manually under weird and wonderful circumstances
which is where the direction things are currently going...

I'd like to hold off on this one.

Cheers,

Richard
Koen Kooi - Sept. 28, 2011, 6:42 p.m.
Op 28 sep. 2011 om 09:54 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:

> On Tue, 2011-09-27 at 18:40 -0500, Koen Kooi wrote:
>> 
>> Op 27 sep. 2011 om 08:52 heeft Bruce Ashfield <bruce.ashfield@gmail.com> het volgende geschreven:
>> 
>>> On Sat, Sep 17, 2011 at 6:18 PM, Dmitry Eremin-Solenikov
>>> <dbaryshkov@gmail.com> wrote:
>>>> MACHINE_KERNEL_PR was introduced long ago in org.oe.dev. It's present in
>>>> meta-oe kernel.bbclass. Several machines depend on this functionality.
>>> 
>>> I don' t have a big problem with this, since the change is obviously
>>> harmless if it
>>> doesn't need to be used. But similar to my comment on patch 3/5, is there any
>>> history/technical reasons we can capture here ?
>>> 
>>> I did a quick search to dig up a bit on this myself, but a summary
>>> would definitely
>>> help, since I see that this has a long and sometimes twisting history. Is it as
>>> simple as ?
>>> 
>>> "A machine.conf or local.conf can increase MACHINE_KERNEL_PR to force
>>> rebuilds for kernel and external modules"
>> 
>> It is that simple :) 
> 
> I have reservations about this patch given we soon plan to stop needing
> to bump PR values. This patch is actually a perfect example of how brain
> dead the current manual PR bumping is and why we need something better.
> I don't want half the code in the repo to be a mass of PR values which
> need to be incremented manually under weird and wonderful circumstances
> which is where the direction things are currently going...
> 
> I'd like to hold off on this one.

This patch improves the current situation and I don't foresee the autoPR code working soon


> 
> Cheers,
> 
> Richard
> 
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
lumag - Sept. 28, 2011, 6:50 p.m.
On 9/28/11, Koen Kooi <koen@dominion.thruhere.net> wrote:
>
>
> Op 28 sep. 2011 om 09:54 heeft Richard Purdie
> <richard.purdie@linuxfoundation.org> het volgende geschreven:
>
>> On Tue, 2011-09-27 at 18:40 -0500, Koen Kooi wrote:
>>>
>>> Op 27 sep. 2011 om 08:52 heeft Bruce Ashfield <bruce.ashfield@gmail.com>
>>> het volgende geschreven:
>>>
>>>> On Sat, Sep 17, 2011 at 6:18 PM, Dmitry Eremin-Solenikov
>>>> <dbaryshkov@gmail.com> wrote:
>>>>> MACHINE_KERNEL_PR was introduced long ago in org.oe.dev. It's present
>>>>> in
>>>>> meta-oe kernel.bbclass. Several machines depend on this functionality.
>>>>
>>>> I don' t have a big problem with this, since the change is obviously
>>>> harmless if it
>>>> doesn't need to be used. But similar to my comment on patch 3/5, is
>>>> there any
>>>> history/technical reasons we can capture here ?
>>>>
>>>> I did a quick search to dig up a bit on this myself, but a summary
>>>> would definitely
>>>> help, since I see that this has a long and sometimes twisting history.
>>>> Is it as
>>>> simple as ?
>>>>
>>>> "A machine.conf or local.conf can increase MACHINE_KERNEL_PR to force
>>>> rebuilds for kernel and external modules"
>>>
>>> It is that simple :)
>>
>> I have reservations about this patch given we soon plan to stop needing
>> to bump PR values. This patch is actually a perfect example of how brain
>> dead the current manual PR bumping is and why we need something better.
>> I don't want half the code in the repo to be a mass of PR values which
>> need to be incremented manually under weird and wonderful circumstances
>> which is where the direction things are currently going...
>>
>> I'd like to hold off on this one.
>
> This patch improves the current situation and I don't foresee the autoPR
> code working soon

As another point for this patch: I'd like to ask Koen to drop
kernel.bbclass from
meta-oe. After do_uboot_mkimage this is the only significant difference. And
unfortunately this feature is already used on several machines. Quick
grep return the following results. Koen, could you comment on this?

$ grep MACHINE_KERNEL_PR */{,*/}c* -r
meta-openpandora/conf/machine/include/omap3.inc:MACHINE_KERNEL_PR = "r101"
meta-openpandora/conf/machine/omap3-pandora.conf:MACHINE_KERNEL_PR = "r3"
meta-texasinstruments/conf/machine/include/davinci.inc:MACHINE_KERNEL_PR = "r51"
meta-texasinstruments/conf/machine/include/omap3.inc:MACHINE_KERNEL_PR = "r105"
meta-texasinstruments/conf/machine/include/ti814x.inc:MACHINE_KERNEL_PR = "r1"
meta-texasinstruments/conf/machine/include/ti816x.inc:MACHINE_KERNEL_PR = "r2"
meta-smartphone/meta-nokia/conf/machine/nokia900.conf:MACHINE_KERNEL_PR = "r68"
meta-smartphone/meta-palm/conf/machine/include/palmpre.inc:MACHINE_KERNEL_PR
= "r0"
meta-texasinstruments/recipes-ti/c6accel/ti-c6accel.inc:PR =
"${MACHINE_KERNEL_PR}"
meta-texasinstruments/recipes-ti/codec-engine/ti-codec-engine.inc:PR =
"${MACHINE_KERNEL_PR}"
meta-texasinstruments/recipes-ti/codec-engine/ti-codecs-omap3530_4.00.00.00.bb:PR="${MACHINE_KERNEL_PR}"
openembedded-core/meta/classes/kernel.bbclass:    machine_kernel_pr =
bb.data.getVar('MACHINE_KERNEL_PR', d, True)
Richard Purdie - Sept. 28, 2011, 7:50 p.m.
On Wed, 2011-09-28 at 13:42 -0500, Koen Kooi wrote:
> 
> Op 28 sep. 2011 om 09:54 heeft Richard Purdie <richard.purdie@linuxfoundation.org> het volgende geschreven:
> 
> > On Tue, 2011-09-27 at 18:40 -0500, Koen Kooi wrote:
> >> 
> >> Op 27 sep. 2011 om 08:52 heeft Bruce Ashfield <bruce.ashfield@gmail.com> het volgende geschreven:
> >> 
> >>> On Sat, Sep 17, 2011 at 6:18 PM, Dmitry Eremin-Solenikov
> >>> <dbaryshkov@gmail.com> wrote:
> >>>> MACHINE_KERNEL_PR was introduced long ago in org.oe.dev. It's present in
> >>>> meta-oe kernel.bbclass. Several machines depend on this functionality.
> >>> 
> >>> I don' t have a big problem with this, since the change is obviously
> >>> harmless if it
> >>> doesn't need to be used. But similar to my comment on patch 3/5, is there any
> >>> history/technical reasons we can capture here ?
> >>> 
> >>> I did a quick search to dig up a bit on this myself, but a summary
> >>> would definitely
> >>> help, since I see that this has a long and sometimes twisting history. Is it as
> >>> simple as ?
> >>> 
> >>> "A machine.conf or local.conf can increase MACHINE_KERNEL_PR to force
> >>> rebuilds for kernel and external modules"
> >> 
> >> It is that simple :) 
> > 
> > I have reservations about this patch given we soon plan to stop needing
> > to bump PR values. This patch is actually a perfect example of how brain
> > dead the current manual PR bumping is and why we need something better.
> > I don't want half the code in the repo to be a mass of PR values which
> > need to be incremented manually under weird and wonderful circumstances
> > which is where the direction things are currently going...
> > 
> > I'd like to hold off on this one.
> 
> This patch improves the current situation and I don't foresee the
> autoPR code working soon

Which is why we need to switch to that model and shake out the issues
sooner than later. Enough is enough with the PR madness and we need to
get to grips and fix it.

Cheers,

Richard
Otavio Salvador - Sept. 28, 2011, 8:04 p.m.
On Wed, Sep 28, 2011 at 16:50, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>> This patch improves the current situation and I don't foresee the
>> autoPR code working soon
>
> Which is why we need to switch to that model and shake out the issues
> sooner than later. Enough is enough with the PR madness and we need to
> get to grips and fix it.

I fully agree this is the way to go but this doesn't mean we ought to
hold this patch until all this happens. This patch allows the removal
of the kernel.bbclass from meta-oe so reducing the delta between
oe-core and meta-oe.
Koen Kooi - Oct. 20, 2011, 6:23 a.m.
Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:

> On Wed, Sep 28, 2011 at 16:50, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>>> This patch improves the current situation and I don't foresee the
>>> autoPR code working soon
>> 
>> Which is why we need to switch to that model and shake out the issues
>> sooner than later. Enough is enough with the PR madness and we need to
>> get to grips and fix it.
> 
> I fully agree this is the way to go but this doesn't mean we ought to
> hold this patch until all this happens. This patch allows the removal
> of the kernel.bbclass from meta-oe so reducing the delta between
> oe-core and meta-oe.

So a month later and no sign of the mythical working auto-PR-incrementer or work on it. So can this patch go in? It would mean we can drop kernel.bbclass from meta-oe.
Richard Purdie - Oct. 20, 2011, 11:21 a.m.
On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
> 
> > On Wed, Sep 28, 2011 at 16:50, Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> >>> This patch improves the current situation and I don't foresee the
> >>> autoPR code working soon
> >> 
> >> Which is why we need to switch to that model and shake out the issues
> >> sooner than later. Enough is enough with the PR madness and we need to
> >> get to grips and fix it.
> > 
> > I fully agree this is the way to go but this doesn't mean we ought to
> > hold this patch until all this happens. This patch allows the removal
> > of the kernel.bbclass from meta-oe so reducing the delta between
> > oe-core and meta-oe.
> 
> So a month later and no sign of the mythical working
> auto-PR-incrementer or work on it.

A month where we were stabilising for a release. Its on the 1.2 feature
list and as it happens I've been hearing questions about what is needed
here.

>  So can this patch go in? It would mean we can drop kernel.bbclass
> from meta-oe.

I *HATE* this PR bumping stuff. I've just been told we likely need to
bump the PR for anything using libGL which once again shows that build
system basically failing to automate building things.

So I'm drawing a line here and no, we can't take this. If its fine to
expect people to bump PR values manually for lib* changes, its fine for
kernels too. I'd suggest you do drop this from meta-oe and we start
building up pressure for the problem to get fixed properly rather than
letting people wallpaper over the cracks.

Cheers,

Richard
Koen Kooi - Oct. 20, 2011, 11:29 a.m.
Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:

> On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
>> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
>> 
>>> On Wed, Sep 28, 2011 at 16:50, Richard Purdie
>>> <richard.purdie@linuxfoundation.org> wrote:
>>>>> This patch improves the current situation and I don't foresee the
>>>>> autoPR code working soon
>>>> 
>>>> Which is why we need to switch to that model and shake out the issues
>>>> sooner than later. Enough is enough with the PR madness and we need to
>>>> get to grips and fix it.
>>> 
>>> I fully agree this is the way to go but this doesn't mean we ought to
>>> hold this patch until all this happens. This patch allows the removal
>>> of the kernel.bbclass from meta-oe so reducing the delta between
>>> oe-core and meta-oe.
>> 
>> So a month later and no sign of the mythical working
>> auto-PR-incrementer or work on it.
> 
> A month where we were stabilising for a release. Its on the 1.2 feature
> list and as it happens I've been hearing questions about what is needed
> here.
> 
>> So can this patch go in? It would mean we can drop kernel.bbclass
>> from meta-oe.
> 
> I *HATE* this PR bumping stuff. I've just been told we likely need to
> bump the PR for anything using libGL which once again shows that build
> system basically failing to automate building things.
> 
> So I'm drawing a line here and no, we can't take this. If its fine to
> expect people to bump PR values manually for lib* changes, its fine for
> kernels too. I'd suggest you do drop this from meta-oe and we start
> building up pressure for the problem to get fixed properly rather than
> letting people wallpaper over the cracks.

I have products to ship, so treating meta-oe as a plaything and break this for the sake of breaking it is unacceptable. I'll let oe-core have the monopoly on high-qualitily, but broken metadata.
Otavio Salvador - Oct. 20, 2011, 11:35 a.m.
On Thu, Oct 20, 2011 at 09:29, Koen Kooi <koen@dominion.thruhere.net> wrote:
...
>> So I'm drawing a line here and no, we can't take this. If its fine to
>> expect people to bump PR values manually for lib* changes, its fine for
>> kernels too. I'd suggest you do drop this from meta-oe and we start
>> building up pressure for the problem to get fixed properly rather than
>> letting people wallpaper over the cracks.
>
> I have products to ship, so treating meta-oe as a plaything and break this for the sake of breaking it is unacceptable. I'll let oe-core have the monopoly on high-qualitily, but broken metadata.

Richard,

It makes no sense to don't accept this as it reduces delta between
oe-core and meta-oe and makes easier for other people to move from
oe-classic to oe-core. Once the auto-PR arrives this can be deprecated
but delaying it with no ETA is no sense.
Frans Meulenbroeks - Oct. 20, 2011, 11:53 a.m.
2011/10/20 Koen Kooi <koen@dominion.thruhere.net>

>
> Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
>
> > On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
> >> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
> >>
> >>> On Wed, Sep 28, 2011 at 16:50, Richard Purdie
> >>> <richard.purdie@linuxfoundation.org> wrote:
> >>>>> This patch improves the current situation and I don't foresee the
> >>>>> autoPR code working soon
> >>>>
> >>>> Which is why we need to switch to that model and shake out the issues
> >>>> sooner than later. Enough is enough with the PR madness and we need to
> >>>> get to grips and fix it.
> >>>
> >>> I fully agree this is the way to go but this doesn't mean we ought to
> >>> hold this patch until all this happens. This patch allows the removal
> >>> of the kernel.bbclass from meta-oe so reducing the delta between
> >>> oe-core and meta-oe.
> >>
> >> So a month later and no sign of the mythical working
> >> auto-PR-incrementer or work on it.
> >
> > A month where we were stabilising for a release. Its on the 1.2 feature
> > list and as it happens I've been hearing questions about what is needed
> > here.
> >
> >> So can this patch go in? It would mean we can drop kernel.bbclass
> >> from meta-oe.
> >
> > I *HATE* this PR bumping stuff. I've just been told we likely need to
> > bump the PR for anything using libGL which once again shows that build
> > system basically failing to automate building things.
> >
> > So I'm drawing a line here and no, we can't take this. If its fine to
> > expect people to bump PR values manually for lib* changes, its fine for
> > kernels too. I'd suggest you do drop this from meta-oe and we start
> > building up pressure for the problem to get fixed properly rather than
> > letting people wallpaper over the cracks.
>
> I have products to ship, so treating meta-oe as a plaything and break this
> for the sake of breaking it is unacceptable. I'll let oe-core have the
> monopoly on high-qualitily, but broken metadata.
> .
>

Didn't we have a TSC to escalate discussions and disagreements between
developers to???

Best regards, Frans
Richard Purdie - Oct. 20, 2011, 12:38 p.m.
On Thu, 2011-10-20 at 13:29 +0200, Koen Kooi wrote:
> Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
> 
> > On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
> >> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
> >> 
> >>> On Wed, Sep 28, 2011 at 16:50, Richard Purdie
> >>> <richard.purdie@linuxfoundation.org> wrote:
> >>>>> This patch improves the current situation and I don't foresee the
> >>>>> autoPR code working soon
> >>>> 
> >>>> Which is why we need to switch to that model and shake out the issues
> >>>> sooner than later. Enough is enough with the PR madness and we need to
> >>>> get to grips and fix it.
> >>> 
> >>> I fully agree this is the way to go but this doesn't mean we ought to
> >>> hold this patch until all this happens. This patch allows the removal
> >>> of the kernel.bbclass from meta-oe so reducing the delta between
> >>> oe-core and meta-oe.
> >> 
> >> So a month later and no sign of the mythical working
> >> auto-PR-incrementer or work on it.
> > 
> > A month where we were stabilising for a release. Its on the 1.2 feature
> > list and as it happens I've been hearing questions about what is needed
> > here.
> > 
> >> So can this patch go in? It would mean we can drop kernel.bbclass
> >> from meta-oe.
> > 
> > I *HATE* this PR bumping stuff. I've just been told we likely need to
> > bump the PR for anything using libGL which once again shows that build
> > system basically failing to automate building things.
> > 
> > So I'm drawing a line here and no, we can't take this. If its fine to
> > expect people to bump PR values manually for lib* changes, its fine for
> > kernels too. I'd suggest you do drop this from meta-oe and we start
> > building up pressure for the problem to get fixed properly rather than
> > letting people wallpaper over the cracks.
> 
> I have products to ship, so treating meta-oe as a plaything and break
> this for the sake of breaking it is unacceptable. I'll let oe-core
> have the monopoly on high-qualitily, but broken metadata.

Its not as if there isn't another way to handle this, it is a little
harder work I agree. This isn't breaking for the sake of breaking
either, its applying a bit of pressure to ensure we fix an underlying
problem we've had for a long time. I don't think fixing it will be easy,
I do think we need to though.

Also, the idea never was to have everyone using bleeding edge for
shipping products. This is what stable releases are for?

Cheers,

Richard
Koen Kooi - Oct. 20, 2011, 12:54 p.m.
Op 20 okt. 2011, om 14:38 heeft Richard Purdie het volgende geschreven:

> On Thu, 2011-10-20 at 13:29 +0200, Koen Kooi wrote:
>> Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
>> 
>>> On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
>>>> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
>>>> 
>>>>> On Wed, Sep 28, 2011 at 16:50, Richard Purdie
>>>>> <richard.purdie@linuxfoundation.org> wrote:
>>>>>>> This patch improves the current situation and I don't foresee the
>>>>>>> autoPR code working soon
>>>>>> 
>>>>>> Which is why we need to switch to that model and shake out the issues
>>>>>> sooner than later. Enough is enough with the PR madness and we need to
>>>>>> get to grips and fix it.
>>>>> 
>>>>> I fully agree this is the way to go but this doesn't mean we ought to
>>>>> hold this patch until all this happens. This patch allows the removal
>>>>> of the kernel.bbclass from meta-oe so reducing the delta between
>>>>> oe-core and meta-oe.
>>>> 
>>>> So a month later and no sign of the mythical working
>>>> auto-PR-incrementer or work on it.
>>> 
>>> A month where we were stabilising for a release. Its on the 1.2 feature
>>> list and as it happens I've been hearing questions about what is needed
>>> here.
>>> 
>>>> So can this patch go in? It would mean we can drop kernel.bbclass
>>>> from meta-oe.
>>> 
>>> I *HATE* this PR bumping stuff. I've just been told we likely need to
>>> bump the PR for anything using libGL which once again shows that build
>>> system basically failing to automate building things.
>>> 
>>> So I'm drawing a line here and no, we can't take this. If its fine to
>>> expect people to bump PR values manually for lib* changes, its fine for
>>> kernels too. I'd suggest you do drop this from meta-oe and we start
>>> building up pressure for the problem to get fixed properly rather than
>>> letting people wallpaper over the cracks.
>> 
>> I have products to ship, so treating meta-oe as a plaything and break
>> this for the sake of breaking it is unacceptable. I'll let oe-core
>> have the monopoly on high-qualitily, but broken metadata.
> 
> Its not as if there isn't another way to handle this, it is a little
> harder work I agree. This isn't breaking for the sake of breaking
> either, its applying a bit of pressure to ensure we fix an underlying
> problem we've had for a long time. I don't think fixing it will be easy,
> I do think we need to though.
> 
> Also, the idea never was to have everyone using bleeding edge for
> shipping products. This is what stable releases are for?

That's what stable releases are for, but I don't see a release for OE-core, do you? I see a poky release, but not an OE-core release.
Otavio Salvador - Oct. 20, 2011, 1:02 p.m.
On Thu, Oct 20, 2011 at 10:54, Koen Kooi <koen@dominion.thruhere.net> wrote:
...
>> Also, the idea never was to have everyone using bleeding edge for
>> shipping products. This is what stable releases are for?
>
> That's what stable releases are for, but I don't see a release for OE-core, do you? I see a poky release, but not an OE-core release.

People, let's calm down.

I think since Richard disagree about pushing this patch and more then
one person disagree with Richard, TSC is the way to go.
Richard Purdie - Oct. 20, 2011, 1:56 p.m.
On Thu, 2011-10-20 at 14:54 +0200, Koen Kooi wrote:
> Op 20 okt. 2011, om 14:38 heeft Richard Purdie het volgende geschreven:
> 
> > On Thu, 2011-10-20 at 13:29 +0200, Koen Kooi wrote:
> >> Op 20 okt. 2011, om 13:21 heeft Richard Purdie het volgende geschreven:
> >> 
> >>> On Thu, 2011-10-20 at 08:23 +0200, Koen Kooi wrote:
> >>>> Op 28 sep. 2011, om 22:04 heeft Otavio Salvador het volgende geschreven:
> >>>> 
> >>>>> On Wed, Sep 28, 2011 at 16:50, Richard Purdie
> >>>>> <richard.purdie@linuxfoundation.org> wrote:
> >>>>>>> This patch improves the current situation and I don't foresee the
> >>>>>>> autoPR code working soon
> >>>>>> 
> >>>>>> Which is why we need to switch to that model and shake out the issues
> >>>>>> sooner than later. Enough is enough with the PR madness and we need to
> >>>>>> get to grips and fix it.
> >>>>> 
> >>>>> I fully agree this is the way to go but this doesn't mean we ought to
> >>>>> hold this patch until all this happens. This patch allows the removal
> >>>>> of the kernel.bbclass from meta-oe so reducing the delta between
> >>>>> oe-core and meta-oe.
> >>>> 
> >>>> So a month later and no sign of the mythical working
> >>>> auto-PR-incrementer or work on it.
> >>> 
> >>> A month where we were stabilising for a release. Its on the 1.2 feature
> >>> list and as it happens I've been hearing questions about what is needed
> >>> here.
> >>> 
> >>>> So can this patch go in? It would mean we can drop kernel.bbclass
> >>>> from meta-oe.
> >>> 
> >>> I *HATE* this PR bumping stuff. I've just been told we likely need to
> >>> bump the PR for anything using libGL which once again shows that build
> >>> system basically failing to automate building things.
> >>> 
> >>> So I'm drawing a line here and no, we can't take this. If its fine to
> >>> expect people to bump PR values manually for lib* changes, its fine for
> >>> kernels too. I'd suggest you do drop this from meta-oe and we start
> >>> building up pressure for the problem to get fixed properly rather than
> >>> letting people wallpaper over the cracks.
> >> 
> >> I have products to ship, so treating meta-oe as a plaything and break
> >> this for the sake of breaking it is unacceptable. I'll let oe-core
> >> have the monopoly on high-qualitily, but broken metadata.
> > 
> > Its not as if there isn't another way to handle this, it is a little
> > harder work I agree. This isn't breaking for the sake of breaking
> > either, its applying a bit of pressure to ensure we fix an underlying
> > problem we've had for a long time. I don't think fixing it will be easy,
> > I do think we need to though.
> > 
> > Also, the idea never was to have everyone using bleeding edge for
> > shipping products. This is what stable releases are for?
> 
> That's what stable releases are for, but I don't see a release for
> OE-core, do you? I see a poky release, but not an OE-core release.

As you are no doubt aware, that got discussed at the last TSC meeting.
Khem did volunteer to help with that, there is a branch there ready to
be tagged too and I was planning to raise progress with this at
tonight's TSC meeting.

Cheers,

Richard
Koen Kooi - Oct. 21, 2011, 12:05 p.m.
Op 20 okt. 2011, om 15:02 heeft Otavio Salvador het volgende geschreven:

> On Thu, Oct 20, 2011 at 10:54, Koen Kooi <koen@dominion.thruhere.net> wrote:
> ...
>>> Also, the idea never was to have everyone using bleeding edge for
>>> shipping products. This is what stable releases are for?
>> 
>> That's what stable releases are for, but I don't see a release for OE-core, do you? I see a poky release, but not an OE-core release.
> 
> People, let's calm down.
> 
> I think since Richard disagree about pushing this patch and more then
> one person disagree with Richard, TSC is the way to go.

Executive summary of the TSC meeting:

1) This patch gets applied, but no more PR helpers will be allowed, INC_PR and MACHINE_KERNEL_PR are the only ones tolerated for the time being.
2) kernel.bbclass gets dropped from meta-oe
3) basic-hash will get turned on in master-next
4) super-duper PR automation work will land in master-next and get merged into master when it's deemed "good enough"

The intermediate merge step into master-next is only done if enough people test master-next. If people don't want to test it, the merge and associated breakage will go straight into master.

regards,

Koen

Patch

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index c577011..b44e3b5 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -20,6 +20,11 @@  python __anonymous () {
     image = bb.data.getVar('INITRAMFS_IMAGE', d, True)
     if image:
         bb.data.setVar('INITRAMFS_TASK', '${INITRAMFS_IMAGE}:do_rootfs', d)
+
+    machine_kernel_pr = bb.data.getVar('MACHINE_KERNEL_PR', d, True)
+
+    if machine_kernel_pr:
+        bb.data.setVar('PR', machine_kernel_pr, d)
 }
 
 inherit kernel-arch deploy