Hi All, I had some thoughts and a suggestion this morning about the monthly release cycle that I'd like to share. Perhaps I'll get booed off the stage, perhaps not. I'm sure it can be improved on.
There is a great deal of stress around what blueprints fit into what monthly release boundary. For deliveries like the LEB that combine the fruits of our Linaro labors this makes great sense. Outside of the process for LEB creation and release, I'd like to suggest it's less than efficient and creates a bit of stress as we have the monthly rush to make the release dates. PMs and TLs continually have to be watching for what will and what won't be making dates that fit with the LEB. This passes on the stress to the engineering team, causes some late night hack-a-thons which in turn I believe caused us to rush software what was less than ready to be included in a LEB. I'm sure we all have examples we could point to. To address this I'd like to suggest the following. The production of the LEB and related builds should continue to be on a monthly release cycle. However outside of that process, for the WGs and such, we should go to a process based on continuous integration. As work groups, landing teams and so on, we commit to the LEB process that we have some set of blueprints IN QUEUE, meaning they are being worked on right now. When they go complete if they are LEB bound, they are delivered to the staging overlay. Items in the staging overlay are candidates for promotion to the overlay. When an item in the staging overlay is judged as being ready (bugs are at least triaged and deemed to not be blocking) it is promoted into the overlay from which daily builds are made and the monthly release is made. Packages in the staging overlay are the subject of functional test.IE Does it work? Packages in the overlay are the subject of integration test. IE Does it break the system? Work Groups, Landing Teams will also commit to having a priority list of blueprints and bugs that are being addressed or will be addressed. This keeps the release process and management team aware of what is coming and when. The # of completed work items per week (or other counts) can also help the management team measure forward momentum and progress. In some respects it's subtle process tweek. But I feel shifting part of linaro to a continuous integration / ship when ready model makes sense. In the work groups we are more connected upstream as we stay tune with upstream release boundaries but still want to showcase results in the monthly LEBs. Likewise focus on the LEB continues with higher quality software. It does shift the goal of creating great software by date X, to creating great software and ship when it's ready. Perhaps this would be a good discussion for 1Q12LC. -- Regards, Tom "Where's the kaboom!? There was supposed to be an earth-shattering kaboom!" Marvin Martian Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
