[OE-core] [PATCH 1/1] kern-tools: checkpoint restoration for reset branches

Richard Purdie richard.purdie at linuxfoundation.org
Wed May 9 19:43:44 UTC 2012


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 at gmail.com> wrote:
> > On Wed, May 9, 2012 at 12:02 PM, Phil Blundell <philb at 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 at 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





More information about the Openembedded-core mailing list