[yocto] 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 at 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 at intel.com>  wrote:
>>>
>>> Hey Matthew -
>>>
>>>> From: yocto-bounces at yoctoproject.org [mailto:yocto-
>>>> bounces at 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