[yocto] 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 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.

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