On Wed, Jan 11, 2012 at 1:09 AM, Andy Green andy.green@linaro.org wrote:
On 01/11/2012 03:34 AM, Somebody in the thread at some point said:
Hi -
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).
I think there is confusion inside Linaro about what these releases are. What you're saying is correct, but it doesn't always reflect what's happening on the ground.
For LT the 'beat' we work to is kernel cycle and as you say monthly release is something downstream of what we are anyway doing for us, it should just be a staging post for what popped out of our sausage machine recently.
However people responsible for making the releases feel under pressure to maximize what's in there for a deadline that's not inherently meaningful, when at times when we may be dedicated to having to do something else do to lack of sync with our underlying 'beat'. At its worst, the drama of having a release leads to a false sense of urgency and bad decisions that are not in Linaro's overall interest.
Once we agree that with CI we'll always try to avoid having regressions (bugs on new features and development is expected), I don't see why the LEBs would not just follow the LT trees directly. But, unfortunately, when the features are closely related with binary blobs from the vendor, that is not always the truth, and things can be quite broken over the time.
Guess we should probably thing better on how we're integrating the content produced by the LTs and the LEBs. While I agree that we want to the release snapshot to be something stable and working without critical regressions, that's not the case atm, and fighting against this situation will for sure just add a lot of pressure at folks all around.
For other projects than Kernel, I don't see our cycle as an issue, as once something is released (or in a shape we can merge at our LEBs), we can then plan the integration work and work on getting them available at our images (by staging PPA and such, as described by Tom).
Cheers,