On Tue, Jul 17, 2012 at 4:19 PM, William Mills <wmi...@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.stew...@intel.com> wrote: >>> >>> Hey Matthew - >>> >>>> From: yocto-boun...@yoctoproject.org [mailto:yocto- >>>> boun...@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 _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto