Hello,
Based on the discussions and decisions made at the Linaro Connect Q4.11, Infrastructure team is pleased to announce changes in the process of Linaro Android Infrastructure planning and maintenance. The main audience of the new process is Linaro Android Team, which is the primary stakeholder of the Android infrastructure, but it also applies to other groups and individuals in Linaro, as well as external contributors and community.
The basic idea is to make Android infrastructure planning and management more sustainable, as well as improve the Infrastructure Team internal processes which will allow entire team to handle Android infrastructure tasks and improve cross-team work and knowledge sharing.
The new process is as follows:
1. There's a new Linaro Android Infrastructure project at Launchpad, https://launchpad.net/linaro-android-infrastructure/ , which is intended to be a central facade for Android infrastructure development and maintenance.
2. The bugtracker in that project, https://bugs.launchpad.net/linaro-android-infrastructure is intended as a single contact point to report Android infrastructure issues, so please bookmark it and keep it handy. This ticket queue replaces all older communication means, like direct email, IRC pings, etc. (that doesn't mean they can't be used, it means that any issue should be reported as a ticket nonetheless). The bugtracker is indeed conceived to be a single point of contact, and if a ticket requires recursing to Linaro IS team, that will be handled by Infrastructure team itself. Using the "bug also affects project" Launchpad feature, tickets can be easily cross-posted to other projects which are affected.
3. The blueprints area in that project, https://blueprints.launchpad.net/linaro-android-infrastructure is used to host all blueprints related to Android infrastructure. That may change in the future (i.e. they will be filed against individual projects), but so far it's good step forward from such bluprints being filed against linaro-android project, which caused scheduling and accounting issues for both Android and Infrastructure teams.
4. The usual rules of thumb are applied to blueprints and tickets: Blueprints represent work to develop new (sub)systems or add non-trivial functionality to existing systems. They can be filed at any time, but prioritized and scheduled for execution at the beginning of monthly milestones. Tickets represent issues reports and requests to make changes which only Infra team can do, other maintenance requests, and feature requests. Tickets which turn out to require substantial effort, may be converted to blueprints.
5. For the time being, the Infrastructure team commits to working on 1-2 Android infrastructure blueprints each milestone, with more time spent on maintenance (including documentation and testsuites) of existing systems. Following the process above will allow us to optimize and improve our workflow, and provide more resources to Android infrastructure work, if that proves to be required.
Thanks, Paul
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