Date   

TSC Meeting Agenda for Nov 7, 2019

Abhijit Kumbhare
 

Agenda for this meeting is at:


If you need to add anything, please let me know.

Thanks,
Abhijit


Re: [release] Micro distribution tech discussion

Abhijit Kumbhare
 

Samuel,

When do you think you will be ready to move this project proposal beyond draft to an actual proposal by sending it to the mailing list for project proposals <project-proposals@...>?

Thanks,
Abhijit


NetVirt TSC representation

Abhijit Kumbhare
 

Hi Abhinav & the NetVirt project,

We needed some input last week TSC meeting from the NetVirt project. I understand that Abhinav was on a vacation last week due to Diwali. Can you folks please ensure that someone can represent the project during the TSC meeting if Abhinav/PTL cannot attend?

I also understand that the TSC timings maybe a little late for some folks (particularly in India) - and with the new TSC elected we will look into getting the meeting timings adjustment so that it is convenient to all the TSC Members.

Thanks,
Abhijit


Re: [release] [OpenDaylight TSC] ODL yang models

Luis Gomez
 

No that I know, but I should probably ask the intern to do so, so at least we have a per-project track.

On Nov 6, 2019, at 4:25 AM, Nidhi Adhvaryu <nidhi.adhvaryu@...> wrote:

Hi Luis,

I have incorporated few failures identified in yang model for genius.
I have raised a patch here, https://git.opendaylight.org/gerrit/#/c/genius/+/85534/

Is there any jira raised for this activity?

Thanks,
Nidhi Adhvaryu


-----Original Message-----
From: release@... <release@...> On Behalf Of Robert Varga via Lists.Opendaylight.Org
Sent: Wednesday, October 23, 2019 2:41 PM
To: Luis Gomez <ecelgp@...>; Release <release@...>; tsc <tsc@...>
Cc: release@...
Subject: Re: [release] [OpenDaylight TSC] ODL yang models

On 22/10/2019 21:08, Luis Gomez wrote:
Hi everyone,

You may know already, we have an ODL intern, Rohan Julka, working on
yang model pushing to Yang github (https://protect2.fireeye.com/v1/url?k=ee7a31d0-b2ae346f-ee7a714b-868f633dbf25-abae512c859ad01f&q=1&e=93aaea4f-322c-4e0b-9a6f-56add005a851&u=https%3A%2F%2Fgithub.com%2FYangModels%2Fyang).

As part of this exercise, we added a test in the distribution merge
job to collect and verify ODL generated yang models using pyang, see
the results here:

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/distributio
n-merge-managed-magnesium/657/opendaylight-models/

The test shows we have issues in many models (see error file under
each project). Some of them like "import" not used, are easy to fix
and have no impact, but other may require further analysis and the fix
may impact the API.

So how do we want to go about this? should we open bugs to every
project to fix this? any other idea to get the models repaired?
Well, we need attribution to where the model is packaged -- the current approach of matching namespace is nice (in that it points out wrong namespaces), but really those 'external' models need to be charged to the project packaging them (most of which is mdsal, as designed).

As for the individual failures ... yeah, they need to be classified and analyzed, as for example we are more liberal around keyless lists in config (because they are not a problem for our internal workings).

Regards,
Robert


Re: Moving from sonar.opendaylight.org to Sonarcloud.io

Andrew Grimberg
 

On 11/6/19 2:40 PM, Eric Ball wrote:
All: I'm going to abandon the previously-linked patch request, and break it out into separate commits by project.
Robert: I've updated the Sonarcloud user permissions to match SonarQube, where all registered users can administer issues. As for the history import, it is not supported. We will have to leave the history behind.
A couple of notes about this:

1) Registered users are going to be users that are logging into SonarCloud using a GitHub account that is associated with the OpenDaylight GitHub organization. We presently have no quick and easy way of figuring out what those identities are so we'll have to do it on a case by case basis right now.

2) We're pushing for this change for a few of reasons.

a) This gives the project a fully up to date version Sonar and it will stay up to date since this is being maintained by SonarSource itself.

b) It reduces costs to the projects (we're pushing for this across the board everywhere) as it removes a server and a database from the support equation. Since we're being pushed hard by the different boards to reduce costs where possible this is a low hanging fruit type of change.

Yes y'all will lose the historical data, there isn't much we can do about that in this case since there is no ability to import data from SonarQube into SonarCloud.

-Andy-

On Wed, Nov 6, 2019 at 3:24 PM Robert Varga <nite@... <mailto:nite@...>> wrote:
On 06/11/2019 23:01, Eric Ball wrote:
>
> You can view the OpenDaylight Sonarcloud page
> here: https://sonarcloud.io/organizations/opendaylight/projects
> Currently, the only projects showing results are those that have
run and
> passed on the sandbox. Once the change is merged, all projects
will show
> results after their next successful run.
>
> You may notice that while quantitative numbers like code coverage and
> duplication haven't changed, the number of bugs/vulnerabilities/code
> smells may have changed significantly (most likely an increase).
This is
> due to Sonarcloud using much more up-to-date Quality Profiles
than ODL's
> SonarQube instance, so this should be considered an improvement in
> results (even though I understand that it can be a pain to
suddenly have
> a backlog of issues where there were few or none before). These
profiles
> can be customized, so if anyone sees something coming up that
absolutely
> should not be in the results, we can remove it from the Quality
Profile.
>
> Please let me know if you have any questions, or if you'd like to
bring
> this up for discussion during the next TSC meeting.
Another thing: there seems to be no historical data available. I would
hate to lose the 4+ years of data accumulated in
https://sonar.opendaylight.org/dashboard?id=org.opendaylight.yangtools%3Ayangtools-aggregator.
What is being done about that?
Regards,
Robert
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12184): https://lists.opendaylight.org/g/TSC/message/12184
Mute This Topic: https://lists.opendaylight.org/mt/44622856/517193
Group Owner: TSC+owner@...
Unsubscribe: https://lists.opendaylight.org/g/TSC/unsub [agrimberg@...]
-=-=-=-=-=-=-=-=-=-=-=-
--
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation


Re: Moving from sonar.opendaylight.org to Sonarcloud.io

Eric Ball <eball@...>
 

All: I'm going to abandon the previously-linked patch request, and break it out into separate commits by project.

Robert: I've updated the Sonarcloud user permissions to match SonarQube, where all registered users can administer issues. As for the history import, it is not supported. We will have to leave the history behind.


On Wed, Nov 6, 2019 at 3:24 PM Robert Varga <nite@...> wrote:
On 06/11/2019 23:01, Eric Ball wrote:
>
> You can view the OpenDaylight Sonarcloud page
> here: https://sonarcloud.io/organizations/opendaylight/projects
> Currently, the only projects showing results are those that have run and
> passed on the sandbox. Once the change is merged, all projects will show
> results after their next successful run.
>
> You may notice that while quantitative numbers like code coverage and
> duplication haven't changed, the number of bugs/vulnerabilities/code
> smells may have changed significantly (most likely an increase). This is
> due to Sonarcloud using much more up-to-date Quality Profiles than ODL's
> SonarQube instance, so this should be considered an improvement in
> results (even though I understand that it can be a pain to suddenly have
> a backlog of issues where there were few or none before). These profiles
> can be customized, so if anyone sees something coming up that absolutely
> should not be in the results, we can remove it from the Quality Profile.
>
> Please let me know if you have any questions, or if you'd like to bring
> this up for discussion during the next TSC meeting.

Another thing: there seems to be no historical data available. I would
hate to lose the 4+ years of data accumulated in
https://sonar.opendaylight.org/dashboard?id=org.opendaylight.yangtools%3Ayangtools-aggregator.

What is being done about that?

Regards,
Robert


Re: Moving from sonar.opendaylight.org to Sonarcloud.io

Robert Varga
 

On 06/11/2019 23:01, Eric Ball wrote:

You can view the OpenDaylight Sonarcloud page
here: https://sonarcloud.io/organizations/opendaylight/projects
Currently, the only projects showing results are those that have run and
passed on the sandbox. Once the change is merged, all projects will show
results after their next successful run.

You may notice that while quantitative numbers like code coverage and
duplication haven't changed, the number of bugs/vulnerabilities/code
smells may have changed significantly (most likely an increase). This is
due to Sonarcloud using much more up-to-date Quality Profiles than ODL's
SonarQube instance, so this should be considered an improvement in
results (even though I understand that it can be a pain to suddenly have
a backlog of issues where there were few or none before). These profiles
can be customized, so if anyone sees something coming up that absolutely
should not be in the results, we can remove it from the Quality Profile.

Please let me know if you have any questions, or if you'd like to bring
this up for discussion during the next TSC meeting.
Another thing: there seems to be no historical data available. I would
hate to lose the 4+ years of data accumulated in
https://sonar.opendaylight.org/dashboard?id=org.opendaylight.yangtools%3Ayangtools-aggregator.

What is being done about that?

Regards,
Robert


Re: [OpenDaylight Infrastructure] Moving from sonar.opendaylight.org to Sonarcloud.io

Robert Varga
 

On 06/11/2019 23:01, Eric Ball wrote:
Hello all,

We here at the LF Release Engineering team are working on a move from
hosted SonarQube instances to the cloud-based Sonarcloud service. To
that end, there is currently a proposed change to all Sonar jobs that
would move them to
Sonarcloud: https://git.opendaylight.org/gerrit/c/releng/builder/+/85644

Sonarcloud has more features and better language support than SonarQube,
and it will remove the hosting and maintenance costs associated with the
SonarQube server. Our plan is to decommission the SonarQube server about
a month after we make the move to Sonarcloud.

You can view the OpenDaylight Sonarcloud page
here: https://sonarcloud.io/organizations/opendaylight/projects
Currently, the only projects showing results are those that have run and
passed on the sandbox. Once the change is merged, all projects will show
results after their next successful run.

You may notice that while quantitative numbers like code coverage and
duplication haven't changed, the number of bugs/vulnerabilities/code
smells may have changed significantly (most likely an increase). This is
due to Sonarcloud using much more up-to-date Quality Profiles than ODL's
SonarQube instance, so this should be considered an improvement in
results (even though I understand that it can be a pain to suddenly have
a backlog of issues where there were few or none before). These profiles
can be customized, so if anyone sees something coming up that absolutely
should not be in the results, we can remove it from the Quality Profile.

Please let me know if you have any questions, or if you'd like to bring
this up for discussion during the next TSC meeting.
How are project permissions being handled? I currently do not have the
rights to work with the issues reported (for example here:
https://sonarcloud.io/project/issues?id=opendaylight_aaa&open=AW44xOdh_323jmKWHypB&resolved=false&types=BUG)

Regards,
Robert


Moving from sonar.opendaylight.org to Sonarcloud.io

Eric Ball <eball@...>
 

Hello all,

We here at the LF Release Engineering team are working on a move from hosted SonarQube instances to the cloud-based Sonarcloud service. To that end, there is currently a proposed change to all Sonar jobs that would move them to Sonarcloud: https://git.opendaylight.org/gerrit/c/releng/builder/+/85644

Sonarcloud has more features and better language support than SonarQube, and it will remove the hosting and maintenance costs associated with the SonarQube server. Our plan is to decommission the SonarQube server about a month after we make the move to Sonarcloud.

You can view the OpenDaylight Sonarcloud page here: https://sonarcloud.io/organizations/opendaylight/projects
Currently, the only projects showing results are those that have run and passed on the sandbox. Once the change is merged, all projects will show results after their next successful run.

You may notice that while quantitative numbers like code coverage and duplication haven't changed, the number of bugs/vulnerabilities/code smells may have changed significantly (most likely an increase). This is due to Sonarcloud using much more up-to-date Quality Profiles than ODL's SonarQube instance, so this should be considered an improvement in results (even though I understand that it can be a pain to suddenly have a backlog of issues where there were few or none before). These profiles can be customized, so if anyone sees something coming up that absolutely should not be in the results, we can remove it from the Quality Profile.

Please let me know if you have any questions, or if you'd like to bring this up for discussion during the next TSC meeting.

Note: ovsdb is using a custom Sonar template. This will need to be changed to work with Sonarcloud, or (preferably) changed to use global-jjb templates. If there's something our global-jjb jobs do not currently support, we should be able to add that functionality.

Eric Ball
Release Engineer
The Linux Foundation


Re: [release] [OpenDaylight TSC] ODL yang models

Nidhi Adhvaryu <nidhi.adhvaryu@...>
 

Hi Luis,

I have incorporated few failures identified in yang model for genius.
I have raised a patch here, https://git.opendaylight.org/gerrit/#/c/genius/+/85534/

Is there any jira raised for this activity?

Thanks,
Nidhi Adhvaryu

-----Original Message-----
From: release@... <release@...> On Behalf Of Robert Varga via Lists.Opendaylight.Org
Sent: Wednesday, October 23, 2019 2:41 PM
To: Luis Gomez <ecelgp@...>; Release <release@...>; tsc <tsc@...>
Cc: release@...
Subject: Re: [release] [OpenDaylight TSC] ODL yang models

On 22/10/2019 21:08, Luis Gomez wrote:
Hi everyone,

You may know already, we have an ODL intern, Rohan Julka, working on
yang model pushing to Yang github (https://protect2.fireeye.com/v1/url?k=ee7a31d0-b2ae346f-ee7a714b-868f633dbf25-abae512c859ad01f&q=1&e=93aaea4f-322c-4e0b-9a6f-56add005a851&u=https%3A%2F%2Fgithub.com%2FYangModels%2Fyang).

As part of this exercise, we added a test in the distribution merge
job to collect and verify ODL generated yang models using pyang, see
the results here:

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/distributio
n-merge-managed-magnesium/657/opendaylight-models/

The test shows we have issues in many models (see error file under
each project). Some of them like "import" not used, are easy to fix
and have no impact, but other may require further analysis and the fix
may impact the API.

So how do we want to go about this? should we open bugs to every
project to fix this? any other idea to get the models repaired?
Well, we need attribution to where the model is packaged -- the current approach of matching namespace is nice (in that it points out wrong namespaces), but really those 'external' models need to be charged to the project packaging them (most of which is mdsal, as designed).

As for the individual failures ... yeah, they need to be classified and analyzed, as for example we are more liberal around keyless lists in config (because they are not a problem for our internal workings).

Regards,
Robert


Re: [release] ODL Technical Advisory Council Representative Election

Luis Gomez
 

OK, then it is fine.

On Nov 5, 2019, at 3:40 PM, Abhijit Kumbhare <abhijitkoss@...> wrote:

No - we did not vote on that. However the election plan was that the 3 elections would be held in parallel. Also all the LFN projects now seem to have the 3 different elections.


On Tue, Nov 5, 2019 at 3:30 PM Luis Gomez <ecelgp@...> wrote:
Did not we say that going forward TSC/TAC/SPC could be the same person to simplify the process?

On Nov 5, 2019, at 3:02 PM, Abhijit Kumbhare <abhijitkoss@...> wrote:

Hi Casey,

Can you please align all the three elections to have the same timeline? TSC Chair, TAC and the SPC?

Currently the TSC Chair election nomination period & voting period is 3 days before the TAC & the SPC elections. It will be great if you can just extend the self nomination period of the TSC Chair election to align with the TAC & SPC elections.

Thanks,
Abhijit


On Tue, Nov 5, 2019 at 9:37 AM Casey Cain <ccain@...> wrote:
Hello, everyone.

The role of the Technical Advisory Council is to facilitate communication and collaboration among the Technical Projects in the LFN.  All OpenDaylight Committers are eligible. 

TAC Representative Responsibilities
  • Coordinating collaboration across technical projects
  • Making recommendations to the Finance Committee of resource priorities for Technical Projects
  • Electing TAC representative to the governing board
  • Setting processes/procedures for the election of "committer representative" to the LFN Governing Board
  • Other matters related to the technical role of the TAC that may be communicated to the TAC by the LFN Governing Board
Nominations will close November 18th, 2019.  If you would like to self-nominate, please do so here:

Best,
Casey Cain
Technical Program Manager / Community Architect
Linux Foundation
_________________
IRC - CaseyLF
WeChat - okaru6
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#18296): https://lists.opendaylight.org/g/release/message/18296
Mute This Topic: https://lists.opendaylight.org/mt/42296121/675589
Group Owner: release+owner@...
Unsubscribe: https://lists.opendaylight.org/g/release/unsub  [abhijitkoss@...]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#18298): https://lists.opendaylight.org/g/release/message/18298
Mute This Topic: https://lists.opendaylight.org/mt/42296121/1217165
Group Owner: release+owner@...
Unsubscribe: https://lists.opendaylight.org/g/release/unsub  [ecelgp@...]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [release] ODL Technical Advisory Council Representative Election

Abhijit Kumbhare
 

No - we did not vote on that. However the election plan was that the 3 elections would be held in parallel. Also all the LFN projects now seem to have the 3 different elections.


On Tue, Nov 5, 2019 at 3:30 PM Luis Gomez <ecelgp@...> wrote:
Did not we say that going forward TSC/TAC/SPC could be the same person to simplify the process?

On Nov 5, 2019, at 3:02 PM, Abhijit Kumbhare <abhijitkoss@...> wrote:

Hi Casey,

Can you please align all the three elections to have the same timeline? TSC Chair, TAC and the SPC?

Currently the TSC Chair election nomination period & voting period is 3 days before the TAC & the SPC elections. It will be great if you can just extend the self nomination period of the TSC Chair election to align with the TAC & SPC elections.

Thanks,
Abhijit


On Tue, Nov 5, 2019 at 9:37 AM Casey Cain <ccain@...> wrote:
Hello, everyone.

The role of the Technical Advisory Council is to facilitate communication and collaboration among the Technical Projects in the LFN.  All OpenDaylight Committers are eligible. 

TAC Representative Responsibilities
  • Coordinating collaboration across technical projects
  • Making recommendations to the Finance Committee of resource priorities for Technical Projects
  • Electing TAC representative to the governing board
  • Setting processes/procedures for the election of "committer representative" to the LFN Governing Board
  • Other matters related to the technical role of the TAC that may be communicated to the TAC by the LFN Governing Board
Nominations will close November 18th, 2019.  If you would like to self-nominate, please do so here:

Best,
Casey Cain
Technical Program Manager / Community Architect
Linux Foundation
_________________
IRC - CaseyLF
WeChat - okaru6
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#18296): https://lists.opendaylight.org/g/release/message/18296
Mute This Topic: https://lists.opendaylight.org/mt/42296121/675589
Group Owner: release+owner@...
Unsubscribe: https://lists.opendaylight.org/g/release/unsub  [abhijitkoss@...]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#18298): https://lists.opendaylight.org/g/release/message/18298
Mute This Topic: https://lists.opendaylight.org/mt/42296121/1217165
Group Owner: release+owner@...
Unsubscribe: https://lists.opendaylight.org/g/release/unsub  [ecelgp@...]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [release] ODL Technical Advisory Council Representative Election

Luis Gomez
 

Did not we say that going forward TSC/TAC/SPC could be the same person to simplify the process?

On Nov 5, 2019, at 3:02 PM, Abhijit Kumbhare <abhijitkoss@...> wrote:

Hi Casey,

Can you please align all the three elections to have the same timeline? TSC Chair, TAC and the SPC?

Currently the TSC Chair election nomination period & voting period is 3 days before the TAC & the SPC elections. It will be great if you can just extend the self nomination period of the TSC Chair election to align with the TAC & SPC elections.

Thanks,
Abhijit


On Tue, Nov 5, 2019 at 9:37 AM Casey Cain <ccain@...> wrote:
Hello, everyone.

The role of the Technical Advisory Council is to facilitate communication and collaboration among the Technical Projects in the LFN.  All OpenDaylight Committers are eligible. 

TAC Representative Responsibilities
  • Coordinating collaboration across technical projects
  • Making recommendations to the Finance Committee of resource priorities for Technical Projects
  • Electing TAC representative to the governing board
  • Setting processes/procedures for the election of "committer representative" to the LFN Governing Board
  • Other matters related to the technical role of the TAC that may be communicated to the TAC by the LFN Governing Board
Nominations will close November 18th, 2019.  If you would like to self-nominate, please do so here:

Best,
Casey Cain
Technical Program Manager / Community Architect
Linux Foundation
_________________
IRC - CaseyLF
WeChat - okaru6
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#18296): https://lists.opendaylight.org/g/release/message/18296
Mute This Topic: https://lists.opendaylight.org/mt/42296121/675589
Group Owner: release+owner@...
Unsubscribe: https://lists.opendaylight.org/g/release/unsub  [abhijitkoss@...]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#18298): https://lists.opendaylight.org/g/release/message/18298
Mute This Topic: https://lists.opendaylight.org/mt/42296121/1217165
Group Owner: release+owner@...
Unsubscribe: https://lists.opendaylight.org/g/release/unsub  [ecelgp@...]
-=-=-=-=-=-=-=-=-=-=-=-


Re: [release] ODL Technical Advisory Council Representative Election

Abhijit Kumbhare
 

Hi Casey,

Can you please align all the three elections to have the same timeline? TSC Chair, TAC and the SPC?

Currently the TSC Chair election nomination period & voting period is 3 days before the TAC & the SPC elections. It will be great if you can just extend the self nomination period of the TSC Chair election to align with the TAC & SPC elections.

Thanks,
Abhijit


On Tue, Nov 5, 2019 at 9:37 AM Casey Cain <ccain@...> wrote:
Hello, everyone.

The role of the Technical Advisory Council is to facilitate communication and collaboration among the Technical Projects in the LFN.  All OpenDaylight Committers are eligible. 

TAC Representative Responsibilities
  • Coordinating collaboration across technical projects
  • Making recommendations to the Finance Committee of resource priorities for Technical Projects
  • Electing TAC representative to the governing board
  • Setting processes/procedures for the election of "committer representative" to the LFN Governing Board
  • Other matters related to the technical role of the TAC that may be communicated to the TAC by the LFN Governing Board
Nominations will close November 18th, 2019.  If you would like to self-nominate, please do so here:

Best,
Casey Cain
Technical Program Manager / Community Architect
Linux Foundation
_________________
IRC - CaseyLF
WeChat - okaru6
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#18296): https://lists.opendaylight.org/g/release/message/18296
Mute This Topic: https://lists.opendaylight.org/mt/42296121/675589
Group Owner: release+owner@...
Unsubscribe: https://lists.opendaylight.org/g/release/unsub  [abhijitkoss@...]
-=-=-=-=-=-=-=-=-=-=-=-


Re: Sodium MRI update

Robert Varga
 

On 05/11/2019 17:45, Robert Varga wrote:
Hello everyone,

https://git.opendaylight.org/gerrit/q/topic:"mri-sodium-sr2" is being
rolled out right now, mirroring the fixes delivered in mri-neon-sr3 code
drop. Version diff can be seen here:
https://git.opendaylight.org/gerrit/c/integration/distribution/+/85527/1/docs/platform-versions.rst

The process will take a couple of hours to complete, ETA is tomorrow
morning CET.
All patches are merged up, it will take some 30 more minutes for dust to
settle around netvirt and int/dist, after which everything should be
back to normal.

Regards,
Robert


ODL Technical Advisory Council Representative Election

Casey Cain
 

Hello, everyone.

The role of the Technical Advisory Council is to facilitate communication and collaboration among the Technical Projects in the LFN.  All OpenDaylight Committers are eligible. 

TAC Representative Responsibilities
  • Coordinating collaboration across technical projects
  • Making recommendations to the Finance Committee of resource priorities for Technical Projects
  • Electing TAC representative to the governing board
  • Setting processes/procedures for the election of "committer representative" to the LFN Governing Board
  • Other matters related to the technical role of the TAC that may be communicated to the TAC by the LFN Governing Board
Nominations will close November 18th, 2019.  If you would like to self-nominate, please do so here:

Best,
Casey Cain
Technical Program Manager / Community Architect
Linux Foundation
_________________
IRC - CaseyLF
WeChat - okaru6


SPC Representative Election

Casey Cain
 

Hello, members of the TSC.

The election for the Strategic Planning Committee Representative has begun.  Only TSC members are currently eligible.

SPC Overview and Role
The LFN SPC was approved on May 15, 2019, as a committee of the Governing Board. The SPC has the dual role of helping to set the strategy for the LFN portfolio of projects as a whole and providing Projects visibility into the directions of the Governing Board. As with all GB committees, the SPC only provides recommendations and guidance to the Governing Board. It is the GB that has the ultimate decision-making authority regarding those recommendations.

More information may be found here: https://wiki.lfnetworking.org/x/o4Hu

ODL Representative Responsibilities
  • The SPC currently meets regularly (once per week on Mondays) for one hour.
  • Additional SPC internal/planning meetings that may be needed
  • Once a quarter meeting with the TAC on LFN portfolio guidance
  • Once every quarter before GB meetings to prepare an agenda item for the GB
  • Mailing list discussion between meetings
  • Face-to-face meetings with TAC/TSCs when possible and needed (e.g., at ONES when both SPC and TAC are present)
Nominations will close on November 18th, 2019. If you would like to self-nominate, please do so here:

Best,
Casey Cain
Technical Program Manager / Community Architect
Linux Foundation
_________________
IRC - CaseyLF
WeChat - okaru6


Sodium MRI update

Robert Varga
 

Hello everyone,

https://git.opendaylight.org/gerrit/q/topic:"mri-sodium-sr2" is being
rolled out right now, mirroring the fixes delivered in mri-neon-sr3 code
drop. Version diff can be seen here:
https://git.opendaylight.org/gerrit/c/integration/distribution/+/85527/1/docs/platform-versions.rst

The process will take a couple of hours to complete, ETA is tomorrow
morning CET.

Regards,
Robert


Re: [release] [OpenDaylight TSC] How to handle DLUX & Projects Under the TSC Purview ?

Thanh ha <zxiiro@...>
 

On Fri, 1 Nov 2019 at 15:07, JamO Luhrsen <jluhrsen@...> wrote:
On 11/1/19 10:50 AM, Robert Varga wrote:
On 01/11/2019 00:48, Abhijit Kumbhare wrote:
Hi TSC members,

During the TSC meeting today (Oct 31, 2019) Robert asked the TSC how
should we deal with projects which should be under the TSC purview due
to lack of active members. Example: DLUX which is not part of the
current simultaneous release - but still need fixes for the previous
releases SRs. Robert had an excellent suggestion that since these
projects are in a way managed by the TSC but have no longer any active
members - all the TSC members should be committers on these projects.
This way we would be able to merge any absolutely needed code changes to
the project. There was an overall consensus on this - but it would be
important to have a conversation around this - followed by a vote.
I would like to note that the proposal hinges on the project being dead
and the TSC already taking an action -- DLUX is under consideration for
archival. The aim is to define an alternative to archiving the project,
but this may become useful in different situations as well -- which we
can consider when such a situation arises.

I think there are three topics here that need to be clarified via a
discussion & a vote:

*Topic 1:* What are the criteria to have a project under the TSC purview? 

In my opinion, the minimum criteria would be: 

  * The TSC should think that the project is important enough to make it
    under TSC purview. Instead of specifying specific rules for what is
    an important project, I think this should be decided on a case by
    case basis by a TSC vote. 
  * These projects have no active committers. Implicitly having no
    active committers also means that the project has no objections to
    be under the TSC purview. 
  * The above two should be the minimum criteria. Not all the projects
    which satisfy the above two criteria should be put under the TSC
    purview. Whether a particular project should be under the TSC
    purview, should be decided by a TSC vote.
+1. I am not sure about timing -- perhaps this process can become
available sooner than the 18 month archival period?

+1

Maybe once a project goes for a single release with zero activity (I propose gerrit
be the data we use) we can allow for TSC to become committers on that project
and after 3 releases with no activity we'll be at the 18month period and can decide
to archive or not.

+1 I think this makes a lot of sense. 

      
*Topic 2*: Should the TSC be committers on a project under TSC purview? 
+1, TSC members should be committers on the project, making their vote
equivalent to the decision of committers on any other project. This
should include the nomination and approval of non-TSC committers to the
project -- which would be a step towards the project coming out of TSC
purview and resuming normal life...


+1

+1
 

*Topic 3*: Does the TSC agree that DLUX should be under the TSC purview?
+1.
+1
 
+1
 
We should also consider l2switch, as it seems to be close to being in
working state here:
https://git.opendaylight.org/gerrit/c/l2switch/+/85209 and it is a
useful example on getting started on development.

totally agree. there are always questions about l2switch in the wild. I2switch + dlux
was normally everyone's first introduction to ODL as a whole.


Agreed.

Thanh


Re: [opendaylight-dev] OpenDaylight TSC Election Results

Abhijit Kumbhare
 

A correction inside my email - I had missed Thanh by mistake (his name was alphabetically the last one and I missed scrolling down to his name/description on the TSC page). Apologies Thanh.

On Fri, Nov 1, 2019 at 11:55 AM Abhijit Kumbhare <abhijitkoss@...> wrote:
Congratulations and welcome to the new TSC Members :

Hema Gopalakrishnan
Arunprakash D
Balaji Varadaraju
Tejas Nevrekar
Venkatrangan Govindarajan

Also I would like to thank all the TSC Members who have served during the last TSC term.

An Ho
Anil Belur
Anil Vishnoi
Faseela K
Jamo Luhrsen
Luis Gomez
Michael Vorburger
Prem Sankar Gopannan
Robert Varga
Sam Hague
Stephen Kitt
Thanh Ha  

We will miss the members who will not continue during the new term. For the members who will continue, thank you for your continued contributions as OpenDaylight TSC Members.


On Fri, Nov 1, 2019 at 11:11 AM Casey Cain <ccain@...> wrote:
Hello, Everyone.

I would like to announce that the OpenDaylight Technical Steering Committee Election has concluded.  Please congratulate the new TSC.

Hema Gopalakrishnan
Robert Varga
Arunprakash D
Anil Belur
Balaji Varadaraju
Luis Gomez
Jamo Luhrsen
Tejas Nevrekar
Venkatrangan Govindarajan
Faseela K
Abhijit Kumbhare

Congratulations!  Thank you to everyone who participated in the Election. The nomination period for the TSC Chair will begin immediately.  TSC members who are interested in nominating themselves for Chairperson may do so on this page:

Best,
Casey Cain
Technical Program Manager / Community Architect
Linux Foundation
_________________
IRC - CaseyLF
WeChat - okaru6
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#5668): https://lists.opendaylight.org/g/dev/message/5668
Mute This Topic: https://lists.opendaylight.org/mt/40457635/675589
Group Owner: dev+owner@...
Unsubscribe: https://lists.opendaylight.org/g/dev/unsub  [abhijitkoss@...]
-=-=-=-=-=-=-=-=-=-=-=-

2161 - 2180 of 14349