On 09/25/2014 07:09 AM, Colin Dixon wrote:

Based on what Chris Price sent out I wanted to say a few things about the Lithium release plan.

The high-order bit is that I think we as a TSC haven't done a great job putting together the previous release plans. For the most part, we've just taken the release plan which Ed handed us and rubber stamped it.

This hasn't been out of malice and shouldn't be taken as an offense. Ed's release plans have been hugely helpful and we likely would have struggled without them. I also think we've been making the best decisions with the information we have.

That being said, we had very little information when adopting our first two release plans, both because we had relatively few data points (zero and one) and few of the TSC members spend time "on the ground" interacting with the consequences of dates in the release plans.

Fortunately, I now think we have enough data points and enough experience dealing with release plans on the TSC to significantly improve things next time. I've been aggregating points to address (ranging from trivial to very complex) here:
https://wiki.opendaylight.org/view/Simultaneous_Release:Lithium_Release_Plan#Lessons_from_Hydrogen.2FHelium_that_Should_be_Applied

I think the key next step is to make time to critically walk through the Lithium release with input from from as much of the TSC as possible and see if we can figure out how to change milestones, dates, requirements and consequences to make Lithium go as smoothly as possible.

While I agree with the lessons, I think the release structure has to change. The API freeze/code freeze structure leads to features being rushed at the last minute, often with inadequate quality, just to get the code in. That increases the risk in the very small RC window. We have seen major integration issues being reported literally hours before RC2 was supposed to be cut.

The lack of a ramp-down period is painfully apparent: if you take a look at the number of issues being tracked in sonar it is obvious projects do not have a window where they work exclusively on code quality.

For that, I believe we need a proper 4-week ramp-down, where the release branches are cut and operate on hard-API-freeze rules -- e.g. no new API additions without a waiver, but code is allowed to evolve and get hardened. If we cannot spare that time, we really need to think long and pick two out of three: frequent releases, reliable releases or feature-rich releases.

Bye,
Robert