Re: [OpenDaylight Discuss] release planning for Helium

Luis Gomez

OK, because integration test is being used for many things, I just wanted to make sure what it was the meaning here.

Also before I forget, we should have a milestone for release editions definition and its components as the "system test" we do in Integration project applies to release editions.


On 4/2/2014 1:31 PM, Ed Warnicke (eaw) wrote:

On Apr 2, 2014, at 12:24 PM, Luis Gomez <ecelgp@...> wrote:

Hi Ed,

We can add an entry for system test but before that I would like to know more about the CI milestone: 

- Are these the JUnit and PAX-EXAM tests executed as part of the build in the verify and merge jobs or is there anything else?

I have tended to think of the ‘Integration’ step as having ‘integration’ Jenkin’s Jobs for the other projects you depend on and
the System Test piece as being the System test kinds of stuff the integration project does.

I’m not married to those notions… but I do think we should get a clear answer to give the projects :)


- "Last call for CI” means the above jobs have to be there but devs can still work on adding more tests, right? in that case I would call it “Last call for CI jobs”

- I still miss a recommendation on the CI test coverage, like it would be good to have a milestone at the end where we say CI test coverage is the recommended.


On Apr 2, 2014, at 10:00 AM, Ed Warnicke (eaw) <eaw@...> wrote:

Comments inline...
On Apr 1, 2014, at 7:15 PM, Christopher Price <christopher.price@...> wrote:

My best case might look like:

M0 - 4/07

I am so pleased not to be starting in the past ;)

M1 - 5/01 publish release plans
M2 - 5/27 (Tue for Memorial Day) finalize relese plans
M3 - 6/23 last call for CI

Did we loose a last call for System test somewhere?

M4 - 7/21 API Freeze
M5 - 8/18 Code freeze
RC0 - 8/25
RC1 - 9/2 (Tue for Labor Day)
RC2 - 9/8
Final - 9/15

I get the sense we are trying to work back from a date… it might be helpful
if we are very clear as to which date we are trying to work back from and why, 
as it gives us a sense of how much space we have to play with.

But we will be squeezed for new projects to get everything in place for
5/01 and I expect some effort on behalf of the community leadership will
be required to make such a thing happen.  

It did for Hydrogen as well.  No matter how simple you try to make things,
everybody feels a little better with a helping hand :)

Improvements on Hydrogen and
additional quality gating are really important in this release so we have
to find a way to fit that in and communicate well enough to make it
possible to keep the projects aligned and on track with those changes.

Agreed.  I think we need to be a little careful to do it intelligently, but I think
its clear we need to do it.

I do think that once we have a published simultaneous release plan the
projects that can hit those dates will know it, and those that will want
to wait for the first release of 2015 will know it also.  Not
participating in the Helium SR does not exclude a project from
participating in the OpenDaylight Helium community, that needs to be well

Agreed.  Its a fine line, but one I think we can successfully walk with a little care :)

Finally… I know we’d all like to start hitting a regular cadence going forward,
so I’d strongly advocate that once we settle urgent business (like getting the Simultaneous Release
Plan going and getting the service pack release going etc) that we lay down the ‘bones’
of the Lithium Release… not the *final* Release Plan for Lithium with all requisite requirements,
but the sketch of the milestones and dates that we don’t expect to move so that it becomes
simpler to hold to a cadence going forward.


/ Chris

On 4/1/14, 4:30 PM, "Chris Wright" <chrisw@...> wrote:

M0 - 3/31
M1 - 4/28 publish release plans
M2 - 5/27 (Tue for Memorial Day) finalize relese plans
M3 - 6/23 last call for CI
M4 - 7/21 API Freeze
M5 - 8/18 Code freeze
RC0 - 8/25
RC1 - 9/2 (Tue for Labor Day)
RC2 - 9/8
Final - 9/15

TSC mailing list

Join to automatically receive all group messages.