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
>
>
>
>
>
> [image: Ericsson] <http://www.ericsson.com/>
>
>
>
> Daniel Smith
>
> Sr. System Designer
>
> Ericsson Inc.
>
> 8400 Decarie Blvd.  Montreal, PQ
>
> (514)-594-2799
>
>
>
> [image: http://www.ericsson.com/current_campaign]
> <http://www.ericsson.com/current_campaign>
>
>
>
> 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

Reply via email to