From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/1] kern-tools: checkpoint restoration for reset branches
Date: Wed, 09 May 2012 20:43:44 +0100 [thread overview]
Message-ID: <1336592624.2494.68.camel@ted> (raw)
In-Reply-To: <CADkTA4NG8Ncge_7miPc38tzConX0FxJN-By+RmzO01Y3j4F3Cg@mail.gmail.com>
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
prev parent reply other threads:[~2012-05-09 19:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-09 3:48 [PATCH 0/1] kern-tools: fix meta-intel builds Bruce Ashfield
2012-05-09 3:48 ` [PATCH 1/1] kern-tools: checkpoint restoration for reset branches Bruce Ashfield
2012-05-09 15:40 ` Darren Hart
2012-05-09 15:48 ` Bruce Ashfield
2012-05-09 16:02 ` Phil Blundell
2012-05-09 16:11 ` Bruce Ashfield
2012-05-09 16:42 ` Bruce Ashfield
2012-05-09 19:43 ` Richard Purdie [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1336592624.2494.68.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox