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,