[yocto] 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 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.
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 at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto