Just a reminder that we will hold a special session of the TSC meeting in about 30 minutes to vote on whether to bless the Helium SU1 artifacts [0] and whether to approve the draft Lithium release

This event has been changed. more details » Changed: Special (Helium Stable Release - 1) TSC Meeting Changed: As agreed during the TSC meeting on Nov. 6th,this is a special meeting of the TSC to

more details » Special (Lithium Release) TSC Meeting As agreed during the TSC meeting on Nov. 6th,this is a special meeting of the TSC to discuss and agree upon the Release Plan for

In general, I think this is right. A few comments inline. --Colin The yangtools, openflowjava, and odlparent projects come to mind as projects that wouldn't have an user-facing features. +1 to this.

Hi all, I have added section for Job builder as I think it is very important this release + projects to setup upstream triggers + some minor fixes. Please review it before we vote on

Thanks Abhijit, and sorry if I created confusion when I said "define user-facing features" instead of “create karaf user-facing features”. My take here is: In general we should let projects

It turns out most of the real documentation was in the karaf features archetype, so I pushed this patch instead of editing the Karaf step-by-step guide: https://git.opendaylight.org/gerrit/12656 I'll

I agree - but probably better to just keep it in the Karaf step-by-step rather than the requirements in the release plan.

If that's the question, I would say that the naming convention that openflowplugin and l2switch used was good. We could suggest (or maybe even require it) in Lithium: 1.)

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