All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: Philip Tricca <flihp@twobit.us>,
	"yocto@yoctoproject.org" <yocto@yoctoproject.org>
Subject: Re: [meta-selinux] git recipes
Date: Mon, 29 Feb 2016 08:06:43 -0600	[thread overview]
Message-ID: <56D45073.3050800@windriver.com> (raw)
In-Reply-To: <56D27649.4040306@twobit.us>

On 2/27/16 10:23 PM, Philip Tricca wrote:
> Adding a sensible subject.

Sorry couldn't reply when I saw this when you first sent it.  Corporate email
server went down for those of us who DON'T use outlook.. argh..

Anyway..

What I'm generally used to in the Yocto Project work is that the 'git' version
picks a specific git snapshot and makes it a quick operation for someone to
arbitrarily change that snapshot by adjusting the SRCREV.

We don't use the AUTOREV parameter, because that causes the system to have to do
a git pull in order to evaluate the available versions and determine the SRCREV
to use.  So it's all down to a parsing and performance issue.

What I've done on some of my own projects is have an AUTOREV version (locally),
then when it triggers a recipe breakage, I think update the SRCREV and fix it in
the remote tree..  so I get the autorev, the world gets a version of the package
that keeps working.  (I also update the SRCREV other times as well.. but the
autorev breakage is one of the key triggers.)

Joe might have some suggestions as well, I'm not against AUTOREV per say, but I
am worried about any performance issues during the parse.

--Mark

> On 02/27/2016 08:17 PM, Philip Tricca wrote:
>> While going through the backlog I ran across the 'git' versions of the
>> user space. I noticed that a recent contribution was adding a patch to
>> the git recipe and I figured that this patch would already be upstream
>> and so wouldn't be necessary. Not so. The 'git' versions have SRCREV
>> hard wired (SRCREV) to a commit id but it's way back from the end of
>> 2013. They're also disabled via DEFAULT_PREFERENCE = "-1"
>>
>> These 'git' versions seem super useful for testing bleeding edge stuff
>> so IMHO keeping them around would be the right thing to do. Not sure how
>> I feel about them tracking an ancient commit though. Since they're never
>> built by default it seems reasonable to track the master branch.
>>
>> What's our philosophy w/r to recipes that pull from git? Is there some
>> history behind this SRCREV?
>>
>> Thanks,
>> Philip
>>
> 



  reply	other threads:[~2016-02-29 14:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-28  4:17 [meta-selinux] Philip Tricca
2016-02-28  4:23 ` [meta-selinux] git recipes Philip Tricca
2016-02-29 14:06   ` Mark Hatle [this message]
2016-03-01 18:30     ` Joe MacDonald
2016-03-02  5:40       ` Philip Tricca
  -- strict thread matches above, loose matches on Subject: below --
2016-03-02 15:47 Radzykewycz, T (Radzy)
2016-03-03  3:59 ` Philip Tricca
2016-03-03 20:44   ` Joe MacDonald
2016-03-06 20:31     ` Philip Tricca

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=56D45073.3050800@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=flihp@twobit.us \
    --cc=yocto@yoctoproject.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.