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.
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
