just some random thoughts on our release model, etc.. I've been meaning to write up for a while but haven't had time
There has been some feedback, for example on #pandaboard, that the monthly release cycle is confusing and detrimental for folks looking for something working and stable, and not necessarily bleeding edge, the question is, "should I upgrade?", "what is fixed and what is now broken?". Linaro is doing some great upstream work, and enabling features on these boards, and it is good to showcase that, but I'm not really sure the best way to do this is rush that into the next monthly release and break things for all the new users of their shiny new xyz-board.
I tend to think that part of the problem is that the cadence of monthly releases is too fast for any sort of stability. Perhaps we should think more along the lines of releases roughly every quarter (potentially with "beta"s in between). I don't think we should strictly adhere to a time based release cycle, but we should call it a final/stable release when it actually is so. There is a reason that the linux kernel uses an approx 3 month release cycle, but doesn't stick to that dogmatically when things aren't really at release quality yet.
But, we do still need a place for latest-and-greatest bleeding edge for folks who want to check out what we are working on. One approach, for example for ubuntu releases, we could have a "release" and "trunk" PPA for bleeding-edge.. that way folks looking for bleeding-edge can get it, and folks looking for "it just works" are not screwed. I'm not quite sure what android equivalent would be, but I guess we could figure something out. This gives folks in board specific channels like #pandaboard who are trying to help new users something to reliably point them at without having to worry if they are giving bad advice to recommend a linaro filesystem. And updates do not have to be tied to a time-based schedule. If something is broken for feature x for board y in the release PPA, then as soon as it is fixed (and if it doesn't break board z), then push an update to the release PPA. But maybe big new features shouldn't immediately go to the release PPA without some soak time first in the trunk PPA. It is great to be enabling new features, but for someone new to the arm platform I don't want to just frustrate and scare them off.
Also, I wonder if we should split #linaro, either into #linaro-devel and leave #linaro as a place that users can come to for help, or setup a separate #linaro-users? This way we aren't just dumping out new releases with nowhere for users to turn to for help.. (Well, they can always come to #linaro but I guess this would help with the signal-to-noise..)
BR, -R
+++ Clark, Rob [2012-04-05 21:10 -0500]:
just some random thoughts on our release model, etc.. I've been meaning to write up for a while but haven't had time
There has been some feedback, for example on #pandaboard, that the monthly release cycle is confusing and detrimental for folks looking for something working and stable, and not necessarily bleeding edge,
You make some good points.
The fundamental question really is 'are we a distro or not'? If linaro is not a distro then no-one should be expecting stable releases - we are a technology showcase, and developer quick-start mechanism, and the existing process seems reasonably appropriate for that, but if we are expecting people to actually base real work off our outputs, then he's right and we ought to change some things.
The original model was that we just sent things upstream and people who wanted a stable platform used whatever distro they wanted. But by putting out images and encouraging people to use them we seem to be increasingly viewed as a distro and so users will expect distro levels of integration testing and stability.
I think we should continue to resists 'distroness', concentrate on upstreaming and discourage the use of our releases for anything other than development, but it seems to me that things are headed in exactly the opposite direction at the moment.
There is a fundamental problem of timing - it takes several months longer, sometimes years, for people to get what we are doing via a distro, and that's too long for many of them, which is where the pressure comes from. We are all aware of that tension.
So are we a distro now or not?
Wookey
On Fri, Apr 6, 2012 at 4:05 AM, Wookey wookey@wookware.org wrote:
+++ Clark, Rob [2012-04-05 21:10 -0500]:
just some random thoughts on our release model, etc.. I've been meaning to write up for a while but haven't had time
There has been some feedback, for example on #pandaboard, that the monthly release cycle is confusing and detrimental for folks looking for something working and stable, and not necessarily bleeding edge,
You make some good points.
The fundamental question really is 'are we a distro or not'? If linaro is not a distro then no-one should be expecting stable releases - we are a technology showcase, and developer quick-start mechanism, and the existing process seems reasonably appropriate for that, but if we are expecting people to actually base real work off our outputs, then he's right and we ought to change some things.
yeah, I think this is actually a very good way to describe the problem..
Currently, people *think* we are a distro, and I guess you could say this is the source of the confusion. Someone new to arm world gets their shiny new xyz-board and isn't sure whether to use an ubuntu 11.10 release, or linaro 12.01 release, etc. Maybe the solution, to put it in management buzzword-speak, is the need for some "crisp messaging about what our builds are".
The original model was that we just sent things upstream and people who wanted a stable platform used whatever distro they wanted. But by putting out images and encouraging people to use them we seem to be increasingly viewed as a distro and so users will expect distro levels of integration testing and stability.
I think we should continue to resists 'distroness', concentrate on upstreaming and discourage the use of our releases for anything other than development, but it seems to me that things are headed in exactly the opposite direction at the moment.
I certainly don't want to distract from the upstream aspect of what we do. (And to be honest, I am more on the upstreaming side of things.. the distro side of things is certainly outside my area of expertise so it's quite possible that everything I say on the subject is complete and utter BS.. I just saw that it was causing confusion so thought I needed to start the discussion)
There is a fundamental problem of timing - it takes several months longer, sometimes years, for people to get what we are doing via a distro, and that's too long for many of them, which is where the pressure comes from. We are all aware of that tension.
This is part of the problem.. even a 6 month cycle for ubuntu is forever in arm-years. This was partly why I was thinking of a 3(ish) month cycle. Maybe not necessarily only doing a build every 3 months, but having the focus of every 3rd month build be something that is more stable, and something we wouldn't be afraid to give new users. So if joe-new-user wants something a bit more enabled than 11.10, we could tell them, here, go use ubuntu 12.q1. But maybe I speak complete crack ;-)
But if we should only do technology showcases, I'm not even sure the approach of popping out one build every month really works for everything there. At least not for some of the larger topics. Maybe we should be thinking more along the lines of builds for different work topics.. Well, the one I'm familiar with is UMM/dmabuf, but that is touching many areas and takes much more than a month to get all the pieces (display, gles, multimedia, etc) in place, as well as cooperation from member companies for the evil binary blob bits. If we'd pulled that into a monthly release a month or two ago, you would have completely lost gfx and multimedia accel. Well, from TI side, I know they are busily trying to pull all the bits into a 3.3 kernel and TI PPA to enable this for ubuntu/linaro 12.04 (well, still a few bits missing to have all the multimedia, eglImage xbmc/ubuntu-tv stuff, so it won't immediately have feature parity with the old stuff).. I suppose Rome wasn't built in a day (or month).
But on the other hand, doing N*M build for N different topics and M different member boards perhaps doesn't really scale well. So I'm not really sure what the best solution is.
BR, -R
So are we a distro now or not?
Wookey
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Fri, Apr 6, 2012 at 4:05 AM, Wookey wookey@wookware.org wrote:
+++ Clark, Rob [2012-04-05 21:10 -0500]:
just some random thoughts on our release model, etc.. I've been meaning to write up for a while but haven't had time
There has been some feedback, for example on #pandaboard, that the monthly release cycle is confusing and detrimental for folks looking for something working and stable, and not necessarily bleeding edge,
You make some good points.
+1, good post Rob!
The fundamental question really is 'are we a distro or not'? If linaro is not a distro then no-one should be expecting stable releases - we are a technology showcase, and developer quick-start mechanism, and the existing process seems reasonably appropriate for that, but if we are expecting people to actually base real work off our outputs, then he's right and we ought to change some things.
With our current quick cadence, it does seem to be confusing the users where by users I'm not saying end users but more smarter than the average bear types which are making use of development boards. Aunt Tillie doesn't come home from the local mall with a panda board in hand and a project on her mind.
The original model was that we just sent things upstream and people who wanted a stable platform used whatever distro they wanted. But by putting out images and encouraging people to use them we seem to be increasingly viewed as a distro and so users will expect distro levels of integration testing and stability.
Exactly. With putting something together and releasing it comes expectations, intended or not. Put another way can anyone think of an intel "showcase" distro that would be akin to what we're doing now? PowerPC? I would suggest OpenEmbedded or say Cyanogenmod would be the closest examples. We're pretty unique but using a common distro release mechanism which people identify with.
In Gentoo a few years back we had this issue. We had quarterly releases and it was just too fast. So, we got rid of releases. Instead one just pulled the latest install media and depending on the last time that media had been refreshed you'd either have a short or longer upgraded cycle as you would install.
Imagine, here's the linaro install media for panda. You can choose stable or development. Development is a continuous rolling daily CI. Stable is as the release team feels it's appropriate to update.
I think we should continue to resists 'distroness', concentrate on upstreaming and discourage the use of our releases for anything other than development, but it seems to me that things are headed in exactly the opposite direction at the moment.
I like Rob's suggestion of stable and unstable. I agree we should resist the full complexities that other distros do.
There is a fundamental problem of timing - it takes several months longer, sometimes years, for people to get what we are doing via a distro, and that's too long for many of them, which is where the pressure comes from. We are all aware of that tension.
To me the other distros are going to do what they are going to do. It's their business. Meanwhile we know what we want and I think we have a good idea of what the people who pick up the boards that we care about want. I think keeping those two groups happy is what counts.
So are we a distro now or not?
We are. Keeping those that use our codebase happy I would advocate is an important goal.
Wookey
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Fri, Apr 6, 2012 at 6:05 AM, Wookey wookey@wookware.org wrote:
+++ Clark, Rob [2012-04-05 21:10 -0500]:
just some random thoughts on our release model, etc.. I've been meaning to write up for a while but haven't had time
There has been some feedback, for example on #pandaboard, that the monthly release cycle is confusing and detrimental for folks looking for something working and stable, and not necessarily bleeding edge,
You make some good points.
The fundamental question really is 'are we a distro or not'? If linaro is not a distro then no-one should be expecting stable releases - we are a technology showcase, and developer quick-start mechanism, and the existing process seems reasonably appropriate for that, but if we are expecting people to actually base real work off our outputs, then he's right and we ought to change some things.
It might be the same thing, but for me the question is really "do we care about users and we want people to use our LEBs?". If we assume the LEBs are just a bunch of evaluation images to be used internally to help improving the development and testing, then you could simply say that we're not any kind of distro.
Now if we decide to have people using and consuming our LEBs (what I believe we do), then we need to think a bit further, and assume some extra responsibilities. We don't want to be a full distro, as we want to be flexible enough to break things once a while, but we really need to be aware that once we get users running our images, they will *expect* some sort of stability, putting us back as we were a distro :-)
Cheers,
Hi,
Interesting discussion. :-) Here is my short take on this fwiw.
Two key points (public source: http://www.linaro.org/about)
1) Linaro's goals are to deliver value to its members through enabling their engineering teams to focus on differentiation and product delivery, and to reduce time to market for OEM/ODMs delivering open source based products using ARM technology.
2) Linaro is not a Linux distribution. The organization provides great software and tools for distributions to pull from.
So from the big picture, our first order optimization should be around these.
We've talked about how and when we release quite a lot over the last two years. My own belief (and I don't manage the release process) is that the second order of optimization should be for efficiency at the Working Group level (efficient engineers are happier engineers and that means more productivity) and that then, as a third priority, we see what we can do to help out folks who look at Linaro as a Linux and Android distribution.
I'm personally fond of this last one because we all know that Linaro's code rocks and many people want to pick it up and use it. A quick way to get there is for our members to ask us to develop an LTS (Long Term Support) version. We've talked about that previously as well and there are some member-affecting trade-offs to be made if we did that (which is why we haven't as of yet).
J
On Fri, 6 Apr 2012, Ricardo Salveti wrote:
On Fri, Apr 6, 2012 at 6:05 AM, Wookey wookey@wookware.org wrote:
The fundamental question really is 'are we a distro or not'? If linaro is not a distro then no-one should be expecting stable releases - we are a technology showcase, and developer quick-start mechanism, and the existing process seems reasonably appropriate for that, but if we are expecting people to actually base real work off our outputs, then he's right and we ought to change some things.
It might be the same thing, but for me the question is really "do we care about users and we want people to use our LEBs?". If we assume the LEBs are just a bunch of evaluation images to be used internally to help improving the development and testing, then you could simply say that we're not any kind of distro.
Now if we decide to have people using and consuming our LEBs (what I believe we do), then we need to think a bit further, and assume some extra responsibilities. We don't want to be a full distro, as we want to be flexible enough to break things once a while, but we really need to be aware that once we get users running our images, they will *expect* some sort of stability, putting us back as we were a distro :-)
Stability is not sufficient. Users will also expect support, updates, and security fixes, etc. And the more stable our stuff looks, the more users and user demands we'll get. Fulfilling those user *expectations* is hard and costly. Some companies are basing their entire business on that, and they do a really great job already.
We certainly don't shine at being a distro, and IMHO we shouldn't even try. If some people want the latest cool stuff we provide that's fine, but they should expect a shaky world. Existing distro people out there will pick up our work too and stabilize it. In fact, they are encouraged to do so.
Stabilization takes time, which is why there is a delay before our stuff is available through existing distros. There is simply no way around that. Stable and latest bleeding edge are simply not compatible. If Linaro is to produce stabilized releases, we'll introduce extra delays too, and we'll consume a significant amount of development resources doing that.
Therefore I don't think we should duplicate what distro people are already doing. That shouldn't be where our focus is. Expectations to users should probably be clarified as well.
Nicolas
On Fri, Apr 6, 2012 at 4:59 PM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Fri, 6 Apr 2012, Ricardo Salveti wrote:
On Fri, Apr 6, 2012 at 6:05 AM, Wookey wookey@wookware.org wrote:
The fundamental question really is 'are we a distro or not'? If linaro is not a distro then no-one should be expecting stable releases - we are a technology showcase, and developer quick-start mechanism, and the existing process seems reasonably appropriate for that, but if we are expecting people to actually base real work off our outputs, then he's right and we ought to change some things.
It might be the same thing, but for me the question is really "do we care about users and we want people to use our LEBs?". If we assume the LEBs are just a bunch of evaluation images to be used internally to help improving the development and testing, then you could simply say that we're not any kind of distro.
Now if we decide to have people using and consuming our LEBs (what I believe we do), then we need to think a bit further, and assume some extra responsibilities. We don't want to be a full distro, as we want to be flexible enough to break things once a while, but we really need to be aware that once we get users running our images, they will *expect* some sort of stability, putting us back as we were a distro :-)
Stability is not sufficient. Users will also expect support, updates, and security fixes, etc. And the more stable our stuff looks, the more users and user demands we'll get. Fulfilling those user *expectations* is hard and costly. Some companies are basing their entire business on that, and they do a really great job already.
We certainly don't shine at being a distro, and IMHO we shouldn't even try. If some people want the latest cool stuff we provide that's fine, but they should expect a shaky world. Existing distro people out there will pick up our work too and stabilize it. In fact, they are encouraged to do so.
That's happening already, and most of the stuff we do at the Ubuntu LEB ends up at Ubuntu itself when possible. And I know other distros are doing that as well (just not sure about Android, I really don't know how much we did ended up at AOSP), so from a distro perceptive I believe things are quite clear, it's not not that clear for our end users.
Therefore I don't think we should duplicate what distro people are already doing. That shouldn't be where our focus is. Expectations to users should probably be clarified as well.
I believe that this is the main issue here. I don't think there's any clear statement today saying that our builds are just meant to be an experimentation and focused on on development and validation. We need to be aware that once we start pushing our builds down to our users, they will expect all these sort of things you pointed out, so to avoid frustration we should put a big warning already at the download page.
That's why I believe having what I called "stable" and "unstable" builds should help a bit at least. Once our main development branch is in a good shape, we just copy that an call that "stable" (or any other better word). This way we'd be able to always have working images for demo purposes and also help our users by not breaking everything every month.
Maybe it's also time to stop calling our builds as LEBs, and get a better naming, to avoid confusion since day 0.
Cheers,
On 06/04/12 21:59, Ricardo Salveti wrote:
On Fri, Apr 6, 2012 at 4:59 PM, Nicolas Pitrenicolas.pitre@linaro.org wrote:
On Fri, 6 Apr 2012, Ricardo Salveti wrote:
On Fri, Apr 6, 2012 at 6:05 AM, Wookeywookey@wookware.org wrote:
The fundamental question really is 'are we a distro or not'? If linaro is not a distro then no-one should be expecting stable releases - we are a technology showcase, and developer quick-start mechanism, and the existing process seems reasonably appropriate for that, but if we are expecting people to actually base real work off our outputs, then he's right and we ought to change some things.
It might be the same thing, but for me the question is really "do we care about users and we want people to use our LEBs?". If we assume the LEBs are just a bunch of evaluation images to be used internally to help improving the development and testing, then you could simply say that we're not any kind of distro.
Now if we decide to have people using and consuming our LEBs (what I believe we do), then we need to think a bit further, and assume some extra responsibilities. We don't want to be a full distro, as we want to be flexible enough to break things once a while, but we really need to be aware that once we get users running our images, they will *expect* some sort of stability, putting us back as we were a distro :-)
Stability is not sufficient. Users will also expect support, updates, and security fixes, etc. And the more stable our stuff looks, the more users and user demands we'll get. Fulfilling those user *expectations* is hard and costly. Some companies are basing their entire business on that, and they do a really great job already.
We certainly don't shine at being a distro, and IMHO we shouldn't even try. If some people want the latest cool stuff we provide that's fine, but they should expect a shaky world. Existing distro people out there will pick up our work too and stabilize it. In fact, they are encouraged to do so.
That's happening already, and most of the stuff we do at the Ubuntu LEB ends up at Ubuntu itself when possible. And I know other distros are doing that as well (just not sure about Android, I really don't know how much we did ended up at AOSP), so from a distro perceptive I believe things are quite clear, it's not not that clear for our end users.
Therefore I don't think we should duplicate what distro people are already doing. That shouldn't be where our focus is. Expectations to users should probably be clarified as well.
I believe that this is the main issue here. I don't think there's any clear statement today saying that our builds are just meant to be an experimentation and focused on on development and validation. We need to be aware that once we start pushing our builds down to our users, they will expect all these sort of things you pointed out, so to avoid frustration we should put a big warning already at the download page.
+1 I think two things would help outsiders like myself tremendously
1. An indication on the download links for Ubuntu and Android images to say that they are not intended for production (more of a "proof of concept", I suppose)
2. Links to real distros that are intended for production users.
If I have a product using one of the supported platforms, what are my options to get distro using a stable and tested Linaro kernel?
Bye for now, Chris.
On Fri, Apr 6, 2012 at 2:59 PM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Fri, 6 Apr 2012, Ricardo Salveti wrote:
On Fri, Apr 6, 2012 at 6:05 AM, Wookey wookey@wookware.org wrote:
The fundamental question really is 'are we a distro or not'? If linaro is not a distro then no-one should be expecting stable releases - we are a technology showcase, and developer quick-start mechanism, and the existing process seems reasonably appropriate for that, but if we are expecting people to actually base real work off our outputs, then he's right and we ought to change some things.
It might be the same thing, but for me the question is really "do we care about users and we want people to use our LEBs?". If we assume the LEBs are just a bunch of evaluation images to be used internally to help improving the development and testing, then you could simply say that we're not any kind of distro.
Now if we decide to have people using and consuming our LEBs (what I believe we do), then we need to think a bit further, and assume some extra responsibilities. We don't want to be a full distro, as we want to be flexible enough to break things once a while, but we really need to be aware that once we get users running our images, they will *expect* some sort of stability, putting us back as we were a distro :-)
Stability is not sufficient. Users will also expect support, updates, and security fixes, etc. And the more stable our stuff looks, the more users and user demands we'll get. Fulfilling those user *expectations* is hard and costly. Some companies are basing their entire business on that, and they do a really great job already.
We certainly don't shine at being a distro, and IMHO we shouldn't even try. If some people want the latest cool stuff we provide that's fine, but they should expect a shaky world. Existing distro people out there will pick up our work too and stabilize it. In fact, they are encouraged to do so.
Stabilization takes time, which is why there is a delay before our stuff is available through existing distros. There is simply no way around that. Stable and latest bleeding edge are simply not compatible. If Linaro is to produce stabilized releases, we'll introduce extra delays too, and we'll consume a significant amount of development resources doing that.
Therefore I don't think we should duplicate what distro people are already doing. That shouldn't be where our focus is. Expectations to users should probably be clarified as well.
That is fair.. there is no point duplicating what distro folks are already doing.
It might be nice to do a better job of folding back bits and pieces of what we do into (for example) ubuntu PPA's.. for example, I think a number of people are trying linaro builds just because they want xbmc, not because they care about various other bleeding edge bits.
Although, other than OMAP, are there ubuntu PPA's to get graphics, etc, accel for other member company platforms? Ie. when someone like the FXI cotton candy folks come along looking for a filesystem they can use on their product (where presumably they care more about enablement than bleeding edge), could we tell them to use ubuntu or AOSP or whatever? I'm just wondering if there is a good "one size fits all" answer.. if there isn't a member company supported PPA for ubuntu where you can get the gfx and/or multimedia blobs, then the only-bleeding-edge-devel filesystems approach might be leaving a bit of a gap for someone trying to make a product (which is, in the end, what we care about).
BR, -R
On Mon, Apr 9, 2012 at 2:47 PM, Clark, Rob rob@ti.com wrote:
On Fri, Apr 6, 2012 at 2:59 PM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Fri, 6 Apr 2012, Ricardo Salveti wrote:
On Fri, Apr 6, 2012 at 6:05 AM, Wookey wookey@wookware.org wrote:
The fundamental question really is 'are we a distro or not'?
Tom Gall said; "We are." Joey Stanford said; "Linaro is not a Linux distribution." Jeremiah said; "I'm confused."
Is there a way for Linaro to clarify the distro / non-distro position?
There are lot of "distributions" that say "We're not a Linux distro!" but in reality they tie you to their dependency resolution scheme and their build system, (I'm looking at you Yocto.) If Linaro is or isn't a distro, can Linaro then please define, and adhere to, what it is? This would likely help clarify the release cycle and the stable / unstable dichotomy. If you're a distro you likely need a stable release, if you're just "shiny Linux kernel for ARM" then I guess you can just do rolling releases, but even upstream seems to have "long term kernel releases."
Regards,
Jeremiah
Hi Jeremiah,
On Thu, Apr 12, 2012 at 4:58 AM, Jeremiah Foster jeremiah.foster@pelagicore.com wrote:
On Mon, Apr 9, 2012 at 2:47 PM, Clark, Rob rob@ti.com wrote:
On Fri, Apr 6, 2012 at 2:59 PM, Nicolas Pitre nicolas.pitre@linaro.org wrote:
On Fri, 6 Apr 2012, Ricardo Salveti wrote:
On Fri, Apr 6, 2012 at 6:05 AM, Wookey wookey@wookware.org wrote:
The fundamental question really is 'are we a distro or not'?
Tom Gall said; "We are." Joey Stanford said; "Linaro is not a Linux distribution." Jeremiah said; "I'm confused."
Is there a way for Linaro to clarify the distro / non-distro position?
There are lot of "distributions" that say "We're not a Linux distro!" but in reality they tie you to their dependency resolution scheme and their build system, (I'm looking at you Yocto.) If Linaro is or isn't a distro, can Linaro then please define, and adhere to, what it is? This would likely help clarify the release cycle and the stable / unstable dichotomy. If you're a distro you likely need a stable release, if you're just "shiny Linux kernel for ARM" then I guess you can just do rolling releases, but even upstream seems to have "long term kernel releases."
Here's my take on it and please understand it's my take.
There really isn't a clear definition or test for what is and isn't a linux distribution. So much so the term could in some ways be useless. However there are a number of crisp attributes we can be clear on.
Does Linaro do world class engineering, creating new features pushing them upstream? Yes. It's one of our major goals.
Does Linaro have a package and build system? Yes. It follows in the footsteps of ubuntu/debian.
Can you request features? Sure. We love it when people show up at Linaro Connect, start a discussion in irc or post to one of our lists with ideas or technical items that need discussion. We like to work with others.
Can you report bugs? Sure. Linaro don't make any promises when or if a bug will be fixed. Linaro has at times decided to put off even what would be considered high priorities bugs because work is going on what was considered high priority features.
Does Linaro have long term support releases? No.
Does Linaro keep up on the latest in security fixes? No, Linaro doesn't even have a security team. If something that is security related and it's fixed in the ubuntu archive, as long as that package isn't overridden you'll get that fix too but still the important thing is Linaro doesn't have a security team.
Does Linaro support a wide variety of architectures? No, Linaro focuses entirely on the arm architecture.
I could go on and I'm sure you have your own list of attributes that are important to you.
Does this help? Probably not. But in this thread I don't think the "is Linaro a distribution" is the important question. It's the attributes surrounding what Linaro does that is most important within the context of the goals set by our members as well as how Linaro to advanced Arm on Android & Linux.
Regards,
Jeremiah
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 04/06/2012 10:10 AM, Somebody in the thread at some point said:
just some random thoughts on our release model, etc.. I've been meaning to write up for a while but haven't had time
There has been some feedback, for example on #pandaboard, that the monthly release cycle is confusing and detrimental for folks looking
Right it's desynchronized from the kernel heartbeat which is upstream release cycle.
Linaro releases other things than kernels though I guess it can be less of an issue depending on the project. But for kernel it is noticeable.
But, we do still need a place for latest-and-greatest bleeding edge for folks who want to check out what we are working on. One approach, for example for ubuntu releases, we could have a "release" and "trunk" PPA for bleeding-edge.. that way folks looking for bleeding-edge can get it, and folks looking for "it just works" are not screwed. I'm not quite sure what android equivalent would be, but I guess we could
For binary package case, for quite a while until the current, hopefully coming-to-an-end discontiguity on our tree made it moot, both Ubuntu and Android packaged our last release (or in ubuntu case, last release with working mm decode) and our tracking.
That worked out well since people could choose to stick with last release or follow latest and sometimes [not] the greatest, and be able to revert simply at package or leb flavour level if it didn't look good. If the release was getting old, they could still get access to newest features and fixes on tracking with some risk of instability when tracking crossed an upstream release.
Several things disrupt that, in our case switch to OMAP5 tree, but also things like gingerbread -> ics transition disrupted what we had from the other side, and for Ubuntu lack of mm decode on 3.2. But overall packaging previous release and tracking usually leaves something that's a workable solution.
For kernel source case though, consumers will typically not be in a position to take such a granular and relaxed approach as follow monthly source release tarballs, but insist to follow git.
-Andy
Hey Rob,
On Thu, Apr 5, 2012 at 11:10 PM, Clark, Rob rob@ti.com wrote:
just some random thoughts on our release model, etc.. I've been meaning to write up for a while but haven't had time
Thanks for bringing this up here.
There has been some feedback, for example on #pandaboard, that the monthly release cycle is confusing and detrimental for folks looking for something working and stable, and not necessarily bleeding edge, the question is, "should I upgrade?", "what is fixed and what is now broken?". Linaro is doing some great upstream work, and enabling features on these boards, and it is good to showcase that, but I'm not really sure the best way to do this is rush that into the next monthly release and break things for all the new users of their shiny new xyz-board.
I tend to think that part of the problem is that the cadence of monthly releases is too fast for any sort of stability. Perhaps we should think more along the lines of releases roughly every quarter (potentially with "beta"s in between). I don't think we should strictly adhere to a time based release cycle, but we should call it a final/stable release when it actually is so. There is a reason that the linux kernel uses an approx 3 month release cycle, but doesn't stick to that dogmatically when things aren't really at release quality yet.
I think the main problem here is the constant change of direction from the platform group. Initially the Android/Ubuntu LEB (Linaro Evaluation Builds) were meant to be somehow stable, always delivering the best working components, even if they were not reflecting the latest upstream. On example of that is that we were still releasing the Pandaboard hwpacks based on the old tilt-linux-linaro-3.1, because it was the only one that was stable enough and had multimedia working out of the box.
With this model, we attracted quite a few users, we presented our builds at numerous places (ELC, Connect, UDS, etc), got people at Linaro just to deal with community and always pointed the users to use them as reference, because it would always be somehow stable and working.
Then at previous Connect Linaro decided that we would not worry about stabilising our LEBs any more, and start delivering just the latest components available, even if they would not be working with any other hw acceleration piece, which naturally made all of our users unhappy about it, getting us to the current situation.
This is why I also thought we should go back and rethink how we would be dealing with our releases. The email I sent last week about stable/unstable LEBs is basically to cover the same issue. One thing we should do, if we're planning on working with *users*, is to always provide a working (stable) LEBs together with a unstable one, so if they decide to help and contribute to Linaro, they would always have the possibility to grab the latest stuff from the unstable PPA (on Ubuntu side).
Now about the monthly releases I don't really have a strong opinion. I believe releasing the LEBs at every quarter might improve things, if we decided to get working (stable) LEBs out of the door. Doing it quarterly would give us have enough time to think about which components we'd be working on, and prepare the enablement properly (one thing we need to think about is that most of the builds require some sort of binary blob, and a one month-time frame is almost impossible for the Vendor to respin a newer version if needed).
But, we do still need a place for latest-and-greatest bleeding edge for folks who want to check out what we are working on. One approach, for example for ubuntu releases, we could have a "release" and "trunk" PPA for bleeding-edge.. that way folks looking for bleeding-edge can get it, and folks looking for "it just works" are not screwed. I'm not quite sure what android equivalent would be, but I guess we could figure something out. This gives folks in board specific channels like #pandaboard who are trying to help new users something to reliably point them at without having to worry if they are giving bad advice to recommend a linaro filesystem. And updates do not have to be tied to a time-based schedule. If something is broken for feature x for board y in the release PPA, then as soon as it is fixed (and if it doesn't break board z), then push an update to the release PPA. But maybe big new features shouldn't immediately go to the release PPA without some soak time first in the trunk PPA. It is great to be enabling new features, but for someone new to the arm platform I don't want to just frustrate and scare them off.
This unstable/development place needs to be around, because that's also our main baseline when we're developing and testing our components. That's why for me the stable release would basically be a snapshot of a working unstable one, in a way we could later protect the users to avoid total breakage with a simple update.
Cheers,
Clark, Rob wrote:
just some random thoughts on our release model, etc.. I've been meaning to write up for a while but haven't had time
[+1] :)
Actually, the issue isn't as much with Ubuntu as with Android.
For Ubuntu, I have stopped pointing people at Linaro and always advise them to use official Ubuntu releases because there they at least stand a chance of getting some kind of support - although they often return from #ubuntu-arm saying that nobody would/could help them there... And don't get me wrong, I absolutely do not expect Linaro to provide Ubuntu support, I would actually prefer if Linaro Ubuntu builds were much more less visible to end users :)
For Android on e.g. Pandaboard, there simply is not much else than Linaro to point people to. The original TI Pandroid effort was scrapped when TI found that it is too much work to support a user centric Android release and now TI as well points to Linaro. The only other place one could point people to is plain AOSP, but that lacks stuff like HW accell and isn't the focus of Google any more as far as panda is concerned.
So Linaro is the only viable solution there, but as with Ubuntu, there is no end-customer support and the monthly releases make it a moving target. Again, I do not blame Linaro for the lack of support, it is simply a fact that "Android as a distribution" is way less supported than others, especially on less mainstream platforms. Having e.g. Cyanogenmod on Panda would surely help a lot, but I guess there is no critical mass for that and dev boards like Panda and others are in a way moving targets themselves...
So I guess the only thing that can be done short-term is to state very clearly what Linaro builds are and what they are not and to discourage the average user from going down that road unless they know what they are doing (which will fail as well since users like car drivers all think they are above average..)
Regards,
Vladimir
On Mon, Apr 23, 2012 at 3:23 AM, Vladimir Pantelic vladoman@gmail.com wrote:
Clark, Rob wrote:
just some random thoughts on our release model, etc.. I've been meaning to write up for a while but haven't had time
[+1] :)
Actually, the issue isn't as much with Ubuntu as with Android.
For Ubuntu, I have stopped pointing people at Linaro and always advise them to use official Ubuntu releases because there they at least stand a chance of getting some kind of support - although they often return from #ubuntu-arm saying that nobody would/could help them there... And don't get me wrong, I absolutely do not expect Linaro to provide Ubuntu support, I would actually prefer if Linaro Ubuntu builds were much more less visible to end users :)
For some of these users, is ubuntu-arm# really the best place? I know we'd like to say it's the best place for quick answers, but unless the user stays logged in for a good length of time and someone that is able to respond was also logged in saw the actual question, it's more of hindrance.. If it's related to running something on the panda, the pandaboard google group would be a much better place to redirect them.. Then at-least a respondent could actually reply without the user just disconnecting..
Regards,
Clark, Rob wrote:
Also, I wonder if we should split #linaro, either into #linaro-devel and leave #linaro as a place that users can come to for help, or setup a separate #linaro-users? This way we aren't just dumping out new releases with nowhere for users to turn to for help.. (Well, they can always come to #linaro but I guess this would help with the signal-to-noise..)
Think twice before setting up something like #linaro-users, unless you are willing to staff it and really help users there. Just having another "idle mostly" ghost town on IRC does not help much.
-
Andy Green -
Chris Simmonds -
Clark, Rob -
Jeremiah Foster -
Joey STANFORD -
Nicolas Pitre -
Ricardo Salveti -
Robert Nelson -
Tom Gall -
Vladimir Pantelic -
Wookey