Hi,
Following some complains and issues with the way we're currently maintaining our main Overlay PPA, I'd like to propose a new way to produce the Ubuntu LEBs, by generating Stable and Unstable/Development focused images.
At the moment all the development work for the Ubuntu LEB happens at 2 different repositories: - Staging PPA (https://launchpad.net/~linaro-maintainers/+archive/staging-overlay): test and development related builds, usually broken but a common place to share the packages before making them official at the LEB. - Overlay PPA (https://launchpad.net/~linaro-maintainers/+archive/overlay): main overlay repository, and common location for hardware enablement packages and released components by Linaro (e.g. Linux Linaro, glmark2, etc).
Using just one single main repository seems fine until you have at least one board fully enabled, with dependencies going from Kernel to user space, as the enablement usually doesn't keep up with the latest development and updates produced by the Landing Teams and Working Groups. One simple case is what happened with Pandaboard, that had a fully enabled userspace (OpenGL ES2.0 and HW Decode), but needed to be locked down with an specific kernel and user space packages.
Differently than what we have with Android images, we don't just produce one single tarball where the user is unable to change or extend. At our side we're maintaining a real distro, and updating/upgrading packages is expected. Once we release a fully enabled build, we can't simply break it down with newer updates because will make all users unhappy, which is bad for the users and for Linaro (as it's hard to compare hw enablement, produce demos and such).
At the same time, we don't want to be locked down into specific versions, because one of our goals is to make sure the hardware enablement is always matching the latest kernel/components available. Working with upstream based components helps us with development and validation, and also identifying what is still needed to get everything working from time to time.
Looking at the problem, here's what I think it'd help to fix the situation: 1 - Overlay PPA becomes the main repository for basic platform development, without having any hardware specific package (not even the kernel): This PPA would be used by all the images we're producing (stable/unstable), as all the changes would be just related with the distribution. Once we get newer components that are not related with hardware enablement, and not critical enough to break compatibility across images, we would be integrating them at this repository (e.g. powertop, glmark2, libpng, libjpeg-turbo, etc). 2 - We create the Development Overlay PPA, to be the main place carrying the hardware related pieces, like kernel, drivers and multimedia: This would be the main PPA used during our own development, always containing the latest kernel packages from the Linux Linaro and Landing Team trees. Here we could also integrate components related with hardware enablement that are not for prime use yet, but would help people that are always looking for the latest stuff available. 3 - Create a set of Stable PPAs for every board we're officially supporting: Here the goal would be to have a single place where we can push the enablement related changes that are known to be working. At the Pandaboard case this PPA would contain the 3.1 based kernel with SGX and HW video decoding working out of the box. Once a new snapshot based on the development release is known to work in a satisfactory way, we would simply just copy them over the Stable PPA for the respective board. This would also help the cases where we have packages with hw enablement changes that conflict with other boards.
So in the end we'd be generating 2 sets of hwpacks per board, one based on the Development Overlay (latest components, even if not working properly), and one based on the Stable PPAs, that we know it'll always have a better enablement. Both would be using the same rootfs, as all distro related core changes will be part of the Overlay PPA anyway.
I believe this can simply things a bit, and would not consume much of our time as the stable repository would just be a snapshot of a known to be working development PPA.
Please let me know what you all think, as we could have this model working with the 12.04 Ubuntu Precise based images already.
Thanks,
On Tue, Apr 3, 2012 at 9:08 AM, Ricardo Salveti ricardo.salveti@linaro.org wrote:
<snip>
Looking at the problem, here's what I think it'd help to fix the situation: 1 - Overlay PPA becomes the main repository for basic platform development, without having any hardware specific package (not even the kernel): This PPA would be used by all the images we're producing (stable/unstable), as all the changes would be just related with the distribution. Once we get newer components that are not related with hardware enablement, and not critical enough to break compatibility across images, we would be integrating them at this repository (e.g. powertop, glmark2, libpng, libjpeg-turbo, etc). 2 - We create the Development Overlay PPA, to be the main place carrying the hardware related pieces, like kernel, drivers and multimedia: This would be the main PPA used during our own development, always containing the latest kernel packages from the Linux Linaro and Landing Team trees. Here we could also integrate components related with hardware enablement that are not for prime use yet, but would help people that are always looking for the latest stuff available. 3 - Create a set of Stable PPAs for every board we're officially supporting: Here the goal would be to have a single place where we can push the enablement related changes that are known to be working. At the Pandaboard case this PPA would contain the 3.1 based kernel with SGX and HW video decoding working out of the box. Once a new snapshot based on the development release is known to work in a satisfactory way, we would simply just copy them over the Stable PPA for the respective board. This would also help the cases where we have packages with hw enablement changes that conflict with other boards.
So in the end we'd be generating 2 sets of hwpacks per board, one based on the Development Overlay (latest components, even if not working properly), and one based on the Stable PPAs, that we know it'll always have a better enablement. Both would be using the same rootfs, as all distro related core changes will be part of the Overlay PPA anyway.
I believe this can simply things a bit, and would not consume much of our time as the stable repository would just be a snapshot of a known to be working development PPA.
What would the monthly release be based on? The stable PPA?
On Tue, Apr 3, 2012 at 6:10 AM, Amit Kucheria amit.kucheria@linaro.org wrote:
On Tue, Apr 3, 2012 at 9:08 AM, Ricardo Salveti
So in the end we'd be generating 2 sets of hwpacks per board, one based on the Development Overlay (latest components, even if not working properly), and one based on the Stable PPAs, that we know it'll always have a better enablement. Both would be using the same rootfs, as all distro related core changes will be part of the Overlay PPA anyway.
I believe this can simply things a bit, and would not consume much of our time as the stable repository would just be a snapshot of a known to be working development PPA.
What would the monthly release be based on? The stable PPA?
We'd be producing the release based on both the stable and dev/unstable PPA. Stable for users that just want to have the latest userspace working with an enabled kernel, and unstable for brave users and linaro developers that are mainly concerned about upstream support and enablement there.
Cheers,
On Tue, Apr 3, 2012 at 3:40 PM, Ricardo Salveti ricardo.salveti@linaro.org wrote:
On Tue, Apr 3, 2012 at 6:10 AM, Amit Kucheria amit.kucheria@linaro.org wrote:
On Tue, Apr 3, 2012 at 9:08 AM, Ricardo Salveti
So in the end we'd be generating 2 sets of hwpacks per board, one based on the Development Overlay (latest components, even if not working properly), and one based on the Stable PPAs, that we know it'll always have a better enablement. Both would be using the same rootfs, as all distro related core changes will be part of the Overlay PPA anyway.
I believe this can simply things a bit, and would not consume much of our time as the stable repository would just be a snapshot of a known to be working development PPA.
What would the monthly release be based on? The stable PPA?
We'd be producing the release based on both the stable and dev/unstable PPA. Stable for users that just want to have the latest userspace working with an enabled kernel, and unstable for brave users and linaro developers that are mainly concerned about upstream support and enablement there.
This will certainly be useful for a certain category of users and increase our community size.
However, I worry about a situation where everybody settles down on the stable release and the unstable versions don't get much testing.
Can there be some commitment from those responsible for HW enablement (kernel porting, binary blobs, etc.) to provide periodic refreshes of these components? e.g. every 3 months. IOW, some predictable forward momentum for the stable releases instead of continuing divergence similar to internal BSPs.
/Amit
On Tue, Apr 3, 2012 at 10:30 AM, Amit Kucheria amit.kucheria@linaro.org wrote:
On Tue, Apr 3, 2012 at 3:40 PM, Ricardo Salveti ricardo.salveti@linaro.org wrote:
On Tue, Apr 3, 2012 at 6:10 AM, Amit Kucheria amit.kucheria@linaro.org wrote:
On Tue, Apr 3, 2012 at 9:08 AM, Ricardo Salveti
So in the end we'd be generating 2 sets of hwpacks per board, one based on the Development Overlay (latest components, even if not working properly), and one based on the Stable PPAs, that we know it'll always have a better enablement. Both would be using the same rootfs, as all distro related core changes will be part of the Overlay PPA anyway.
I believe this can simply things a bit, and would not consume much of our time as the stable repository would just be a snapshot of a known to be working development PPA.
What would the monthly release be based on? The stable PPA?
We'd be producing the release based on both the stable and dev/unstable PPA. Stable for users that just want to have the latest userspace working with an enabled kernel, and unstable for brave users and linaro developers that are mainly concerned about upstream support and enablement there.
This will certainly be useful for a certain category of users and increase our community size.
However, I worry about a situation where everybody settles down on the stable release and the unstable versions don't get much testing.
Can there be some commitment from those responsible for HW enablement (kernel porting, binary blobs, etc.) to provide periodic refreshes of these components? e.g. every 3 months. IOW, some predictable forward momentum for the stable releases instead of continuing divergence similar to internal BSPs.
Yeah, that's the goal. Our effort inside Linaro is to always enable and test the unstable release, so we can make sure our development is progressing properly, and that the vendor is also publishing the blogs at a useful schedule.
The stable would be initially a working snapshot of the unstable PPA, to be used by end users. We would not spend resources validating it over the cycles, as I'd expect the maintenance to be more a community driven effort, that can be owned by the vendor itself, or just by community users/developers.
Cheers,
-
Amit Kucheria -
Ricardo Salveti