On Feb 8, 2019, at 1:28 AM, Richard Kosegi <richard.kosegi@...> wrote:

+jsonrpc-dev

Hi Luis,

thank you for notice.

Jsonrpc would like to be part of both Fluorine-SR2 and Neon.

Regards,

Richard.

On Fri, Feb 8, 2019 at 12:36 AM Luis Gomez <ecelgp@...> wrote:

This mail is to all committers of the Self-Managed projects in OpenDaylight:

Can you please respond to this mail if you have any plan to release your project in Fluorine SR2 (mail just sent) or Neon (next coming release).

BR/Luis

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

OK, thanks for responding.

On Feb 14, 2019, at 10:28 PM, <ylhsieh@...> <ylhsieh@...> wrote:

Hi,

Hope it’s not too late to respond. SNMP4SDN would like to be part of Neon, and already have the stable/neon branch. Current status: our code freezes, and recently we are fixing the build failure like missing dependency, but not yet solve completely, may need help.

Best regards,
Christine

From: release-bounces@... [mailto:release-bounces@...] On Behalf Of Luis Gomez
Sent: Saturday, February 09, 2019 7:33 AM
To: transportpce-dev@...; jsonrpc-dev@...
Cc: tsc; Release
Subject: Re: [release] SM projects status

OK, thanks for responding.

For those releasing in Neon, I would recommend to perform the stable/neon branch cut + master version bump ASAP so that your branches aligns in Jenkins, e.g. if you have not done this step yet, you will see sodium job building neon code and neon job failing.

You are welcome to open a ticket to helpdesk if you are unsure how to do this.

BR/Luis



On Feb 8, 2019, at 1:28 AM, Richard Kosegi <richard.kosegi@...> wrote:

+jsonrpc-dev

Hi Luis,

thank you for notice.
Jsonrpc would like to be part of both Fluorine-SR2 and Neon.

Regards,
Richard.

On Fri, Feb 8, 2019 at 12:36 AM Luis Gomez <ecelgp@...> wrote:
This mail is to all committers of the Self-Managed projects in OpenDaylight:

Can you please respond to this mail if you have any plan to release your project in Fluorine SR2 (mail just sent) or Neon (next coming release).

BR/Luis

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



--
本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。 This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient.

-----Original Message-----
From: release-bounces@... [mailto:release-
bounces@...] On Behalf Of Luis Gomez
Sent: vendredi 15 février 2019 19:23
To: <ylhsieh@...>
Cc: tsc@...; release@...
Subject: Re: [release] SM projects status

SM projects are free to join any release as long as they provide a release
artifact in the week after the managed projects release (~2 weeks from now).

Current status of SM projects that we are aware of:

JSON-RPC:

- stable/neon branch: YES
- stable/neon build: YES
- in distribution: YES

SNMP4SDN:

- stable/neon branch: YES
- stable/neon build: NO
- in distribution: NO

Telemetry:

- stable/neon branch: YES
- stable/neon build: YES
- in distribution: YES

TransportPCE:

- stable/neon branch: NO
- stable/neon build: NO
- in distribution: NO

Also for those having issues building code make sure you are aware of the
following versions and changes:

https://docs.opendaylight.org/projects/integration-
distribution/en/latest/platform-versions.html
https://wiki.opendaylight.org/view/Neon_platform_upgrade

BR/Luis

On Feb 14, 2019, at 10:28 PM, <ylhsieh@...> <ylhsieh@...>

wrote:

Hi,

Hope it’s not too late to respond. SNMP4SDN would like to be part of Neon,

and already have the stable/neon branch. Current status: our code freezes,
and recently we are fixing the build failure like missing dependency, but not
yet solve completely, may need help.

Best regards,
Christine

From: release-bounces@... [mailto:release-

bounces@...] On Behalf Of Luis Gomez

Sent: Saturday, February 09, 2019 7:33 AM
To: transportpce-dev@...; jsonrpc-

dev@...

Cc: tsc; Release
Subject: Re: [release] SM projects status

OK, thanks for responding.

For those releasing in Neon, I would recommend to perform the

stable/neon branch cut + master version bump ASAP so that your branches
aligns in Jenkins, e.g. if you have not done this step yet, you will see sodium
job building neon code and neon job failing.

You are welcome to open a ticket to helpdesk if you are unsure how to do

this.

BR/Luis



On Feb 8, 2019, at 1:28 AM, Richard Kosegi <richard.kosegi@...>

wrote:

+jsonrpc-dev

Hi Luis,

thank you for notice.
Jsonrpc would like to be part of both Fluorine-SR2 and Neon.

Regards,
Richard.

On Fri, Feb 8, 2019 at 12:36 AM Luis Gomez <ecelgp@...> wrote:
This mail is to all committers of the Self-Managed projects in OpenDaylight:

Can you please respond to this mail if you have any plan to release your

project in Fluorine SR2 (mail just sent) or Neon (next coming release).

BR/Luis

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



--
本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭

露本信件內容，並請銷毀此信件。 This email may contain confidential
information. Please do not use or disclose it in any way and delete it if you are
not the intended recipient.

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

On Feb 19, 2019, at 7:38 AM, <guillaume.lambert@...> <guillaume.lambert@...> wrote:

Thanks for the answer.
If so, on which non-SNAPSHOT versions am I supposed to depend on ? Is 1.2.6 okay ?

Cf previous thread at https://lists.opendaylight.org/pipermail/tsc/2019-January/010942.html

I didn’t have any clue on either
https://docs.opendaylight.org/projects/integration-distribution/en/latest/platform-versions.html
or
https://wiki.opendaylight.org/view/Neon_platform_upgrade#MD-SAL_Impacts



From: Tom Pantelis [mailto:tompantelis@...]
Sent: mardi 19 février 2019 15:37
To: LAMBERT Guillaume TGI/OLN
Cc: Luis Gomez; <ylhsieh@...>; tsc@...; release@...
Subject: Re: [release] SM projects status



On Tue, Feb 19, 2019 at 5:16 AM <guillaume.lambert@...> wrote:
Hi all

Luis, I created a TransportPCE stable/neon branch yesterday with a config that was working last week..
But I got a Jenkins build failure because of obsolete poms. It appears that Mdsal binding models 1.2.6-SNAPSHOT were removed yesterday and replaced by 1.2.7-SNAPSHOT ones.

The mdsal ;project is release integrated (or whatever the official term is) so you're not supposed to depend on snapshot versions.


I fixed the poms in this change https://git.opendaylight.org/gerrit/#/c/80373/ but the branch was locked... I believe this is an error since branch locks should probably not apply to SM projects.
So I had no other choices than to delete the branch and recreate it from master to have a working pom configuration.
Now the stable/neon branch builds.
However, I believe the netconf REST API has evolved and this causes many functional tests unexpected failures. We are investigating that.
https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/transportpce-tox-verify-neon/95/tox/py27/
(to compare with before Neon bump https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/transportpce-tox-verify-sodium/5/tox/py27/ )

Best regards
Guillaume


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

-----Original Message-----
From: Luis Gomez [mailto:ecelgp@...]
Sent: mardi 19 février 2019 18:20
To: LAMBERT Guillaume TGI/OLN
Cc: Tom Pantelis; <ylhsieh@...>; tsc@...;
release@...
Subject: Re: [release] SM projects status

Hi Guillome,

If you see the link: https://docs.opendaylight.org/projects/integration-
distribution/en/latest/platform-versions.html, you will see mdsal version for
Neon is 3.0.6.

On Feb 19, 2019, at 7:38 AM, <guillaume.lambert@...>

<guillaume.lambert@...> wrote:

Thanks for the answer.
If so, on which non-SNAPSHOT versions am I supposed to depend on ? Is

1.2.6 okay ?

Cf previous thread at https://lists.opendaylight.org/pipermail/tsc/2019-

January/010942.html

I didn’t have any clue on either
https://docs.opendaylight.org/projects/integration-

distribution/en/latest/platform-versions.html

or
https://wiki.opendaylight.org/view/Neon_platform_upgrade#MD-

SAL_Impacts

From: Tom Pantelis [mailto:tompantelis@...]
Sent: mardi 19 février 2019 15:37
To: LAMBERT Guillaume TGI/OLN
Cc: Luis Gomez; <ylhsieh@...>; tsc@...;

release@...

Subject: Re: [release] SM projects status



On Tue, Feb 19, 2019 at 5:16 AM <guillaume.lambert@...> wrote:
Hi all

Luis, I created a TransportPCE stable/neon branch yesterday with a config

that was working last week..

But I got a Jenkins build failure because of obsolete poms. It appears that

Mdsal binding models 1.2.6-SNAPSHOT were removed yesterday and
replaced by 1.2.7-SNAPSHOT ones.

The mdsal ;project is release integrated (or whatever the official term is) so

you're not supposed to depend on snapshot versions.

I fixed the poms in this change

https://git.opendaylight.org/gerrit/#/c/80373/ but the branch was locked... I
believe this is an error since branch locks should probably not apply to SM
projects.

So I had no other choices than to delete the branch and recreate it from

master to have a working pom configuration.

Now the stable/neon branch builds.
However, I believe the netconf REST API has evolved and this causes many

functional tests unexpected failures. We are investigating that.

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/transportpce-

tox-verify-neon/95/tox/py27/

(to compare with before Neon bump

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/transportpce-tox-
verify-sodium/5/tox/py27/ )

Best regards
Guillaume

___________________________________________________________
___________________________________________________________
___

Ce message et ses pieces jointes peuvent contenir des informations

confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce

message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages

electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou

falsifie. Merci.

This message and its attachments may contain confidential or privileged

information that may be protected by law;

they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete

this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been

modified, changed or falsified.

Thank you.

On Feb 20, 2019, at 3:32 AM, <guillaume.lambert@...> <guillaume.lambert@...> wrote:

I guess we have here a confusion between mdsal binding-parent and mdsal binding.model.
My point was that they use different revisions and that binding.model versions are not documented anywhere, nor the documentation nor the wiki.

But fair enough, what I understand from your answers is that mdsal binding.model version should be aligned with mdsal binding-parent version 3.0.6 since mdsal is now released.
I found confirmation on nexus that version 1.2.7-SNAPSHOT is not aligned with binding-parent 3.0.6 but 3.0.7-SNAPSHOT probably to prepare Neon SR1.
According to nexus, mdsal binding.model version 1.2.6 is OK
https://nexus.opendaylight.org/service/local/repositories/opendaylight.release/content/org/opendaylight/mdsal/binding/model/ietf/rfc6991-ietf-yang-types/1.2.6/rfc6991-ietf-yang-types-1.2.6.pom
Same things for ietf-access-control-list 0.13.6 and iana-if-type 1.0.6.
So it is now fixed in change 80409. https://git.opendaylight.org/gerrit/#/c/80409/

Thank you both for your feedbacks.

BR
Guillaume

PS: About the branch locking, I see there is another thread started with SNMP4SDN so I will joint it.

-----Original Message-----
From: Luis Gomez [mailto:ecelgp@...]
Sent: mardi 19 février 2019 18:20
To: LAMBERT Guillaume TGI/OLN
Cc: Tom Pantelis; <ylhsieh@...>; tsc@...;
release@...
Subject: Re: [release] SM projects status

Hi Guillome,

If you see the link: https://docs.opendaylight.org/projects/integration-
distribution/en/latest/platform-versions.html, you will see mdsal version for
Neon is 3.0.6.

On Feb 19, 2019, at 7:38 AM, <guillaume.lambert@...>

<guillaume.lambert@...> wrote:

Thanks for the answer.
If so, on which non-SNAPSHOT versions am I supposed to depend on ? Is

1.2.6 okay ?

Cf previous thread at https://lists.opendaylight.org/pipermail/tsc/2019-

January/010942.html

I didn’t have any clue on either
https://docs.opendaylight.org/projects/integration-

distribution/en/latest/platform-versions.html

or
https://wiki.opendaylight.org/view/Neon_platform_upgrade#MD-

SAL_Impacts

From: Tom Pantelis [mailto:tompantelis@...]
Sent: mardi 19 février 2019 15:37
To: LAMBERT Guillaume TGI/OLN
Cc: Luis Gomez; <ylhsieh@...>; tsc@...;

release@...

Subject: Re: [release] SM projects status



On Tue, Feb 19, 2019 at 5:16 AM <guillaume.lambert@...> wrote:
Hi all

Luis, I created a TransportPCE stable/neon branch yesterday with a config

that was working last week..

But I got a Jenkins build failure because of obsolete poms. It appears that

Mdsal binding models 1.2.6-SNAPSHOT were removed yesterday and
replaced by 1.2.7-SNAPSHOT ones.

The mdsal ;project is release integrated (or whatever the official term is) so

you're not supposed to depend on snapshot versions.

I fixed the poms in this change

https://git.opendaylight.org/gerrit/#/c/80373/ but the branch was locked... I
believe this is an error since branch locks should probably not apply to SM
projects.

So I had no other choices than to delete the branch and recreate it from

master to have a working pom configuration.

Now the stable/neon branch builds.
However, I believe the netconf REST API has evolved and this causes many

functional tests unexpected failures. We are investigating that.

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/transportpce-

tox-verify-neon/95/tox/py27/

(to compare with before Neon bump

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/transportpce-tox-
verify-sodium/5/tox/py27/ )

Best regards
Guillaume

___________________________________________________________
___________________________________________________________
___

Ce message et ses pieces jointes peuvent contenir des informations

confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce

message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages

electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou

falsifie. Merci.

This message and its attachments may contain confidential or privileged

information that may be protected by law;

they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete

this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been

modified, changed or falsified.

Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

-----Original Message-----
From: Luis Gomez [mailto:ecelgp@...]
Sent: mercredi 20 février 2019 20:34
To: LAMBERT Guillaume TGI/OLN
Cc: Tom Pantelis; <ylhsieh@...>; tsc@...;
release@...
Subject: Re: [release] SM projects status

Just on note: if your pom.xml file has the mdsal binding-parent as parent, you
do not need to declare individual mdsal artifacts version as these get
automatically resolved via maven transitive dependency.

On Feb 20, 2019, at 3:32 AM, <guillaume.lambert@...>

<guillaume.lambert@...> wrote:

I guess we have here a confusion between mdsal binding-parent and mdsal

binding.model.

My point was that they use different revisions and that binding.model

versions are not documented anywhere, nor the documentation nor the wiki.

But fair enough, what I understand from your answers is that mdsal

binding.model version should be aligned with mdsal binding-parent version
3.0.6 since mdsal is now released.

I found confirmation on nexus that version 1.2.7-SNAPSHOT is not aligned

with binding-parent 3.0.6 but 3.0.7-SNAPSHOT probably to prepare Neon SR1.

According to nexus, mdsal binding.model version 1.2.6 is OK

https://nexus.opendaylight.org/service/local/repositories/opendaylight.relea
se/content/org/opendaylight/mdsal/binding/model/ietf/rfc6991-ietf-yang-
types/1.2.6/rfc6991-ietf-yang-types-1.2.6.pom

Same things for ietf-access-control-list 0.13.6 and iana-if-type 1.0.6.
So it is now fixed in change 80409.

https://git.opendaylight.org/gerrit/#/c/80409/

Thank you both for your feedbacks.

BR
Guillaume

PS: About the branch locking, I see there is another thread started with

SNMP4SDN so I will joint it.

-----Original Message-----
From: Luis Gomez [mailto:ecelgp@...]
Sent: mardi 19 février 2019 18:20
To: LAMBERT Guillaume TGI/OLN
Cc: Tom Pantelis; <ylhsieh@...>; tsc@...;
release@...
Subject: Re: [release] SM projects status

Hi Guillome,

If you see the link: https://docs.opendaylight.org/projects/integration-
distribution/en/latest/platform-versions.html, you will see mdsal version

for

Neon is 3.0.6.

On Feb 19, 2019, at 7:38 AM, <guillaume.lambert@...>

<guillaume.lambert@...> wrote:

Thanks for the answer.
If so, on which non-SNAPSHOT versions am I supposed to depend on ? Is

1.2.6 okay ?

Cf previous thread at https://lists.opendaylight.org/pipermail/tsc/2019-

January/010942.html

I didn’t have any clue on either
https://docs.opendaylight.org/projects/integration-

distribution/en/latest/platform-versions.html

or
https://wiki.opendaylight.org/view/Neon_platform_upgrade#MD-

SAL_Impacts

From: Tom Pantelis [mailto:tompantelis@...]
Sent: mardi 19 février 2019 15:37
To: LAMBERT Guillaume TGI/OLN
Cc: Luis Gomez; <ylhsieh@...>; tsc@...;

release@...

Subject: Re: [release] SM projects status



On Tue, Feb 19, 2019 at 5:16 AM <guillaume.lambert@...>

wrote:

Hi all

Luis, I created a TransportPCE stable/neon branch yesterday with a config

that was working last week..

But I got a Jenkins build failure because of obsolete poms. It appears that

Mdsal binding models 1.2.6-SNAPSHOT were removed yesterday and
replaced by 1.2.7-SNAPSHOT ones.

The mdsal ;project is release integrated (or whatever the official term is)

so

you're not supposed to depend on snapshot versions.

I fixed the poms in this change

https://git.opendaylight.org/gerrit/#/c/80373/ but the branch was

locked... I

believe this is an error since branch locks should probably not apply to SM
projects.

So I had no other choices than to delete the branch and recreate it from

master to have a working pom configuration.

Now the stable/neon branch builds.
However, I believe the netconf REST API has evolved and this causes

many

functional tests unexpected failures. We are investigating that.

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-

1/transportpce-

tox-verify-neon/95/tox/py27/

(to compare with before Neon bump

https://logs.opendaylight.org/releng/vex-yul-odl-jenkins-1/transportpce-

tox-

verify-sodium/5/tox/py27/ )

Best regards
Guillaume

___________________________________________________________

___________________________________________________________

___

Ce message et ses pieces jointes peuvent contenir des informations

confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu

ce

message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages

electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme

ou

falsifie. Merci.

This message and its attachments may contain confidential or privileged

information that may be protected by law;

they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and

delete

this message and its attachments.

As emails may be altered, Orange is not liable for messages that have

been

modified, changed or falsified.

Thank you.

___________________________________________________________
___________________________________________________________
___

Ce message et ses pieces jointes peuvent contenir des informations

confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce

message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages

electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou

falsifie. Merci.

This message and its attachments may contain confidential or privileged

information that may be protected by law;

they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete

this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been

modified, changed or falsified.

Thank you.