All of lore.kernel.org
 help / color / mirror / Atom feed
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




      reply	other threads:[~2012-05-09 19:54 UTC|newest]

Thread overview: 9+ 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 15:48       ` [OE-core] " 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.