Hi Colin, I personally would like to see following milestones for the Integration group: M1: Integration Project To Publish Integration & System Test requirements for participating projects M2:

I also think the best approach would be: describe the best we can the requirements we already know before SR but also keep open for changes and adjustments as we progress in the release. As for the

Hi Colin, Thank you for the info. So, it looks like thee are no official formal testings plans for ODL projects. BTW, Sonar was mentioned somewhere in the ODL mailing lists. Is it being used for this

While I don't think we have official rules, in general we've gone with passing all the unit, system, and integration tests in the relevant projects and integration. If a project or the integration

Dear ODL, > * We intend to release the first stable update for helium based on artifacts cut on 11/2 [1] assuming they are tested and found to be good. It's good to know that. BTW, what are the

Dear List, > Videos should be available by the end of next week. It is much appreciated if someone with the link to the ODL Controller Design Summit recording would share it. Best regards, PhiHo

As Kent pointed out in his last mail [0], we really do want to explain what should be sent as a readout for each milestone, when and how. Here's what I'm thinking, with requests for George to help.

Thanks Kent! I'll make these edits, but put them here as well. Comments inline. (Sorry for messing up the formatting, but I had to for inline comments.) I guess the high-order bit is that we should

I've started a separate thread on the possibility of adding requirements after the release plan has been has been approved

I'm starting a new thread to discuss this. Currently, the plan [0] is to have new project infrastructure up 1 week after M1 modulo Thanksgiving. Phil has told me that Andrew agreed that should be

(Starting this discussion as it's own thread.) My worry is that, like Karaf [0], we will end up with something that every project will really need to do and which can be made KDC, but that wasn't

Actually, karaf in Helium is the *perfect* example of why KDC is crucial. We *rushed* the Helium Simultaneous Release Plan out the door. We did *not* KDC karaf for Helium. We *did* make a series of

Overall very good at defining "what", but less so at defining "how". For instance: Planning Projects must declare their intent to participate in the Simultaneous Release by M1. How? Send email to

The issue is that I think most people will merely use the API and see if it works without ever looking at the Javadoc or seeing that there's an @Beta. Ideally, we'd generate a warning for using @Beta

Inline, also with snips where we agree. Again, while I'm 100% in favor of these ideals, I just want to make sure that we don't shoot ourselves in the foot in terms of our ability to drive a successful

I would like to see the TSC vote on the final Lithium release plan at next week's TSC meeting (on Thursday, 11/6). The current draft is on the wiki

Most of these annotations (like @Beta) are @Documented, so they should show up in Javadocs and similar contexts. Bye, Robert

The TSC met for two hours on Thursday, October 30th 2014 and covered a range of topics. The full minutes can be found in the usual place [0]. The major topics covered were: * We intend to release the

I feel kind of strongly that we have at least a Milestone for projects to work out what they need for M1 (particularly planning). The simplest way to do that is M0, but we could figure something else

I'm having audio issue, so please allow Flavio to be my proxy