I think what Luis is asking (or what I think he is asking) makes sense. He wants an intuitive naming convention for the features which is followed by all the projects - so that the users can quickly

My (slightly different) reading of the net-net is: * M1–RC2 shift back by two weeks (or 3 in one case because of holidays) * Final release shifts back by 1 week (you sacrifice a week of time between

So, are you asking: 1.) how projects can tell the TSC (and the rest of the world) which of their features are user-facing once they know internally which features they want to be user facing? OR 2.)

Hi all, I have modified the requirements (thanks Colin) to say Integration project will be responsible to setup and trigger all downstream system tests so projects will only take care of their after

I think the net-net is this: M1 bumps back 2 weeks (+1 week for holidays for a total of 3… but we are eating the holiday offsets no matter what, so only effectively 2 weeks) Final Lithium Release

OK, I think I am not explaining myself clear. The problem is not documenting an already defined feature, the problem is to come up with a standard model for projects to identify user-facing features.

As part of the ongoing cleanup on controller, there is a patch: https://git.opendaylight.org/gerrit/#/c/12512/ to remove the legacy hydrogen-style distribution. This is in keeping with the

Yes that is what blocked me on download page... On Nov 7, 2014 4:31 PM, "Luis Gomez" <ecelgp@...> wrote:

The documentation requirements for Lithium [0] try to take a stab at this when they say: "Intimately related features, e.g., l2switch-switch, l2switch-switch-rest, and l2switch-switch-ui, can be

Hi Colin, My point is user-facing features are key yes but their definition is not as simple as it seems, it can be done in very many different ways (see the discussion with ofplugin project I sent

I did this. You can find it here: https://wiki.opendaylight.org/view/Project_Proposals:Main#Guidelines_for_your_Creation_Review Others should feel free to add anything else as well. Cheers, --Colin

We do really need to have a list of user-facing features (if any) from each project. I can add that to part of features definition in the main release plan if everyone agrees that makes sense. We need

Thank you Luis for the feedback it is more than appreciated.. As you mentioned I would agree for vendor-supported vs vendor led.. Moreover, +1 on the inter-project solutions. I think ODL needs to

Dear TSC, Yesterday call and this conversation with ofplugin project today remind me this release we should define and make some recommendations to projects on how to define their “user-facing”

Dear TSC, I have updated Integration requirements for projects based on comments from this morning, please check the link below in case I forgot anything or you have further

Hi, All system integration test passed successfully on Helium SR1: https://jenkins.opendaylight.org/integration/view/Release/job/integration-helium-test-release/11/console BR/Luis

That is very good news Mathieu and very wise decision IMHO, I am glad to have you and your team full engaged in OpenDaylight. For the article itself, I do not share most of the information there and

Hi everyone, I apologize if this may sound as "spam" to some but I wanted to give some news about me and my team. After Helium release, we took a step back to evaluate how we could best serve the

Sounds good. Thanks for letting us know. --Colin

Hi, Informing you that I will be the Point of Contact for the OpFlex project. Scott Mann has moved to a new opportunity and said he will not be able to participate in this project. Please also note