Vote
Note the Background Material below for informal polls that are not explicit in the proposal.
Additional Background Information
After many discussions, the Release Process Slides as of June 9th Release Meeting are attached below (updated June 21, 2020)
Polls
| Type | Project Name |
|---|---|
| Participate in release under this process |
|
| Self-Release only, as defined in the process |
|
NOTE: The latest proposal does not include this categorization below.
Note: Only list projects in the table below that are planning to participate in the next OPNFV release.
| Type | Project Name |
|---|---|
| INTEGRATED Projects that are planning to participate in the next OPNFV release and categorize themselves as "integrated" per the draft release process proposal (see slide 13 in the deck below) | |
| NON-INTEGRATED Projects that are planning to participate in the next OPNFV release and categorize themselves as "integrated" per the draft release process proposal (see slide 13 in the deck below) |
|
21 Comments
sunku ranganath
The document talks about "multiple stakeholders" across various places. From what I understand CNTT is one of the stakeholders that can provide requirements.
The backup slide provides example of what stakeholders could be. However could we add a FAQ possibly in the lines of "I am a PTL, how do I know who are my stakeholders and how do I find them" and provide examples of stakeholders apart from CNTT?
David McBride
A stakeholder could be anyone that's using your code.
For this proposal, you can think of two levels of requirements: 1) OPNFV requirements that come in through the requirements proposal process; 2) work that the project has determined on its own should be done (e.g., new features, bug fixes, etc.). The first case is designed to manage requirements that span multiple projects, or that come from CNTT, in particular. Some OPNFV projects may rarely or never be affected by #1. In that case, they would simply work on their individual project requirements (i.e., #2).
As the lead for the Closed Loop Automation working group, you could also be a requirements stakeholder. You may have a use case or a requirement for which you need effort by one or more OPNFV projects. So, you could write a requirement and submit it to the requirements subcommittee for consideration for the release.
sunku ranganath
Thanks David McBride These are good examples. I remember even GSMA was mentioned as one of the stakeholder.
Would you be adding the above examples as a FAQ or possibly in detailed wiki later? I believe FAQ would be great, since more folks might have same question and we dont have to repeat this later.
Al Morton
I have used term stakeholder slightly differently, to mean the organization(s) that is/are willing to step-up and staff development for a particular set of requirements. Ideally, each requirement presented to OPNFV identifies one or more organizations that are willing to make such a commitment. Further, when these organizations continue to use the tools/tests that meet their requirements, they must recognize that maintenance is a continuing responsibility as well as initial development. As Cedric Ollivier often points-out, maintenance is a larger and more critical part of some test projects than new feature development, owing to the evolution of what they test (APIs, etc.).
So in many cases, the participants allocated by stakeholders must transition from architect to developer roles, in order to realize their goals.
David McBride
Unknown User (sujata.tibrewala@intel.com) I'm adding a FAQ page for this topic to the next iteration of the slide deck. Thanks for the suggestion.
sunku ranganath
Another question, its not clear how would a project's 'Self release' based release tie in with OPNFV's release that happens every 6 months.
Would OPNFV release collateral consider the tagged repo of latest release of a self-released project to be included at the time of OPNFV release or would it be completely ignored as the project chose to self-release?
David McBride
All project releases would be self-releases. For OPNFV major releases, projects would be asked to provide a release that:
Presumably, this would be the self-release that occurs closest to the OPNFV major release, but not necessarily.
sunku ranganath
Ok. So during the major OPNFV release, the latest self-release from all of the projects would be consolidated as a single release.
David McBride
Correct. Projects would be encouraged to contribute to OPNFV major releases, but could opt out if necessary.
Frank Brockners
Reading through the deck, I can follow the logic - having been through a series of discussions.
That said, the flow of the deck and the naming of the project categories is IMHO a bit counter-intuitive and might even be confusing to someone who does not have the history, i.e. "non integrated" is the base release process that likely every project in OPNFV would follow though "non integrated" does not really mean that the project does not integrate with anything, but it just does not follow any CNTT-related gating. Whereas "integrated" is specific to CNTT related requirements and follows a gating process.
As such, could we consider renaming the two categories to:
This category would likely match to e.g. the "tools" oriented projects in OPNFV.
In addition, the "requirements subcommittee" would be a key part of the new release process.
Given that we don't have a notion of subcommittees in OPNFV yet - IMHO we'd need a description how such a subcommittee would be formed, organized, run, etc.
sunku ranganath
Agree that the names integrated/non-integrated are not trivial at first. However its not hard to understand once anyone goes through the document.
The term "simultaneous-release" is not very easy to grasp at first stretch too.
Also from various conversations, I figured, we dont want various categories - CNTT-integrated, GSMA-integrated, ABC-integrated, etc. It will be a tough mix of alphabet soup with less clarity on what they all mean. Rather it might be easier to have single 'integrated' (or whatever we call it) project!
Requirements subcommittee seem to be a great idea!
Just my 2 cents.
Frank Brockners
Hi Sunku - right now "integrated" is very specific about CNTT. So if we want to have a more general "integrated" category, we probably need to revisit this definition-
Al Morton
Hi Frank, Regarding TSC Sub-Committees:
The TSC already formed a Sub-committee by simply recognizing the need and asking for volunteers: The OPNFV 2.0 committee that was chaired by Qiao Fu. They held weekly meetings after polling for meeting times and primarily worked to create new mission statements. I understand that ONAP has created similar sub-committees of their TSC. The 2.0 Committee's work was put on hold while we help CNTT at their Future Mode of Operation meetings, since resolving issues with current work relationships has a direct effect on OPNFV. The role of the Requirements Sub-Committee seems clear-enough to organize, under the assumption that it is part of the Release process and will evolve as necessary (like every Release since Arno).
Frank Brockners
Thanks Al. Good point on OPNFV 2.0 - I missed that it isn't a working group but a sub-committee.
Per your note, we likely want to formalized what sub-committees are and how they operate if we start to have more of them and they become less "ad hoc" (like the ONAP subcommittees).
IMHO we form a dedicate sub-committee for requirements. This could be done as part of the TSC - and would thus avoid creating additional org.
Al Morton
I mostly agree, Frank, that this Requirements vetting activity needs to be a TSC sub-committee. The TSC has chartered rights to create such committees (iv.creating sub-committees or working groups to focus on cross-project technical issues and requirements; from our charter ). But with over 100 requirements coming from CNTT alone, I'm sure this committee will need more than a few TSC meeting time-slots to deal with that volume.
Cedric Ollivier
Thank you for adding "projects may veto requirements that affect their project and engage in negotiations with requirements stakeholders over blocking issues, such as resource constraints."
"Supporting CNTT requirements will be the highest priority for OPNFV for the foreseeable future" is still unlinked to the project activity.
Maintenance is always more important than the new features if long term success is targeted.
This bullet is quite unclear more if we dive into CNTT FMO discussions which seem targeting resources per new requirements.
Cedric Ollivier
I consider Functest as non integrated:
Functest Jerma was already released (Train is being considered as next CNTT releases)
David McBride
That's incorrect. Functest would be integrated.
Cedric Ollivier
David McBride as far as I know, you haven't submitted any code in Functest.
I don't see why Functest needs an overhead/override in such a case (out of new Functest testcases, nothing in case of RA1).
Even from an overall point of view, these rules may have been applied with a decent amount of developers and all entities composed of contributors or contributing compagnies.
In the current context, it could quickly raise lots of side effects as companies could decide for others.
Al Morton
Given that comments have continued past the original comment close date (June 11), and that recent comments will result in changes to the process description (revised slides today, June 19), I think it only fair to continue discussion and keep the voting open through the next TSC meeting (June 23) when we will discuss and agree on the new schedule and closing date for the vote.
Cedric Ollivier
Meanwhile I would appreciate to know the project list supporting this new release model (it has been asked multiple times).