_________________________________________________________________________________________________________________________

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 19/10/2020 15:34, guillaume.lambert@... wrote:

Hi all

Hello,

We started an interesting discussion during our DDF last week with Robert who proposed to keep on talking by email.

Sorry this was stuck way down on the to-reply list.

Here is a quick sum-up.
During the release cycle, old –SNAPSHOT dependencies are regularly deleted from Nexus.
And they might be replaced by new ones with a bug that prevent from keeping on developing a new feature.
( For example YANG deviations not well supported in Netconf https://jira.opendaylight.org/browse/NETCONF-637 <https://jira.opendaylight.org/browse/NETCONF-637>)
The question is “how in that case keep on working on the new features development and parallel with the integration of new dependencies?”
There might be possibilities to use stable dependencies version in Jenkins by keeping on using –SNAPSHOT dependencies in the master branch.
Or should we wait for the dependencies bugs to be fixed ?

This is one of the reasons to not work on snapshots, but releases. So for normal operations, just use everything released -- transportpce can certainly do that today.

Now, receiving a fix, that should be possible if upstream codebase has not divereged much (usually does not) by:
- checkout upstream project's tag you have integrated (i.e. git checkout v2.0.5 for current netconf)
- cherry-pick required fixes
- rebuild changed artifacts

Your local maven repo now has the fixes working in those versions. Might not be the prettiest, but works.

Now the second thing is -- we want to have project releases done periodically. My running average is a release every ~3 weeks, but we can do much better.

I really want to see automatically-working as-needed daily releases, but that is a long journey -- the MRI testing rework being the prerequisite (releases must be gated and for that CSIT must be stable). Then we'll get into properly managing repository releases and propagating version bump patches, etc.

Regards,
Robert

Hello

Thanks for your feedback Robert.
You're apologized for the late reply. My mailbox is also pretty full.

I agree with you. Release should be preferred to SNAPSHOT.
There is a lot of things that evolved since then and TPCE can certainly do that now.
It is much more easier. Just to mention it, having Netconf in MRI helped us a lot.
Thanks again to you and the netconf team for this hard work.
We should probably advertize that to ONAP people who bumped into similar issues.
They might be interested in using a closer version of Opendaylight.

Yes local maven repo is not so pretty but usually works.
Rebuilding jars takes times on bigger projects and is a bit hard for maven beginners.
Though, it is not always feasible just after a release bump.

Daily builds would be the holy grail but 3 weeks average is already a good start.
If we can live with that today, it can be certainly improved.


Best Regards
Guillaume

________________________________________
De : Robert Varga [nite@...]
Envoyé : dimanche 3 octobre 2021 16:59
À : LAMBERT Guillaume INNOV/NET; Discuss+help@...; Discuss@...
Objet : Re: working simultaneously on new features and with upstream dependencies bug fixes

On 19/10/2020 15:34, guillaume.lambert@... wrote:

Hi all

Hello,

We started an interesting discussion during our DDF last week with
Robert who proposed to keep on talking by email.

Sorry this was stuck way down on the to-reply list.

Here is a quick sum-up.

During the release cycle, old –SNAPSHOT dependencies are regularly
deleted from Nexus.

And they might be replaced by new ones with a bug that prevent from
keeping on developing a new feature.

( For example YANG deviations not well supported in Netconf
https://jira.opendaylight.org/browse/NETCONF-637
<https://jira.opendaylight.org/browse/NETCONF-637>)

The question is “how in that case keep on working on the new features
development and parallel with the integration of new dependencies?”

There might be possibilities to use stable dependencies version in
Jenkins by keeping on using –SNAPSHOT dependencies in the master branch.

Or should we wait for the dependencies bugs to be fixed ?

This is one of the reasons to not work on snapshots, but releases. So
for normal operations, just use everything released -- transportpce can
certainly do that today.

Now, receiving a fix, that should be possible if upstream codebase has
not divereged much (usually does not) by:
- checkout upstream project's tag you have integrated (i.e. git checkout
v2.0.5 for current netconf)
- cherry-pick required fixes
- rebuild changed artifacts

Your local maven repo now has the fixes working in those versions. Might
not be the prettiest, but works.

Now the second thing is -- we want to have project releases done
periodically. My running average is a release every ~3 weeks, but we can
do much better.

I really want to see automatically-working as-needed daily releases, but
that is a long journey -- the MRI testing rework being the prerequisite
(releases must be gated and for that CSIT must be stable). Then we'll
get into properly managing repository releases and propagating version
bump patches, etc.

Regards,
Robert

_________________________________________________________________________________________________________________________

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 06/10/2021 16:39, guillaume.lambert@... wrote:

Hello

Hello again,

Thanks for your feedback Robert.
You're apologized for the late reply. My mailbox is also pretty full.
I agree with you. Release should be preferred to SNAPSHOT.
There is a lot of things that evolved since then and TPCE can certainly do that now.
It is much more easier. Just to mention it, having Netconf in MRI helped us a lot.
Thanks again to you and the netconf team for this hard work.
We should probably advertize that to ONAP people who bumped into similar issues.
They might be interested in using a closer version of Opendaylight.

Right, although I do not know how it aligns with their plans :)

My take on that is that the onap distro thing we build in int/dist needs to be rehosted into ccsdk (or wherever). Unfortunately they do not trust our SRs and as I understand it they are not quite there in terms of what they'll need to do for closer tracking.

I hope to get that conversation started, but it looks as though that's going to be a 2022 thing.

Yes local maven repo is not so pretty but usually works.
Rebuilding jars takes times on bigger projects and is a bit hard for maven beginners.
Though, it is not always feasible just after a release bump.
Daily builds would be the holy grail but 3 weeks average is already a good start.
If we can live with that today, it can be certainly improved.

It is a start, but is a ton of error-prone, repetitive manual work. Next step is to get the automation in place and once we have it, we'll see if we can crank it up to 11.

Regards,
Robert