from:"Frank Brockners \(fbrockne\)"

Re: [opnfv-tech-discuss] [opnfv-tsc] Red-lined TSC Charter Document

2018-04-10 Thread Frank Brockners (fbrockne)

The discussion hints at a problem that the current proposal in the red-lined 
TSC charter doc has:
The charter refers to a wiki page that anyone with an LF account ID is free to 
edit (remember the early days, where we had folks “changing” the content of 
project proposals post the project approval..)

IMHO we should use the contents of the wiki 
https://wiki.opnfv.org/display/DEV/Community+Election+Procedure to create a pdf 
document which would then be posted on opnfv.org. The Charter should refer to 
that document instead of the wiki.
Thanks, Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
 On Behalf Of Raymond Paik
Sent: Mittwoch, 4. April 2018 17:45
To: Julien 
Cc: opnfv-...@lists.opnfv.org; opnfv-tech-discuss 

Subject: Re: [opnfv-tech-discuss] [opnfv-tsc] Red-lined TSC Charter Document

Good catch Julien.  I used "organization" as TSC members could come from 
research institutions, universities, etc. that are not (for profit) companies.

Thanks,

Ray

On Wed, Apr 4, 2018 at 7:04 AM, Julien 
> wrote:
Hi Ray,

"Cap per company:
·   Each organization can have a maximum of 2 TSC reps." in url: 
https://wiki.opnfv.org/display/DEV/Community+Election+Procedure

I would suggest using the same word for company and organization in this 
description, and maybe company here is better.

BR,
Julien

Raymond Paik 
>于2018年4月4日周三 
上午7:49写道：
Just update the wiki page incorporating Wenjing's feedback.  Take a look at the 
TSC Chair election section at 
https://wiki.opnfv.org/display/DEV/Community+Election+Procedure and let me know 
if there are other questions/feedback.

Thanks,

Ray

On Mon, Apr 2, 2018 at 1:50 PM, Raymond Paik 
> wrote:
Wenjing:

Good points.  Yes, I'll go ahead and update the wiki in the next few days.

Thanks,

Ray

On Mon, Apr 2, 2018 at 1:35 PM, Wenjing Chu 
> wrote:
In the wiki page: 
https://wiki.opnfv.org/display/DEV/Community+Election+Procedure:

The TSC member election is scheduled on “mid-September” with flexibility, but 
the TSC chair wording is still hard-coded to September 7. I think that should 
be modified to be consistent – so that the newly elected TSC members choose the 
Chair, not the outgoing TSC.

If that is indeed the intent here, which I assume so, then we should revise the 
wiki text as soon as possible.

Another problem with the wiki section related to Chair election is its 
reference to the OPNFV By-Law
” (per section 5.5(b) of the OPNFV 
Bylaws)”.
That is no longer valid. We should refer to the OPNFV Technical Charter (or 
LFN’s) instead.

Regards
Wenjing

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org

[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org]
 On Behalf Of Raymond Paik
Sent: Wednesday, March 28, 2018 4:12 PM
To: opnfv-tech-discuss 
>;
 opnfv-...@lists.opnfv.org
Subject: [opnfv-tech-discuss] Red-lined TSC Charter Document

All,

Please find attached red-lined TSC Charter document that reflects OPNFV's move 
to a merit-based TSC. The new text was heavily borrowed from OpenDaylight's 
Charter
 as they already migrated to a merit-based TSC.  The details on size, 
eligibility, election timing, etc. will be updated on the wiki if/when 
community decides to make any tweaks.

Please let me know if you have any questions/feedback.  The plan is to vote on 
this during the TSC meeting April 10th (after ~2 week review period).

Thanks,

Ray

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

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

Re: [opnfv-tech-discuss] [releng] Committer list per Releng repository

2017-12-11 Thread Frank Brockners (fbrockne)

Hi Fatih,

this was just a suggestion - mostly to keep Releng in line with what other 
projects do in OPNFV - the test-projects are probably the closest comparison 
here. 
I also don't think that there would not be much of a change: You'd have a 
Releng working group with several projects (those 5) participating, i.e. the 
structure would look much like what is done for testing.

Anyway - just do what the contributors and committers feel is best for Releng.

Cheers, Frank

-Original Message-
From: Fatih Degirmenci [mailto:fatih.degirme...@ericsson.com] 
Sent: Montag, 11. Dezember 2017 05:20
To: Frank Brockners (fbrockne) <fbroc...@cisco.com>; Trevor Bramwell 
<tbramw...@linuxfoundation.org>
Cc: Serena Feng <feng.xiao...@zte.com.cn>; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [releng] Committer list per Releng repository

Hi Frank,

Thanks for the feedback.

Splitting Releng is perhaps an option but I personally do not think it will add 
too much value. 
I believe support functions such as what Releng aims to provide is best handled 
as a whole rather than multiple individual projects.
This is important in order to ensure the project provides best service to the 
community and sub teams follow overall direction set by Infra WG in general and 
Releng Project in particular.

With that said, if any Releng committer comes up with a proposal to split 
Releng, resulting in multiple smaller projects, we can put these 2 proposals to 
vote and do accordingly.

Another thing I would like to highlight is that the proposed setup with 
subprojects/teams is pretty similar to how OpenStack Infra project works; top 
level Infra project and multiple sub teams that specialize in certain aspects 
of the infra. [1] We as project need to work on the details if this proposal is 
accepted and approved by the TSC. Until this happens, that link can give an 
idea regarding where we might end up. 

One last point is, Releng will probably not be the only one with this need. We 
are just the first one.

[1] https://docs.openstack.org/infra/system-config/project.html#teams

/Fatih

On 2017-12-11, 03:03, "Frank Brockners (fbrockne)" <fbroc...@cisco.com> wrote:

Hey folks,

Have we considered making these just 5 separate projects (which basically 
what they are)? That'd fit the OPNFV structure, gives each project a dedicated 
repo (which they have already), and a dedicated set of committers plus a PTO...

Frank

-Original Message-
From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Trevor Bramwell
Sent: Sonntag, 10. Dezember 2017 15:34
To: Fatih Degirmenci <fatih.degirme...@ericsson.com>
Cc: Serena Feng <feng.xiao...@zte.com.cn>; 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [releng] Committer list per Releng 
repository

+1

Giving leaders of subproject the freedom to manage +2 rights on their own 
repository will be very helpful for ensuring patches are reviewed by those with 
the correct competencies and merged in a timely manner.

Perhaps having a 'mini-info' file in each repository would help track this, 
intead of expanding the current INFO file. Simple fields such as:
parent-project, project-name, creation-date, subproject-lead, committers, 
and parent-project-approval-link would work. This is merely a suggestion 
though, and a decision on this shouldn't block us from moving forward. I'm fine 
with things currently being added the INFO file.

Regards,
Trevor Bramwell

On Fri, Dec 08, 2017 at 12:01:34AM +, Fatih Degirmenci wrote:
> Hi Releng Committers,
> 
> During OPNFV Plugfest, we had conversations around having committer list 
per Releng repository/Gerrit Project.
> 
> The reason behind this is that, Releng project currently has 5 
> different repositories as listed below. [1]
> 
> 
>   *   releng
>   *   releng-anteater
>   *   releng-testresults
>   *   releng-utils
>   *   releng-xci
> 
> The work that is done in these repositories require different competence 
profiles. For example for releng repository, the committers need to have 
knowledge in CI, Jenkins, Jenkins Job Builder and so on.
> Apart from the required competence, some developers might not be 
interested in certain parts of Releng but interested in others.
> 
> Having single committer list across all Releng owned repositories 
prevents us from recognizing contributors and promoting them as committers for 
the corresponding repositories since they will perhaps never have enough 
contributions across all of them.
> Another limitation is that, the current review practices followed by 
Releng is not good and we need to improve this. Having right set of committers

Re: [opnfv-tech-discuss] [releng] Committer list per Releng repository

2017-12-10 Thread Frank Brockners (fbrockne)

Hey folks,

Have we considered making these just 5 separate projects (which basically what 
they are)? That'd fit the OPNFV structure, gives each project a dedicated repo 
(which they have already), and a dedicated set of committers plus a PTO...

Frank

-Original Message-
From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Trevor Bramwell
Sent: Sonntag, 10. Dezember 2017 15:34
To: Fatih Degirmenci 
Cc: Serena Feng ; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [releng] Committer list per Releng repository

+1

Giving leaders of subproject the freedom to manage +2 rights on their own 
repository will be very helpful for ensuring patches are reviewed by those with 
the correct competencies and merged in a timely manner.

Perhaps having a 'mini-info' file in each repository would help track this, 
intead of expanding the current INFO file. Simple fields such as:
parent-project, project-name, creation-date, subproject-lead, committers, and 
parent-project-approval-link would work. This is merely a suggestion though, 
and a decision on this shouldn't block us from moving forward. I'm fine with 
things currently being added the INFO file.

Regards,
Trevor Bramwell

On Fri, Dec 08, 2017 at 12:01:34AM +, Fatih Degirmenci wrote:
> Hi Releng Committers,
> 
> During OPNFV Plugfest, we had conversations around having committer list per 
> Releng repository/Gerrit Project.
> 
> The reason behind this is that, Releng project currently has 5 
> different repositories as listed below. [1]
> 
> 
>   *   releng
>   *   releng-anteater
>   *   releng-testresults
>   *   releng-utils
>   *   releng-xci
> 
> The work that is done in these repositories require different competence 
> profiles. For example for releng repository, the committers need to have 
> knowledge in CI, Jenkins, Jenkins Job Builder and so on.
> Apart from the required competence, some developers might not be interested 
> in certain parts of Releng but interested in others.
> 
> Having single committer list across all Releng owned repositories prevents us 
> from recognizing contributors and promoting them as committers for the 
> corresponding repositories since they will perhaps never have enough 
> contributions across all of them.
> Another limitation is that, the current review practices followed by Releng 
> is not good and we need to improve this. Having right set of committers per 
> repo and getting patches reviewed by them properly will help with the quality 
> of work we are doing.
> 
> In order to address this limitation and have the ability and the possibility 
> to recognize and promote developers who made great contributions to Releng in 
> general in the repositories they worked in, I propose to create committer 
> list per repo.
> 
> Please respond to this mail with +1 and -1 and share questions, comments, 
> concerns if you have any.
> 
> I plan to bring this topic to TSC on December 12th if the vote passes.
> 
> [1] https://gerrit.opnfv.org/gerrit/#/admin/projects/?filter=releng
> 
> /Fatih
___
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] urgent euphrates git tags vote needed

2017-09-26 Thread Frank Brockners (fbrockne)

+1 – per what Alec mentioned below, the new tagging scheme is only a small 
change incremental change from the earlier plans, but offers a lot of 
flexibility moving forward.

Frank

From: Alec Hothan (ahothan)
Sent: Montag, 25. September 2017 21:34
To: opnfv-tech-discuss@lists.opnfv.org
Cc: David McBride <dmcbr...@linuxfoundation.org>; Fatih Degirmenci 
<fatih.degirme...@ericsson.com>; Frank Brockners (fbrockne) 
<fbroc...@cisco.com>; Tallgren, Tapio (Nokia - FI/Espoo) 
<tapio.tallg...@nokia.com>
Subject: [opnfv-tech-discuss] urgent euphrates git tags vote needed

I would like to get a quick vote from any person that works directly or 
indirectly with code in OPNFV

Please reply with -1, 0 +1

For using prefixed git tags for the Euphrates release: “opnfv-5.0.0”

This is a slight change to the plan on record (which was to use “5.0.0”). This 
does NOT impact euphrates deliverables for participating OPNFV projects (git 
tags on stable/euphrates are applied by releng).
The only externally visible effect is the naming of container tags for 
Euphrates official images in DockerHub will be named accordingly (e.g. 
“opnfv/functest:opnfv-5.0.0”).
Everything else remains the same.

If you’d like to know more, the rationale is described here: 
https://wiki.opnfv.org/display/releng/OPNFV+projects+and+OPNFV+release+versioning
 (thanks for Fatih, David, Frank, Tapio for reviewing)
In a nutshell, this adjustment is needed to prepare the path for proper 
continuous delivery support by projects.
Any clarification/questions/discussion can be done over email or at the TSC or 
release meetings tomorrow.

Thank You.

  Alec

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

Re: [opnfv-tech-discuss] [announce] 2018 OPNFV release names

2017-09-25 Thread Frank Brockners (fbrockne)

Ray,

while there are not a ton of river “Fenix” photos, there are some, e.g 
http://www.soberaniachile.cl/archivosdeimagenes/fenix.jpg and 
http://photo500x500.mnstatic.com/f11c1c363de24a0a5ad44bb39046e2da/rio-fenix-grande.jpg
 – there are wiki entries such as… 
https://es.wikipedia.org/wiki/Desv%C3%ADo_del_r%C3%ADo_F%C3%A9nix and 
https://es.wikipedia.org/wiki/R%C3%ADo_F%C3%A9nix_Grande

If you want better photos, do we have any friends in Argentina that fancy a 
trip to lago Buenos Aires? 
http://viento.com.ar/wp-content/uploads/2015/09/desvio-rio-fenix.jpg

Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Raymond Paik
Sent: Montag, 25. September 2017 18:25
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [announce] 2018 OPNFV release names

All:

Thanks for voting on the release naming poll.

First, for G-release the winner is Gambia (the first African river for OPNFV).

For the F-release, the top vote getter was Fenix in Argentina.  However, after 
some research it looks this is a tributary of another river 
(Deseado), and I wasn't able to 
find photos of Fenix River on the web (or even find it on Google Maps).

I talked to LF marketing colleagues as we've been using river images for 
release marketing, and they do have concerns about going with a river that is 
not well known.  The second choice was 
Fraser in Canada (the longest river 
in British Columbia) and I suggest going with Fraser as the F-release name.  
Although Fenix sounds cool, I think it's problematic if you can't find it on a 
map.

Let me know if you have any questions.

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

Re: [opnfv-tech-discuss] [infra] Proposal for LaaS Hardware

2017-08-16 Thread Frank Brockners (fbrockne)

True. A 2port 10GE NIC is ~500 $US. I've already updated the wiki :)

Thanks again, Frank

From: Bryan Sullivan [mailto:bls...@hotmail.com]
Sent: Mittwoch, 16. August 2017 15:36
To: Frank Brockners (fbrockne) <fbroc...@cisco.com>; Fatih Degirmenci 
<fatih.degirme...@ericsson.com>; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [infra] Proposal for LaaS Hardware

Re budget I don't think 2 or 4 NICs will have much impact given the type of 
servers we are talking about here (datacenter, production-grade servers). Most 
I have seen come with 4 NICs onboard and often dedicated IPMI.

Thanks,
Bryan Sullivan
____
From: Frank Brockners (fbrockne) <fbroc...@cisco.com<mailto:fbroc...@cisco.com>>
Sent: Wednesday, August 16, 2017 3:36 AM
To: Bryan Sullivan; Fatih Degirmenci; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: RE: [infra] Proposal for LaaS Hardware

Bryan,

Thanks for raising an important point. IMHO 2 NICs are the minimal setup. This 
allows for performance focused setups (i.e. traffic enters on one NIC and 
leaves on another NIC), and it also allows for setups where you use the NICs 
for different purposes (e.g. dedicate a NIC to the kernel, and another one to 
VPP).

We can of course handle all three "types" of networks (admin, public, 
tenant/private) using VLAN/VLAN-ranges - but for some deployments a physical 
decoupling might ease things.

Per your suggestion: In order to allow for better flexibility, let's plan with 
3 NICs for now. We can always scale back in case there are budget constraints.

Lights-out-management is something that is often vendor specific - and it may, 
or may not require a dedicated port (IPMI 2.0 even runs over VLANs) - but as 
part of the requirements list, we should spell out that lights-out-management 
is something we absolutely require. I'll update the wiki accordingly.

Thanks, Frank

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Bryan Sullivan
Sent: Dienstag, 15. August 2017 22:58
To: Fatih Degirmenci 
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [infra] Proposal for LaaS Hardware

Fatih,

Do "2 x 10 Gbps NICs" suffice for Pharos POD servers? I thought the NIC 
requirements were more substantial. IMO we should require at least IPMI + 3 
NICs (Admin/PXE, Private, Public).

The lab we are building as described at 
https://wiki.opnfv.org/display/joid/MAAS+as+Lab+Admin+Server will be designed 
that way. Our vision for how we will use this lab (initially, for internal 
development/CI activities only) is very similar to your vision for LaaS dynamic 
assignment of server resources. We plan to use MAAS, Ansible, and Jenkins to 
manage the admin and distribution of development/CI/etc activities across these 
servers.

Thanks,
Bryan Sullivan

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>

<opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>>
 on behalf of Fatih Degirmenci 
<fatih.degirme...@ericsson.com<mailto:fatih.degirme...@ericsson.com>>
Sent: Tuesday, August 15, 2017 1:02 PM
To: 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: [opnfv-tech-discuss] [infra] Proposal for LaaS Hardware

Hi,

Please see the proposal regarding the number of servers and hardware specs for 
LaaS from the links below.

*   Number of x86 and ARM servers: 
https://wiki.opnfv.org/display/INF/Lab+as+a+Service#LabasaService-LaaS-NumberofServers
*   Definition of hardware for x86 and ARM: 
https://wiki.opnfv.org/display/INF/Lab+as+a+Service#LabasaService-LaaSHardware

Please share your thoughts, comments and questions either by replying to this 
mail, directly on Wiki page, or by joining the Infra WG Meeting on August 21st 
where this topic will be discussed.

/Fatih

___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org<mailto: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] [infra] Proposal for LaaS Hardware

2017-08-16 Thread Frank Brockners (fbrockne)

Bryan,

Thanks for raising an important point. IMHO 2 NICs are the minimal setup. This 
allows for performance focused setups (i.e. traffic enters on one NIC and 
leaves on another NIC), and it also allows for setups where you use the NICs 
for different purposes (e.g. dedicate a NIC to the kernel, and another one to 
VPP).

We can of course handle all three "types" of networks (admin, public, 
tenant/private) using VLAN/VLAN-ranges - but for some deployments a physical 
decoupling might ease things.

Per your suggestion: In order to allow for better flexibility, let's plan with 
3 NICs for now. We can always scale back in case there are budget constraints.

Lights-out-management is something that is often vendor specific - and it may, 
or may not require a dedicated port (IPMI 2.0 even runs over VLANs) - but as 
part of the requirements list, we should spell out that lights-out-management 
is something we absolutely require. I'll update the wiki accordingly.

Thanks, Frank



From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Bryan Sullivan
Sent: Dienstag, 15. August 2017 22:58
To: Fatih Degirmenci ; 
opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] [infra] Proposal for LaaS Hardware

Fatih,

Do "2 x 10 Gbps NICs" suffice for Pharos POD servers? I thought the NIC 
requirements were more substantial. IMO we should require at least IPMI + 3 
NICs (Admin/PXE, Private, Public).

The lab we are building as described at 
https://wiki.opnfv.org/display/joid/MAAS+as+Lab+Admin+Server will be designed 
that way. Our vision for how we will use this lab (initially, for internal 
development/CI activities only) is very similar to your vision for LaaS dynamic 
assignment of server resources. We plan to use MAAS, Ansible, and Jenkins to 
manage the admin and distribution of development/CI/etc activities across these 
servers.

Thanks,
Bryan Sullivan

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org
 
>
 on behalf of Fatih Degirmenci 
>
Sent: Tuesday, August 15, 2017 1:02 PM
To: 
opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] [infra] Proposal for LaaS Hardware

Hi,

Please see the proposal regarding the number of servers and hardware specs for 
LaaS from the links below.

*   Number of x86 and ARM servers: 
https://wiki.opnfv.org/display/INF/Lab+as+a+Service#LabasaService-LaaS-NumberofServers
*   Definition of hardware for x86 and ARM: 
https://wiki.opnfv.org/display/INF/Lab+as+a+Service#LabasaService-LaaSHardware

Please share your thoughts, comments and questions either by replying to this 
mail, directly on Wiki page, or by joining the Infra WG Meeting on August 21st 
where this topic will be discussed.

/Fatih

___
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] ODL target Release for Euphrates

2017-08-08 Thread Frank Brockners (fbrockne)

Hi Cédric,

is there a way to have a per-scenario functest config file? We could have a 
default file, which we’d modify on a case by case basis. Note that e.g. only a 
subset of the scenarios use NetVirt, hence having Netvirt as a default 
testsuite probably won’t make sense.

Thanks, Frank

From: cedric.olliv...@orange.com [mailto:cedric.olliv...@orange.com]
Sent: Dienstag, 8. August 2017 11:17
To: Frank Brockners (fbrockne) <fbroc...@cisco.com>; RICHOMME Morgan IMT/OLN 
<morgan.richo...@orange.com>; Tim Rozet <tro...@redhat.com>; 
narinder.gu...@canonical.com; 'Michal Skalski' <mskal...@mirantis.com>; Chigang 
(Justin) <chig...@huawei.com>; hu.zhiji...@zte.com.cn; David McBride 
<dmcbr...@linuxfoundation.org>; Georg Kunz <georg.k...@ericsson.com>; Tim 
Irnich <tim.irn...@ericsson.com>; Manuel Buil <manuel.b...@ericsson.com>; 
Michael Polenchuk <mpolenc...@mirantis.com>; HE Ruan IMT/OLS 
<ruan...@orange.com>; Juraj Linkes -X (jlinkes - PANTHEON TECHNOLOGIES at 
Cisco) <jlin...@cisco.com>; Feng Pan <f...@redhat.com>; Michal Cmarada -X 
(mcmarada - PANTHEON TECHNOLOGIES at Cisco) <mcmar...@cisco.com>
Cc: wangwulin <wangwu...@huawei.com>; opnfv-tech-discuss@lists.opnfv.org
Subject: RE: [OPNFV] ODL target Release for Euphrates

Hello,

I understand your point but Functest requires a default answer to finish the 
containers and to write the testcase config file (suites and dependencies on 
scenarii or installers).
Then we take the decision about the release (the last one seems fine) and if 
the NetVirt test suite is ran by default before the possible harmonization.
I would have thought it was an upper decision as for OpenStack.

Cédric

De : Frank Brockners (fbrockne) [mailto:fbroc...@cisco.com]
Envoyé : mardi 8 août 2017 10:10
À : RICHOMME Morgan IMT/OLN; Tim Rozet; 
narinder.gu...@canonical.com<mailto:narinder.gu...@canonical.com>; 'Michal 
Skalski'; Chigang (Justin); 
hu.zhiji...@zte.com.cn<mailto:hu.zhiji...@zte.com.cn>; David McBride; Georg 
Kunz; Tim Irnich; Manuel Buil; Michael Polenchuk; HE Ruan IMT/OLS; Juraj Linkes 
-X (jlinkes - PANTHEON TECHNOLOGIES at Cisco); Feng Pan; Michal Cmarada -X 
(mcmarada - PANTHEON TECHNOLOGIES at Cisco)
Cc : OLLIVIER Cédric IMT/OLN; wangwulin; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Objet : RE: [OPNFV] ODL target Release for Euphrates

Hi Morgan,

it might well be that there is no one answer to your question – especially for 
those scenarios which are leading edge and actively drive development upstream 
(i.e. in ODL and HoneyComb). In addition, given the sister relationship between 
ODL and Honeycomb, model updates go hand in hand – which drive another version 
dependency.
For FDS, we plan for an effort similar to what we’ve done for Danube: Once 
we’re getting closer to the E-release, we’ll try to harmonize on a single 
version of ODL, i.e. we’ll try to harmonize on a pre-release version of 
Nitrogen – but for the time being, you’ll find different scenarios using 
different versions of ODL (sometimes even dedicated builds, e.g. as used for 
the GBP-Netvirt PoC or for the fdio-dvr scenario), also due to the fact that 
Karaf-4 migration isn’t yet done for all the components.

Regards, Frank

From: morgan.richo...@orange.com<mailto:morgan.richo...@orange.com> 
[mailto:morgan.richo...@orange.com]
Sent: Dienstag, 8. August 2017 09:18
To: Tim Rozet <tro...@redhat.com<mailto:tro...@redhat.com>>; 
narinder.gu...@canonical.com<mailto:narinder.gu...@canonical.com>; 'Michal 
Skalski' <mskal...@mirantis.com<mailto:mskal...@mirantis.com>>; Chigang 
(Justin) <chig...@huawei.com<mailto:chig...@huawei.com>>; 
hu.zhiji...@zte.com.cn<mailto:hu.zhiji...@zte.com.cn>; David McBride 
<dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>>; Georg Kunz 
<georg.k...@ericsson.com<mailto:georg.k...@ericsson.com>>; Frank Brockners 
(fbrockne) <fbroc...@cisco.com<mailto:fbroc...@cisco.com>>; Tim Irnich 
<tim.irn...@ericsson.com<mailto:tim.irn...@ericsson.com>>; Manuel Buil 
<manuel.b...@ericsson.com<mailto:manuel.b...@ericsson.com>>; Michael Polenchuk 
<mpolenc...@mirantis.com<mailto:mpolenc...@mirantis.com>>; HE Ruan IMT/OLPS 
<ruan...@orange.com<mailto:ruan...@orange.com>>; Frank Brockners (fbrockne) 
<fbroc...@cisco.com<mailto:fbroc...@cisco.com>>
Cc: OLLIVIER Cédric IMT/OLN 
<cedric.olliv...@orange.com<mailto:cedric.olliv...@orange.com>>; wangwulin 
<wangwu...@huawei.com<mailto:wangwu...@huawei.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: [OPNFV] ODL target Release for Euphrates

Hi,

I did not find the list of the target versions for the main components 
integrated in Euphrates version.
it would make s

Re: [opnfv-tech-discuss] [OPNFV] ODL target Release for Euphrates

2017-08-08 Thread Frank Brockners (fbrockne)

Hi Morgan,

it might well be that there is no one answer to your question – especially for 
those scenarios which are leading edge and actively drive development upstream 
(i.e. in ODL and HoneyComb). In addition, given the sister relationship between 
ODL and Honeycomb, model updates go hand in hand – which drive another version 
dependency.
For FDS, we plan for an effort similar to what we’ve done for Danube: Once 
we’re getting closer to the E-release, we’ll try to harmonize on a single 
version of ODL, i.e. we’ll try to harmonize on a pre-release version of 
Nitrogen – but for the time being, you’ll find different scenarios using 
different versions of ODL (sometimes even dedicated builds, e.g. as used for 
the GBP-Netvirt PoC or for the fdio-dvr scenario), also due to the fact that 
Karaf-4 migration isn’t yet done for all the components.

Regards, Frank

From: morgan.richo...@orange.com [mailto:morgan.richo...@orange.com]
Sent: Dienstag, 8. August 2017 09:18
To: Tim Rozet <tro...@redhat.com>; narinder.gu...@canonical.com; 'Michal 
Skalski' <mskal...@mirantis.com>; Chigang (Justin) <chig...@huawei.com>; 
hu.zhiji...@zte.com.cn; David McBride <dmcbr...@linuxfoundation.org>; Georg 
Kunz <georg.k...@ericsson.com>; Frank Brockners (fbrockne) 
<fbroc...@cisco.com>; Tim Irnich <tim.irn...@ericsson.com>; Manuel Buil 
<manuel.b...@ericsson.com>; Michael Polenchuk <mpolenc...@mirantis.com>; HE 
Ruan IMT/OLPS <ruan...@orange.com>; Frank Brockners (fbrockne) 
<fbroc...@cisco.com>
Cc: OLLIVIER Cédric IMT/OLN <cedric.olliv...@orange.com>; wangwulin 
<wangwu...@huawei.com>; opnfv-tech-discuss@lists.opnfv.org
Subject: [OPNFV] ODL target Release for Euphrates

Hi,

I did not find the list of the target versions for the main components 
integrated in Euphrates version.
it would make sense to explicitely reference them on one of the wiki pages 
dedicated to the release https://wiki.opnfv.org/display/SWREL/Euphrates

In functest, we need to know it.
Cedric consolidated Functest in order to manage properly the upstream 
dependencies (including clients/tooling/lib needed for testing relatively to 
upstream components) and introduced a clean packetization, which is key for an 
integration project.

At the moment, the only ODL version reference we found was beryllium-sr4, which 
is pretty old.

According to https://wiki.opnfv.org/display/SWREL/Euphrates+Scenario+Status
scenario owners dealing with ODL are:
- Frank (Apex ∩ Fdio)
- Tim Inrich (Apex ∩ bgpvpn)
- Brady (not sure the page is up to date) / Manuel (Apex ∩ Sfc)
- Georg (not sure it is up to date) Apex ∩ gluon
- Tim Rozet (Other Apex scenarios)
- Ruan He (Compass ∩ moon)
- Justin (Other Compass scenarios)
- Zhiang (Daisy ∩ moon)
- Michael (Fuel/MCP)

could you confirm the target version for ODL?


/Morgan

note: no scenario ODL with joid referenced in the page.


_



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.
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [release][announce] RESPONSE REQUIRED / proposed change to release date for Danube 3.0

2017-06-29 Thread Frank Brockners (fbrockne)

+1

Frank

Am 28.06.2017 um 11:12 schrieb David McBride 
>:

TSC,

After examining status and considering various alternatives, Ray and I have 
agreed to propose July 14 as the new release date for Danube 3.  We believe 
that this will give project and installer teams time to overcome current 
issues, as well as allowing us to avoid the 4th of July holiday in the U.S., 
when many community members will be away on vacation.

Assuming that the TSC approves this change, then I would suggest the following 
schedule:

  *   July 12 - complete testing
  *   July 13 - finish document updates / update JIRA
  *   July 14 - tag repos and release
  *   Week of July 17 - download page goes live

TSC members, please respond to this email with your vote on the following by 
EOD PT June 30:

Does the TSC approve moving the Danube 3.0 release date to July 14th? (+1, 0, 
-1)

David

--
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

Re: [opnfv-tech-discuss] [release][euphrates] RESPONSE REQUIRED - Milestone 2 - test case documentation - May 22

2017-05-18 Thread Frank Brockners (fbrockne)

David,

for FDS, we’ve so far just noted the test-cases with “pen and paper”: 
https://wiki.opnfv.org/display/fds/FDS+Testing+Euphrates
Once things are a bit more settled, we’ll also add them to the Database.

Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Donnerstag, 18. Mai 2017 20:27
To: TECH-DISCUSS OPNFV ; 
opnfv-project-leads 
Subject: Re: [opnfv-tech-discuss] [release][euphrates] RESPONSE REQUIRED - 
Milestone 2 - test case documentation - May 22

REMINDER - MS2 is on Monday, May 22.  I've only heard from a few projects, so 
far. Please send me the link to your test cases in the test case database.  See 
the links in my previous mail for links to instructions and an example.

On Mon, May 15, 2017 at 11:00 AM, David McBride 
> wrote:
OPNFV Feature Project Owners,

Test case documentation (MS2) is due in 1 week (May 
22).
  Please register your project with functest and document your test cases in 
the test case database, as described 
here.

In order to verify compliance, please respond to this email with a link to your 
test case documentation (e.g., for 
FDS).  
Note:  please send the link even if you are not changing your test cases from 
the previous release.

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

Re: [opnfv-tech-discuss] [release][danube] Danube 3.0 - June 8

2017-05-16 Thread Frank Brockners (fbrockne)

Thanks David.

A minor points: Below you probably refer to D3.0. In addition, did we move the 
release date to June/9 now (instead of June/8 as listed on 
https://wiki.opnfv.org/display/SWREL/Danube?preview=/6827418/8689182/OPNFV%20Release%20%2522Danube%2522%20r4.pdf)

Thanks, Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Montag, 15. Mai 2017 20:29
To: TECH-DISCUSS OPNFV ; 
opnfv-project-leads 
Subject: [opnfv-tech-discuss] [release][danube] Danube 3.0 - June 8

Team,

Our final release for OPNFV Danube is just 3 1/2 weeks away.  We will start 
daily meetings for this release beginning May 29.

Scenario owners - please take a moment and make sure that the 
"intent-to-release" column on the scenario status 
page is up to date 
for your scenario.

The schedule for the D2.0 release is as follows:

  *   June 6 - complete formal testing
  *   June 7 - complete documentation / JIRA cleanup
  *   June 9 - tag projects / release
David

--
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] New project proposal: NFVbench

2017-04-17 Thread Frank Brockners (fbrockne)

Hi Trevor,

fully agreed. Let's discuss this in the proposal review during the technical 
meeting on Thursday.
Are you coming to the hackfest next week?

Thanks, Frank

From: Cooper, Trevor [mailto:trevor.coo...@intel.com]
Sent: Montag, 17. April 2017 08:22
To: Frank Brockners (fbrockne) <fbroc...@cisco.com>; TSC OPNFV 
<opnfv-...@lists.opnfv.org>; TECH-DISCUSS OPNFV 
<opnfv-tech-discuss@lists.opnfv.org>
Cc: Carsten Rossenhoevel <cr...@eantc.de>; Alec Hothan (ahothan) 
<ahot...@cisco.com>
Subject: RE: New project proposal: NFVbench

Hi Frank

I think that your proposal aligns with some of the stress testing concepts that 
we have been developing in the Testing Working Group. Re. While VSPERF does not 
utilize the full stack (with Open Stack), the test cases can provide a baseline 
for any NFVI data-plane suite ... i.e. Throughput Tests, Packet and Frame Delay 
Tests, Stream Performance Tests, Request/Response Performance Tests, Packet 
Delay Tests, Scalability Tests, Control Path and Datapath Coupling Tests, CPU 
and Memory Consumption Tests, Time to Establish Flows Tests, Noisy Neighbor 
Tests. We should try to maintain consistency of methods/metrics form component 
level tests to system level where possible. It will be good to discuss this 
further.

/Trevor

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Frank 
Brockners (fbrockne)
Sent: Wednesday, April 12, 2017 9:40 AM
To: TSC OPNFV <opnfv-...@lists.opnfv.org<mailto:opnfv-...@lists.opnfv.org>>; 
TECH-DISCUSS OPNFV 
<opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>>
Cc: Carsten Rossenhoevel <cr...@eantc.de<mailto:cr...@eantc.de>>; Alec Hothan 
(ahothan) <ahot...@cisco.com<mailto:ahot...@cisco.com>>
Subject: [opnfv-tech-discuss] New project proposal: NFVbench

Hi OPNFV,

over the past few weeks we've distilled a proposals to create a toolkit to 
allow for black-box performance testing of NFVI with a network focus:
NFVbench: https://wiki.opnfv.org/display/nfvbench/NFVbench+Project+Proposal

The NFVbench project is to develop a toolkit that allows developers, 
integrators, testers and customers to measure and assess the L2/L3 forwarding 
performance of an NFV-infrastructure solution stack (i.e. OPNFV scenario) using 
a black-box approach.

We're hoping for a discussion in the technical community meeting on April/20, 
and are also asking for an official TSC review post the technical community 
review on May/2, so that NFVbench can participate in Euphrates. Consequently, 
NFVbench asks for tentative inclusion into Euphrates.

Your thoughts and ideas are greatly appreciated.

Thanks much, Frank, Carsten, Alec


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

[opnfv-tech-discuss] New project proposal: NFVbench

2017-04-12 Thread Frank Brockners (fbrockne)

Hi OPNFV,

over the past few weeks we've distilled a proposals to create a toolkit to 
allow for black-box performance testing of NFVI with a network focus:
NFVbench: https://wiki.opnfv.org/display/nfvbench/NFVbench+Project+Proposal

The NFVbench project is to develop a toolkit that allows developers, 
integrators, testers and customers to measure and assess the L2/L3 forwarding 
performance of an NFV-infrastructure solution stack (i.e. OPNFV scenario) using 
a black-box approach.

We're hoping for a discussion in the technical community meeting on April/20, 
and are also asking for an official TSC review post the technical community 
review on May/2, so that NFVbench can participate in Euphrates. Consequently, 
NFVbench asks for tentative inclusion into Euphrates.

Your thoughts and ideas are greatly appreciated.

Thanks much, Frank, Carsten, Alec


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

Re: [opnfv-tech-discuss] [release][danube] MS6 compliance assessment

2017-02-27 Thread Frank Brockners (fbrockne)

David,

for FDS, please see inline...

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Mittwoch, 22. Februar 2017 21:30
To: opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV 

Subject: [opnfv-tech-discuss] [release][danube] MS6 compliance assessment

Team,

I'd like to request that the PTLs for projects participating in Danube respond 
to the following questions, designed to assess compliance with MS6.

...FB: FDS does feature development (upstream), system integration and test – 
hence is a bit hard to fit into the below categories. Still, please find 
answers inline where they “kind of” fit.
Feature Projects
1. Please provide a list of commits for the following:
a. Enabling testing for your project in the Functest repo (or other test 
framework repo if you are not using functest)
b. Test case implementation in your project repo.
...FB: Tests were directly added to FuncTest for security groups testing: 
https://gerrit.opnfv.org/gerrit/#/c/28883/
2. Please indicate whether the scenarios with which your project is 
integrated are visible on the Functest dashboard.  If not, why?
...FB: The above patch isn’t merged yet.
Test Framework Projects
1. Please provide a list of commits for your self-validation tests.
Preliminary Documentation Requirement
1. Please provide a link to the preliminary documentation for your project.
...FB: See
https://git.opnfv.org/fds/tree/docs/scenarios/os-odl_l2-fdio-ha
https://git.opnfv.org/fds/tree/docs/scenarios/os-odl_l3-fdio-noha

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
___
opnfv-tech-discuss mailing list
opnfv-tech-discuss@lists.opnfv.org
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Re: [opnfv-tech-discuss] [release] E-release schedule

2017-02-16 Thread Frank Brockners (fbrockne)

David,

thanks for the summary. Let’s remind ourselves, that in OPNFV we’re really 
trying to meet the needs of two different audiences: (1) User/consumer of a 
readily integrated NFV stack – as well as marketing operations (2) 
Developer/tester of an NFV stack. Audience #1 is mostly interested in 
stability, even if that means that things are released a little later (i.e. you 
build on long released components). Audience #2 is pushing the envelope and 
requires the ability to evolve/develop and integrate the latest set of 
components; once working they desire to release things to allow others to build 
on top; and move on/start over.

The current 1.0/2.0/3.0 was an effort to meet the needs of both audiences, i.e.

·   Have a “major” release.

·   Allow developers to release scenarios when they are ready and evolve, 
without too much of a maintenance burden.
This is also why we typically did not fix component versions for a release, but 
said: Based or ODL Boron or later.

I agree that releases are not free – especially the “major” release, because it 
comes with significant documentation and coordination needs. That said, it is 
mostly the “major” release with a lot of central coordination which creates 
efforts. Labeling and pushing an updated version of test results and 
documentation is relatively low effort – and can even be done by a scenario 
team. It does not even require central coordination. And our pipeline is now 
mature enough to do these things with low/moderate overhead.

So rather than move back in history and go back to a single release every 6 
months, which will make OPNFV a very inflexible organization for developers, I 
would strongly suggest that we rather consider evolving the current release 
process. IMHO we should be ready to have monthly micro-releases (scenario 
owners publish those scenarios which are “ready”, i.e. have docs ready and pass 
testing), and every 6 months we do a macro-release (with marketing/press 
announcement) which includes the set of scenarios which are “ready” by then. 
Macro-releases can be coupled to certain upstream component versions (as 
selection criteria for what is in/out of a macro release) – whereas 
micro-release would enjoy complete freedom.

Thoughts?

Thanks, Frank



From: David McBride [mailto:dmcbr...@linuxfoundation.org]
Sent: Mittwoch, 15. Februar 2017 20:26
To: TECH-DISCUSS OPNFV <opnfv-tech-discuss@lists.opnfv.org>; 
opnfv-project-le...@lists.opnfv.org
Cc: Frank Brockners (fbrockne) <fbroc...@cisco.com>; Tapio Tallgren 
<tapio.tallg...@nokia.com>
Subject: [release] E-release schedule

Greetings,

During the TSC call, yesterday, I took an action to start an email discussion 
about the schedule for the 
E-release<https://wiki.opnfv.org/display/SWREL/E-River>.

Specifically, I suggested that we just plan for a single release, rather than 
three releases, as we've done in the past.  Then, when the release date 
approaches, we evaluate whether we need a point release, then schedule it at 
that time.

Why?

  *   Scheduling three releases has created a lot of confusion with the project 
teams  The purpose of the three releases is to give project teams time to debug 
and fix scenarios that are not ready for 1.0.  They are not separate 
development timelines with separate release milestones.  However, many believe 
that it isn't necessary to meet release milestones, because they will simply 
shift to the 2.0 or 3.0 release.
  *   In the past two releases, the new content released in 2.0 has been 
minimal.  For example, for Colorado 2.0, just two new scenarios were released.  
Human nature is such that, given the opportunity for a later deadline, many 
will take it.
  *   Releases are not free.  In addition to the overhead required for 
labeling, creating ISOs, and updating documentation, projects that released in 
previous releases, are required to update their code for subsequent releases to 
resolve any issues, even if they weren't intending to do any additional work on 
that major release.  For example, let's say that a project releases in Danube 
1.0, they're satisfied with their effort, so they shift their focus to the 
E-release.  However, changes after 1.0 break their scenario.  So, suddenly, 
they find themselves working on Danube 2.0, even though they aren't releasing 
any new scenarios. This process repeats for Danube 3.0.
During the TSC call, it was suggested that a 2.0 or 3.0 release provides an 
opportunity to integrate a late release of a major upstream component (e.g. 
ODL).  However, this is counter to our previous agreement not to change major 
upstream components after the 1.0 release.  Unfortunately, this happened in 
Colorado and created significant disruption, including a slip in the 2.0 
release.

Per our discussion on Tuesday, I've created a wiki 
page<https://wiki.opnfv.org/display/SWREL/E-Release+Schedule+discussion> to 
capture pros and cons of various schedule options.  Feel

[opnfv-tech-discuss] Project proposals for adding analytics to OPNFV

2017-02-07 Thread Frank Brockners (fbrockne)

Hi OPNFV,

over the past few weeks we've distilled two proposals to add analytics and more 
diagnostic capabilities to OPNFV and OPNFV scenarios. We've published the two 
new project proposals on the wiki:

*   Bamboo: https://wiki.opnfv.org/display/bamboo/Bamboo+Project+Proposal

*   VINA: https://wiki.opnfv.org/display/vina/VINA+Project+Proposal

Bamboo is to introduce the analytics infrastructure provided by PNDA.io to 
OPNFV. VINA is to offer discovery and system health status for VIMs. Both 
projects are to work and in hand and are expected to integrate with both 
Barometer, VES, Qtip, etc. - as well as integrate with the testresults 
post-processing that we already do.

We're hoping for a discussion in the technical community meeting on Feb/23, and 
are also asking for an official TSC review post the technical community review. 
Target would be the TSC call on March/7.

Your thoughts and ideas are greatly appreciated.

Thanks much, Frank

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

Re: [opnfv-tech-discuss] Labelling your Colorado repo for the release.

2016-09-22 Thread Frank Brockners (fbrockne)

Chris,

Juraj just completed tagging for FDS: 
https://git.opnfv.org/cgit/fds/tag/?h=colorado.1.0 (thanks Juraj!)

Frank

From: opnfv-project-leads-boun...@lists.opnfv.org 
[mailto:opnfv-project-leads-boun...@lists.opnfv.org] On Behalf Of Christopher 
Price
Sent: Mittwoch, 21. September 2016 19:24
To: opnfv-project-le...@lists.opnfv.org; opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-project-leads] Labelling your Colorado repo for the release.

Hi Project leads,

If you have not already done it, now is the right time to make sure you have 
the Colorado 1.0 label correctly applied to your repo.
Please follow the instructions here:  
https://wiki.opnfv.org/display/SWREL/Git+Tagging+Instructions+for+Colorado+Release

/ Chris

___
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] D-release schedule

2016-09-13 Thread Frank Brockners (fbrockne)

+1 – that sounds like a really simple resolution to the problem: “Unless you’re 
on the release branch and the release runs are done using the branch, you 
cannot participate in the release”.

Frank

From: Christopher Price [mailto:chrispric...@gmail.com]
Sent: Dienstag, 13. September 2016 21:06
To: David McBride <dmcbr...@linuxfoundation.org>
Cc: Dave Neary <dne...@redhat.com>; Frank Brockners (fbrockne) 
<fbroc...@cisco.com>; opnfv-project-le...@lists.opnfv.org; TECH-DISCUSS OPNFV 
<opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release 
schedule

I would suggest a simple rule is that a release candidate can only be produced 
from the release branch.

From: David McBride 
<dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>>
Date: Tuesday 13 September 2016 at 20:57
To: Christopher Price <chrispric...@gmail.com<mailto:chrispric...@gmail.com>>
Cc: Dave Neary <dne...@redhat.com<mailto:dne...@redhat.com>>, "Frank Brockners 
(fbrockne)" <fbroc...@cisco.com<mailto:fbroc...@cisco.com>>, 
opnfv-project-leads 
<opnfv-project-le...@lists.opnfv.org<mailto:opnfv-project-le...@lists.opnfv.org>>,
 TECH-DISCUSS OPNFV 
<opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release 
schedule

I think that we've reduced the branch-related overhead in 'Danube' by closing 
the stable branch window just 10 days before the release, as opposed to about a 
month with Colorado.  My concern about individual projects deciding whether to 
branch is that I think that it creates some confusion about the location of the 
candidate release.  I think it's simpler and more predictable if we have a 
common process for all projects participating in the release.

David

On Tue, Sep 13, 2016 at 8:21 AM, Christopher Price 
<chrispric...@gmail.com<mailto:chrispric...@gmail.com>> wrote:
We are making some progress.

While I do agree with this: “I think projects should have autonomy over when 
branches are created.”.
I also think it is up to the release project to set the projects with the 
latest date to do it if they want to participate in any given release.  I think 
that’s essentially what we are trying to tune and optimize for everyone in this 
dialog.

/ Chris

On 13/09/16 16:10, "Dave Neary" 
<opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 on behalf of dne...@redhat.com<mailto:dne...@redhat.com>> wrote:

Hi,

On 09/13/2016 06:42 AM, Frank Brockners (fbrockne) wrote:
> one thing that we’ve not closed on in the discussion last Tuesday is the
> stable-branching milestone. Per what Morgan and I elaborated on:
> Branching occurs a lot of unnecessary overhead for projects which have a
> single development stream only. Hence I’d like to propose that
>
> ·   the branching milestones **prior** to the release should
> **only** be applied to projects which do parallel development.
>
> ·   All other projects would branch on the release date – so that we
> have a proper maintenance branch.
>
> Thoughts?

I'm in favour of anything that removes process overhead from projects -
I think projects should have autonomy over when branches are created.

Thanks,
Dave.

--
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182<tel:%2B1-978-399-2182> / Cell: 
+1-978-799-3338<tel:%2B1-978-799-3338>
___
opnfv-tech-discuss mailing list

opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018<tel:%2B1.805.276.8018>
Email/Google Talk: 
dmcbr...@linuxfoundation.org<mailto: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] D-release schedule

2016-09-13 Thread Frank Brockners (fbrockne)

Hi Chris,

we can pull stable once projects are done with the work on the release (i.e. 
release criteria is met) – i.e. it does not have to be the release date itself, 
but whenever a project feels like “ready”. One week prior to the release sounds 
reasonable – assuming you know when you’ll release ;-).

BTW/ - Releng already adopts this “don’t branch” principle – they didn’t even 
branch for Colorado.

Frank

From: Christopher Price [mailto:chrispric...@gmail.com]
Sent: Dienstag, 13. September 2016 13:19
To: Frank Brockners (fbrockne) <fbroc...@cisco.com>; David McBride 
<dmcbr...@linuxfoundation.org>; opnfv-project-le...@lists.opnfv.org; 
TECH-DISCUSS OPNFV <opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release 
schedule

Hi Frank,

I’m not sure the release date is realistic.
Given the way we use stable branch in our CI and release processes it has been 
apparent that it takes around a week or more for the labels and artefacts to be 
generated from stable.

I do think using a “window” for projects to progress to D release or not is 
valuable.
I would suggest having the CI team provide guidance on the latest possible date 
to branch to stable for any release.  (This depends on project adherence to CI 
processes and the processes themselves.)

/ Chris

From: 
<opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>>
 on behalf of "Frank Brockners (fbrockne)" 
<fbroc...@cisco.com<mailto:fbroc...@cisco.com>>
Date: Tuesday 13 September 2016 at 12:42
To: David McBride 
<dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>>, 
opnfv-project-leads 
<opnfv-project-le...@lists.opnfv.org<mailto:opnfv-project-le...@lists.opnfv.org>>,
 TECH-DISCUSS OPNFV 
<opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release 
schedule

David,

one thing that we’ve not closed on in the discussion last Tuesday is the 
stable-branching milestone. Per what Morgan and I elaborated on: Branching 
occurs a lot of unnecessary overhead for projects which have a single 
development stream only. Hence I’d like to propose that

·   the branching milestones *prior* to the release should *only* be 
applied to projects which do parallel development.

·   All other projects would branch on the release date – so that we have a 
proper maintenance branch.

Thoughts?

Thanks, Frank

From: 
opnfv-project-leads-boun...@lists.opnfv.org<mailto:opnfv-project-leads-boun...@lists.opnfv.org>
 [mailto:opnfv-project-leads-boun...@lists.opnfv.org] On Behalf Of David McBride
Sent: Montag, 12. September 2016 23:52
To: 
opnfv-project-le...@lists.opnfv.org<mailto:opnfv-project-le...@lists.opnfv.org>;
 TECH-DISCUSS OPNFV 
<opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: Re: [opnfv-project-leads] [release] D-release schedule

Reminder... if you haven't yet reviewed the schedule, please do so before the 
TSC and release meetings on Tuesday, where it will likely be discussed.

David

On Thu, Sep 8, 2016 at 3:45 PM, David McBride 
<dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>> wrote:
Team,

I've posted an update to the 
schedule<https://wiki.opnfv.org/download/attachments/6827418/OPNFV%20Release%20%2522D%2522%20r2.pdf?version=1=1473367413338=v2>.
  Please review and provide feedback.

Note:  during the release meeting on Tuesday, we discussed removing the JIRA 
milestone, since it was not considered release gating.  Since then, I've 
changed my mind.  For the D-release, I expect that we will have implemented our 
JIRA processes sufficiently that we will be able to rely on JIRA to understand 
project status.  Therefore, it is appropriate to believe that if we still have 
unresolved JIRA issues assigned to the release, then the release is not 
complete.  We will be discussing exactly how this will be accomplished in the 
coming weeks.

David


--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018<tel:%2B1.805.276.8018>
Email/Google Talk: 
dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>
Skype: davidjmcbride1
IRC: dmcbride



--
David McBride
Release Manager, OPNFV
Mobile: +1.805.276.8018<tel:%2B1.805.276.8018>
Email/Google Talk: 
dmcbr...@linuxfoundation.org<mailto:dmcbr...@linuxfoundation.org>
Skype: davidjmcbride1
IRC: dmcbride
___ opnfv-tech-discuss mailing list 
opnfv-tech-discuss@lists.opnfv.org<mailto: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] Following up on Project Health metrics discussion

2016-09-08 Thread Frank Brockners (fbrockne)

s/now a page/not a page/

Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Frank 
Brockners (fbrockne)
Sent: Donnerstag, 8. September 2016 17:28
To: Christopher Price <chrispric...@gmail.com>; Raymond Paik 
<rp...@linuxfoundation.org>
Cc: opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Following up on Project Health metrics 
discussion

Hi Chris,

thanks – as long as we clearly position this effort as one of “trying to drive 
proper metrics”, we should be fine. I’m just concerned that once we have these 
toy metrics that people will start to rely on them and read things into them 
that are just not reflecting reality.  This should obviously be avoided.
I just updated the title of the wiki to reflect that this is a discussion page 
– and now a page with health metrics…

Thanks, Frank

From: Christopher Price [mailto:chrispric...@gmail.com]
Sent: Donnerstag, 8. September 2016 15:57
To: Frank Brockners (fbrockne) <fbroc...@cisco.com<mailto:fbroc...@cisco.com>>; 
Raymond Paik <rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>>
Cc: Daniel Smith <daniel.sm...@ericsson.com<mailto:daniel.sm...@ericsson.com>>; 
Dave Neary <dne...@redhat.com<mailto:dne...@redhat.com>>; SULLIVAN, BRYAN L 
<bs3...@att.com<mailto:bs3...@att.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] Following up on Project Health metrics 
discussion

Hi Frank,

I’m not sure I would equate the “rough metrics” implied in the current project 
lifecycle as providing significant guidance or establishing a meaningful 
measure of a projects maturity.  I might argue that they are sorely lacking on 
community discussion and agreement.

I see this dialog on community metrics as one vehicle for our community to 
chime in and help set these guidelines with the TSC.  I would not propose we 
stop doing this because we feel the lifecycle metrics are sufficient, rather 
the opposite in that this work may help us find meaningful lifecycle metrics as 
a community.

/ Chris

From: "Frank Brockners (fbrockne)" 
<fbroc...@cisco.com<mailto:fbroc...@cisco.com>>
Date: Thursday 8 September 2016 at 15:28
To: Raymond Paik <rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>>
Cc: Daniel Smith <daniel.sm...@ericsson.com<mailto:daniel.sm...@ericsson.com>>, 
Christopher Price <chrispric...@gmail.com<mailto:chrispric...@gmail.com>>, Dave 
Neary <dne...@redhat.com<mailto:dne...@redhat.com>>, "SULLIVAN, BRYAN L" 
<bs3...@att.com<mailto:bs3...@att.com>>, TECH-DISCUSS OPNFV 
<opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: RE: [opnfv-tech-discuss] Following up on Project Health metrics 
discussion

Ray,

thanks – in which case, let’s first try to get the overall project lifecycle 
concept adopted. Once done – and we have experiences with the project life 
cycle, we can look into whether we need to create additional metrics etc. We 
could do that as another iteration of the project lifecycle doc – but for now, 
it would be key to get the lifecycle really adopted by projects. Let’s do one 
step after the other.

Thanks, Frank

From: Raymond Paik [mailto:rp...@linuxfoundation.org]
Sent: Donnerstag, 8. September 2016 15:23
To: Frank Brockners (fbrockne) <fbroc...@cisco.com<mailto:fbroc...@cisco.com>>
Cc: Daniel Smith <daniel.sm...@ericsson.com<mailto:daniel.sm...@ericsson.com>>; 
Christopher Price <chrispric...@gmail.com<mailto:chrispric...@gmail.com>>; Dave 
Neary <dne...@redhat.com<mailto:dne...@redhat.com>>; SULLIVAN, BRYAN L 
<bs3...@att.com<mailto:bs3...@att.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] Following up on Project Health metrics 
discussion

Frank,

It's in the same spirit as the project lifecycle you mentioned earlier.  For 
example, I'd like to use it as one of the data points for guidance (as you 
noted) to highlight projects that are not doing as well

Thanks,

Ray

On Thu, Sep 8, 2016 at 2:28 AM, Frank Brockners (fbrockne) 
<fbroc...@cisco.com<mailto:fbroc...@cisco.com>> wrote:
Hi Ray,

question: What problem are we trying to solve with the metrics for project 
health?
For the project lifecycle we have a defined process already – so nothing new is 
needed.

Thanks, Frank

From: Raymond Paik 
[mailto:rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>]
Sent: Donnerstag, 8. September 2016 07:14
To: Daniel Smith <daniel.sm...@ericsson.com<mailto:daniel.sm...@ericsson.com>>
Cc: Christopher Price <chrispric...@gmail.com<mailto:chrispric...@gmail.com>>; 
Dave Neary <dn

Re: [opnfv-tech-discuss] Following up on Project Health metrics discussion

2016-09-08 Thread Frank Brockners (fbrockne)

Ray,

thanks – in which case, let’s first try to get the overall project lifecycle 
concept adopted. Once done – and we have experiences with the project life 
cycle, we can look into whether we need to create additional metrics etc. We 
could do that as another iteration of the project lifecycle doc – but for now, 
it would be key to get the lifecycle really adopted by projects. Let’s do one 
step after the other.

Thanks, Frank

From: Raymond Paik [mailto:rp...@linuxfoundation.org]
Sent: Donnerstag, 8. September 2016 15:23
To: Frank Brockners (fbrockne) <fbroc...@cisco.com>
Cc: Daniel Smith <daniel.sm...@ericsson.com>; Christopher Price 
<chrispric...@gmail.com>; Dave Neary <dne...@redhat.com>; SULLIVAN, BRYAN L 
<bs3...@att.com>; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Following up on Project Health metrics 
discussion

Frank,

It's in the same spirit as the project lifecycle you mentioned earlier.  For 
example, I'd like to use it as one of the data points for guidance (as you 
noted) to highlight projects that are not doing as well

Thanks,

Ray

On Thu, Sep 8, 2016 at 2:28 AM, Frank Brockners (fbrockne) 
<fbroc...@cisco.com<mailto:fbroc...@cisco.com>> wrote:
Hi Ray,

question: What problem are we trying to solve with the metrics for project 
health?
For the project lifecycle we have a defined process already – so nothing new is 
needed.

Thanks, Frank

From: Raymond Paik 
[mailto:rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>]
Sent: Donnerstag, 8. September 2016 07:14
To: Daniel Smith <daniel.sm...@ericsson.com<mailto:daniel.sm...@ericsson.com>>
Cc: Christopher Price <chrispric...@gmail.com<mailto:chrispric...@gmail.com>>; 
Dave Neary <dne...@redhat.com<mailto:dne...@redhat.com>>; Frank Brockners 
(fbrockne) <fbroc...@cisco.com<mailto:fbroc...@cisco.com>>; SULLIVAN, BRYAN L 
<bs3...@att.com<mailto:bs3...@att.com>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>

Subject: Re: [opnfv-tech-discuss] Following up on Project Health metrics 
discussion

All,

Glad to see the thread coming back to life (plus comments on the wiki) :-) 
Definitely understand concerns about the composite score.  Maybe another option 
would be to start by looking at 4 areas (git, Jira, wiki, etc.) individually.

I also want to suggest that if a project is active (and even if most of the 
work is being done upstream) I doubt the activities in OPNFV repo or other 
tools would be zero over a period of 3-6 months.  So I think having a regular 
metrics (composite or otherwise) would be helpful in identifying projects that 
are either in need of help or are candidates for "archiving"

My 2 cents

Ray

On Wed, Sep 7, 2016 at 9:42 PM, Daniel Smith 
<daniel.sm...@ericsson.com<mailto:daniel.sm...@ericsson.com>> wrote:
Hello All.

My take on this and sorry maybe a bit blunt, but I don’t see what the purpose 
is here?

While guideline, guidance and such are good things, the discussion below seems 
awfully heavy and very boxed in.

As Chris in the evaluation on how to improve the community, I am not sure how 
we could ever resolve what one person thinks is an adequate measure of 
something over another (i.e endless debate), since metrics, improvements - 
unless we are talking about something quantifiable - and that would mean taking 
this to code optimization level ultimately - are subjective based and 
implement/reaction based measured over time in the case of adjustment.

As well +1 to doing our own assessments - since it should be us that outlines 
what we want to say about how we feel we have improved, and this only makes 
sense I would think as we are the only ones who have the context to see where 
we came from to where we are and what we are talking about doing next.

I would say however, that I am really concerned at that level of discussion 
across all meetings on project handling and process and such - release and 
otherwise - while this shows we are active and "moving" sure - there is a lot 
of dissonance in the communication, mixed messages and again, lots of 
information overflow.   I would like to see the "Operational" parts of OPNFV 
(Release Project, INFRA, TSC) focus more on how we support the projects in 
terms of day to day pain points - that is a solid, referable release process, a 
solid, regularly maintained method of publish,  a solid Change process (for 
anything) that ensures that we don’t discuss and move from one week to another 
- not because an idea is good or bad, but simply cause we need to recognize 
that there are more than the 25 or so regular attendees in the groups / this 
mailing list.

Would there be a market for such publishing outside our domain I would wonder?  
For Code stats and fun numbers those are nice to have, but a qualitative review 
of how we have impr

Re: [opnfv-tech-discuss] Following up on Project Health metrics discussion

2016-09-08 Thread Frank Brockners (fbrockne)

Hi Ray,

question: What problem are we trying to solve with the metrics for project 
health?
For the project lifecycle we have a defined process already – so nothing new is 
needed.

Thanks, Frank

From: Raymond Paik [mailto:rp...@linuxfoundation.org]
Sent: Donnerstag, 8. September 2016 07:14
To: Daniel Smith <daniel.sm...@ericsson.com>
Cc: Christopher Price <chrispric...@gmail.com>; Dave Neary <dne...@redhat.com>; 
Frank Brockners (fbrockne) <fbroc...@cisco.com>; SULLIVAN, BRYAN L 
<bs3...@att.com>; opnfv-tech-discuss@lists.opnfv.org
Subject: Re: [opnfv-tech-discuss] Following up on Project Health metrics 
discussion

All,

Glad to see the thread coming back to life (plus comments on the wiki) :-) 
Definitely understand concerns about the composite score.  Maybe another option 
would be to start by looking at 4 areas (git, Jira, wiki, etc.) individually.

I also want to suggest that if a project is active (and even if most of the 
work is being done upstream) I doubt the activities in OPNFV repo or other 
tools would be zero over a period of 3-6 months.  So I think having a regular 
metrics (composite or otherwise) would be helpful in identifying projects that 
are either in need of help or are candidates for "archiving"

My 2 cents

Ray

On Wed, Sep 7, 2016 at 9:42 PM, Daniel Smith 
<daniel.sm...@ericsson.com<mailto:daniel.sm...@ericsson.com>> wrote:
Hello All.

My take on this and sorry maybe a bit blunt, but I don’t see what the purpose 
is here?

While guideline, guidance and such are good things, the discussion below seems 
awfully heavy and very boxed in.

As Chris in the evaluation on how to improve the community, I am not sure how 
we could ever resolve what one person thinks is an adequate measure of 
something over another (i.e endless debate), since metrics, improvements - 
unless we are talking about something quantifiable - and that would mean taking 
this to code optimization level ultimately - are subjective based and 
implement/reaction based measured over time in the case of adjustment.

As well +1 to doing our own assessments - since it should be us that outlines 
what we want to say about how we feel we have improved, and this only makes 
sense I would think as we are the only ones who have the context to see where 
we came from to where we are and what we are talking about doing next.

I would say however, that I am really concerned at that level of discussion 
across all meetings on project handling and process and such - release and 
otherwise - while this shows we are active and "moving" sure - there is a lot 
of dissonance in the communication, mixed messages and again, lots of 
information overflow.   I would like to see the "Operational" parts of OPNFV 
(Release Project, INFRA, TSC) focus more on how we support the projects in 
terms of day to day pain points - that is a solid, referable release process, a 
solid, regularly maintained method of publish,  a solid Change process (for 
anything) that ensures that we don’t discuss and move from one week to another 
- not because an idea is good or bad, but simply cause we need to recognize 
that there are more than the 25 or so regular attendees in the groups / this 
mailing list.

Would there be a market for such publishing outside our domain I would wonder?  
For Code stats and fun numbers those are nice to have, but a qualitative review 
of how we have improved our processes as a community, im not sure?  I would 
vouchsafe that our work in the projects themselves are what OPNFV is pushing 
out, the operational aspects of "how we are doing things" - while nice to 
outline, against the backdrop of every growing laundry list of things to 
"Decide" is really not high on a list?I didn’t understand from below the 
"why" and "who" for this fully.


Cheers and thank you
D




-Original Message-
From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>]
 On Behalf Of Christopher Price
Sent: Wednesday, September 07, 2016 9:20 PM
To: Dave Neary <dne...@redhat.com<mailto:dne...@redhat.com>>; Frank Brockners 
(fbrockne) <fbroc...@cisco.com<mailto:fbroc...@cisco.com>>; SULLIVAN, BRYAN L 
<bs3...@att.com<mailto:bs3...@att.com>>; Raymond Paik 
<rp...@linuxfoundation.org<mailto:rp...@linuxfoundation.org>>; 
opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] Following up on Project Health metrics 
discussion

Good comments Dave and everyone, I’d like to share my take on it is this.

I don’t see any problem in looking at the metrics we already publish and using 
them to help us create a better understanding across our community on how we go 
about getti

Re: [opnfv-tech-discuss] Following up on Project Health metrics discussion

2016-09-06 Thread Frank Brockners (fbrockne)

Hi Ray,

thanks for posting the initial cut. IMHO a "composite score", as proposed on 
the page, could be *very* misleading, especially for projects which do most of 
the work upstream. So unless we track all upstream repos and upstream Jiras (or 
similar), I would suggest to *not* compute a composite score but evaluate 
things qualitatively only.

Thanks, Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Raymond Paik
Sent: Montag, 29. August 2016 19:33
To: opnfv-tech-discuss@lists.opnfv.org
Subject: [opnfv-tech-discuss] Following up on Project Health metrics discussion

All,

I had an action item from last week to start a wiki page for the "project 
health metrics".  You can find a proposal page at 
https://wiki.opnfv.org/display/PROJ/Project+Health+Metrics.

Please add your comments/feedback via email or directly on the wiki page.  I 
listed four activity areas that was discussed on the TSC call, but feel free to 
add other activities that the community should consider.

Thanks,

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

Re: [opnfv-tech-discuss] Working with the docs toolchain locally on your laptop.

2016-08-10 Thread Frank Brockners (fbrockne)

Just to clarify: I’d like to use the OPNFV tool chain on a set of specific 
files only and see whether they render correctly – as opposed to just use 
rst2html (which is what I currently do).

Thanks, Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Frank 
Brockners (fbrockne)
Sent: Mittwoch, 10. August 2016 13:28
To: Christopher Price <christopher.pr...@ericsson.com>; TECH-DISCUSS OPNFV 
<opnfv-tech-discuss@lists.opnfv.org>
Subject: Re: [opnfv-tech-discuss] Working with the docs toolchain locally on 
your laptop.

Hi Chris,

thanks for the pointer. Is there a way to just check whether a single file 
builds/parses correctly – rather than always building the entire project?

Thanks, Frank

From: 
opnfv-tech-discuss-boun...@lists.opnfv.org<mailto:opnfv-tech-discuss-boun...@lists.opnfv.org>
 [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Christopher 
Price
Sent: Mittwoch, 10. August 2016 12:29
To: TECH-DISCUSS OPNFV 
<opnfv-tech-discuss@lists.opnfv.org<mailto:opnfv-tech-discuss@lists.opnfv.org>>
Subject: [opnfv-tech-discuss] Working with the docs toolchain locally on your 
laptop.

Hi Community,

While our CI system provides a complete docs renderer that gives you up to date 
links to your documentation when you push a patch for review it may be useful 
for you to work with the toolchain locally while doing you Colorado 
documentation.

This has been made rather simple by our champion of docs scripting Ryota and 
the procedure is kept up to date and relevant at this link:
http://artifacts.opnfv.org/opnfvdocs/docs/how-to-use-docs/documentation-example.html#testing

If you would like to render your docs as you go, please try the toolchain above.
If you prefer you can also simply push a docs patch and follow the links 
provided on the review page.

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

Re: [opnfv-tech-discuss] Working with the docs toolchain locally on your laptop.

2016-08-10 Thread Frank Brockners (fbrockne)

Hi Chris,

thanks for the pointer. Is there a way to just check whether a single file 
builds/parses correctly – rather than always building the entire project?

Thanks, Frank

From: opnfv-tech-discuss-boun...@lists.opnfv.org 
[mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Christopher 
Price
Sent: Mittwoch, 10. August 2016 12:29
To: TECH-DISCUSS OPNFV 
Subject: [opnfv-tech-discuss] Working with the docs toolchain locally on your 
laptop.

Hi Community,

While our CI system provides a complete docs renderer that gives you up to date 
links to your documentation when you push a patch for review it may be useful 
for you to work with the toolchain locally while doing you Colorado 
documentation.

This has been made rather simple by our champion of docs scripting Ryota and 
the procedure is kept up to date and relevant at this link:
http://artifacts.opnfv.org/opnfvdocs/docs/how-to-use-docs/documentation-example.html#testing

If you would like to render your docs as you go, please try the toolchain above.
If you prefer you can also simply push a docs patch and follow the links 
provided on the review page.

Regards,
Chris
___
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-tsc] Red-lined TSC Charter Document

Re: [opnfv-tech-discuss] [releng] Committer list per Releng repository

Re: [opnfv-tech-discuss] [releng] Committer list per Releng repository

Re: [opnfv-tech-discuss] urgent euphrates git tags vote needed

Re: [opnfv-tech-discuss] [announce] 2018 OPNFV release names

Re: [opnfv-tech-discuss] [infra] Proposal for LaaS Hardware

Re: [opnfv-tech-discuss] [infra] Proposal for LaaS Hardware

Re: [opnfv-tech-discuss] [OPNFV] ODL target Release for Euphrates

Re: [opnfv-tech-discuss] [OPNFV] ODL target Release for Euphrates

Re: [opnfv-tech-discuss] [release][announce] RESPONSE REQUIRED / proposed change to release date for Danube 3.0

Re: [opnfv-tech-discuss] [release][euphrates] RESPONSE REQUIRED - Milestone 2 - test case documentation - May 22

Re: [opnfv-tech-discuss] [release][danube] Danube 3.0 - June 8

Re: [opnfv-tech-discuss] New project proposal: NFVbench

[opnfv-tech-discuss] New project proposal: NFVbench

Re: [opnfv-tech-discuss] [release][danube] MS6 compliance assessment

Re: [opnfv-tech-discuss] [release] E-release schedule

[opnfv-tech-discuss] Project proposals for adding analytics to OPNFV

Re: [opnfv-tech-discuss] Labelling your Colorado repo for the release.

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

Re: [opnfv-tech-discuss] [opnfv-project-leads] [release] D-release schedule

Re: [opnfv-tech-discuss] Following up on Project Health metrics discussion

Re: [opnfv-tech-discuss] Following up on Project Health metrics discussion

Re: [opnfv-tech-discuss] Following up on Project Health metrics discussion

Re: [opnfv-tech-discuss] Following up on Project Health metrics discussion

Re: [opnfv-tech-discuss] Working with the docs toolchain locally on your laptop.

Re: [opnfv-tech-discuss] Working with the docs toolchain locally on your laptop.

26 matches

Site Navigation

Mail list logo

Footer information