Patchwork [1/1] kern-tools: checkpoint restoration for reset branches

login
register
mail settings
Submitter Bruce Ashfield
Date May 9, 2012, 3:48 a.m.
Message ID <893d8018c655f70ada731eaf5f03b178f4dfe2b3.1336535085.git.bruce.ashfield@windriver.com>
Download mbox | patch
Permalink /patch/27337/
State Accepted
Commit bd794b92d12ceda2728520701e980b7a3cabd23d
Headers show

Comments

Bruce Ashfield - May 9, 2012, 3:48 a.m.
Updating the SRCREV to pickup the following fix:

    createme: fix checkpoint restoration for reset branches

    The meta branch can optionally be merged out to BSP branches. This removes
    the need to restore the checkpoint when working with the tree.  The way
    it detects the merge is by checking to see how many branches contain the
    meta data. If there's more than one, the branch was was merged out.

    Unless you are a BSP that isn't tracking the latest meta, and you get
    meta and meta-orig created. That's two branches and the code opts to not
    restore the checkpoint, which leads to configuration errors.

    The fix is simple. We allow for 2 or less branches with meta, and will
    still restore the checkpoint. Three and up, we won't.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 .../kern-tools/kern-tools-native_git.bb            |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
Darren Hart - May 9, 2012, 3:40 p.m.
On 05/08/2012 08:48 PM, Bruce Ashfield wrote:
> Updating the SRCREV to pickup the following fix:
> 
>     createme: fix checkpoint restoration for reset branches
> 
>     The meta branch can optionally be merged out to BSP branches. This removes
>     the need to restore the checkpoint when working with the tree.  The way
>     it detects the merge is by checking to see how many branches contain the
>     meta data. If there's more than one, the branch was was merged out.
> 
>     Unless you are a BSP that isn't tracking the latest meta, and you get
>     meta and meta-orig created. That's two branches and the code opts to not
>     restore the checkpoint, which leads to configuration errors.
> 
>     The fix is simple. We allow for 2 or less branches with meta, and will
>     still restore the checkpoint. Three and up, we won't.
> 

Uhm... am I the only one for whom this language is really confusing?
"merged out" ?
"restore the checkpoint" ?
Why does a BSP using a different meta SRCREV get two meta branches?

The fix of incrementing the allowed count of meta branches honestly
feels like a bandaid. Why do we create two in the first place?

Regardless, this is a blocker for working with meta-intel, so we need
this in. But it does seem to me that a more direct solution may be
needed. Bruce, can you help fill me in re. the above?

--
Darren

> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> ---
>  .../kern-tools/kern-tools-native_git.bb            |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> index b6fab39..b5e203e 100644
> --- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> +++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> @@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d8
>  
>  DEPENDS = "git-native guilt-native"
>  
> -SRCREV = "9bb704df0a86578b8ae1f4c85e45089bef28e026"
> +SRCREV = "de3649840e8e3ca25bc79d2444f04a1b158a1769"
>  PR = "r12"
>  PV = "0.1+git${SRCPV}"
>
Bruce Ashfield - May 9, 2012, 3:48 p.m.
On Wed, May 9, 2012 at 11:40 AM, Darren Hart <dvhart@linux.intel.com> wrote:
>
>
> On 05/08/2012 08:48 PM, Bruce Ashfield wrote:
>> Updating the SRCREV to pickup the following fix:
>>
>>     createme: fix checkpoint restoration for reset branches
>>
>>     The meta branch can optionally be merged out to BSP branches. This removes
>>     the need to restore the checkpoint when working with the tree.  The way
>>     it detects the merge is by checking to see how many branches contain the
>>     meta data. If there's more than one, the branch was was merged out.
>>
>>     Unless you are a BSP that isn't tracking the latest meta, and you get
>>     meta and meta-orig created. That's two branches and the code opts to not
>>     restore the checkpoint, which leads to configuration errors.
>>
>>     The fix is simple. We allow for 2 or less branches with meta, and will
>>     still restore the checkpoint. Three and up, we won't.
>>
>
> Uhm... am I the only one for whom this language is really confusing?
> "merged out" ?
> "restore the checkpoint" ?

I could be more verbose, but it's like reading a kernel -mm commit. I
don't grok everything they write, but they aren't writing it for me as a
-mm newbie.

> Why does a BSP using a different meta SRCREV get two meta branches?
>
> The fix of incrementing the allowed count of meta branches honestly
> feels like a bandaid. Why do we create two in the first place?

do_validate_branches() has to check if the HEAD of meta matches the meta
SRCREV that the BSP defines. If they don't match, it saves the old branch
as $branch-orig. So you have two branches, with the base meta commit
(which is what is tested).  I don't want to destroy any branches, since there
is value in keeping them around.

The tools are actually separate to the bitbake bindings, so they don't expect
this to happen. I could destroy the old branch in do_validate_branches, but
that's not a solution I particularly liked. It was easier to add some
flexibility to
the tools.

Cheers,

Bruce

>
> Regardless, this is a blocker for working with meta-intel, so we need
> this in. But it does seem to me that a more direct solution may be
> needed. Bruce, can you help fill me in re. the above?
>
> --
> Darren
>
>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>> ---
>>  .../kern-tools/kern-tools-native_git.bb            |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>> index b6fab39..b5e203e 100644
>> --- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>> +++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
>> @@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d8
>>
>>  DEPENDS = "git-native guilt-native"
>>
>> -SRCREV = "9bb704df0a86578b8ae1f4c85e45089bef28e026"
>> +SRCREV = "de3649840e8e3ca25bc79d2444f04a1b158a1769"
>>  PR = "r12"
>>  PV = "0.1+git${SRCPV}"
>>
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Phil Blundell - May 9, 2012, 4:02 p.m.
On Wed, 2012-05-09 at 11:48 -0400, Bruce Ashfield wrote:
> On Wed, May 9, 2012 at 11:40 AM, Darren Hart <dvhart@linux.intel.com> wrote:
> >
> >
> > On 05/08/2012 08:48 PM, Bruce Ashfield wrote:
> >> Updating the SRCREV to pickup the following fix:
> >>
> >>     createme: fix checkpoint restoration for reset branches
> >>
> >>     The meta branch can optionally be merged out to BSP branches. This removes
> >>     the need to restore the checkpoint when working with the tree.  The way
> >>     it detects the merge is by checking to see how many branches contain the
> >>     meta data. If there's more than one, the branch was was merged out.
> >>
> >>     Unless you are a BSP that isn't tracking the latest meta, and you get
> >>     meta and meta-orig created. That's two branches and the code opts to not
> >>     restore the checkpoint, which leads to configuration errors.
> >>
> >>     The fix is simple. We allow for 2 or less branches with meta, and will
> >>     still restore the checkpoint. Three and up, we won't.
> >>
> >
> > Uhm... am I the only one for whom this language is really confusing?
> > "merged out" ?
> > "restore the checkpoint" ?
> 
> I could be more verbose, but it's like reading a kernel -mm commit. I
> don't grok everything they write, but they aren't writing it for me as a
> -mm newbie.

So, who exactly is the target audience for the above text?  I'm not sure
that "really confusing" does it justice: from my point of view (though
admittedly I am very far from being an eleet k3rn3l h4x0r) it just looks
like gibberish.  If it's going into oe-core then I would have hoped that
the checkin comment would be intelligible to oe-core users at large, not
just those who are schooled in the mysterious ways of some particular
subgroup.

p.
Bruce Ashfield - May 9, 2012, 4:11 p.m.
On Wed, May 9, 2012 at 12:02 PM, Phil Blundell <philb@gnu.org> wrote:
> On Wed, 2012-05-09 at 11:48 -0400, Bruce Ashfield wrote:
>> On Wed, May 9, 2012 at 11:40 AM, Darren Hart <dvhart@linux.intel.com> wrote:
>> >
>> >
>> > On 05/08/2012 08:48 PM, Bruce Ashfield wrote:
>> >> Updating the SRCREV to pickup the following fix:
>> >>
>> >>     createme: fix checkpoint restoration for reset branches
>> >>
>> >>     The meta branch can optionally be merged out to BSP branches. This removes
>> >>     the need to restore the checkpoint when working with the tree.  The way
>> >>     it detects the merge is by checking to see how many branches contain the
>> >>     meta data. If there's more than one, the branch was was merged out.
>> >>
>> >>     Unless you are a BSP that isn't tracking the latest meta, and you get
>> >>     meta and meta-orig created. That's two branches and the code opts to not
>> >>     restore the checkpoint, which leads to configuration errors.
>> >>
>> >>     The fix is simple. We allow for 2 or less branches with meta, and will
>> >>     still restore the checkpoint. Three and up, we won't.
>> >>
>> >
>> > Uhm... am I the only one for whom this language is really confusing?
>> > "merged out" ?
>> > "restore the checkpoint" ?
>>
>> I could be more verbose, but it's like reading a kernel -mm commit. I
>> don't grok everything they write, but they aren't writing it for me as a
>> -mm newbie.
>
> So, who exactly is the target audience for the above text?  I'm not sure
> that "really confusing" does it justice: from my point of view (though
> admittedly I am very far from being an eleet k3rn3l h4x0r) it just looks
> like gibberish.  If it's going into oe-core then I would have hoped that
> the checkin comment would be intelligible to oe-core users at large, not
> just those who are schooled in the mysterious ways of some particular
> subgroup.

It's a quote from the kern-tools commit log. I could just put: 'fixes stuff',
but that's not good either. Writing a novel isn't good either.

I'm not sure why everyone is having such an issue with this, there's many
other examples of commits like this, and everyone sits in a glass house
in this regard.

I can re-work it of course, I wrote it very late at night to fix a
fairly blocking
bug, so everyone cutting a little bit of slack would be appreciated.

Cheers,

Bruce

>
> p.
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Bruce Ashfield - May 9, 2012, 4:42 p.m.
On Wed, May 9, 2012 at 12:11 PM, Bruce Ashfield
<bruce.ashfield@gmail.com> wrote:
> On Wed, May 9, 2012 at 12:02 PM, Phil Blundell <philb@gnu.org> wrote:
>> On Wed, 2012-05-09 at 11:48 -0400, Bruce Ashfield wrote:
>>> On Wed, May 9, 2012 at 11:40 AM, Darren Hart <dvhart@linux.intel.com> wrote:
>>> >
>>> >
>>> > On 05/08/2012 08:48 PM, Bruce Ashfield wrote:
>>> >> Updating the SRCREV to pickup the following fix:
>>> >>
>>> >>     createme: fix checkpoint restoration for reset branches
>>> >>
>>> >>     The meta branch can optionally be merged out to BSP branches. This removes
>>> >>     the need to restore the checkpoint when working with the tree.  The way
>>> >>     it detects the merge is by checking to see how many branches contain the
>>> >>     meta data. If there's more than one, the branch was was merged out.
>>> >>
>>> >>     Unless you are a BSP that isn't tracking the latest meta, and you get
>>> >>     meta and meta-orig created. That's two branches and the code opts to not
>>> >>     restore the checkpoint, which leads to configuration errors.
>>> >>
>>> >>     The fix is simple. We allow for 2 or less branches with meta, and will
>>> >>     still restore the checkpoint. Three and up, we won't.
>>> >>
>>> >
>>> > Uhm... am I the only one for whom this language is really confusing?
>>> > "merged out" ?
>>> > "restore the checkpoint" ?
>>>
>>> I could be more verbose, but it's like reading a kernel -mm commit. I
>>> don't grok everything they write, but they aren't writing it for me as a
>>> -mm newbie.
>>
>> So, who exactly is the target audience for the above text?  I'm not sure
>> that "really confusing" does it justice: from my point of view (though
>> admittedly I am very far from being an eleet k3rn3l h4x0r) it just looks
>> like gibberish.  If it's going into oe-core then I would have hoped that
>> the checkin comment would be intelligible to oe-core users at large, not
>> just those who are schooled in the mysterious ways of some particular
>> subgroup.
>
> It's a quote from the kern-tools commit log. I could just put: 'fixes stuff',
> but that's not good either. Writing a novel isn't good either.
>
> I'm not sure why everyone is having such an issue with this, there's many
> other examples of commits like this, and everyone sits in a glass house
> in this regard.
>
> I can re-work it of course, I wrote it very late at night to fix a

I rewrote the SRCREV update commit into something more legible. It's on
the same branch as the original pull request.

Cheers,

Bruce

> fairly blocking
> bug, so everyone cutting a little bit of slack would be appreciated.
>
> Cheers,
>
> Bruce
>
>>
>> p.
>>
>>
>>
>> _______________________________________________
>> 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"
Richard Purdie - May 9, 2012, 7:43 p.m.
On Wed, 2012-05-09 at 12:42 -0400, Bruce Ashfield wrote:
> On Wed, May 9, 2012 at 12:11 PM, Bruce Ashfield
> <bruce.ashfield@gmail.com> wrote:
> > On Wed, May 9, 2012 at 12:02 PM, Phil Blundell <philb@gnu.org> wrote:
> >> On Wed, 2012-05-09 at 11:48 -0400, Bruce Ashfield wrote:
> >>> On Wed, May 9, 2012 at 11:40 AM, Darren Hart <dvhart@linux.intel.com> wrote:
> >>> >
> >>> >
> >>> > On 05/08/2012 08:48 PM, Bruce Ashfield wrote:
> >>> >> Updating the SRCREV to pickup the following fix:
> >>> >>
> >>> >>     createme: fix checkpoint restoration for reset branches
> >>> >>
> >>> >>     The meta branch can optionally be merged out to BSP branches. This removes
> >>> >>     the need to restore the checkpoint when working with the tree.  The way
> >>> >>     it detects the merge is by checking to see how many branches contain the
> >>> >>     meta data. If there's more than one, the branch was was merged out.
> >>> >>
> >>> >>     Unless you are a BSP that isn't tracking the latest meta, and you get
> >>> >>     meta and meta-orig created. That's two branches and the code opts to not
> >>> >>     restore the checkpoint, which leads to configuration errors.
> >>> >>
> >>> >>     The fix is simple. We allow for 2 or less branches with meta, and will
> >>> >>     still restore the checkpoint. Three and up, we won't.
> >>> >>
> >>> >
> >>> > Uhm... am I the only one for whom this language is really confusing?
> >>> > "merged out" ?
> >>> > "restore the checkpoint" ?
> >>>
> >>> I could be more verbose, but it's like reading a kernel -mm commit. I
> >>> don't grok everything they write, but they aren't writing it for me as a
> >>> -mm newbie.
> >>
> >> So, who exactly is the target audience for the above text?  I'm not sure
> >> that "really confusing" does it justice: from my point of view (though
> >> admittedly I am very far from being an eleet k3rn3l h4x0r) it just looks
> >> like gibberish.  If it's going into oe-core then I would have hoped that
> >> the checkin comment would be intelligible to oe-core users at large, not
> >> just those who are schooled in the mysterious ways of some particular
> >> subgroup.
> >
> > It's a quote from the kern-tools commit log. I could just put: 'fixes stuff',
> > but that's not good either. Writing a novel isn't good either.
> >
> > I'm not sure why everyone is having such an issue with this, there's many
> > other examples of commits like this, and everyone sits in a glass house
> > in this regard.
> >
> > I can re-work it of course, I wrote it very late at night to fix a
> 
> I rewrote the SRCREV update commit into something more legible. It's on
> the same branch as the original pull request.

Thanks, I think this is a timely reminder to everyone to think about the
people who might read a commit message and try and make it meaningful to
them. I've merged the revised version to master.

Cheers,

Richard

Patch

diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index b6fab39..b5e203e 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,7 +4,7 @@  LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d8
 
 DEPENDS = "git-native guilt-native"
 
-SRCREV = "9bb704df0a86578b8ae1f4c85e45089bef28e026"
+SRCREV = "de3649840e8e3ca25bc79d2444f04a1b158a1769"
 PR = "r12"
 PV = "0.1+git${SRCPV}"