| 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
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}" >
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
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.
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
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"
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}"
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(-)