edison/denzil patches (post-1.1.2 and 1.2.1)

edison/denzil patches (post-1.1.2 and 1.2.1)

[McClintock Matthew-B29882]

Josh, Scott:

I've pushed a set of patches for edison/denzil branch - and I may push
a few more still to:

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/edison
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil

These are all cherry-pick's and most applied cleanly and a few had
some minor cleanups. Please consider these for after the point
releases. I will continue to push to these branches and rebase these
branches off the official upstream trees as well.

-M

Re: edison/denzil patches (post-1.1.2 and 1.2.1)

[McClintock Matthew-B29882]

Adding Scott...

On Thu, Jul 12, 2012 at 12:43 PM, Matthew McClintock <msm@freescale.com> wrote:
> Josh, Scott:
>
> I've pushed a set of patches for edison/denzil branch - and I may push
> a few more still to:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/edison
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil
>
> These are all cherry-pick's and most applied cleanly and a few had
> some minor cleanups. Please consider these for after the point
> releases. I will continue to push to these branches and rebase these
> branches off the official upstream trees as well.
>
> -M

Re: edison/denzil patches (post-1.1.2 and 1.2.1)

[Joshua Lock]

On 12/07/12 10:43, McClintock Matthew-B29882 wrote:
> Josh, Scott:
>
> I've pushed a set of patches for edison/denzil branch - and I may push
> a few more still to:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/edison
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil
>
> These are all cherry-pick's and most applied cleanly and a few had
> some minor cleanups. Please consider these for after the point
> releases. I will continue to push to these branches and rebase these
> branches off the official upstream trees as well.

I don't know how much work will be done on Edison after the 1.1.2 
release. I personally will no longer be working on it and I don't think 
the team here as enough resources to maintain it perpetually.

I assume that these changes are predominantly to further improve PPC 
support?

In general your branch has several types of changes that have generally 
been considered inappropriate for a point release (such as recipe 
upgrades, new functionality, etc).

Personally I'm not very keen on the idea of pushing them all and 
advocating their inclusion. I'd strongly encourage adoption of this 
release series if it's to continue to be relevant to your work.

Cheers,
Joshua
-- 
Joshua Lock
         Intel Open Source Technology Centre

Re: edison/denzil patches (post-1.1.2 and 1.2.1)

[McClintock Matthew-B29882]

On Mon, Jul 16, 2012 at 9:58 AM, Joshua Lock <josh@linux.intel.com> wrote:
> On 12/07/12 10:43, McClintock Matthew-B29882 wrote:
>>
>> Josh, Scott:
>>
>> I've pushed a set of patches for edison/denzil branch - and I may push
>> a few more still to:
>>
>>
>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/edison
>>
>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil
>>
>> These are all cherry-pick's and most applied cleanly and a few had
>> some minor cleanups. Please consider these for after the point
>> releases. I will continue to push to these branches and rebase these
>> branches off the official upstream trees as well.
>
>
> I don't know how much work will be done on Edison after the 1.1.2 release. I
> personally will no longer be working on it and I don't think the team here
> as enough resources to maintain it perpetually.

OK.

> I assume that these changes are predominantly to further improve PPC
> support?

Yes.

> In general your branch has several types of changes that have generally been
> considered inappropriate for a point release (such as recipe upgrades, new
> functionality, etc).

I see very little of this, the valgrind series and/or the a few other
image generation bits.

> Personally I'm not very keen on the idea of pushing them all and advocating
> their inclusion. I'd strongly encourage adoption of this release series if
> it's to continue to be relevant to your work.

So is poky edison dead now? How do I support folks that still want to
use it? I understand that *you* may not have time but is there a
process for someone that cares about this release still to do work? If
a fork is required is there a way to point folks at this fork? Such as
if you want this to work use this other version?

As far as these changes go, we are mostly done with edison as well -
but I was trying to get the official poky edison into a useful state
for powerpc so if folks wanted to go with a community version it would
work reasonably well.

-M

Re: edison/denzil patches (post-1.1.2 and 1.2.1)

[Joshua Lock]

On 16/07/12 08:10, McClintock Matthew-B29882 wrote:
> On Mon, Jul 16, 2012 at 9:58 AM, Joshua Lock <josh@linux.intel.com> wrote:
>> On 12/07/12 10:43, McClintock Matthew-B29882 wrote:
>>>
>>> Josh, Scott:
>>>
>>> I've pushed a set of patches for edison/denzil branch - and I may push
>>> a few more still to:
>>>
>>>
>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/edison
>>>
>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil
>>>
>>> These are all cherry-pick's and most applied cleanly and a few had
>>> some minor cleanups. Please consider these for after the point
>>> releases. I will continue to push to these branches and rebase these
>>> branches off the official upstream trees as well.
>>
>>
>> I don't know how much work will be done on Edison after the 1.1.2 release. I
>> personally will no longer be working on it and I don't think the team here
>> as enough resources to maintain it perpetually.
>
> OK.
>
>> I assume that these changes are predominantly to further improve PPC
>> support?
>
> Yes.
>
>> In general your branch has several types of changes that have generally been
>> considered inappropriate for a point release (such as recipe upgrades, new
>> functionality, etc).
>
> I see very little of this, the valgrind series and/or the a few other
> image generation bits.

Indeed, that's likely the sum of it but the changes in isolation don't 
offer any context as to why they're required for PPC so my gut reaction 
is to reject them as they violate the suggested guidelines for stable 
releases.

>> Personally I'm not very keen on the idea of pushing them all and advocating
>> their inclusion. I'd strongly encourage adoption of this release series if
>> it's to continue to be relevant to your work.
>
> So is poky edison dead now? How do I support folks that still want to
> use it? I understand that *you* may not have time but is there a
> process for someone that cares about this release still to do work? If
> a fork is required is there a way to point folks at this fork? Such as
> if you want this to work use this other version?

I certainly can't see why one would need to fork.

I would like to see Edison live on, which is why I sent an email 
suggesting it be adopted, *I* just don't have time to work on it any more.

I'm sure Saul and/or David can help work out a process, as I don't have 
a clear understanding of it (I am but one cog in the engine). I can't 
imagine why it would be hugely different from the way it's been 
maintained thus far.

Much of that work you've already been doing with the branch you have 
submitted.

In addition there are a different set of requirements for just getting 
changes into the branch vs. having some kind of release which includes 
those changes.

The latter would require QA, build/release engineering, release 
readiness, etc.

Thanks,
Joshua
-- 
Joshua Lock
         Yocto Project
         Intel Open Source Technology Centre

Re: edison/denzil patches (post-1.1.2 and 1.2.1)

[McClintock Matthew-B29882]

On Mon, Jul 16, 2012 at 10:32 AM, Joshua Lock <josh@linux.intel.com> wrote:
> On 16/07/12 08:10, McClintock Matthew-B29882 wrote:
>>
>> On Mon, Jul 16, 2012 at 9:58 AM, Joshua Lock <josh@linux.intel.com> wrote:
>>>
>>> On 12/07/12 10:43, McClintock Matthew-B29882 wrote:
>>>>
>>>>
>>>> Josh, Scott:
>>>>
>>>> I've pushed a set of patches for edison/denzil branch - and I may push
>>>> a few more still to:
>>>>
>>>>
>>>>
>>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/edison
>>>>
>>>>
>>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil
>>>>
>>>> These are all cherry-pick's and most applied cleanly and a few had
>>>> some minor cleanups. Please consider these for after the point
>>>> releases. I will continue to push to these branches and rebase these
>>>> branches off the official upstream trees as well.
>>>
>>>
>>>
>>> I don't know how much work will be done on Edison after the 1.1.2
>>> release. I
>>> personally will no longer be working on it and I don't think the team
>>> here
>>> as enough resources to maintain it perpetually.
>>
>>
>> OK.
>>
>>> I assume that these changes are predominantly to further improve PPC
>>> support?
>>
>>
>> Yes.
>>
>>> In general your branch has several types of changes that have generally
>>> been
>>> considered inappropriate for a point release (such as recipe upgrades,
>>> new
>>> functionality, etc).
>>
>>
>> I see very little of this, the valgrind series and/or the a few other
>> image generation bits.
>
>
> Indeed, that's likely the sum of it but the changes in isolation don't offer
> any context as to why they're required for PPC so my gut reaction is to
> reject them as they violate the suggested guidelines for stable releases.

I'm fine to have some of them rejected, such is how things work ;)

>>> Personally I'm not very keen on the idea of pushing them all and
>>> advocating
>>> their inclusion. I'd strongly encourage adoption of this release series
>>> if
>>> it's to continue to be relevant to your work.
>>
>>
>> So is poky edison dead now? How do I support folks that still want to
>> use it? I understand that *you* may not have time but is there a
>> process for someone that cares about this release still to do work? If
>> a fork is required is there a way to point folks at this fork? Such as
>> if you want this to work use this other version?
>
>
> I certainly can't see why one would need to fork.
>
> I would like to see Edison live on, which is why I sent an email suggesting
> it be adopted, *I* just don't have time to work on it any more.

I know what you mean ;)

> I'm sure Saul and/or David can help work out a process, as I don't have a
> clear understanding of it (I am but one cog in the engine). I can't imagine
> why it would be hugely different from the way it's been maintained thus far.
>
> Much of that work you've already been doing with the branch you have
> submitted.

Yep, I've made my best effort to only backport commits already upstream.

> In addition there are a different set of requirements for just getting
> changes into the branch vs. having some kind of release which includes those
> changes.
>
> The latter would require QA, build/release engineering, release readiness,
> etc.

I understand. I'm fine with adding stuff to the edison branch for now
and we can worry about another official release sometime in the future
(or never). I'm mostly wanting a place I can tell people to get the
(working) code from for our targets. And ideally it's on
yoctoproject.org and not github.com or git.fsl.com

Just for some more context, we just release our SDK off of edison and
I expect plenty of activity around bugfixes and back porting commits.
I would like this work to be available to all attempting to build
edison as well.

-M

Re: edison/denzil patches (post-1.1.2 and 1.2.1)

[Scott Garman]

On 07/12/2012 10:43 AM, McClintock Matthew-B29882 wrote:
> Josh, Scott:
>
> I've pushed a set of patches for edison/denzil branch - and I may push
> a few more still to:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/edison
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil
>
> These are all cherry-pick's and most applied cleanly and a few had
> some minor cleanups. Please consider these for after the point
> releases. I will continue to push to these branches and rebase these
> branches off the official upstream trees as well.

Cool, this is a fairly convenient way for me to merge in these commits. 
Like Joshua has pointed out, as long as they are bugfixes and don't 
introduce significant feature additions or create backward compatibility 
problems, we are likely to accept them.

I'm back from vacation and am catching up on a massive email backlog. 
Please feel free to ping me in a few days if you don't see these merged 
into my sgarman/denzil-next-1.2.2 branch.

Thanks,

Scott

-- 
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center

Re: edison/denzil patches (post-1.1.2 and 1.2.1)

[McClintock Matthew-B29882]

On Mon, Jul 16, 2012 at 11:22 AM, Scott Garman <scott.a.garman@intel.com> wrote:
> On 07/12/2012 10:43 AM, McClintock Matthew-B29882 wrote:
>>
>> Josh, Scott:
>>
>> I've pushed a set of patches for edison/denzil branch - and I may push
>> a few more still to:
>>
>>
>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/edison
>>
>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil
>>
>> These are all cherry-pick's and most applied cleanly and a few had
>> some minor cleanups. Please consider these for after the point
>> releases. I will continue to push to these branches and rebase these
>> branches off the official upstream trees as well.
>
>
> Cool, this is a fairly convenient way for me to merge in these commits. Like
> Joshua has pointed out, as long as they are bugfixes and don't introduce
> significant feature additions or create backward compatibility problems, we
> are likely to accept them.
>
> I'm back from vacation and am catching up on a massive email backlog. Please
> feel free to ping me in a few days if you don't see these merged into my
> sgarman/denzil-next-1.2.2 branch.

Thanks Scott,

I'm closing up on the edison branch changes and testing and I will be
adding more to the denzil branch soon.

-M

>
> Thanks,
>
> Scott
>
> --
> Scott Garman
> Embedded Linux Engineer - Yocto Project
> Intel Open Source Technology Center
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Re: edison/denzil patches (post-1.1.2 and 1.2.1)

[Joshua Lock]

On Mon, 2012-07-16 at 16:01 +0000, McClintock Matthew-B29882 wrote:
> On Mon, Jul 16, 2012 at 10:32 AM, Joshua Lock <josh@linux.intel.com> wrote:
> > On 16/07/12 08:10, McClintock Matthew-B29882 wrote:
> >>
> >> On Mon, Jul 16, 2012 at 9:58 AM, Joshua Lock <josh@linux.intel.com> wrote:
> >>>
> >>> On 12/07/12 10:43, McClintock Matthew-B29882 wrote:
> >>>>
> >>>>
> >>>> Josh, Scott:
> >>>>
> >>>> I've pushed a set of patches for edison/denzil branch - and I may push
> >>>> a few more still to:
> >>>>
> >>>>
> >>>>
> >>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/edison
> >>>>
> >>>>
> >>>> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=mattsm/denzil
> >>>>
> >>>> These are all cherry-pick's and most applied cleanly and a few had
> >>>> some minor cleanups. Please consider these for after the point
> >>>> releases. I will continue to push to these branches and rebase these
> >>>> branches off the official upstream trees as well.
> >>>
> >>>
> >>>
> >>> I don't know how much work will be done on Edison after the 1.1.2
> >>> release. I
> >>> personally will no longer be working on it and I don't think the team
> >>> here
> >>> as enough resources to maintain it perpetually.
> >>
> >>
> >> OK.
> >>
> >>> I assume that these changes are predominantly to further improve PPC
> >>> support?
> >>
> >>
> >> Yes.
> >>
> >>> In general your branch has several types of changes that have generally
> >>> been
> >>> considered inappropriate for a point release (such as recipe upgrades,
> >>> new
> >>> functionality, etc).
> >>
> >>
> >> I see very little of this, the valgrind series and/or the a few other
> >> image generation bits.
> >
> >
> > Indeed, that's likely the sum of it but the changes in isolation don't offer
> > any context as to why they're required for PPC so my gut reaction is to
> > reject them as they violate the suggested guidelines for stable releases.
> 
> I'm fine to have some of them rejected, such is how things work ;)
> 
> >>> Personally I'm not very keen on the idea of pushing them all and
> >>> advocating
> >>> their inclusion. I'd strongly encourage adoption of this release series
> >>> if
> >>> it's to continue to be relevant to your work.
> >>
> >>
> >> So is poky edison dead now? How do I support folks that still want to
> >> use it? I understand that *you* may not have time but is there a
> >> process for someone that cares about this release still to do work? If
> >> a fork is required is there a way to point folks at this fork? Such as
> >> if you want this to work use this other version?
> >
> >
> > I certainly can't see why one would need to fork.
> >
> > I would like to see Edison live on, which is why I sent an email suggesting
> > it be adopted, *I* just don't have time to work on it any more.
> 
> I know what you mean ;)
> 
> > I'm sure Saul and/or David can help work out a process, as I don't have a
> > clear understanding of it (I am but one cog in the engine). I can't imagine
> > why it would be hugely different from the way it's been maintained thus far.
> >
> > Much of that work you've already been doing with the branch you have
> > submitted.
> 
> Yep, I've made my best effort to only backport commits already upstream.
> 
> > In addition there are a different set of requirements for just getting
> > changes into the branch vs. having some kind of release which includes those
> > changes.
> >
> > The latter would require QA, build/release engineering, release readiness,
> > etc.
> 
> I understand. I'm fine with adding stuff to the edison branch for now
> and we can worry about another official release sometime in the future
> (or never). I'm mostly wanting a place I can tell people to get the
> (working) code from for our targets. And ideally it's on
> yoctoproject.org and not github.com or git.fsl.com

Great, the best thing would be to submit a pull request against the
edison branch with a suitable subject.

> 
> Just for some more context, we just release our SDK off of edison and
> I expect plenty of activity around bugfixes and back porting commits.
> I would like this work to be available to all attempting to build
> edison as well.

Congratulations! I appreciate your effort in sharing this work.

Joshua

Re: edison/denzil patches (post-1.1.2 and 1.2.1)

[Stewart, David C]

Hey Matthew - 

>From: yocto-bounces@yoctoproject.org [mailto:yocto-
>bounces@yoctoproject.org] On Behalf Of McClintock Matthew-B29882
>Sent: Monday, July 16, 2012 9:01 AM

>I understand. I'm fine with adding stuff to the edison branch for now
>and we can worry about another official release sometime in the future
>(or never). I'm mostly wanting a place I can tell people to get the
>(working) code from for our targets. And ideally it's on
>yoctoproject.org and not github.com or git.fsl.com

This comes down to a resource trade-off, which is why I'm replying. :-) 

As an open source project and not a product, we have to set some boundaries on how long we will put effort on a given release. It also seems prudent to treat our release branches consistently as well. Besides tagging branches when we release them, I think we want to leave the head of the release branches in some known good state. That known good state has always been "passed our release criteria" which includes QA, release notes, etc.

So what if we create a separate branch off of edison, something like edison-fsl? Then you could base your patches against it, but we leave edison in the known good state?

>Just for some more context, we just release our SDK off of edison and
>I expect plenty of activity around bugfixes and back porting commits.
>I would like this work to be available to all attempting to build
>edison as well.

I know... I'm in agony that we have run out of resources to continue to put effort into edison (or "Eddie" as I call him now). Hopefully the above compromise serves your needs and keeps our resource commitment and known good state assumptions in check.

Whatcha think?

Re: edison/denzil patches (post-1.1.2 and 1.2.1)

[McClintock Matthew-B29882]

On Tue, Jul 17, 2012 at 3:18 PM, Stewart, David C
<david.c.stewart@intel.com> wrote:
> Hey Matthew -
>
>>From: yocto-bounces@yoctoproject.org [mailto:yocto-
>>bounces@yoctoproject.org] On Behalf Of McClintock Matthew-B29882
>>Sent: Monday, July 16, 2012 9:01 AM
>
>>I understand. I'm fine with adding stuff to the edison branch for now
>>and we can worry about another official release sometime in the future
>>(or never). I'm mostly wanting a place I can tell people to get the
>>(working) code from for our targets. And ideally it's on
>>yoctoproject.org and not github.com or git.fsl.com
>
> This comes down to a resource trade-off, which is why I'm replying. :-)
>
> As an open source project and not a product, we have to set some boundaries on how long we will put effort on a given release. It also seems prudent to treat our release branches consistently as well. Besides tagging branches when we release them, I think we want to leave the head of the release branches in some known good state. That known good state has always been "passed our release criteria" which includes QA, release notes, etc.

This is coming up on a year old, and we released our SDK based off
edison late too so that eats up some of the time that this release was
officially supported. But I would encourage us to support releases for
more than 1 year given the typical embedded product development life
cycle - and support can be arbitrary, I'm not 100% sure it should mean
it's been through a full QA process... but maybe it does too. Maybe we
should time the releases too so they are 4 and 8 months after the
release to get max overlap for that full year.

> So what if we create a separate branch off of edison, something like edison-fsl? Then you could base your patches against it, but we leave edison in the known good state?

That's perfectly fine with me. See my other suggestion below too.

>
>>Just for some more context, we just release our SDK off of edison and
>>I expect plenty of activity around bugfixes and back porting commits.
>>I would like this work to be available to all attempting to build
>>edison as well.
>
> I know... I'm in agony that we have run out of resources to continue to put effort into edison (or "Eddie" as I call him now). Hopefully the above compromise serves your needs and keeps our resource commitment and known good state assumptions in check.
>
> Whatcha think?

I know resources are tight, I also see the appeal of having the head
of edison point at the last release, but... edison proper will miss
out on all our fixes we backport over the next few months as this is
our primary SDK until our next release based off denzil. This does not
seem to be as big as an issue for edison since I don't think many
(any?) others have based an SDK/BSP off this release.

It may become more prudent for denzil if we have multiple interested
parties in maintaining these older releases for longer... I know I
would like to pull in others fixes for denzil for as long as possible.
But how do these other interested parties initiate a QA cycle within
Yocto? Obviously having done their own QA for their own stuff and the
other interested parties did more QA on the others work but never the
full official Yocto QA cycle?

Maybe an official strategy for a staging to release branches is in order?

edison-{staging,experimental,next}

Then folks can possibly see some potential fixes for their issues in
the experimental branch?

Just sharing my thoughts, I'm not insisting on any particular method
but I would like my edison fixes available somehow on yp.org.

-M

Re: edison/denzil patches (post-1.1.2 and 1.2.1)

[William Mills]

On 07/17/2012 04:43 PM, McClintock Matthew-B29882 wrote:
> On Tue, Jul 17, 2012 at 3:18 PM, Stewart, David C
> <david.c.stewart@intel.com>  wrote:
>> Hey Matthew -
>>
>>> From: yocto-bounces@yoctoproject.org [mailto:yocto-
>>> bounces@yoctoproject.org] On Behalf Of McClintock Matthew-B29882
>>> Sent: Monday, July 16, 2012 9:01 AM
>>> I understand. I'm fine with adding stuff to the edison branch for now
>>> and we can worry about another official release sometime in the future
>>> (or never). I'm mostly wanting a place I can tell people to get the
>>> (working) code from for our targets. And ideally it's on
>>> yoctoproject.org and not github.com or git.fsl.com
>> This comes down to a resource trade-off, which is why I'm replying. :-)
>>
>> As an open source project and not a product, we have to set some boundaries on how long we will put effort on a given release. It also seems prudent to treat our release branches consistently as well. Besides tagging branches when we release them, I think we want to leave the head of the release branches in some known good state. That known good state has always been "passed our release criteria" which includes QA, release notes, etc.
> This is coming up on a year old, and we released our SDK based off
> edison late too so that eats up some of the time that this release was
> officially supported. But I would encourage us to support releases for
> more than 1 year given the typical embedded product development life
> cycle - and support can be arbitrary, I'm not 100% sure it should mean
> it's been through a full QA process... but maybe it does too. Maybe we
> should time the releases too so they are 4 and 8 months after the
> release to get max overlap for that full year.
>
>> So what if we create a separate branch off of edison, something like edison-fsl? Then you could base your patches against it, but we leave edison in the known good state?
> That's perfectly fine with me. See my other suggestion below too.

Each company/group still using an old release could create its own 
branch as you suggest.  However, it might make sense to create a generic 
branch of branch so any remaining stranglers could attempt to cooperate 
even w/o official yocto-project resources.

e.g. edison-community-maint


>>> Just for some more context, we just release our SDK off of edison and
>>> I expect plenty of activity around bugfixes and back porting commits.
>>> I would like this work to be available to all attempting to build
>>> edison as well.
>> I know... I'm in agony that we have run out of resources to continue to put effort into edison (or "Eddie" as I call him now). Hopefully the above compromise serves your needs and keeps our resource commitment and known good state assumptions in check.
>>
>> Whatcha think?
> I know resources are tight, I also see the appeal of having the head
> of edison point at the last release, but... edison proper will miss
> out on all our fixes we backport over the next few months as this is
> our primary SDK until our next release based off denzil. This does not
> seem to be as big as an issue for edison since I don't think many
> (any?) others have based an SDK/BSP off this release.
>
> It may become more prudent for denzil if we have multiple interested
> parties in maintaining these older releases for longer... I know I
> would like to pull in others fixes for denzil for as long as possible.
> But how do these other interested parties initiate a QA cycle within
> Yocto? Obviously having done their own QA for their own stuff and the
> other interested parties did more QA on the others work but never the
> full official Yocto QA cycle?
>
> Maybe an official strategy for a staging to release branches is in order?
>
> edison-{staging,experimental,next}
>

This is another good approach.  However I think after yp has moved on, I 
doubt there is any resources to promote from the last stage to the 
"official".

> Then folks can possibly see some potential fixes for their issues in
> the experimental branch?
>
> Just sharing my thoughts, I'm not insisting on any particular method
> but I would like my edison fixes available somehow on yp.org.
>
> -M

I think Matthew's current need will not be unique.  It would be good to 
think this through and have a published stand-down policy.

Re: edison/denzil patches (post-1.1.2 and 1.2.1)

[McClintock Matthew-B29882]

On Tue, Jul 17, 2012 at 4:19 PM, William Mills <wmills@ti.com> wrote:
>
>
> On 07/17/2012 04:43 PM, McClintock Matthew-B29882 wrote:
>>
>> On Tue, Jul 17, 2012 at 3:18 PM, Stewart, David C
>> <david.c.stewart@intel.com>  wrote:
>>>
>>> Hey Matthew -
>>>
>>>> From: yocto-bounces@yoctoproject.org [mailto:yocto-
>>>> bounces@yoctoproject.org] On Behalf Of McClintock Matthew-B29882
>>>> Sent: Monday, July 16, 2012 9:01 AM
>>>> I understand. I'm fine with adding stuff to the edison branch for now
>>>> and we can worry about another official release sometime in the future
>>>> (or never). I'm mostly wanting a place I can tell people to get the
>>>> (working) code from for our targets. And ideally it's on
>>>> yoctoproject.org and not github.com or git.fsl.com
>>>
>>> This comes down to a resource trade-off, which is why I'm replying. :-)
>>>
>>> As an open source project and not a product, we have to set some
>>> boundaries on how long we will put effort on a given release. It also seems
>>> prudent to treat our release branches consistently as well. Besides tagging
>>> branches when we release them, I think we want to leave the head of the
>>> release branches in some known good state. That known good state has always
>>> been "passed our release criteria" which includes QA, release notes, etc.
>>
>> This is coming up on a year old, and we released our SDK based off
>> edison late too so that eats up some of the time that this release was
>> officially supported. But I would encourage us to support releases for
>> more than 1 year given the typical embedded product development life
>> cycle - and support can be arbitrary, I'm not 100% sure it should mean
>> it's been through a full QA process... but maybe it does too. Maybe we
>> should time the releases too so they are 4 and 8 months after the
>> release to get max overlap for that full year.
>>
>>> So what if we create a separate branch off of edison, something like
>>> edison-fsl? Then you could base your patches against it, but we leave edison
>>> in the known good state?
>>
>> That's perfectly fine with me. See my other suggestion below too.
>
>
> Each company/group still using an old release could create its own branch as
> you suggest.  However, it might make sense to create a generic branch of
> branch so any remaining stranglers could attempt to cooperate even w/o
> official yocto-project resources.
>
> e.g. edison-community-maint
>
>
>
>>>> Just for some more context, we just release our SDK off of edison and
>>>> I expect plenty of activity around bugfixes and back porting commits.
>>>> I would like this work to be available to all attempting to build
>>>> edison as well.
>>>
>>> I know... I'm in agony that we have run out of resources to continue to
>>> put effort into edison (or "Eddie" as I call him now). Hopefully the above
>>> compromise serves your needs and keeps our resource commitment and known
>>> good state assumptions in check.
>>>
>>> Whatcha think?
>>
>> I know resources are tight, I also see the appeal of having the head
>> of edison point at the last release, but... edison proper will miss
>> out on all our fixes we backport over the next few months as this is
>> our primary SDK until our next release based off denzil. This does not
>> seem to be as big as an issue for edison since I don't think many
>> (any?) others have based an SDK/BSP off this release.
>>
>> It may become more prudent for denzil if we have multiple interested
>> parties in maintaining these older releases for longer... I know I
>> would like to pull in others fixes for denzil for as long as possible.
>> But how do these other interested parties initiate a QA cycle within
>> Yocto? Obviously having done their own QA for their own stuff and the
>> other interested parties did more QA on the others work but never the
>> full official Yocto QA cycle?
>>
>> Maybe an official strategy for a staging to release branches is in order?
>>
>> edison-{staging,experimental,next}
>>
>
> This is another good approach.  However I think after yp has moved on, I
> doubt there is any resources to promote from the last stage to the
> "official".
>
>
>> Then folks can possibly see some potential fixes for their issues in
>> the experimental branch?
>>
>> Just sharing my thoughts, I'm not insisting on any particular method
>> but I would like my edison fixes available somehow on yp.org.
>>
>> -M
>
>
> I think Matthew's current need will not be unique.  It would be good to
> think this through and have a published stand-down policy.

Any more comments?

I'm fine with a edison-community branch.

-M

Re: edison/denzil patches (post-1.1.2 and 1.2.1)

[David Nyström]

On 07/23/2012 09:59 PM, McClintock Matthew-B29882 wrote:
> On Tue, Jul 17, 2012 at 4:19 PM, William Mills <wmills@ti.com> wrote:
>>
>> On 07/17/2012 04:43 PM, McClintock Matthew-B29882 wrote:
>>> On Tue, Jul 17, 2012 at 3:18 PM, Stewart, David C
>>> <david.c.stewart@intel.com>  wrote:
>>>> Hey Matthew -
>>>>
>>>>> From: yocto-bounces@yoctoproject.org [mailto:yocto-
>>>>> bounces@yoctoproject.org] On Behalf Of McClintock Matthew-B29882
>>>>> Sent: Monday, July 16, 2012 9:01 AM
>>>>> I understand. I'm fine with adding stuff to the edison branch for now
>>>>> and we can worry about another official release sometime in the future
>>>>> (or never). I'm mostly wanting a place I can tell people to get the
>>>>> (working) code from for our targets. And ideally it's on
>>>>> yoctoproject.org and not github.com or git.fsl.com
>>>> This comes down to a resource trade-off, which is why I'm replying. :-)
>>>>
>>>> As an open source project and not a product, we have to set some
>>>> boundaries on how long we will put effort on a given release. It also seems
>>>> prudent to treat our release branches consistently as well. Besides tagging
>>>> branches when we release them, I think we want to leave the head of the
>>>> release branches in some known good state. That known good state has always
>>>> been "passed our release criteria" which includes QA, release notes, etc.
>>> This is coming up on a year old, and we released our SDK based off
>>> edison late too so that eats up some of the time that this release was
>>> officially supported. But I would encourage us to support releases for
>>> more than 1 year given the typical embedded product development life
>>> cycle - and support can be arbitrary, I'm not 100% sure it should mean
>>> it's been through a full QA process... but maybe it does too. Maybe we
>>> should time the releases too so they are 4 and 8 months after the
>>> release to get max overlap for that full year.
>>>
>>>> So what if we create a separate branch off of edison, something like
>>>> edison-fsl? Then you could base your patches against it, but we leave edison
>>>> in the known good state?
>>> That's perfectly fine with me. See my other suggestion below too.
>>
>> Each company/group still using an old release could create its own branch as
>> you suggest.  However, it might make sense to create a generic branch of
>> branch so any remaining stranglers could attempt to cooperate even w/o
>> official yocto-project resources.
>>
>> e.g. edison-community-maint
>>
>>
>>
>>>>> Just for some more context, we just release our SDK off of edison and
>>>>> I expect plenty of activity around bugfixes and back porting commits.
>>>>> I would like this work to be available to all attempting to build
>>>>> edison as well.
>>>> I know... I'm in agony that we have run out of resources to continue to
>>>> put effort into edison (or "Eddie" as I call him now). Hopefully the above
>>>> compromise serves your needs and keeps our resource commitment and known
>>>> good state assumptions in check.
>>>>
>>>> Whatcha think?
>>> I know resources are tight, I also see the appeal of having the head
>>> of edison point at the last release, but... edison proper will miss
>>> out on all our fixes we backport over the next few months as this is
>>> our primary SDK until our next release based off denzil. This does not
>>> seem to be as big as an issue for edison since I don't think many
>>> (any?) others have based an SDK/BSP off this release.
>>>
>>> It may become more prudent for denzil if we have multiple interested
>>> parties in maintaining these older releases for longer... I know I
>>> would like to pull in others fixes for denzil for as long as possible.
>>> But how do these other interested parties initiate a QA cycle within
>>> Yocto? Obviously having done their own QA for their own stuff and the
>>> other interested parties did more QA on the others work but never the
>>> full official Yocto QA cycle?
>>>
>>> Maybe an official strategy for a staging to release branches is in order?
>>>
>>> edison-{staging,experimental,next}
>>>
>> This is another good approach.  However I think after yp has moved on, I
>> doubt there is any resources to promote from the last stage to the
>> "official".
>>
>>
>>> Then folks can possibly see some potential fixes for their issues in
>>> the experimental branch?
>>>
>>> Just sharing my thoughts, I'm not insisting on any particular method
>>> but I would like my edison fixes available somehow on yp.org.
>>>
>>> -M
>>
>> I think Matthew's current need will not be unique.  It would be good to
>> think this through and have a published stand-down policy.
> Any more comments?
>
> I'm fine with a edison-community branch.
I think there has to be a common community maint branch, as discussed 
above, otherwise the good intentions around the layer structure will
fall apart if (in a worst case scenario) a Yocto OSV has one poky 
repo/branch per BSP provider. Possibly with conflicting patchsets.

Regarding maintenence resources, I think there are many interested 
parties to assume maintenance of old community maintained branches in 
which OSV:s has commitments towards customers against.

Br,
David

> -M
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto