Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][euphrates] stable branch window

[David McBride]

Alec,

I saw from Fatih's presentation this morning in the TSC meeting that you
are taking on the task of proposing a new versioning scheme to accommodate
XCI.  Thanks for agreeing to do that.  I look forward to seeing your
proposal.

David

On Fri, Sep 15, 2017 at 12:43 PM, Alec Hothan (ahothan) 
wrote:

>
>
> David,
>
>
>
> I have synced with Fatih already and I will do my best to help on the CD
> front (time permitting).
>
> Note that my primary involvement in OPNFV is not versioning but since my
> project NFVbench is coming from a CD environment I might as well contribute
> there to make sure I’m not getting into trouble ;-)
>
> I will keep Frank in the loop of course.
>
>
>
> Thanks for writing that wiki page.
>
>
>
> Regards,
>
>
>
>Alec
>
>
>
>
>
>
>
>
>
> *From: *David McBride 
> *Date: *Friday, September 15, 2017 at 12:04 PM
> *To: *"Alec Hothan (ahothan)" 
> *Cc: *TECH-DISCUSS OPNFV ,
> opnfv-project-leads , Aric Gardner <
> agard...@linuxfoundation.org>, Raymond Paik ,
> Trevor Bramwell , Tapio Tallgren <
> tapio.tallg...@nokia.com>
>
> *Subject: *Re: [opnfv-project-leads] [release][euphrates] stable branch
> window
>
>
>
> Hi Alec,
>
>
>
> I really appreciate your interest in and knowledge of configuration
> management and versioning.  This is an important topic that doesn't get
> enough attention, IMHO.  I don't mind your questions at all.
>
>
>
> Yes, you are correct about the branch name.  The change in versioning has
> not affected the branch naming.  As you said, the the branch will be
> "stable/euphrates".  My apologies for not being clear about that.
>
>
>
> As far as your proposal is concerned, here are a couple of suggestions:
>
> · Please make sure that you coordinate with Fatih, since he is
> working on a new proposal for versioning that will take into consideration
> XCI.  I don't think it would be productive for both of you to be working on
> separate versioning proposals in isolation.
>
> · Also, if you haven't already, make sure that you involve your
> Cisco TSC representative, Frank Brockners.  Frank is very familiar with TSC
> policies and procedures and can advise you on preparing an effective
> presentation and getting it on the agenda.
>
> David
>
>
>
> On Fri, Sep 15, 2017 at 11:41 AM, Alec Hothan (ahothan) 
> wrote:
>
> David,
>
>
>
> That might look obvious but perhaps you could confirm the exact branch
> name moving forward (or perhaps this has not changed).
>
> From the look of existing branches, looks like it will be
>
> “stable/euphrates”
>
>
>
> I assume projects can/will commit stuff on that branch until some code
> freeze milestone? Could you point to the remaining limestone agenda for
> euphrates?
>
>
>
> And I assume there will be at some point tags to point to subrelease (5.0,
> 5.1…) on that branch?
>
> When will these tags be created and what format will they have?
>
> I’m trying to get a proposal out for tagging/CD and would like to avoid
> OPNFV release tags with “5.0.0” format if possible (will explain why in my
> proposal).
>
>
>
> Sorry if I ask many questions,
>
>
>
> Thanks
>
>
>
>   Alec
>
>
>
>
>
>
>
>
>
>
>
> *From: * on behalf of David
> McBride 
> *Date: *Friday, September 15, 2017 at 11:26 AM
> *To: *TECH-DISCUSS OPNFV ,
> opnfv-project-leads 
> *Cc: *Aric Gardner , Raymond Paik <
> rp...@linuxfoundation.org>, Trevor Bramwell ,
> Tapio Tallgren 
> *Subject: *Re: [opnfv-project-leads] [release][euphrates] stable branch
> window
>
>
>
> Reminder...
>
>
>
> In a few minutes, Aric will begin generating branches for projects that
> have not yet been branched.
>
>
>
> Exceptions:
>
> · RelEng
>
> · Projects that did not participate in the release
>
> · Projects that withdrew from the release
>
> List:
>
> 1.   Apex
>
> 2.   Armband
>
> 3.   Bamboo
>
> 4.   Barometer
>
> 5.   Bottlenecks
>
> 6.   Calipso
>
> 7.   Compass4nfv
>
> 8.   Daisy4NFV
>
> 9.   Doctor
>
> 10.   Domino
>
> 11.   FastDataStacks
>
> 12.   Fuel@OPNFV
>
> 13.   FUNCTEST
>
> 14.   High availability (HA)
>
> 15.   IPv6
>
> 16.   JOID
>
> 17.   KVMforNFV
>
> 18.   Moon
>
> 19.   NFVBench
>
> 20.   Octopus
>
> 21.   OpenRetriever
>
> 22.   OPNFVDOCS
>
> 23.   OVNO
>
> 24.   Orchestra
>
> 25.   OVN4NFV
>
> 26.   Parser
>
> 27.   Pharos
>
> 28.   Promise
>
> 29.   QTIP
>
> 30.   SampleVNF
>
> 31.   SDNVPN
>
> 32.   SFC
>
> 33.   StorPerf
>
> 34.   VSPerf
>
> 35.   Yardstick
>
>
>
> On Fri, Sep 8, 2017 at 4:24 PM, David McBride <
> dmcbr...@linuxfoundation.org> wrote:

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][euphrates] stable branch window

[David McBride]

Thanks, Alec.  As I'm sure you're aware, participation in an open source
project often involves contributing in diverse and unexpected ways.  We
appreciate your interest and willingness in working with Fatih to develop a
new versioning proposal.

David

On Fri, Sep 15, 2017 at 12:43 PM, Alec Hothan (ahothan) 
wrote:

>
>
> David,
>
>
>
> I have synced with Fatih already and I will do my best to help on the CD
> front (time permitting).
>
> Note that my primary involvement in OPNFV is not versioning but since my
> project NFVbench is coming from a CD environment I might as well contribute
> there to make sure I’m not getting into trouble ;-)
>
> I will keep Frank in the loop of course.
>
>
>
> Thanks for writing that wiki page.
>
>
>
> Regards,
>
>
>
>Alec
>
>
>
>
>
>
>
>
>
> *From: *David McBride 
> *Date: *Friday, September 15, 2017 at 12:04 PM
> *To: *"Alec Hothan (ahothan)" 
> *Cc: *TECH-DISCUSS OPNFV ,
> opnfv-project-leads , Aric Gardner <
> agard...@linuxfoundation.org>, Raymond Paik ,
> Trevor Bramwell , Tapio Tallgren <
> tapio.tallg...@nokia.com>
>
> *Subject: *Re: [opnfv-project-leads] [release][euphrates] stable branch
> window
>
>
>
> Hi Alec,
>
>
>
> I really appreciate your interest in and knowledge of configuration
> management and versioning.  This is an important topic that doesn't get
> enough attention, IMHO.  I don't mind your questions at all.
>
>
>
> Yes, you are correct about the branch name.  The change in versioning has
> not affected the branch naming.  As you said, the the branch will be
> "stable/euphrates".  My apologies for not being clear about that.
>
>
>
> As far as your proposal is concerned, here are a couple of suggestions:
>
> · Please make sure that you coordinate with Fatih, since he is
> working on a new proposal for versioning that will take into consideration
> XCI.  I don't think it would be productive for both of you to be working on
> separate versioning proposals in isolation.
>
> · Also, if you haven't already, make sure that you involve your
> Cisco TSC representative, Frank Brockners.  Frank is very familiar with TSC
> policies and procedures and can advise you on preparing an effective
> presentation and getting it on the agenda.
>
> David
>
>
>
> On Fri, Sep 15, 2017 at 11:41 AM, Alec Hothan (ahothan) 
> wrote:
>
> David,
>
>
>
> That might look obvious but perhaps you could confirm the exact branch
> name moving forward (or perhaps this has not changed).
>
> From the look of existing branches, looks like it will be
>
> “stable/euphrates”
>
>
>
> I assume projects can/will commit stuff on that branch until some code
> freeze milestone? Could you point to the remaining limestone agenda for
> euphrates?
>
>
>
> And I assume there will be at some point tags to point to subrelease (5.0,
> 5.1…) on that branch?
>
> When will these tags be created and what format will they have?
>
> I’m trying to get a proposal out for tagging/CD and would like to avoid
> OPNFV release tags with “5.0.0” format if possible (will explain why in my
> proposal).
>
>
>
> Sorry if I ask many questions,
>
>
>
> Thanks
>
>
>
>   Alec
>
>
>
>
>
>
>
>
>
>
>
> *From: * on behalf of David
> McBride 
> *Date: *Friday, September 15, 2017 at 11:26 AM
> *To: *TECH-DISCUSS OPNFV ,
> opnfv-project-leads 
> *Cc: *Aric Gardner , Raymond Paik <
> rp...@linuxfoundation.org>, Trevor Bramwell ,
> Tapio Tallgren 
> *Subject: *Re: [opnfv-project-leads] [release][euphrates] stable branch
> window
>
>
>
> Reminder...
>
>
>
> In a few minutes, Aric will begin generating branches for projects that
> have not yet been branched.
>
>
>
> Exceptions:
>
> · RelEng
>
> · Projects that did not participate in the release
>
> · Projects that withdrew from the release
>
> List:
>
> 1.   Apex
>
> 2.   Armband
>
> 3.   Bamboo
>
> 4.   Barometer
>
> 5.   Bottlenecks
>
> 6.   Calipso
>
> 7.   Compass4nfv
>
> 8.   Daisy4NFV
>
> 9.   Doctor
>
> 10.   Domino
>
> 11.   FastDataStacks
>
> 12.   Fuel@OPNFV
>
> 13.   FUNCTEST
>
> 14.   High availability (HA)
>
> 15.   IPv6
>
> 16.   JOID
>
> 17.   KVMforNFV
>
> 18.   Moon
>
> 19.   NFVBench
>
> 20.   Octopus
>
> 21.   OpenRetriever
>
> 22.   OPNFVDOCS
>
> 23.   OVNO
>
> 24.   Orchestra
>
> 25.   OVN4NFV
>
> 26.   Parser
>
> 27.   Pharos
>
> 28.   Promise
>
> 29.   QTIP
>
> 30.   SampleVNF
>
> 31.   SDNVPN
>
> 32.   SFC
>
> 33.   StorPerf
>
> 34.   VSPerf
>
> 35.   Yardstick
>
>
>
> On Fri, Sep 8, 2017 at 4:24 PM, David McBride <
> 

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][euphrates] stable branch window

[David McBride]

That is, unfortunately, not correct.  I copied and pasted the directions
from danube and forgot to remove the "euphrates" prefix.  I will update it.

David

On Fri, Sep 15, 2017 at 12:03 PM, Beierl, Mark  wrote:

> Hello, Alec.
>
> The process for the euphrates.1.0, 2.0 etc is documented here:
> https://wiki.opnfv.org/display/SWREL/Git+Tagging+
> Instructions+for+Euphrates
>
> The stable branch essentially means that no code review can be directly
> submitted against stable/euphrates.  Essentially all bug fixes and changes
> should go to master and then get independently cherry pick git Gerrit to
> the stable/euphrates branch.
>
> Once you are happy with the state of your stable branch, the tagging
> instructions are followed.  This ultimately boils down to this one step:
>
> git tag -am "euphrates.5.0" euphrates.5.0
> git push origin euphrates.5.0
>
> Once that is done, the tag is publicly visible and whatever build
> procedure you require for publishing (i.e. docker container, VM, ISO,
> RPM...) can be executed through Jenkins using that tag.
>
> David, others, please correct if I have stated something incorrectly.
>
> Regards,
> Mark
>
> *Mark Beierl*
> SW System Sr Principal Engineer
> *Dell **EMC* | Office of the CTO
> mobile +1 613 314 8106 <1-613-314-8106>
> mark.bei...@dell.com
>
> On Sep 15, 2017, at 14:41, Alec Hothan (ahothan) 
> wrote:
>
> David,
>
> That might look obvious but perhaps you could confirm the exact branch
> name moving forward (or perhaps this has not changed).
> From the look of existing branches, looks like it will be
> “stable/euphrates”
>
> I assume projects can/will commit stuff on that branch until some code
> freeze milestone? Could you point to the remaining limestone agenda for
> euphrates?
>
> And I assume there will be at some point tags to point to subrelease (5.0,
> 5.1…) on that branch?
> When will these tags be created and what format will they have?
> I’m trying to get a proposal out for tagging/CD and would like to avoid
> OPNFV release tags with “5.0.0” format if possible (will explain why in my
> proposal).
>
> Sorry if I ask many questions,
>
> Thanks
>
>   Alec
>
>
>
>
>
> *From: * on behalf of David
> McBride 
> *Date: *Friday, September 15, 2017 at 11:26 AM
> *To: *TECH-DISCUSS OPNFV ,
> opnfv-project-leads 
> *Cc: *Aric Gardner , Raymond Paik <
> rp...@linuxfoundation.org>, Trevor Bramwell ,
> Tapio Tallgren 
> *Subject: *Re: [opnfv-project-leads] [release][euphrates] stable branch
> window
>
> Reminder...
>
> In a few minutes, Aric will begin generating branches for projects that
> have not yet been branched.
>
> Exceptions:
> · RelEng
> · Projects that did not participate in the release
> · Projects that withdrew from the release
> List:
> 1.   Apex
> 2.   Armband
> 3.   Bamboo
> 4.   Barometer
> 5.   Bottlenecks
> 6.   Calipso
> 7.   Compass4nfv
> 8.   Daisy4NFV
> 9.   Doctor
> 10.   Domino
> 11.   FastDataStacks
> 12.   Fuel@OPNFV
> 13.   FUNCTEST
> 14.   High availability (HA)
> 15.   IPv6
> 16.   JOID
> 17.   KVMforNFV
> 18.   Moon
> 19.   NFVBench
> 20.   Octopus
> 21.   OpenRetriever
> 22.   OPNFVDOCS
> 23.   OVNO
> 24.   Orchestra
> 25.   OVN4NFV
> 26.   Parser
> 27.   Pharos
> 28.   Promise
> 29.   QTIP
> 30.   SampleVNF
> 31.   SDNVPN
> 32.   SFC
> 33.   StorPerf
> 34.   VSPerf
> 35.   Yardstick
>
> On Fri, Sep 8, 2017 at 4:24 PM, David McBride <
> dmcbr...@linuxfoundation.org> wrote:
>
> Reminder...
>
> The stable branch window closes as of MS7, one week from today, on
> September 15 at 12 p.m. (PT). PTLs - please contact Aric as soon as you're
> ready to branch.  Aric will branch any projects that have not already been
> branched on Sept 15.
>
> Let me know if you have any questions.
>
> David
>
> On Tue, Aug 29, 2017 at 3:23 PM, David McBride <
> dmcbr...@linuxfoundation.org> wrote:
>
> Team,
>
> As you know, MS6 was this past Friday, Aug 25.  In addition to the
> requirements associated with MS6, this milestone also marks the opening of
> the stable branch window, which subsequently ends with MS7 on Sept 15.
>
> This means that PTLs may request to branch their project any time before
> Sept 15.  Note that I erroneously told the release meeting this morning
> that PTLs may create their own branch.  That's not the case.  Instead,
> please contact Aric (copied) and request that he create the branch for you.
>
> Also, as a reminder, we have changed the version number format as of the
> Euphrates release.
> · 5.0.0 - Euphrates initial release version
> · 5.1.0 - Euphrates SR1
> · 5.2.0 - Euphrates SR2
> Let me know if you have any questions.
>
> David
>
> --
> *David McBride*
> Release 

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][euphrates] stable branch window

[Alec Hothan (ahothan)]

David,

I have synced with Fatih already and I will do my best to help on the CD front 
(time permitting).
Note that my primary involvement in OPNFV is not versioning but since my 
project NFVbench is coming from a CD environment I might as well contribute 
there to make sure I’m not getting into trouble ;-)
I will keep Frank in the loop of course.

Thanks for writing that wiki page.

Regards,

   Alec




From: David McBride 
Date: Friday, September 15, 2017 at 12:04 PM
To: "Alec Hothan (ahothan)" 
Cc: TECH-DISCUSS OPNFV , 
opnfv-project-leads , Aric Gardner 
, Raymond Paik , 
Trevor Bramwell , Tapio Tallgren 

Subject: Re: [opnfv-project-leads] [release][euphrates] stable branch window

Hi Alec,

I really appreciate your interest in and knowledge of configuration management 
and versioning.  This is an important topic that doesn't get enough attention, 
IMHO.  I don't mind your questions at all.

Yes, you are correct about the branch name.  The change in versioning has not 
affected the branch naming.  As you said, the the branch will be 
"stable/euphrates".  My apologies for not being clear about that.

As far as your proposal is concerned, here are a couple of suggestions:
· Please make sure that you coordinate with Fatih, since he is working 
on a new proposal for versioning that will take into consideration XCI.  I 
don't think it would be productive for both of you to be working on separate 
versioning proposals in isolation.
· Also, if you haven't already, make sure that you involve your Cisco 
TSC representative, Frank Brockners.  Frank is very familiar with TSC policies 
and procedures and can advise you on preparing an effective presentation and 
getting it on the agenda.
David

On Fri, Sep 15, 2017 at 11:41 AM, Alec Hothan (ahothan) 
> wrote:
David,

That might look obvious but perhaps you could confirm the exact branch name 
moving forward (or perhaps this has not changed).
From the look of existing branches, looks like it will be
“stable/euphrates”

I assume projects can/will commit stuff on that branch until some code freeze 
milestone? Could you point to the remaining limestone agenda for euphrates?

And I assume there will be at some point tags to point to subrelease (5.0, 
5.1…) on that branch?
When will these tags be created and what format will they have?
I’m trying to get a proposal out for tagging/CD and would like to avoid OPNFV 
release tags with “5.0.0” format if possible (will explain why in my proposal).

Sorry if I ask many questions,

Thanks

  Alec





From: 
>
 on behalf of David McBride 
>
Date: Friday, September 15, 2017 at 11:26 AM
To: TECH-DISCUSS OPNFV 
>,
 opnfv-project-leads 
>
Cc: Aric Gardner 
>, Raymond 
Paik >, Trevor 
Bramwell >, 
Tapio Tallgren >
Subject: Re: [opnfv-project-leads] [release][euphrates] stable branch window

Reminder...

In a few minutes, Aric will begin generating branches for projects that have 
not yet been branched.

Exceptions:
• RelEng
• Projects that did not participate in the release
• Projects that withdrew from the release
List:
1.   Apex
2.   Armband
3.   Bamboo
4.   Barometer
5.   Bottlenecks
6.   Calipso
7.   Compass4nfv
8.   Daisy4NFV
9.   Doctor
10.   Domino
11.   FastDataStacks
12.   Fuel@OPNFV
13.   FUNCTEST
14.   High availability (HA)
15.   IPv6
16.   JOID
17.   KVMforNFV
18.   Moon
19.   NFVBench
20.   Octopus
21.   OpenRetriever
22.   OPNFVDOCS
23.   OVNO
24.   Orchestra
25.   OVN4NFV
26.   Parser
27.   Pharos
28.   Promise
29.   QTIP
30.   SampleVNF
31.   SDNVPN
32.   SFC
33.   StorPerf
34.   VSPerf
35.   Yardstick

On Fri, Sep 8, 2017 at 4:24 PM, David McBride 
> wrote:
Reminder...

The stable branch window closes as of MS7, one week from today, on September 15 
at 12 p.m. (PT). PTLs - please contact Aric as soon as you're ready to branch.  
Aric will branch any projects that have not already been branched on Sept 15.

Let me know if you have any questions.

David

On Tue, Aug 29, 2017 at 3:23 PM, David McBride 

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][euphrates] stable branch window

[Beierl, Mark]

Hello, Alec.

In Confluence, you can "watch" a space and will then receive email 
notifications every time a page is created/updated/deleted.  It's the little 
[cid:A519D3C8-5EB4-4FEF-ABBA-D8F70441C283@corp.emc.com] icon for a page, or 
from the home page of a space this will poop up:

[cid:D6DC9ADC-66DC-40ED-8382-3547FD324A68@corp.emc.com]

Regards,
Mark

Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com

On Sep 15, 2017, at 15:24, Alec Hothan (ahothan) 
> wrote:

Thanks Mark,

That is exactly what I was looking for and your explanation below makes perfect 
sense (and should be added to that page).

I wonder how do we get to know when these wiki pages are created? Do I need to 
attend release meetings or subscribe to some mailer?
I am relieved the tags have a “Euphrates” prefix ;-)

  Alec


From: "Beierl, Mark" >
Date: Friday, September 15, 2017 at 12:04 PM
To: "Alec Hothan (ahothan)" >
Cc: David McBride 
>, 
"opnfv-tech-discuss@lists.opnfv.org" 
>,
 opnfv-project-leads 
>,
 Tapio Tallgren >, 
Raymond Paik >, 
Trevor Bramwell 
>, "Aric 
Gardner (agard...@linuxfoundation.org)" 
>
Subject: Re: [opnfv-project-leads] [release][euphrates] stable branch window

Hello, Alec.

The process for the euphrates.1.0, 2.0 etc is documented here: 
https://wiki.opnfv.org/display/SWREL/Git+Tagging+Instructions+for+Euphrates

The stable branch essentially means that no code review can be directly 
submitted against stable/euphrates.  Essentially all bug fixes and changes 
should go to master and then get independently cherry pick git Gerrit to the 
stable/euphrates branch.

Once you are happy with the state of your stable branch, the tagging 
instructions are followed.  This ultimately boils down to this one step:

git tag -am "euphrates.5.0" euphrates.5.0
git push origin euphrates.5.0

Once that is done, the tag is publicly visible and whatever build procedure you 
require for publishing (i.e. docker container, VM, ISO, RPM...) can be executed 
through Jenkins using that tag.

David, others, please correct if I have stated something incorrectly.

Regards,
Mark

Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com

On Sep 15, 2017, at 14:41, Alec Hothan (ahothan) 
> wrote:

David,

That might look obvious but perhaps you could confirm the exact branch name 
moving forward (or perhaps this has not changed).
From the look of existing branches, looks like it will be
“stable/euphrates”

I assume projects can/will commit stuff on that branch until some code freeze 
milestone? Could you point to the remaining limestone agenda for euphrates?

And I assume there will be at some point tags to point to subrelease (5.0, 
5.1…) on that branch?
When will these tags be created and what format will they have?
I’m trying to get a proposal out for tagging/CD and would like to avoid OPNFV 
release tags with “5.0.0” format if possible (will explain why in my proposal).

Sorry if I ask many questions,

Thanks

  Alec





From: 
>
 on behalf of David McBride 
>
Date: Friday, September 15, 2017 at 11:26 AM
To: TECH-DISCUSS OPNFV 
>,
 opnfv-project-leads 
>
Cc: Aric Gardner 
>, Raymond 
Paik >, Trevor 
Bramwell >, 
Tapio Tallgren >
Subject: Re: [opnfv-project-leads] [release][euphrates] stable branch window

Reminder...

In a few minutes, Aric will begin generating branches for projects that have 
not yet been branched.

Exceptions:
• RelEng
• Projects that did not participate in the release
• Projects that withdrew from the release
List:
1.   

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][euphrates] stable branch window

[Alec Hothan (ahothan)]

Thanks Mark,

That is exactly what I was looking for and your explanation below makes perfect 
sense (and should be added to that page).

I wonder how do we get to know when these wiki pages are created? Do I need to 
attend release meetings or subscribe to some mailer?
I am relieved the tags have a “Euphrates” prefix ;-)

  Alec


From: "Beierl, Mark" 
Date: Friday, September 15, 2017 at 12:04 PM
To: "Alec Hothan (ahothan)" 
Cc: David McBride , 
"opnfv-tech-discuss@lists.opnfv.org" , 
opnfv-project-leads , Tapio Tallgren 
, Raymond Paik , Trevor 
Bramwell , "Aric Gardner 
(agard...@linuxfoundation.org)" 
Subject: Re: [opnfv-project-leads] [release][euphrates] stable branch window

Hello, Alec.

The process for the euphrates.1.0, 2.0 etc is documented here: 
https://wiki.opnfv.org/display/SWREL/Git+Tagging+Instructions+for+Euphrates

The stable branch essentially means that no code review can be directly 
submitted against stable/euphrates.  Essentially all bug fixes and changes 
should go to master and then get independently cherry pick git Gerrit to the 
stable/euphrates branch.

Once you are happy with the state of your stable branch, the tagging 
instructions are followed.  This ultimately boils down to this one step:

git tag -am "euphrates.5.0" euphrates.5.0
git push origin euphrates.5.0

Once that is done, the tag is publicly visible and whatever build procedure you 
require for publishing (i.e. docker container, VM, ISO, RPM...) can be executed 
through Jenkins using that tag.

David, others, please correct if I have stated something incorrectly.

Regards,
Mark

Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com

On Sep 15, 2017, at 14:41, Alec Hothan (ahothan) 
> wrote:

David,

That might look obvious but perhaps you could confirm the exact branch name 
moving forward (or perhaps this has not changed).
From the look of existing branches, looks like it will be
“stable/euphrates”

I assume projects can/will commit stuff on that branch until some code freeze 
milestone? Could you point to the remaining limestone agenda for euphrates?

And I assume there will be at some point tags to point to subrelease (5.0, 
5.1…) on that branch?
When will these tags be created and what format will they have?
I’m trying to get a proposal out for tagging/CD and would like to avoid OPNFV 
release tags with “5.0.0” format if possible (will explain why in my proposal).

Sorry if I ask many questions,

Thanks

  Alec





From: 
>
 on behalf of David McBride 
>
Date: Friday, September 15, 2017 at 11:26 AM
To: TECH-DISCUSS OPNFV 
>,
 opnfv-project-leads 
>
Cc: Aric Gardner 
>, Raymond 
Paik >, Trevor 
Bramwell >, 
Tapio Tallgren >
Subject: Re: [opnfv-project-leads] [release][euphrates] stable branch window

Reminder...

In a few minutes, Aric will begin generating branches for projects that have 
not yet been branched.

Exceptions:
• RelEng
• Projects that did not participate in the release
• Projects that withdrew from the release
List:
1.   Apex
2.   Armband
3.   Bamboo
4.   Barometer
5.   Bottlenecks
6.   Calipso
7.   Compass4nfv
8.   Daisy4NFV
9.   Doctor
10.   Domino
11.   FastDataStacks
12.   Fuel@OPNFV
13.   FUNCTEST
14.   High availability (HA)
15.   IPv6
16.   JOID
17.   KVMforNFV
18.   Moon
19.   NFVBench
20.   Octopus
21.   OpenRetriever
22.   OPNFVDOCS
23.   OVNO
24.   Orchestra
25.   OVN4NFV
26.   Parser
27.   Pharos
28.   Promise
29.   QTIP
30.   SampleVNF
31.   SDNVPN
32.   SFC
33.   StorPerf
34.   VSPerf
35.   Yardstick

On Fri, Sep 8, 2017 at 4:24 PM, David McBride 
> wrote:
Reminder...

The stable branch window closes as of MS7, one week from today, on September 15 
at 12 p.m. (PT). PTLs - please contact Aric as soon as you're ready to branch.  
Aric will branch any projects that have not already been branched on Sept 15.

Let me know if you have any questions.

David

On Tue, Aug 29, 2017 at 3:23 PM, David McBride 

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][euphrates] stable branch window

[David McBride]

Hi Alec,

I really appreciate your interest in and knowledge of configuration
management and versioning.  This is an important topic that doesn't get
enough attention, IMHO.  I don't mind your questions at all.

Yes, you are correct about the branch name.  The change in versioning has
not affected the branch naming.  As you said, the the branch will be
"stable/euphrates".  My apologies for not being clear about that.

As far as your proposal is concerned, here are a couple of suggestions:

   - Please make sure that you coordinate with Fatih, since he is working
   on a new proposal for versioning that will take into consideration XCI.  I
   don't think it would be productive for both of you to be working on
   separate versioning proposals in isolation.
   - Also, if you haven't already, make sure that you involve your Cisco
   TSC representative, Frank Brockners.  Frank is very familiar with TSC
   policies and procedures and can advise you on preparing an effective
   presentation and getting it on the agenda.

David

On Fri, Sep 15, 2017 at 11:41 AM, Alec Hothan (ahothan) 
wrote:

> David,
>
>
>
> That might look obvious but perhaps you could confirm the exact branch
> name moving forward (or perhaps this has not changed).
>
> From the look of existing branches, looks like it will be
>
> “stable/euphrates”
>
>
>
> I assume projects can/will commit stuff on that branch until some code
> freeze milestone? Could you point to the remaining limestone agenda for
> euphrates?
>
>
>
> And I assume there will be at some point tags to point to subrelease (5.0,
> 5.1…) on that branch?
>
> When will these tags be created and what format will they have?
>
> I’m trying to get a proposal out for tagging/CD and would like to avoid
> OPNFV release tags with “5.0.0” format if possible (will explain why in my
> proposal).
>
>
>
> Sorry if I ask many questions,
>
>
>
> Thanks
>
>
>
>   Alec
>
>
>
>
>
>
>
>
>
>
>
> *From: * on behalf of David
> McBride 
> *Date: *Friday, September 15, 2017 at 11:26 AM
> *To: *TECH-DISCUSS OPNFV ,
> opnfv-project-leads 
> *Cc: *Aric Gardner , Raymond Paik <
> rp...@linuxfoundation.org>, Trevor Bramwell ,
> Tapio Tallgren 
> *Subject: *Re: [opnfv-project-leads] [release][euphrates] stable branch
> window
>
>
>
> Reminder...
>
>
>
> In a few minutes, Aric will begin generating branches for projects that
> have not yet been branched.
>
>
>
> Exceptions:
>
> · RelEng
>
> · Projects that did not participate in the release
>
> · Projects that withdrew from the release
>
> List:
>
> 1.   Apex
>
> 2.   Armband
>
> 3.   Bamboo
>
> 4.   Barometer
>
> 5.   Bottlenecks
>
> 6.   Calipso
>
> 7.   Compass4nfv
>
> 8.   Daisy4NFV
>
> 9.   Doctor
>
> 10.   Domino
>
> 11.   FastDataStacks
>
> 12.   Fuel@OPNFV
>
> 13.   FUNCTEST
>
> 14.   High availability (HA)
>
> 15.   IPv6
>
> 16.   JOID
>
> 17.   KVMforNFV
>
> 18.   Moon
>
> 19.   NFVBench
>
> 20.   Octopus
>
> 21.   OpenRetriever
>
> 22.   OPNFVDOCS
>
> 23.   OVNO
>
> 24.   Orchestra
>
> 25.   OVN4NFV
>
> 26.   Parser
>
> 27.   Pharos
>
> 28.   Promise
>
> 29.   QTIP
>
> 30.   SampleVNF
>
> 31.   SDNVPN
>
> 32.   SFC
>
> 33.   StorPerf
>
> 34.   VSPerf
>
> 35.   Yardstick
>
>
>
> On Fri, Sep 8, 2017 at 4:24 PM, David McBride <
> dmcbr...@linuxfoundation.org> wrote:
>
> Reminder...
>
>
>
> The stable branch window closes as of MS7, one week from today, on
> September 15 at 12 p.m. (PT). PTLs - please contact Aric as soon as you're
> ready to branch.  Aric will branch any projects that have not already been
> branched on Sept 15.
>
>
>
> Let me know if you have any questions.
>
>
>
> David
>
>
>
> On Tue, Aug 29, 2017 at 3:23 PM, David McBride <
> dmcbr...@linuxfoundation.org> wrote:
>
> Team,
>
>
>
> As you know, MS6 was this past Friday, Aug 25.  In addition to the
> requirements associated with MS6, this milestone also marks the opening of
> the stable branch window, which subsequently ends with MS7 on Sept 15.
>
>
>
> This means that PTLs may request to branch their project any time before
> Sept 15.  Note that I erroneously told the release meeting this morning
> that PTLs may create their own branch.  That's not the case.  Instead,
> please contact Aric (copied) and request that he create the branch for you.
>
>
>
> Also, as a reminder, we have changed the version number format as of the
> Euphrates release.
>
> · 5.0.0 - Euphrates initial release version
>
> · 5.1.0 - Euphrates SR1
>
> · 5.2.0 - Euphrates SR2
>
> Let me know if you have any questions.
>
>
>
> David
>
>
>
> --
>
> *David McBride*
>
> Release Manager, OPNFV
>
> Mobile: +1.805.276.8018
>
> Email/Google Talk: dmcbr...@linuxfoundation.org
>
> Skype: 

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][euphrates] stable branch window

[Beierl, Mark]

Hello, Alec.

The process for the euphrates.1.0, 2.0 etc is documented here: 
https://wiki.opnfv.org/display/SWREL/Git+Tagging+Instructions+for+Euphrates

The stable branch essentially means that no code review can be directly 
submitted against stable/euphrates.  Essentially all bug fixes and changes 
should go to master and then get independently cherry pick git Gerrit to the 
stable/euphrates branch.

Once you are happy with the state of your stable branch, the tagging 
instructions are followed.  This ultimately boils down to this one step:

git tag -am "euphrates.5.0" euphrates.5.0
git push origin euphrates.5.0

Once that is done, the tag is publicly visible and whatever build procedure you 
require for publishing (i.e. docker container, VM, ISO, RPM...) can be executed 
through Jenkins using that tag.

David, others, please correct if I have stated something incorrectly.

Regards,
Mark

Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com

On Sep 15, 2017, at 14:41, Alec Hothan (ahothan) 
> wrote:

David,

That might look obvious but perhaps you could confirm the exact branch name 
moving forward (or perhaps this has not changed).
From the look of existing branches, looks like it will be
“stable/euphrates”

I assume projects can/will commit stuff on that branch until some code freeze 
milestone? Could you point to the remaining limestone agenda for euphrates?

And I assume there will be at some point tags to point to subrelease (5.0, 
5.1…) on that branch?
When will these tags be created and what format will they have?
I’m trying to get a proposal out for tagging/CD and would like to avoid OPNFV 
release tags with “5.0.0” format if possible (will explain why in my proposal).

Sorry if I ask many questions,

Thanks

  Alec





From: 
>
 on behalf of David McBride 
>
Date: Friday, September 15, 2017 at 11:26 AM
To: TECH-DISCUSS OPNFV 
>,
 opnfv-project-leads 
>
Cc: Aric Gardner 
>, Raymond 
Paik >, Trevor 
Bramwell >, 
Tapio Tallgren >
Subject: Re: [opnfv-project-leads] [release][euphrates] stable branch window

Reminder...

In a few minutes, Aric will begin generating branches for projects that have 
not yet been branched.

Exceptions:
• RelEng
• Projects that did not participate in the release
• Projects that withdrew from the release
List:
1.   Apex
2.   Armband
3.   Bamboo
4.   Barometer
5.   Bottlenecks
6.   Calipso
7.   Compass4nfv
8.   Daisy4NFV
9.   Doctor
10.   Domino
11.   FastDataStacks
12.   Fuel@OPNFV
13.   FUNCTEST
14.   High availability (HA)
15.   IPv6
16.   JOID
17.   KVMforNFV
18.   Moon
19.   NFVBench
20.   Octopus
21.   OpenRetriever
22.   OPNFVDOCS
23.   OVNO
24.   Orchestra
25.   OVN4NFV
26.   Parser
27.   Pharos
28.   Promise
29.   QTIP
30.   SampleVNF
31.   SDNVPN
32.   SFC
33.   StorPerf
34.   VSPerf
35.   Yardstick

On Fri, Sep 8, 2017 at 4:24 PM, David McBride 
> wrote:
Reminder...

The stable branch window closes as of MS7, one week from today, on September 15 
at 12 p.m. (PT). PTLs - please contact Aric as soon as you're ready to branch.  
Aric will branch any projects that have not already been branched on Sept 15.

Let me know if you have any questions.

David

On Tue, Aug 29, 2017 at 3:23 PM, David McBride 
> wrote:
Team,

As you know, MS6 was this past Friday, Aug 25.  In addition to the requirements 
associated with MS6, this milestone also marks the opening of the stable branch 
window, which subsequently ends with MS7 on Sept 15.

This means that PTLs may request to branch their project any time before Sept 
15.  Note that I erroneously told the release meeting this morning that PTLs 
may create their own branch.  That's not the case.  Instead, please contact 
Aric (copied) and request that he create the branch for you.

Also, as a reminder, we have changed the version number format as of the 
Euphrates release.
• 5.0.0 - Euphrates initial release version
• 5.1.0 - Euphrates SR1
• 5.2.0 - Euphrates SR2
Let me know if you have any questions.

David

--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][euphrates] stable branch window

[Alec Hothan (ahothan)]

David,

That might look obvious but perhaps you could confirm the exact branch name 
moving forward (or perhaps this has not changed).
From the look of existing branches, looks like it will be
“stable/euphrates”

I assume projects can/will commit stuff on that branch until some code freeze 
milestone? Could you point to the remaining limestone agenda for euphrates?

And I assume there will be at some point tags to point to subrelease (5.0, 
5.1…) on that branch?
When will these tags be created and what format will they have?
I’m trying to get a proposal out for tagging/CD and would like to avoid OPNFV 
release tags with “5.0.0” format if possible (will explain why in my proposal).

Sorry if I ask many questions,

Thanks

  Alec





From:  on behalf of David McBride 

Date: Friday, September 15, 2017 at 11:26 AM
To: TECH-DISCUSS OPNFV , 
opnfv-project-leads 
Cc: Aric Gardner , Raymond Paik 
, Trevor Bramwell , 
Tapio Tallgren 
Subject: Re: [opnfv-project-leads] [release][euphrates] stable branch window

Reminder...

In a few minutes, Aric will begin generating branches for projects that have 
not yet been branched.

Exceptions:
· RelEng
· Projects that did not participate in the release
· Projects that withdrew from the release
List:
1.   Apex
2.   Armband
3.   Bamboo
4.   Barometer
5.   Bottlenecks
6.   Calipso
7.   Compass4nfv
8.   Daisy4NFV
9.   Doctor
10.   Domino
11.   FastDataStacks
12.   Fuel@OPNFV
13.   FUNCTEST
14.   High availability (HA)
15.   IPv6
16.   JOID
17.   KVMforNFV
18.   Moon
19.   NFVBench
20.   Octopus
21.   OpenRetriever
22.   OPNFVDOCS
23.   OVNO
24.   Orchestra
25.   OVN4NFV
26.   Parser
27.   Pharos
28.   Promise
29.   QTIP
30.   SampleVNF
31.   SDNVPN
32.   SFC
33.   StorPerf
34.   VSPerf
35.   Yardstick

On Fri, Sep 8, 2017 at 4:24 PM, David McBride 
> wrote:
Reminder...

The stable branch window closes as of MS7, one week from today, on September 15 
at 12 p.m. (PT). PTLs - please contact Aric as soon as you're ready to branch.  
Aric will branch any projects that have not already been branched on Sept 15.

Let me know if you have any questions.

David

On Tue, Aug 29, 2017 at 3:23 PM, David McBride 
> wrote:
Team,

As you know, MS6 was this past Friday, Aug 25.  In addition to the requirements 
associated with MS6, this milestone also marks the opening of the stable branch 
window, which subsequently ends with MS7 on Sept 15.

This means that PTLs may request to branch their project any time before Sept 
15.  Note that I erroneously told the release meeting this morning that PTLs 
may create their own branch.  That's not the case.  Instead, please contact 
Aric (copied) and request that he create the branch for you.

Also, as a reminder, we have changed the version number format as of the 
Euphrates release.
· 5.0.0 - Euphrates initial release version
· 5.1.0 - Euphrates SR1
· 5.2.0 - Euphrates SR2
Let me know if you have any questions.

David

--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride



--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride



--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][euphrates] stable branch window

[Cedric OLLIVIER]

Alec,

No, I'm not part of the Doctor team.
I simply fix the requirements (and then packages) over the different
OPNFV projects which are integrated inside Functest.

From Functest point of view, the requirements are key compared to the
versioning as we are currently using git (instead of pypi) to install
the packages.
Stable branches (and tag in case of releng) are currently enough to
build Functest stable docker images.
https://git.opnfv.org/functest/tree/upper-constraints.txt
https://git.opnfv.org/functest/tree/docker/core/Dockerfile

You're right. I had to switch to 2017.9.0 instead of 5 due to the
previous pbr conditions in Doctor setup.cfg which I have mainly
defined in the other packages.
I agree with tagging OPNFV release with 5.0.0 and then with removing
version in setup.cfg.
I set 5 in setup.cfg as default value but it can be safely removed/modified.

If we select 2017.9.0, it can raise minor issues for projects which
would want to release their packages in between official OPNFV
releases.
As the packages are not published in pypi, I don't think it's
currently relevant.

Cédric

2017-09-12 8:54 GMT+02:00 Alec Hothan (ahothan) :
> Hi Cedric,
>
>
>
> Inline…
>
>
>
>
>
> From: Cedric OLLIVIER 
> Date: Monday, September 11, 2017 at 10:31 PM
> To: "Alec Hothan (ahothan)" 
> Cc: "Beierl, Mark" , Alexandru Avadanii
> , opnfv-project-leads
> , "opnfv-tech-discuss@lists.opnfv.org"
> , Fatih Degirmenci
> 
> Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][euphrates]
> stable branch window
>
>
>
> Alec,
>
>
>
> My comment simply highlighted a possible issue.
>
> You can simply trigger it via Doctor by setting version = 5 in its setup.cfg
>
>
>
>
>
> I precise doctor offers 2015.1.0 as tag.
>
> https://git.opnfv.org/doctor/tag/?h=2015.1.0
>
>
>
> Then you can simply call python setup.py install or pip install .
>
> ValueError: git history requires a target version of
>
> pbr.version.SemanticVersion(2015.1.1), but target version is
>
> pbr.version.SemanticVersion(5.0.0)
>
>
>
> As releng/modules version is 5.0, I think the same updated tag (eg
>
> 2017.09) would break the rules.
>
>
>
> [Alec]
>
> OK I think I understand what you mean now.
>
> I see that the doctor git repo has quite a rocky tagging history, starting
> with 2015.1.0, then using danube.3.0 notation and now having to change again
> on possibly a 5.0.0 notation.
>
> I also see that setup.cfg currently sets the metadata version to 2017.9.0
>
> I don’t want to pick on doctor project but this really shows the downside of
> trying to unify an overarching integration project release (in our case
> OPNFV release) and its constituents versioning.
>
>
>
> As a side note, I personally prefer to omit the version field in setup.cfg
> and let pbr derive the version directly from the git tagging - but of course
> this requires you can tag your versions with “2017.9.0” which indeed would
> conflict with an hypothetical OPNFV “5.0.0” tag (pbr would not know which
> one to pick since both are semver syntax compliant).
>
>
>
>
>
>
>
>
>
> When cleaning the requirements of OPNFV projects, I simply set 5 as
>
> default version value (all projects are free to modify that) as
>
> euphrates is an incorrect python package version.
>
> https://wiki.opnfv.org/display/functest/Requirements+management
>
>
>
> [Alec]
>
> How to manage dependencies across packages is an interesting and challenging
> problem but I’d like to focus on the OPNFV project versioning first – and
> hopefully find a good solution that works for everybody.
>
>
>
>
>
> By the way, I think we can hardly compare OPNFV and FD.io as the last
>
> one is java based (packaging and distributions are done via mvn).
>
> [Alec]
>
> Sorry I was merely pointing to the analogy of using a year and month as
> versioning.
>
>
>
> But it's fine to compare with OpenStack projects as we are now
>
> following quite their package rules.
>
>
>
> [Alec]
>
> I’m not familiar yet on who does what, are you part of the doctor team?
>
> Would you agree to a solution that allows projects to tag their repo using
> their own semver versioning (such as 2017.9.0) and tag OPNFV releases using
> a prefix such as opnfv-5.0.0 (which will be conveniently ignored by pbr)?
>
> That is what I am trying to get to with all these emails ;-)
>
> I will also take it that you are not in favor of tagging OPNFV release with
> “5.0.0”.
>
>
>
>
>
> Thanks
>
>
>
>   Alec
>
>
>
>
>
> Cédric
>
>
>
> 2017-09-11 23:53 GMT+02:00 Alec Hothan (ahothan) :
>
> Cedric,
>
>
>
>
>
>
>
> How to tag is a completely separate discussion and I’m actually very glad
>
> that you bring this up along with pbr ;-)
>
>
>
>
>
>
>
> But I’m curious why you bring up the “2017.09” example as it is not a semver
>
> tag and would 

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][euphrates] stable branch window

[Alec Hothan (ahothan)]

Hi Cedric,

Inline…


From: Cedric OLLIVIER 
Date: Monday, September 11, 2017 at 10:31 PM
To: "Alec Hothan (ahothan)" 
Cc: "Beierl, Mark" , Alexandru Avadanii 
, opnfv-project-leads 
, "opnfv-tech-discuss@lists.opnfv.org" 
, Fatih Degirmenci 

Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][euphrates] 
stable branch window

Alec,

My comment simply highlighted a possible issue.
You can simply trigger it via Doctor by setting version = 5 in its setup.cfg


I precise doctor offers 2015.1.0 as tag.
https://git.opnfv.org/doctor/tag/?h=2015.1.0

Then you can simply call python setup.py install or pip install .
ValueError: git history requires a target version of
pbr.version.SemanticVersion(2015.1.1), but target version is
pbr.version.SemanticVersion(5.0.0)

As releng/modules version is 5.0, I think the same updated tag (eg
2017.09) would break the rules.

[Alec]
OK I think I understand what you mean now.
I see that the doctor git repo has quite a rocky tagging history, starting with 
2015.1.0, then using danube.3.0 notation and now having to change again on 
possibly a 5.0.0 notation.
I also see that setup.cfg currently sets the metadata version to 2017.9.0
I don’t want to pick on doctor project but this really shows the downside of 
trying to unify an overarching integration project release (in our case OPNFV 
release) and its constituents versioning.

As a side note, I personally prefer to omit the version field in setup.cfg and 
let pbr derive the version directly from the git tagging - but of course this 
requires you can tag your versions with “2017.9.0” which indeed would conflict 
with an hypothetical OPNFV “5.0.0” tag (pbr would not know which one to pick 
since both are semver syntax compliant).




When cleaning the requirements of OPNFV projects, I simply set 5 as
default version value (all projects are free to modify that) as
euphrates is an incorrect python package version.
https://wiki.opnfv.org/display/functest/Requirements+management

[Alec]
How to manage dependencies across packages is an interesting and challenging 
problem but I’d like to focus on the OPNFV project versioning first – and 
hopefully find a good solution that works for everybody.


By the way, I think we can hardly compare OPNFV and FD.io as the last
one is java based (packaging and distributions are done via mvn).
[Alec]
Sorry I was merely pointing to the analogy of using a year and month as 
versioning.

But it's fine to compare with OpenStack projects as we are now
following quite their package rules.

[Alec]
I’m not familiar yet on who does what, are you part of the doctor team?
Would you agree to a solution that allows projects to tag their repo using 
their own semver versioning (such as 2017.9.0) and tag OPNFV releases using a 
prefix such as opnfv-5.0.0 (which will be conveniently ignored by pbr)?
That is what I am trying to get to with all these emails ;-)
I will also take it that you are not in favor of tagging OPNFV release with 
“5.0.0”.


Thanks

  Alec


Cédric

2017-09-11 23:53 GMT+02:00 Alec Hothan (ahothan) 
>:
Cedric,



How to tag is a completely separate discussion and I’m actually very glad
that you bring this up along with pbr ;-)



But I’m curious why you bring up the “2017.09” example as it is not a semver
tag and would not be recognized by pbr?

For example, FD.io/VPP uses year/month to tag their releases (e.g. 17.04)

OpenStack does not impose any tagging on constituent projects (that would
cause a revolt from component owners I can guarantee that)

Semver tagging has been so far always reserved to individual component
tagging.

I am currently feeling pretty uneasy with the looming E release and its
tagging implication which could put all of us in a hole.

If we don’t do anything, we will see “5.0.0” tags on every repo in OPNFV and
that should be a cause for concern for every project owner.

I am sorry to repeat myself but I don’t think everyone has grasped yet the
implication that has on how projects should version their code and how they
can manage their artifacts starting from Euphrates.



Let me clarify again, I am not questioning the lock-step versioning that is
in effect in Euphrates but a far more damaging decision would be to tie the
OPNFV release version to semver tagging and hijack semver tagging for the
purpose of OPNFV releases versioning (e.g. slap tags like “5.0.0” on every
repo).



I would prefer if we could keep an OPNFV prefix for the tags. That was
perfect pre E release (dabube-1.0.0…). For Euphrates, if we do not want to
see the release name (understandably as it is redundant to the release
version) at least keep an opnfv prefix in front of it for the tags (e.g.
“opnfv-5.0.0”) so that project owners can version 

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][euphrates] stable branch window

[Cedric OLLIVIER]

Alec,

My comment simply highlighted a possible issue.
You can simply trigger it via Doctor by setting version = 5 in its setup.cfg

I precise doctor offers 2015.1.0 as tag.
https://git.opnfv.org/doctor/tag/?h=2015.1.0

Then you can simply call python setup.py install or pip install .
ValueError: git history requires a target version of
pbr.version.SemanticVersion(2015.1.1), but target version is
pbr.version.SemanticVersion(5.0.0)

As releng/modules version is 5.0, I think the same updated tag (eg
2017.09) would break the rules.

When cleaning the requirements of OPNFV projects, I simply set 5 as
default version value (all projects are free to modify that) as
euphrates is an incorrect python package version.
https://wiki.opnfv.org/display/functest/Requirements+management

By the way, I think we can hardly compare OPNFV and FD.io as the last
one is java based (packaging and distributions are done via mvn).
But it's fine to compare with OpenStack projects as we are now
following quite their package rules.

Cédric

2017-09-11 23:53 GMT+02:00 Alec Hothan (ahothan) :
> Cedric,
>
>
>
> How to tag is a completely separate discussion and I’m actually very glad
> that you bring this up along with pbr ;-)
>
>
>
> But I’m curious why you bring up the “2017.09” example as it is not a semver
> tag and would not be recognized by pbr?
>
> For example, FD.io/VPP uses year/month to tag their releases (e.g. 17.04)
>
> OpenStack does not impose any tagging on constituent projects (that would
> cause a revolt from component owners I can guarantee that)
>
> Semver tagging has been so far always reserved to individual component
> tagging.
>
> I am currently feeling pretty uneasy with the looming E release and its
> tagging implication which could put all of us in a hole.
>
> If we don’t do anything, we will see “5.0.0” tags on every repo in OPNFV and
> that should be a cause for concern for every project owner.
>
> I am sorry to repeat myself but I don’t think everyone has grasped yet the
> implication that has on how projects should version their code and how they
> can manage their artifacts starting from Euphrates.
>
>
>
> Let me clarify again, I am not questioning the lock-step versioning that is
> in effect in Euphrates but a far more damaging decision would be to tie the
> OPNFV release version to semver tagging and hijack semver tagging for the
> purpose of OPNFV releases versioning (e.g. slap tags like “5.0.0” on every
> repo).
>
>
>
> I would prefer if we could keep an OPNFV prefix for the tags. That was
> perfect pre E release (dabube-1.0.0…). For Euphrates, if we do not want to
> see the release name (understandably as it is redundant to the release
> version) at least keep an opnfv prefix in front of it for the tags (e.g.
> “opnfv-5.0.0”) so that project owners can version independently of the OPNFV
> release using semver compatible tags (like virtually every other open source
> project out there)
>
>
>
>
>
> Regards,
>
>
>
>   Alec
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: Cedric OLLIVIER 
> Date: Monday, September 11, 2017 at 1:38 PM
> To: "Alec Hothan (ahothan)" 
> Cc: "Beierl, Mark" , Alexandru Avadanii
> , opnfv-project-leads
> , "opnfv-tech-discuss@lists.opnfv.org"
> , Fatih Degirmenci
> 
>
>
> Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][euphrates]
> stable branch window
>
>
>
> I think it could hurt only if you select 2017.09 as tag.
>
> I precise pbr compares version (eg 5.0) and tags then it would break
>
> the python package.
>
>
>
> Cédric
>
>
>
> 2017-09-11 17:20 GMT+02:00 Alec Hothan (ahothan) :
>
>
>
>
>
> Fatih mentioned that changes in F would be in a different repo after the
>
> reorganization of the releng repo – so branching releng would technically
>
> not be needed for Euphrates?
>
>
>
> In any case, it does not hurt to tag (I was surprised tags were not used
>
> more often in OPNFV repos to mark internal versions…)
>
>
>
>
>
>
>
>
>
>
>
> Alec
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From:  on behalf of "Beierl,
>
> Mark" 
>
> Date: Monday, September 11, 2017 at 6:31 AM
>
> To: Alexandru Avadanii 
>
> Cc: opnfv-project-leads , Cedric
>
> OLLIVIER , "opnfv-tech-discuss@lists.opnfv.org"
>
> 
>
> Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][euphrates]
>
> stable branch window
>
>
>
>
>
>
>
> +1.  Would not want changes to the opnfv-docker.sh script for F to impact
>
> building of E maintenance releases.
>
>
>
>
>
>
>
> Regards,
>
>
>
> Mark
>
>
>
>
>
>
>
> Mark Beierl
>
>
>
> SW System Sr Principal Engineer
>
>
>
> Dell EMC | 

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][euphrates] stable branch window

[David McBride]

+Fatih

Alec,

The versioning format was set last spring.  However, Fatih is in the
process of putting together a proposal for versioning that will take into
account changes to the release process due to the introduction of XCI.  My
suggestion is that  you collaborate with Fatih on that proposal.  Thanks.

David

On Mon, Sep 11, 2017 at 2:53 PM, Alec Hothan (ahothan) 
wrote:

> Cedric,
>
>
>
> How to tag is a completely separate discussion and I’m actually very glad
> that you bring this up along with pbr ;-)
>
>
>
> But I’m curious why you bring up the “2017.09” example as it is not a
> semver tag and would not be recognized by pbr?
>
> For example, FD.io/VPP uses year/month to tag their releases (e.g. 17.04)
>
> OpenStack does not impose any tagging on constituent projects (that would
> cause a revolt from component owners I can guarantee that)
>
> Semver tagging has been so far always reserved to individual component
> tagging.
>
> I am currently feeling pretty uneasy with the looming E release and its
> tagging implication which could put all of us in a hole.
>
> If we don’t do anything, we will see “5.0.0” tags on every repo in OPNFV
> and that should be a cause for concern for every project owner.
>
> I am sorry to repeat myself but I don’t think everyone has grasped yet the
> implication that has on how projects should version their code and how they
> can manage their artifacts starting from Euphrates.
>
>
>
> Let me clarify again, I am not questioning the lock-step versioning that
> is in effect in Euphrates but a far more damaging decision would be to tie
> the OPNFV release version to semver tagging and hijack semver tagging for
> the purpose of OPNFV releases versioning (e.g. slap tags like “5.0.0” on
> every repo).
>
>
>
> I would prefer if we could keep an OPNFV prefix for the tags. That was
> perfect pre E release (dabube-1.0.0…). For Euphrates, if we do not want to
> see the release name (understandably as it is redundant to the release
> version) at least keep an opnfv prefix in front of it for the tags (e.g.
> “opnfv-5.0.0”) so that project owners can version independently of the
> OPNFV release using semver compatible tags (like virtually every other open
> source project out there)
>
>
>
>
>
> Regards,
>
>
>
>   Alec
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From: *Cedric OLLIVIER 
> *Date: *Monday, September 11, 2017 at 1:38 PM
> *To: *"Alec Hothan (ahothan)" 
> *Cc: *"Beierl, Mark" , Alexandru Avadanii <
> alexandru.avada...@enea.com>, opnfv-project-leads <
> opnfv-project-le...@lists.opnfv.org>, "opnfv-tech-discuss@lists.opnfv.org"
> , Fatih Degirmenci <
> fatih.degirme...@ericsson.com>
>
> *Subject: *Re: [opnfv-project-leads] [opnfv-tech-discuss]
> [release][euphrates] stable branch window
>
>
>
> I think it could hurt only if you select 2017.09 as tag.
>
> I precise pbr compares version (eg 5.0) and tags then it would break
>
> the python package.
>
>
>
> Cédric
>
>
>
> 2017-09-11 17:20 GMT+02:00 Alec Hothan (ahothan) :
>
>
>
>
>
> Fatih mentioned that changes in F would be in a different repo after the
>
> reorganization of the releng repo – so branching releng would technically
>
> not be needed for Euphrates?
>
>
>
> In any case, it does not hurt to tag (I was surprised tags were not used
>
> more often in OPNFV repos to mark internal versions…)
>
>
>
>
>
>
>
>
>
>
>
> Alec
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From:  on behalf of "Beierl,
>
> Mark" 
>
> Date: Monday, September 11, 2017 at 6:31 AM
>
> To: Alexandru Avadanii 
>
> Cc: opnfv-project-leads , Cedric
>
> OLLIVIER , "opnfv-tech-discuss@lists.opnfv.org"
>
> 
>
> Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss]
> [release][euphrates]
>
> stable branch window
>
>
>
>
>
>
>
> +1.  Would not want changes to the opnfv-docker.sh script for F to impact
>
> building of E maintenance releases.
>
>
>
>
>
>
>
> Regards,
>
>
>
> Mark
>
>
>
>
>
>
>
> Mark Beierl
>
>
>
> SW System Sr Principal Engineer
>
>
>
> Dell EMC | Office of the CTO
>
>
>
> mobile +1 613 314 8106 <(613)%20314-8106>
>
>
>
> mark.bei...@dell.com
>
>
>
>
>
>
>
> On Sep 11, 2017, at 09:26, Alexandru Avadanii  >
>
> wrote:
>
>
>
>
>
>
>
> Hi,
>
> How about tagging releng, without branching it?
>
>
>
> Alex
>
>
>
>
>
> -Original Message-
>
> From: opnfv-tech-discuss-boun...@lists.opnfv.org [
> mailto:opnfv-tech-discuss- 
>
> boun...@lists.opnfv.org] On Behalf Of Cedric OLLIVIER
>
> Sent: Monday, September 11, 2017 7:51 AM
>
> To: David McBride
>
> Cc: opnfv-project-leads; TECH-DISCUSS OPNFV
>
> Subject: Re: [opnfv-tech-discuss] [release][euphrates] stable branch window
>
>
>
> Hello,
>
>
>
> 

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][euphrates] stable branch window

[Alec Hothan (ahothan)]

Cedric,

How to tag is a completely separate discussion and I’m actually very glad that 
you bring this up along with pbr ;-)

But I’m curious why you bring up the “2017.09” example as it is not a semver 
tag and would not be recognized by pbr?
For example, FD.io/VPP uses year/month to tag their releases (e.g. 17.04)
OpenStack does not impose any tagging on constituent projects (that would cause 
a revolt from component owners I can guarantee that)
Semver tagging has been so far always reserved to individual component tagging.

I am currently feeling pretty uneasy with the looming E release and its tagging 
implication which could put all of us in a hole.
If we don’t do anything, we will see “5.0.0” tags on every repo in OPNFV and 
that should be a cause for concern for every project owner.
I am sorry to repeat myself but I don’t think everyone has grasped yet the 
implication that has on how projects should version their code and how they can 
manage their artifacts starting from Euphrates.

Let me clarify again, I am not questioning the lock-step versioning that is in 
effect in Euphrates but a far more damaging decision would be to tie the OPNFV 
release version to semver tagging and hijack semver tagging for the purpose of 
OPNFV releases versioning (e.g. slap tags like “5.0.0” on every repo).

I would prefer if we could keep an OPNFV prefix for the tags. That was perfect 
pre E release (dabube-1.0.0…). For Euphrates, if we do not want to see the 
release name (understandably as it is redundant to the release version) at 
least keep an opnfv prefix in front of it for the tags (e.g. “opnfv-5.0.0”) so 
that project owners can version independently of the OPNFV release using semver 
compatible tags (like virtually every other open source project out there)


Regards,

  Alec







From: Cedric OLLIVIER 
Date: Monday, September 11, 2017 at 1:38 PM
To: "Alec Hothan (ahothan)" 
Cc: "Beierl, Mark" , Alexandru Avadanii 
, opnfv-project-leads 
, "opnfv-tech-discuss@lists.opnfv.org" 
, Fatih Degirmenci 

Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][euphrates] 
stable branch window

I think it could hurt only if you select 2017.09 as tag.
I precise pbr compares version (eg 5.0) and tags then it would break
the python package.

Cédric

2017-09-11 17:20 GMT+02:00 Alec Hothan (ahothan) 
>:


Fatih mentioned that changes in F would be in a different repo after the
reorganization of the releng repo – so branching releng would technically
not be needed for Euphrates?

In any case, it does not hurt to tag (I was surprised tags were not used
more often in OPNFV repos to mark internal versions…)





Alec









From: 
>
 on behalf of "Beierl,
Mark" >
Date: Monday, September 11, 2017 at 6:31 AM
To: Alexandru Avadanii 
>
Cc: opnfv-project-leads 
>,
 Cedric
OLLIVIER >, 
"opnfv-tech-discuss@lists.opnfv.org"
>
Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][euphrates]
stable branch window



+1.  Would not want changes to the opnfv-docker.sh script for F to impact
building of E maintenance releases.



Regards,

Mark



Mark Beierl

SW System Sr Principal Engineer

Dell EMC | Office of the CTO

mobile +1 613 314 8106

mark.bei...@dell.com



On Sep 11, 2017, at 09:26, Alexandru Avadanii 
>
wrote:



Hi,
How about tagging releng, without branching it?

Alex


-Original Message-
From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-
boun...@lists.opnfv.org] On Behalf Of Cedric 
OLLIVIER
Sent: Monday, September 11, 2017 7:51 AM
To: David McBride
Cc: opnfv-project-leads; TECH-DISCUSS OPNFV
Subject: Re: [opnfv-tech-discuss] [release][euphrates] stable branch window

Hello,

Could you please confirm that no stable/euphrates branch will be created for
releng again?
Else we are obliged to select a specific git commit id to build our Functest
stable containers which is not the best way.
I precise Functest depends on the opnfv python package which is hosted by
releng (https://git.opnfv.org/releng/tree/modules).

Cédric

2017-09-09 1:24 GMT+02:00 David McBride 

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][euphrates] stable branch window

[Cedric OLLIVIER]

I think it could hurt only if you select 2017.09 as tag.
I precise pbr compares version (eg 5.0) and tags then it would break
the python package.

Cédric

2017-09-11 17:20 GMT+02:00 Alec Hothan (ahothan) :
>
>
> Fatih mentioned that changes in F would be in a different repo after the
> reorganization of the releng repo – so branching releng would technically
> not be needed for Euphrates?
>
> In any case, it does not hurt to tag (I was surprised tags were not used
> more often in OPNFV repos to mark internal versions…)
>
>
>
>
>
>Alec
>
>
>
>
>
>
>
>
>
> From:  on behalf of "Beierl,
> Mark" 
> Date: Monday, September 11, 2017 at 6:31 AM
> To: Alexandru Avadanii 
> Cc: opnfv-project-leads , Cedric
> OLLIVIER , "opnfv-tech-discuss@lists.opnfv.org"
> 
> Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][euphrates]
> stable branch window
>
>
>
> +1.  Would not want changes to the opnfv-docker.sh script for F to impact
> building of E maintenance releases.
>
>
>
> Regards,
>
> Mark
>
>
>
> Mark Beierl
>
> SW System Sr Principal Engineer
>
> Dell EMC | Office of the CTO
>
> mobile +1 613 314 8106
>
> mark.bei...@dell.com
>
>
>
> On Sep 11, 2017, at 09:26, Alexandru Avadanii 
> wrote:
>
>
>
> Hi,
> How about tagging releng, without branching it?
>
> Alex
>
>
> -Original Message-
> From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-discuss-
> boun...@lists.opnfv.org] On Behalf Of Cedric OLLIVIER
> Sent: Monday, September 11, 2017 7:51 AM
> To: David McBride
> Cc: opnfv-project-leads; TECH-DISCUSS OPNFV
> Subject: Re: [opnfv-tech-discuss] [release][euphrates] stable branch window
>
> Hello,
>
> Could you please confirm that no stable/euphrates branch will be created for
> releng again?
> Else we are obliged to select a specific git commit id to build our Functest
> stable containers which is not the best way.
> I precise Functest depends on the opnfv python package which is hosted by
> releng (https://git.opnfv.org/releng/tree/modules).
>
> Cédric
>
> 2017-09-09 1:24 GMT+02:00 David McBride :
>
> Reminder...
>
> The stable branch window closes as of MS7, one week from today, on
> September
> 15 at 12 p.m. (PT). PTLs - please contact Aric as soon as you're ready
> to branch.  Aric will branch any projects that have not already been
> branched on Sept 15.
>
> Let me know if you have any questions.
>
> David
>
> On Tue, Aug 29, 2017 at 3:23 PM, David McBride
>  wrote:
>
>
> Team,
>
> As you know, MS6 was this past Friday, Aug 25.  In addition to the
> requirements associated with MS6, this milestone also marks the
> opening of the stable branch window, which subsequently ends with MS7 on
>
> Sept 15.
>
>
> This means that PTLs may request to branch their project any time
> before Sept 15.  Note that I erroneously told the release meeting
> this morning that PTLs may create their own branch.  That's not the
> case.  Instead, please contact Aric (copied) and request that he create the
>
> branch for you.
>
>
> Also, as a reminder, we have changed the version number format as of
> the Euphrates release.
>
> 5.0.0 - Euphrates initial release version
> 5.1.0 - Euphrates SR1
> 5.2.0 - Euphrates SR2
>
> Let me know if you have any questions.
>
> David
>
> --
> David McBride
> Release Manager, OPNFV
> Mobile: +1.805.276.8018
> Email/Google Talk: dmcbr...@linuxfoundation.org
> Skype: davidjmcbride1
> IRC: dmcbride
>
>
>
>
>
> --
> David McBride
> Release Manager, OPNFV
> Mobile: +1.805.276.8018
> Email/Google Talk: dmcbr...@linuxfoundation.org
> Skype: davidjmcbride1
> IRC: dmcbride
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
> ___
> opnfv-tech-discuss mailing list
> opnfv-tech-discuss@lists.opnfv.org
> https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
>
>
>
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release][euphrates] stable branch window

[Alec Hothan (ahothan)]

Fatih mentioned that changes in F would be in a different repo after the 
reorganization of the releng repo – so branching releng would technically not 
be needed for Euphrates?
In any case, it does not hurt to tag (I was surprised tags were not used more 
often in OPNFV repos to mark internal versions…)


   Alec




From:  on behalf of "Beierl, Mark" 

Date: Monday, September 11, 2017 at 6:31 AM
To: Alexandru Avadanii 
Cc: opnfv-project-leads , Cedric OLLIVIER 
, "opnfv-tech-discuss@lists.opnfv.org" 

Subject: Re: [opnfv-project-leads] [opnfv-tech-discuss] [release][euphrates] 
stable branch window

+1.  Would not want changes to the opnfv-docker.sh script for F to impact 
building of E maintenance releases.

Regards,
Mark

Mark Beierl
SW System Sr Principal Engineer
Dell EMC | Office of the CTO
mobile +1 613 314 8106
mark.bei...@dell.com

On Sep 11, 2017, at 09:26, Alexandru Avadanii 
> wrote:

Hi,
How about tagging releng, without branching it?

Alex


-Original Message-
From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 [mailto:opnfv-tech-discuss-
boun...@lists.opnfv.org] On Behalf Of Cedric 
OLLIVIER
Sent: Monday, September 11, 2017 7:51 AM
To: David McBride
Cc: opnfv-project-leads; TECH-DISCUSS OPNFV
Subject: Re: [opnfv-tech-discuss] [release][euphrates] stable branch window

Hello,

Could you please confirm that no stable/euphrates branch will be created for
releng again?
Else we are obliged to select a specific git commit id to build our Functest
stable containers which is not the best way.
I precise Functest depends on the opnfv python package which is hosted by
releng (https://git.opnfv.org/releng/tree/modules).

Cédric

2017-09-09 1:24 GMT+02:00 David McBride 
>:

Reminder...

The stable branch window closes as of MS7, one week from today, on
September
15 at 12 p.m. (PT). PTLs - please contact Aric as soon as you're ready
to branch.  Aric will branch any projects that have not already been
branched on Sept 15.

Let me know if you have any questions.

David

On Tue, Aug 29, 2017 at 3:23 PM, David McBride
> wrote:


Team,

As you know, MS6 was this past Friday, Aug 25.  In addition to the
requirements associated with MS6, this milestone also marks the
opening of the stable branch window, which subsequently ends with MS7 on
Sept 15.


This means that PTLs may request to branch their project any time
before Sept 15.  Note that I erroneously told the release meeting
this morning that PTLs may create their own branch.  That's not the
case.  Instead, please contact Aric (copied) and request that he create the
branch for you.


Also, as a reminder, we have changed the version number format as of
the Euphrates release.

5.0.0 - Euphrates initial release version
5.1.0 - Euphrates SR1
5.2.0 - Euphrates SR2

Let me know if you have any questions.

David

--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride




--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: 
dmcbr...@linuxfoundation.org
Skype: davidjmcbride1
IRC: dmcbride

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss


___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss