Hi Folks,
We may have a definition issue here as I think we are all doing the right things as far as we have defined them. Not part of the release: Documents describing requirements are not tracked, nor required to pass specific milestones for a release. The only milestone that is important is docs freeze and what is available is up to the project writing the docs and is not coordinated by the release project. Delivered with Colorado: Requirement or descriptive docs can be included in the document publication of release artifacts by including them on the release page as we did in Brahmaputra. This is OK as long as we are able to differentiate documentation of delivered platform capability and documentation of planned or projected capability. (Future requirements should not be in the same document as the release description) Talk to your friendly docs team about these types of docs you would like to have included in the “Colorado library”. Hope this helps clear things up. As we discussed after Brahmaputra, but not acted upon yet. It would be great for our projects doing “requirements documentation” to collaborate on some form of structure, standard and template with the docs team to make this more consistent and automated. / Chris From: <opnfv-tech-discuss-boun...@lists.opnfv.org> on behalf of David McBride <dmcbr...@linuxfoundation.org> Date: Wednesday 31 August 2016 at 16:58 To: "Kunzmann, Gerald" <kunzm...@docomolab-euro.com> Cc: TECH-DISCUSS OPNFV <opnfv-tech-discuss@lists.opnfv.org> Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects Published in C release Hi Gerald, I'm certainly aware that many project do most, or even all, of their work upstream. When I say "deliver code", that includes making changes in upstream projects. Also, to be clear, I'm NOT saying that requirements projects should not be part of OPNFV, I'm just saying that I do not see the benefit of a project joining a release if their only activity is writing a requirements document. Join the OPNFV project, write a requirements document, then join a release. Perhaps I'm missing something, though. What benefit do you see in the release process for projects that are only writing requirements? Why could that not be done as part of the OPNFV project, but outside of the release process? David On Wed, Aug 31, 2016 at 12:51 AM, Kunzmann, Gerald <kunzm...@docomolab-euro.com> wrote: Hi David, all, My 2 cent on your question: The question is: does it make sense for requirements projects to participate in releases until they're ready to deliver code? Requirement projects are an essential part of OPNFV and some may even do all development in upstream, i.e. there might even be no code within OPNFV except test cases. Thus, I support having the requirement documents as part of the release documentation. Best regards, Gerald From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Georg Kunz Sent: Mittwoch, 31. August 2016 09:42 To: Daniel Smith <daniel.sm...@ericsson.com>; David McBride <dmcbr...@linuxfoundation.org> Cc: opnfv-tech-discuss@lists.opnfv.org Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects Published in C release Hi Daniel, hi all, Thank you Daniel for stating the advantages for the requirements projects and for OPNFV. From my point of view it is important for projects which are currently in the “requirements phase” to be represented in an OPNFV release: - We are in the process of reaching out to the OpenStack community based on our document. Making the requirements document an official part of an OPNFV release helps us in doing that by having an “official backing” of OPNFV (we are an OPNFV project after all) - It shows to the outside world that projects are active in all phases (requirements phase), supporting the overall perception of OPNFV - It gives the project members the feeling of contributing to OPNFV I had some discussions with Chris and Sofia on this during the OPNFV summit. Back then the proposal was to include our requirements document in the “document library” under a section such as “requirements projects”. This could be a simple link – just as we have it right now on our project wiki. As David pointed out, there is some overhead involved for the project, but I believe the benefits outweigh the overhead. Looking forward to discussing with you in today’s docs meeting. Best regards Georg From: opnfv-tech-discuss-boun...@lists.opnfv.org [mailto:opnfv-tech-discuss-boun...@lists.opnfv.org] On Behalf Of Daniel Smith Sent: Tuesday, August 30, 2016 11:44 PM To: David McBride Cc: opnfv-tech-discuss@lists.opnfv.org Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects Published in C release Hey All. I spoke with Sofia as well about this and presented our NetReady situation. We have a document that covers what we wanted to cover for Phase 1 (targeting C release) of the NetReady Requirements Project. We now want to stop internally editing it and release it for comment – and the thinking is that, since we have built the document in gerrit and based on DOCS formatting guidelines, was the vehicle to provide the following in terms of the work that the team did: - Allow for the completion and publishing of the Project Goals Phase 1 targets (in line with agreed principles when the project was approved/started) – Phase2,3,4 as outlined are targeted for subsequent releases as documented - Allow for the distribution of the finished product to external (non commiter/contributer groups) - is it realistic to think that someone from Openstack (whom the requirements are destined for) will look at the RST line format in our gerrit repository to find our documentation? (rather than in the released docs page/artifact)? Or perhaps a different way of looking at it would be to ask, how do we move the finished requirements document for C release to a platform to be viewed and commented (i.e JIRA for D release for review or in gerrit) going forward - Allows us to tag and timestamp the work (and thus the evolution) of the work the team is doing. Provides start and stop points to coordinate work for the team (goal/endpoints). - Allows all projects to feel that they are contributing to a finished release product o Further to that maybe this plays into the idea of “release participation” discussion. At any rate, I thought that Sofia’s response of there would be a ../release/Colorado/docs/RequirementProcject page in the final release that would point to the links that requirements projects delivered and that made sense to me. In the end do as you see fit of course, I would wonder about how requirements projects are to gain inclusiveness in releases and how that affects the ability to trace back to “why did we make this code” when that comes time – since that backstory would have to be ported at that point. Thank you all for the responses. Daniel From: David McBride [mailto:dmcbr...@linuxfoundation.org] Sent: Tuesday, August 30, 2016 2:25 PM To: Daniel Smith <daniel.sm...@ericsson.com> Cc: Sofia Wallin <sofia.wal...@ericsson.com>; opnfv-tech-discuss@lists.opnfv.org Subject: Re: [opnfv-tech-discuss] How are Documentation/Reference Projects Published in C release Hi Daniel, We've had some discussion about this in various meetings, including hackfest, over the past several weeks. The question is: does it make sense for requirements projects to participate in releases until they're ready to deliver code? It's not clear to me that there's any advantage to either the project, or OPNFV as a whole. Furthermore, there's a certain amount of overhead for each project that participates in the release, so if there's no advantage, then perhaps it would be better to wait to join the release until the project is prepared to deliver code. However, I'm open to alternative viewpoints. Thanks. David On Tue, Aug 30, 2016 at 12:29 PM, Daniel Smith <daniel.sm...@ericsson.com> wrote: Hey David and Sofia. In the NetReady group, we have structured our documentation and commits for our C-release documentation in RST format/doc guidelines under the auspices that this was required so that when the DOCS are generated for the release, requirements and documentation projects deliveries are included in the release. In our meeting there was some confusion as to how Requirements Projects, that delivery requirements documents (which are finalized for this phase and then later phases – prototyping, etc occurs for D release, based on the C deliveable) are actually included in the release. Some input was that Requirements projects, since they don’t deliver code are not part of the release? That didn’t sound correct me, so please clarify when you have time. Thank you Daniel Smith Sr. System Designer Ericsson Inc. 8400 Decarie Blvd. Montreal, PQ (514)-594-2799 Legal entity: Ericsson AB, registered office in Stockholm. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer -- 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
