Hi Tom,
On 10 January 2012 19:14, Tom Gall tom.gall@linaro.org wrote:
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.
It seems there's some confusion here. The WGs/LTs deliveries aren't tight to LEB monthly releases, you have your own goals. It's fine to skip a monthly release (like many have done) or provide a snapshot of your current work (like LTs have done).
monthly releases != monthly planning.
It doesn't prevent that PMs/TLs should know what will make the targeted delivery, independently of the release. I'd like to believe that the hack-a-thons/rush is done to meet your own planned date and not the LEB release date.
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.
All the chain should be based on continuous integration, including our builds. That's the goal we're aiming and working on.
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?
The picture is pretty clear and has been discussed at last Connect: https://blueprints.launchpad.net/linaro-project-management/+spec/linaro-gene...
See "The road to Continuous Integration"
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 which way is it different from current workflow? AFAICS the only difference is LTs, as things stand today they don't use blueprint but rally for their project management.
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.
The goal is to create great software and ship it upstream, when it's ready. Though we do project management, planning, estimate deliveries, and it isn't tight to LEB monthly releases. The monthly releases are provided to showcase our results, and is also a playground for our improvements. If you don't have anything to show at the end of a cycle, or aren't interested to test your improvements in a real world environment, just skip it. Re-stating, my initial comment: it seems there's some confusion.
Perhaps this would be a good discussion for 1Q12LC.
I think we want to talk about the monthly planning.
-- 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
Cheers,