1. TSC@lists.opendaylight.org
  2. Messages
   Date   
Re: Results of the OpenDaylight board call of 05.15.2013 and its relationship to the issues we've been discussing

Chris Wright <chrisw@...>
 

* David Meyer (dmm@...) wrote:
(i). Disambiguate the starting point for the DE proposal. This
starting point can be either the "controller" or "net-virt-platform"
code base (again, the third project/repository is not a candidate).
Note that the current list of committers for whichever code base will
*not* be carried forward. The point here is to decouple the issue of
committers from the code base.

The TSC will vote on the starting point as the first order of business
during tomorrow's call.
While my OSGi knowledge is limited, my understanding is that we can
develop bundles in any repo, push to nexus, and combine them via
distribution/pom.xml as a part of a build (could be part of release
engineering). So I'd like to continue understanding the technical
issues associated w/ making, e.g. net-virt-platform or even third repo
modules into bundles and including them as dependencies regardless of
their source genesis before we (TSC) take any invasive[1] action. Put
another way...taken to the extreme, I believe each OSGi bundle could
end up in its own repo (meaning the repo discussion has little merit).

thanks,
-chris

[1] For the record, I believe this is antithetical to an open community
(and not in the purview of the TSC) unless the vote is simply to clarify
the TSC's recommendation.
Re: [OpenDaylight Discuss] Results of the OpenDaylight board call of 05.15.2013 and its relationship to the issues we've been discussing

Rob Sherwood
 

I want to re-iterate Big Switch's position that we're against "top down" TSC or Board votes on technical design and implementation questions, and we feel the current issue falls in to that category.  The communities we've found successful are the ones that have strong processes, but rely on volunteerism and leaders close to the code to drive technical direction.

I understand the concern that we've given ourselves a deadline of Q3 to produce an initial release.  However, on behalf of Big Switch, we feel that in the trade-off between the scope, date and community building, we'd put community first.  Let those close to the code come together and sort this out, and keep our role as a TSC focused on removing the barriers that would prevent that from happening bottoms-up.

So, even though I personally believe that the net-virt code base is the better technical starting point to get the most mature code fastest, I'm going to _abstain_ from tomorrow's vote and would encourage the other TSC members who are concerned about this process to do likewise.  There is are healthier ways to solve this.

- Rob
.

PS @Chris: the feature of pushing modules to nexus is actually a function of maven, not OSGI 


On Wed, May 15, 2013 at 10:13 PM, Chris Wright <chrisw@...> wrote:
* David Meyer (dmm@...) wrote:
> (i).   Disambiguate the starting point for the DE proposal. This
> starting point can be either the "controller" or "net-virt-platform"
> code base (again, the third project/repository is not a candidate).
> Note that the current list of committers for whichever code base will
> *not* be carried forward. The point here is to decouple the issue of
> committers from the code base.
>
> The TSC will vote on the starting point as the first order of business
> during tomorrow's call.

While my OSGi knowledge is limited, my understanding is that we can
develop bundles in any repo, push to nexus, and combine them via
distribution/pom.xml as a part of a build (could be part of release
engineering).  So I'd like to continue understanding the technical
issues associated w/ making, e.g. net-virt-platform or even third repo
modules into bundles and including them as dependencies regardless of
their source genesis before we (TSC) take any invasive[1] action.  Put
another way...taken to the extreme, I believe each OSGi bundle could
end up in its own repo (meaning the repo discussion has little merit).

thanks,
-chris

[1] For the record, I believe this is antithetical to an open community
(and not in the purview of the TSC) unless the vote is simply to clarify
the TSC's recommendation.
_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
Re: [OpenDaylight Discuss] Results of the OpenDaylight board call of 05.15.2013 and its relationship to the issues we've been discussing

Chris Wright <chrisw@...>
 

* Rob Sherwood (rob.sherwood@...) wrote:
PS @Chris: the feature of pushing modules to nexus is actually a function
of maven, not OSGI
Yes, I know. The point being that the bundle <-> repo connection is
papered over by as build.
motions and proxy voting proposals

Thomas Nadeau <tnadeau@...>
 

Resending with edits provided from folks like Chris and Dave.

--Tom




Email-based or Proxy-based Voting

This proposal amends the existing TSC voting procedures that stipulate
that voting by TSC members must be done "in person" during scheduled
meetings.


Motions

Before being put to a vote, motions presented before the TSC must be
raised publicly on the development mailing-list for a minimum of 4
business days prior to a vote. This will give a chance to the wider
community to express their opinion as well as accommodate the
possibility that members might not attend a meeting and vote in person.

TSC members or their designated proxy can vote via email positively,
negatively, or abstain as is the case today, but must voice their votes
in writing on the public mailing list.

This will serve as the official written public record of their vote.
Members or their proxies and designates that do not vote or have their
votes received by the chair via the official mailing list will be counted
as "abstain".

Decisions need more positive votes than negative votes (ties mean the
motion is rejected), and a minimum of positive votes of at least one
third of the total number of TC members (rounded up: in a board with
8PTLs+5 that means a minimum of 5 approvers).


Proxy Delegates

Any Technical Steering Committee (TSC) member may designate a proxy to
attend a meeting in their place. This change must be sent to both the
TSC (private) list as well as the TSC chair in writing at least 1
hour prior to the expiration period of a motion for a vote. This person
may place votes on behalf of the TSC member both in person at a meeting,
or via email in case they cannot attend the meeting for the period
of 1 meeting unless otherwise stipulated.
Model Driven SAL References

Ed Warnicke (eaw) <eaw@...>
 

In the TSC call today I was asked to aggregate the information currently put out there about the
Model Driven SAL and send it out to discuss to draw greater attention to it.

The initial email (there are others in the list archives):


The top of the wiki page cluster around it:


Ed
Re: [controller-dev] Model Driven SAL References

Kyle Forster
 

Hi Ed - 

Thanks much for this.

A question that came up that I wanted to reflect over on list -- which component of the model driven SAL is intended to do reconciliation in the case where you have multiple running instances of a <provider,broker,application> that temporarily get out of sync?  I'm assuming the gist is to replay notifications, but is the design intent to do reconciliation of out-of-order notifications at the Application layer, or is the intent to handle this further down?  (Feel free to say "errr - call Colin and Jan for a walk-through of the basics" if I'm totally off track, or if this should be handled through some mechanism other than the SAL.)

(For context - several of the net-virt-platform components where we're scoping the porting effort follow a design pattern that makes specific assumptions about the way that the storage service reconciles under load and split-brain scenarios.  Think of physical placement of a controller per pod hanging off a DC spine, where each controller is master for one pod and the slave for another.)

-K




 


On Thu, May 16, 2013 at 12:12 PM, Ed Warnicke (eaw) <eaw@...> wrote:
In the TSC call today I was asked to aggregate the information currently put out there about the
Model Driven SAL and send it out to discuss to draw greater attention to it.

The initial email (there are others in the list archives):


The top of the wiki page cluster around it:


Ed

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev




--
---------------------------------------------------------
R. Kyle Forster
+1 (415) 990-2670 (m)
kyle.forster@...

Re: [OpenDaylight Discuss] [controller-dev] Model Driven SAL References

Mandeep Dhami <mandeep.dhami@...>
 

Hi Ed:

Is there also a similar page for concurrency model used by the controller project? I was investigating porting of net-virt host-tracker to controller (using SAL as the south bound interface), and I wanted to make sure that I was minimizing context changes.

Thanks,
Mandeep



On Sun, May 19, 2013 at 11:30 PM, Kyle Forster <kyle.forster@...> wrote:
Hi Ed - 

Thanks much for this.

A question that came up that I wanted to reflect over on list -- which component of the model driven SAL is intended to do reconciliation in the case where you have multiple running instances of a <provider,broker,application> that temporarily get out of sync?  I'm assuming the gist is to replay notifications, but is the design intent to do reconciliation of out-of-order notifications at the Application layer, or is the intent to handle this further down?  (Feel free to say "errr - call Colin and Jan for a walk-through of the basics" if I'm totally off track, or if this should be handled through some mechanism other than the SAL.)

(For context - several of the net-virt-platform components where we're scoping the porting effort follow a design pattern that makes specific assumptions about the way that the storage service reconciles under load and split-brain scenarios.  Think of physical placement of a controller per pod hanging off a DC spine, where each controller is master for one pod and the slave for another.)

-K




 


On Thu, May 16, 2013 at 12:12 PM, Ed Warnicke (eaw) <eaw@...> wrote:
In the TSC call today I was asked to aggregate the information currently put out there about the
Model Driven SAL and send it out to discuss to draw greater attention to it.

The initial email (there are others in the list archives):


The top of the wiki page cluster around it:


Ed

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev




--
---------------------------------------------------------
R. Kyle Forster
+1 (415) 990-2670 (m)
kyle.forster@...

_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss
Re: motions and proxy voting proposals

David Meyer <dmm@...>
 

Folks, please read this for Thursday's meeting. Thanks, --dmm

On Thu, May 16, 2013 at 10:11 AM, Thomas Nadeau <tnadeau@...> wrote:

Resending with edits provided from folks like Chris and Dave.

--Tom




Email-based or Proxy-based Voting

This proposal amends the existing TSC voting procedures that stipulate
that voting by TSC members must be done "in person" during scheduled
meetings.


Motions

Before being put to a vote, motions presented before the TSC must be
raised publicly on the development mailing-list for a minimum of 4
business days prior to a vote. This will give a chance to the wider
community to express their opinion as well as accommodate the
possibility that members might not attend a meeting and vote in person.

TSC members or their designated proxy can vote via email positively,
negatively, or abstain as is the case today, but must voice their votes
in writing on the public mailing list.

This will serve as the official written public record of their vote.
Members or their proxies and designates that do not vote or have their
votes received by the chair via the official mailing list will be counted
as "abstain".

Decisions need more positive votes than negative votes (ties mean the
motion is rejected), and a minimum of positive votes of at least one
third of the total number of TC members (rounded up: in a board with
8PTLs+5 that means a minimum of 5 approvers).


Proxy Delegates

Any Technical Steering Committee (TSC) member may designate a proxy to
attend a meeting in their place. This change must be sent to both the
TSC (private) list as well as the TSC chair in writing at least 1
hour prior to the expiration period of a motion for a vote. This person
may place votes on behalf of the TSC member both in person at a meeting,
or via email in case they cannot attend the meeting for the period
of 1 meeting unless otherwise stipulated.







_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
Re: [controller-dev] Model Driven SAL References

Kyle Forster
 

Following up on Rob's presentation yesterday, let me give a bit more context for the question so we can get all unblocked.

Across about six generations of open source controllers (NOX, SNAC, Beacon, Ryu, Floodlight, net-virt-platform) and good info about the closed versions you can find evolving variants of Host/DeviceManager, TopologyManager, Forwarding and Storage implementations.  Target scale, topology diversity and device diversity (vSwitch vs pSwitch due to perf characteristics) lead to a lot of the differences, as do your assumptions about rainy day scenarios (e.g. a rack of 1k VMs all coming online at once and ARPing, a switch in the middle of a fat tree going down, losing a control link in between controller instances, etc.).

Splitting these out turns out to be quite difficult.  I believe that Colin started to see this in https://wiki.opendaylight.org/view/D-E_Proposal:Host_Tracker_Plan -- #5 is hard, and as Rob mentioned yesterday, stubbing out #6 breaks the (popular) overlay topologies as every host is reachable via both an OpenFlow tunnel path and a cross-Island path.

So... where does this leave us?  We're trying to figure out either:

a) Port all of these over in one big whallop, trying to maintain the target scale, topologies, devices and rainy day characteristics of of net-virt-platform over to controller.  We've been looking at this for the last two weeks, but have been skinning on our knee on the different directions the two projects are headed on the storage assumptions (think CAP theorem trade-offs).  Keep in mind that a practical deployment (at least in our world) is not a single controller, but rather a cluster of controllers for both scale and resiliency, and the cost of having controllers that disagree can (often) result in a forwarding loop.

b) Port Host/DeviceManager, TopologyManager, Forwarding over bit by bit on top of the SAL's storage direction, and do our best to rebuild the target scale, topologies, devices and rainy day characteristics over time.  I think we're coming around to this being the vastly more practical approach, though it is a longer road to get back to the targets in the net-virt-platform, with the amount of time that will take pretty closely tied to the differences in deployment / storage assumptions from the original net-virt-platform to the controller design.

It is actually in the spirit of (b) that I was asking the question about event re-ordering.  (This is basically a where-do-the-CAP-trade-offs-really-get-made in the SAL question.)

Thanks!
-K





On Sun, May 19, 2013 at 11:30 PM, Kyle Forster <kyle.forster@...> wrote:
Hi Ed - 

Thanks much for this.

A question that came up that I wanted to reflect over on list -- which component of the model driven SAL is intended to do reconciliation in the case where you have multiple running instances of a <provider,broker,application> that temporarily get out of sync?  I'm assuming the gist is to replay notifications, but is the design intent to do reconciliation of out-of-order notifications at the Application layer, or is the intent to handle this further down?  (Feel free to say "errr - call Colin and Jan for a walk-through of the basics" if I'm totally off track, or if this should be handled through some mechanism other than the SAL.)

(For context - several of the net-virt-platform components where we're scoping the porting effort follow a design pattern that makes specific assumptions about the way that the storage service reconciles under load and split-brain scenarios.  Think of physical placement of a controller per pod hanging off a DC spine, where each controller is master for one pod and the slave for another.)

-K




 


On Thu, May 16, 2013 at 12:12 PM, Ed Warnicke (eaw) <eaw@...> wrote:
In the TSC call today I was asked to aggregate the information currently put out there about the
Model Driven SAL and send it out to discuss to draw greater attention to it.

The initial email (there are others in the list archives):


The top of the wiki page cluster around it:


Ed

_______________________________________________
controller-dev mailing list
controller-dev@...
https://lists.opendaylight.org/mailman/listinfo/controller-dev




--
---------------------------------------------------------
R. Kyle Forster
+1 (415) 990-2670 (m)
kyle.forster@...



--
---------------------------------------------------------
R. Kyle Forster
+1 (415) 990-2670 (m)
kyle.forster@...

Re: motions and proxy voting proposals

Ed Warnicke (eaw) <eaw@...>
 

A few thoughts inline…

On May 16, 2013, at 12:11 PM, Thomas Nadeau <tnadeau@...> wrote:


Resending with edits provided from folks like Chris and Dave.

--Tom




Email-based or Proxy-based Voting

This proposal amends the existing TSC voting procedures that stipulate
that voting by TSC members must be done "in person" during scheduled
meetings.


Motions

Before being put to a vote, motions presented before the TSC must be
raised publicly on the development mailing-list for a minimum of 4
business days prior to a vote. This will give a chance to the wider
community to express their opinion as well as accommodate the
possibility that members might not attend a meeting and vote in person.

TSC members or their designated proxy can vote via email positively,
negatively, or abstain as is the case today, but must voice their votes
in writing on the public mailing list.

This will serve as the official written public record of their vote.
Members or their proxies and designates that do not vote or have their
votes received by the chair via the official mailing list will be counted
as "abstain".

Decisions need more positive votes than negative votes (ties mean the
motion is rejected), and a minimum of positive votes of at least one
third of the total number of TC members (rounded up: in a board with
8PTLs+5 that means a minimum of 5 approvers).
I am a little concerned with this provision. Consider for example a vote raised
over the Christmas holidays, with only three TSC members voting at all.
The TSC charter is pretty clear currently that simple majority should be used
for decisions of the TSC, and that feels right.


Proxy Delegates

Any Technical Steering Committee (TSC) member may designate a proxy to
attend a meeting in their place. This change must be sent to both the
TSC (private) list as well as the TSC chair in writing at least 1
hour prior to the expiration period of a motion for a vote. This person
may place votes on behalf of the TSC member both in person at a meeting,
or via email in case they cannot attend the meeting for the period
of 1 meeting unless otherwise stipulated.







_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
Re: motions and proxy voting proposals

Thomas Nadeau <tnadeau@...>
 

On 5/23/13 11:23 AM, "Ed Warnicke (eaw)" <eaw@...> wrote:

A few thoughts inlineŠ

On May 16, 2013, at 12:11 PM, Thomas Nadeau <tnadeau@...> wrote:


Resending with edits provided from folks like Chris and Dave.

--Tom




Email-based or Proxy-based Voting

This proposal amends the existing TSC voting procedures that stipulate
that voting by TSC members must be done "in person" during scheduled
meetings.


Motions

Before being put to a vote, motions presented before the TSC must be
raised publicly on the development mailing-list for a minimum of 4
business days prior to a vote. This will give a chance to the wider
community to express their opinion as well as accommodate the
possibility that members might not attend a meeting and vote in person.

TSC members or their designated proxy can vote via email positively,
negatively, or abstain as is the case today, but must voice their votes
in writing on the public mailing list.

This will serve as the official written public record of their vote.
Members or their proxies and designates that do not vote or have their
votes received by the chair via the official mailing list will be
counted
as "abstain".

Decisions need more positive votes than negative votes (ties mean the
motion is rejected), and a minimum of positive votes of at least one
third of the total number of TC members (rounded up: in a board with
8PTLs+5 that means a minimum of 5 approvers).
I am a little concerned with this provision. Consider for example a vote
raised
over the Christmas holidays, with only three TSC members voting at all.
The TSC charter is pretty clear currently that simple majority should be
used
for decisions of the TSC, and that feels right.
I think a simple majority is what that paragraph meant. We could just
say "Decisions require a simple majority"

--Tom





Proxy Delegates

Any Technical Steering Committee (TSC) member may designate a proxy to
attend a meeting in their place. This change must be sent to both the
TSC (private) list as well as the TSC chair in writing at least 1
hour prior to the expiration period of a motion for a vote. This person
may place votes on behalf of the TSC member both in person at a
meeting,
or via email in case they cannot attend the meeting for the period
of 1 meeting unless otherwise stipulated.







_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
Re: motions and proxy voting proposals

Chris Wright <chrisw@...>
 

Re: motions and proxy voting proposals

Thomas Nadeau <tnadeau@...>
 

So the action was for the TSC folks to review that bare text and comment
on how to modify it for our use. Please keep in mind that during our
discussion these points were raised as desirable goals:

1) quorum needed
2) simple majority for votes
3) 4 days notice for proposed votes (at least for major items)
4) All TSC members attend each meeting or their delegate
5) It seemed that we did not want email based voting based on #4 above.


--Tom

On 5/23/13 2:02 PM, "Chris Wright" <chrisw@...> wrote:


Here is the openstack TC wording

https://wiki.openstack.org/wiki/Governance/Foundation/TechnicalCommittee
OpenDaylight TSC Meeting Minutes from 5/23

Phil Robb
 

Hello TSC Members:

Please find the meeting minutes attached.

Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb

PDF
TSC 2013-05-23 Minutes.pdf

Proposed Simultaneous Release Plan

Ed Warnicke (eaw) <eaw@...>
 

I was asked by the TSC to send out the Proposed Simultaneous Release Plan we discussed
in todays TSC call to the list.

You can find it here:

I have made the following edits in response to requests from the TSC since we discussed it:
1)  I have switched the mailing list in the Communication Channels section from 'simultaneous-release' to 
'discuss'.
2)  I have added a 'String Freeze' to allow for internationalization to M5.

Rajeev Nagar raised a very important point that I am still not certain how to correctly incorporate,
but I feel should be: Where does documentation live in all of this? I am would love to hear thoughts as to how 
to correctly incorporate that :)

Ed
Re: Proposed Simultaneous Release Plan

Alejandro Avella <robertico.gonzalez77@...>
 

Hi Ed,

I was wondering if you could provide some details on the test scenarios that you plan to run.   Are they Junit test cases? What about for the Integration tests? Is there documentation for the unit and integration tests? Is there a test plan? Are there QA people involved in this Open Source project?  How long does it take to run all the tests? Where can I find more information about how to test OpenDayLight project?  I saw on the web page that the team is using Gerrit to trigger Jenkins jobs after code has been reviewed?  What build tools are used in the project (Ant, Maven or others?)

I was trying to find this information on the wiki page, but I couldn't find it.  If there is something already written, could you point me to that information?

Regards,
Alejandro


On Thu, May 30, 2013 at 12:49 PM, Ed Warnicke (eaw) <eaw@...> wrote:
I was asked by the TSC to send out the Proposed Simultaneous Release Plan we discussed
in todays TSC call to the list.

You can find it here:

I have made the following edits in response to requests from the TSC since we discussed it:
1)  I have switched the mailing list in the Communication Channels section from 'simultaneous-release' to 
'discuss'.
2)  I have added a 'String Freeze' to allow for internationalization to M5.

Rajeev Nagar raised a very important point that I am still not certain how to correctly incorporate,
but I feel should be: Where does documentation live in all of this? I am would love to hear thoughts as to how 
to correctly incorporate that :)

Ed

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc
Re: [OpenDaylight Discuss] Proposed Simultaneous Release Plan

Kalvin Hom (kahom) <kahom@...>
 

HI Alejandro,

 

The current tests in the controller project are using JUnit for the individual bundles, and separate integration tests are written in their own bundles using Pax-Exam.  Whenever a commit is checked-in, the Jenkins build also runs the tests, and if any of them fail, it leaves a -1 review in Gerrit saying the build is UNSTABLE.

 

There’s a wiki page on the integration tests here:  https://wiki.opendaylight.org/view/OpenDaylight_Controller:Integration_Tests

 

Kalvin

 

From: discuss-bounces@... [mailto:discuss-bounces@...] On Behalf Of David Erickson
Sent: Friday, May 31, 2013 10:18 AM
To: Alejandro Avella
Cc: discuss@...; tsc@...
Subject: Re: [OpenDaylight Discuss] [OpenDaylight TSC] Proposed Simultaneous Release Plan

 

Alejandro-
There are existing unit tests within a project, and cross-project integration tests will have to be created prior to a release.  One existing project uses Maven and the other is being migrated from Ant to Maven.  I don't know that there are any dedicated QA people, but I consider every programmer a QA person :)

The included in-project unit and integration tests run with Maven would be a good place to start learning.

-David

On 5/30/2013 11:13 PM, Alejandro Avella wrote:

Hi Ed,

 

I was wondering if you could provide some details on the test scenarios that you plan to run.   Are they Junit test cases? What about for the Integration tests? Is there documentation for the unit and integration tests? Is there a test plan? Are there QA people involved in this Open Source project?  How long does it take to run all the tests? Where can I find more information about how to test OpenDayLight project?  I saw on the web page that the team is using Gerrit to trigger Jenkins jobs after code has been reviewed?  What build tools are used in the project (Ant, Maven or others?)

 

I was trying to find this information on the wiki page, but I couldn't find it.  If there is something already written, could you point me to that information?

 

Regards,

Alejandro

On Thu, May 30, 2013 at 12:49 PM, Ed Warnicke (eaw) <eaw@...> wrote:

I was asked by the TSC to send out the Proposed Simultaneous Release Plan we discussed

in todays TSC call to the list.

 

You can find it here:

 

I have made the following edits in response to requests from the TSC since we discussed it:

1)  I have switched the mailing list in the Communication Channels section from 'simultaneous-release' to 

'discuss'.

2)  I have added a 'String Freeze' to allow for internationalization to M5.

 

Rajeev Nagar raised a very important point that I am still not certain how to correctly incorporate,

but I feel should be: Where does documentation live in all of this? I am would love to hear thoughts as to how 

to correctly incorporate that :)

 

Ed


_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc

 




_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss

 
Re: [OpenDaylight Discuss] Proposed Simultaneous Release Plan

Ed Warnicke (eaw) <eaw@...>
 

One other thing to keep in mind, it's normal for a project to be responsible for it's own unit tests and 'local' integration tests
(by local I mean integration among the bundles it provides).

Clearly we will need to work something out for inter-project integration as a community.

Ed
On May 31, 2013, at 12:18 PM, David Erickson <daviderickson@...> wrote:

Alejandro-
There are existing unit tests within a project, and cross-project integration tests will have to be created prior to a release.  One existing project uses Maven and the other is being migrated from Ant to Maven.  I don't know that there are any dedicated QA people, but I consider every programmer a QA person :)

The included in-project unit and integration tests run with Maven would be a good place to start learning.

-David

On 5/30/2013 11:13 PM, Alejandro Avella wrote:
Hi Ed,

I was wondering if you could provide some details on the test scenarios that you plan to run.   Are they Junit test cases? What about for the Integration tests? Is there documentation for the unit and integration tests? Is there a test plan? Are there QA people involved in this Open Source project?  How long does it take to run all the tests? Where can I find more information about how to test OpenDayLight project?  I saw on the web page that the team is using Gerrit to trigger Jenkins jobs after code has been reviewed?  What build tools are used in the project (Ant, Maven or others?)

I was trying to find this information on the wiki page, but I couldn't find it.  If there is something already written, could you point me to that information?

Regards,
Alejandro

On Thu, May 30, 2013 at 12:49 PM, Ed Warnicke (eaw) <eaw@...> wrote:
I was asked by the TSC to send out the Proposed Simultaneous Release Plan we discussed
in todays TSC call to the list.

You can find it here:

I have made the following edits in response to requests from the TSC since we discussed it:
1)  I have switched the mailing list in the Communication Channels section from 'simultaneous-release' to 
'discuss'.
2)  I have added a 'String Freeze' to allow for internationalization to M5.

Rajeev Nagar raised a very important point that I am still not certain how to correctly incorporate,
but I feel should be: Where does documentation live in all of this? I am would love to hear thoughts as to how 
to correctly incorporate that :)

Ed

_______________________________________________
TSC mailing list
TSC@...
https://lists.opendaylight.org/mailman/listinfo/tsc




_______________________________________________
Discuss mailing list
Discuss@...
https://lists.opendaylight.org/mailman/listinfo/discuss


Finalizing HackFest Dates Around OSCON

Phil Robb
 

Hello TSC:

At the most recent meeting, the TSC decided to hold a HackFest coincident with OSCON on the 23rd and 24th of July (Tuesday/Wednesday) of that week.

After thinking about this, I want to raise an issue on having the Hackfest on the Tuesday/Wednesday during OSCON.

OSCON is partitioned into two activities that week.  On Monday and Tuesday, there are tutorial sessions on specific topics.  The cost of the Tutorial days is separate from the OSCON conference, and  the tutorials have a much smaller attendance than the regular conference.

Wednesday through Friday is the OSCON conference.  Starting Wednesday morning, Keynotes, and general OSCON sessions will begin.  As with many conferences, the first day is often the most well-attended, and content-rich.

I would suggest that we either do a two day HackFest on Monday/Tuesday (22/23), or do a single day HackFest on Tuesday the 23rd (to accommodate the desire for no weekend travel).  Since we are trying to get OSCON conference goers to attend the HackFest, I don't think we should create a conflict with the most important day of the event.

What are your thoughts?

Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
Re: Finalizing HackFest Dates Around OSCON

Thomas Nadeau <tnadeau@...>
 


I would agree with that approach Phil. I actually recommended that we do it a week earlier than that.  The concern is that the IETF is in Berlin starting the Sunday of that week.   For those that have to travel to California for the HackFest, flying all the way to Germany a two days later isn't going to be a good time so pushing that back as much as possible is welcomed.

--Tom


From: Phil Robb <probb@...>
Date: Friday, May 31, 2013 3:58 PM
To: "tsc@..." <tsc@...>
Subject: [OpenDaylight TSC] Finalizing HackFest Dates Around OSCON

Hello TSC:

At the most recent meeting, the TSC decided to hold a HackFest coincident with OSCON on the 23rd and 24th of July (Tuesday/Wednesday) of that week.

After thinking about this, I want to raise an issue on having the Hackfest on the Tuesday/Wednesday during OSCON.

OSCON is partitioned into two activities that week.  On Monday and Tuesday, there are tutorial sessions on specific topics.  The cost of the Tutorial days is separate from the OSCON conference, and  the tutorials have a much smaller attendance than the regular conference.

Wednesday through Friday is the OSCON conference.  Starting Wednesday morning, Keynotes, and general OSCON sessions will begin.  As with many conferences, the first day is often the most well-attended, and content-rich.

I would suggest that we either do a two day HackFest on Monday/Tuesday (22/23), or do a single day HackFest on Tuesday the 23rd (to accommodate the desire for no weekend travel).  Since we are trying to get OSCON conference goers to attend the HackFest, I don't think we should create a conflict with the most important day of the event.

What are your thoughts?

Phil.
--
Phil Robb
Director - Networking Solutions
The Linux Foundation
(O) 970-229-5949
(M) 970-420-4292
Skype: Phil.Robb
181 - 200 of 14375