I should clarify a little. There are different types of customers. Our main customers are our members. For our members upgraded kernels and GCC4.6 allow them to accelerate their delivery.

The customers I've been talking to are actually using our builds to make stuff. They're the small start-up or even the hobbyist. They are also engineers within the member organizations we're serving. These customers would like their Android experience to be as close to AOSP as possible, just on the board they care about. They're happy with a stable kernel rev and GCC 4.4 because that's what they need to deliver. They use our builds because they generally work. They'd like to get our builds in other flavors, like stable-kernel green and cherry 4.4.

On 31 January 2012 10:55, Zach Pfeffer zach.pfeffer@linaro.org wrote:

Oh one more thing...

Our customers actually prefer to build our distro's from source and not get binary drops.

On 31 January 2012 10:52, Zach Pfeffer zach.pfeffer@linaro.org wrote:

...

So I've been talking to our customers (10 at last count) and they really like what we're doing. There are three things that are getting in their way:

linaro-android-media-create

GCC4.6

frequent kernel upgrades

They love our builds, but they'd really like it if they could get stock AOSP builds for their boards on stable kernels that they can work with using fastboot that have been CI tested and QA'd.

I'm not advocating for the wholesale destruction of our current way of life, tip kernels, tip toolchains, linaro-android-media-create, but I would like to move in a direction that gives our users what they want.

-- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog

-- Zach Pfeffer Android Platform Team Lead, Linaro Platform Teams Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog

On 31 January 2012 11:19, Nicolas Pitre nicolas.pitre@linaro.org wrote:

On Tue, 31 Jan 2012, Zach Pfeffer wrote:

...

They love our builds, but they'd really like it if they could get stock AOSP builds for their boards on stable kernels that they can work with using fastboot that have been CI tested and QA'd.

I'm not advocating for the wholesale destruction of our current way of life, tip kernels, tip toolchains, linaro-android-media-create, but I would like to move in a direction that gives our users what they want.

And by the time you do that i.e. stable kernel and so on, then those customers will come back asking for this and that new cool feature available in the latest upstream kernel and ask you to backport it to your stable kernel.

Nico, you bring up a good point. Consolidating and upstreaming core ARM features that exist across each architecture is our main job.

The customer ask remains the same though. If we deliver a platform with a set of features, customers don't want any of those features to break when we give them an upgrade.

Been there already.

Nicolas

On 31 January 2012 15:01, Nicolas Pitre nicolas.pitre@linaro.org wrote:

On Tue, 31 Jan 2012, Zach Pfeffer wrote:

...

On 31 January 2012 11:19, Nicolas Pitre nicolas.pitre@linaro.org wrote:

...

On Tue, 31 Jan 2012, Zach Pfeffer wrote:

...

They love our builds, but they'd really like it if they could get stock AOSP builds for their boards on stable kernels that they can work with using fastboot that have been CI tested and QA'd.

I'm not advocating for the wholesale destruction of our current way of life, tip kernels, tip toolchains, linaro-android-media-create, but I would like to move in a direction that gives our users what they want.

And by the time you do that i.e. stable kernel and so on, then those customers will come back asking for this and that new cool feature available in the latest upstream kernel and ask you to backport it to your stable kernel.

Nico, you bring up a good point. Consolidating and upstreaming core ARM features that exist across each architecture is our main job.

The customer ask remains the same though. If we deliver a platform with a set of features, customers don't want any of those features to break when we give them an upgrade.

You just can't have it both ways.  If you focus on a stable platform then you cannot have the latest features.  If you develop new features, it obviously can't be stable.  But whatever you do, customers will always ask for both in a single package.

I think it is a matter of clearly defining what we do, and also what we don't (and shouldn't) do.  Expectations about Linaro cannot be the same as for Ubuntu/Canonical or Android/Google.

That is true., but lets talk nuts and bolts.

What I think would be good for Linaro to do, is to list the features of each board it wants to support without regressions and define a set of tests against those features. As we improve things, we ensure that the core feature set doesn't break. We have the test cases, so we know exactly what "break" means. This is fairly doable given that the kernel is conservative when accepting new API changes. Most of the features on our approved list are going to be drivers: SD card support, USB, ADB (for Android), etc... The only real big thing that I know of that may cause issues in this outer code ring is pinmux refactoring.

Then you've got features that touch the middle of the kernel, where changes to APIs are even less frequent. Here, multimedia acceleration and the other "stuff that must move large blocks of memory around" lives. These features are important to enable, because the targets are not very useful with out them, these have also been our major pain points. This will get better though as a new memory allocation architecture come in that meets users needs better. Given UMM , in a year most device manufactures will start to move their camera and audio drivers over to this.

Then we get to the worst offenders, graphics drivers. These tend to do very interesting things with VM tables against alloc_bootmem regions. UMM probably won't get used here since it won't give vendors the SoC specific, low-level per-page bit twiddling APIs that they need to eke out the last drop of graphics performance. These are definitely a problem, but if there's anywhere we should be confronting issues it would be right here since most of our members feel pain here the most.

The pain points we feel are the exact pain points we've been established to correct, but to correct them we still need a fairly useful and stable platform for people to work from. If we do plan on breaking something that something should be discussed and broadcast out before it breaks so people can prepare contingency plans.

At the end of the day, a platform with Ethernet, USB, Graphics, SD card support, and the other basic peripherals that enable kernel and userspace developers to work through each of these issues and that has been tested against a set of known tests would give the users of these platforms confidence in them, allowing them focus on improving the general ARM support in the kernel.

Nicolas

On Tue, 31 Jan 2012, Zach Pfeffer wrote:

On 31 January 2012 15:01, Nicolas Pitre nicolas.pitre@linaro.org wrote:

...

You just can't have it both ways.  If you focus on a stable platform then you cannot have the latest features.  If you develop new features, it obviously can't be stable.  But whatever you do, customers will always ask for both in a single package.

I think it is a matter of clearly defining what we do, and also what we don't (and shouldn't) do.  Expectations about Linaro cannot be the same as for Ubuntu/Canonical or Android/Google.

That is true., but lets talk nuts and bolts.

What I think would be good for Linaro to do, is to list the features of each board it wants to support without regressions and define a set of tests against those features. As we improve things, we ensure that the core feature set doesn't break. We have the test cases, so we know exactly what "break" means.

Absolutely. This is why the Linaro CI loop is so important.

[...]

Then we get to the worst offenders, graphics drivers. These tend to do very interesting things with VM tables against alloc_bootmem regions. UMM probably won't get used here since it won't give vendors the SoC specific, low-level per-page bit twiddling APIs that they need to eke out the last drop of graphics performance. These are definitely a problem, but if there's anywhere we should be confronting issues it would be right here since most of our members feel pain here the most.

I can't agree more. However there won't be any good solution here without access to the source code for those graphics drivers. I don't see any easy way out.

Nicolas

Hi,

I feel, Linaro should maintain only 2 versions - stable and unstable external source. instead of maintain staging, tracking, landing, mainline etc .. I understand internally lot of activities may happen with partners. But for external people, it is should be simple. As of now, only people who are closely tracking the Linaro development can start using the code quickly. Others cannot and it is not the case with AOSP.

Is there any page on wiki, which can explain staging, tracking, landing & mainline sources.

Bye :)

On Wed, Feb 1, 2012 at 6:00 AM, Bharathi Subramanian bharathi.list@gmail.com wrote:

Hi,

I feel, Linaro should maintain only 2 versions - stable and unstable external source. instead of maintain staging, tracking, landing, mainline etc .. I understand internally lot of activities may happen with partners. But for external people, it is should be simple. As of now, only people who are closely tracking the Linaro development can start using the code quickly. Others cannot and it is not the case with AOSP.

While I see that it's useful for people to use the outcome of the Android team to create products, I believe it's quite hard to keep both stable and unstable with the goals and the resources we have. As Zack said, these costumers don't actually care much if they are running the latest stuff available, as long it behaves similarly as AOSP. I believe we might have only two options here: have something awesome to show that everybody will want no matter what (even Google), or improving the user/developer experience a lot, making it even better and easier than just grabbing the sources from AOSP.

But one thing is clear for me, If we think that we can't reach any of these goals, for me it'd make sense to drop the whole stable discussion, and focus even more on trying to get stuff at upstream, so when people decide to use AOSP, they will already consume what Linaro helped producing (what is the *real* stuff IMHO, as it'll improve the *whole* thing).

Cheers,

[resending replying to the list , aplogies Ricardo!]

On Wed, 1 Feb 2012 23:32:00 -0200, Ricardo Salveti ricardo.salveti@linaro.org wrote:

While I see that it's useful for people to use the outcome of the Android team to create products, I believe it's quite hard to keep both stable and unstable with the goals and the resources we have. As Zack said, these costumers don't actually care much if they are running the latest stuff available, as long it behaves similarly as AOSP.

I realize this is a very naive point of view, and a slightly leading question, but if people want something that behaves like AOSP... why don't they use AOSP? What are they expecting from Linaro? Is it just hw enablement?

Cheers, mwh