[meta-selinux]

[meta-selinux]

[Philip Tricca]

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

Re: [meta-selinux] git recipes

[Philip Tricca]

Adding a sensible subject.

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
> 

Re: [meta-selinux] git recipes

[Mark Hatle]

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
>>
> 

Re: [meta-selinux] git recipes

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 3653 bytes --]

[Re: [yocto] [meta-selinux] git recipes] On 16.02.29 (Mon 08:06) Mark Hatle wrote:

> 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.

This has been the approach I'd always tried to take with _git recipes as
well and it tends to work very well for ones that are either the only or
the preferred recipe.  I think in our case we were always preferring the
released versions for several historical reasons and the _git recipes were
relegated to the second-tier because of it.  But that means that basically
they never got updated.

About a year and a half ago I started seriously talking about dumping the
userspace tools entirely and only ever working out of the _git recipes.
Shrikant started doing that work after I discussed it with him but we
never got beyond the policy recipes.  So if you guys think this is not a
completely insane thing to do, that's the direction I'd like to go with
this.

> 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.

And avoiding surprises on the other side of the bathtub curve, when
updates pop up that we aren't prepared for.  :-)  But we've been behind
on developments aging out, too, so I don't have a strong case to argue
against AUTOREV.

> 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.

I would really rather avoid AUTOREV, but I think the way we would
accomplish that is to edge away from our current recipes and bring the
_git ones back to centre stage.  Then we're likely to stay on top of a
fixed SRCREV anyway.

But as I say, maybe I'm completely insane on this point.

-J.

> 
> --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
> >>
> > 
> 
-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 484 bytes --]

Re: [meta-selinux] git recipes

[Philip Tricca]

On 03/01/2016 10:30 AM, Joe MacDonald wrote:
> [Re: [yocto] [meta-selinux] git recipes] On 16.02.29 (Mon 08:06) Mark Hatle wrote:
> 
>> 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.
> 
> This has been the approach I'd always tried to take with _git recipes as
> well and it tends to work very well for ones that are either the only or
> the preferred recipe.  I think in our case we were always preferring the
> released versions for several historical reasons and the _git recipes were
> relegated to the second-tier because of it.  But that means that basically
> they never got updated.
> 
> About a year and a half ago I started seriously talking about dumping the
> userspace tools entirely and only ever working out of the _git recipes.
> Shrikant started doing that work after I discussed it with him but we
> never got beyond the policy recipes.  So if you guys think this is not a
> completely insane thing to do, that's the direction I'd like to go with
> this.
> 
>> 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.
> 
> And avoiding surprises on the other side of the bathtub curve, when
> updates pop up that we aren't prepared for.  :-)  But we've been behind
> on developments aging out, too, so I don't have a strong case to argue
> against AUTOREV.
>
>> 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.
> 
> I would really rather avoid AUTOREV, but I think the way we would
> accomplish that is to edge away from our current recipes and bring the
> _git ones back to centre stage.  Then we're likely to stay on top of a
> fixed SRCREV anyway.

I think there's something to be said for a simple approach. For those
showing up and trying to figure out what's going on / how the build
works it would likely ease their entry if we had straight forward
recipes that build from the usptream release tarballs. For those wanting
to verify hashes published by upstream (and maybe signed) this makes
life easier as well.

Mark's point is well taken though and there's lots of value in having
the git recipes for those who want to experiment. I think Marks test /
development setup / tracking AUTOREV behind closed doors is very useful.

In the interest of not making too many changes too early on I'd like to
propose the following:
- keep the release-tracking recipes the default, no change in
PREFERRED_VERSIONs etc.
- Keep the git recipes around and still pointing to a static SRCREV
- Update SRCREV to the latest release and keep it up to date as we move
the userspace etc forward
- Do not maintain a patch queue for the git recipes

I think this last point is likely the only departure from our current
approach (and my 3rd point is just an update). My reason for removing
the patch queue is that if someone wants to experiment with git they'll
likely not want any of those patches. The patch queue will probably just
get in their way.

> But as I say, maybe I'm completely insane on this point.

Nothing insane but I'm feeling conservative, maybe just till the dust
settles. Agree / disagree with the above as a first step at least?

Philip

> 
> -J.
> 
>>
>> --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
>>>>
>>>
>>