Hi, so as long as it goes about the new release process I share Lukasz point of view.
Key differences between old release process and new one is: 1) Split technical discussion on proposed change and the resource discussion 2) Let people interested in the requirement plan their work how they want and not force them to do everything till the particular milestone. So in the new release process the Feature or Spec is a technical description of the proposed change. It should clearly present what people want to achieve and by design this is not tight to the particular release. The only thing that we require is to get Feature/Spec approved by impacted parties before the M2. If someone fails to meet the deadline and get it approved a week later his or her feature can be worked on in the next release but not the current one. As we have removed the resource part from the table, TSC will no longer need to waste their time to try to asses how many Features or specs we can fit into particular release or to decide what to descope and what not. If the proposed change is technically correct and impacted parties are fine with it then community may start working on it. When it will be ready? It's all matter of resources that community is willing to dedicate to this task but it's purely the decision of interested companies. If this feature has top priority for them they may assign enough resources to implement that in a week but if it's a low priority task they may be working on it for 3 years. When they finish and test their solution they would just report to TSC by updating particular ticket that this feature is finally ready and that's it. This model is nothing new in the open source community. It's exactly the model in which Open Stacks specs or kubernetes KEPs are being used. On 02.12.2020 19:38, David McBride wrote: > Remember that scope affects planning and resource allocation for the > release. It also affects how the TSC evaluates milestone progress and > GO/NOGO decisions. For example, the component impact table documents > what components will be impacted by the defined scope of the > requirement. If your scope includes work that you won't do until > subsequent releases, then the component impact table may imply > allocation of resources that isn't necessary. > > Also, if your defined scope is broader than what you intend to complete > in the release, then it confuses TSC evaluation of your progress at > milestones. > > Perhaps a good compromise would be to include two parts in the > requirement description. The first part would document the overall > scope of the requirement, while the second part would document the scope > that you intend to complete for the current release. > > David > > On Wed, Dec 2, 2020 at 10:21 AM Rajewski Łukasz - Hurt > <lukasz.rajew...@orange.com <mailto:lukasz.rajew...@orange.com>> wrote: > > So we mix here scope for release with the scope of the entire > requirement what is not the same. If the requirements can be > defined for many releases the scope for each release is a part of > the entire one. Otherwise what we mean by continuation of > requirements by design? There is no such option then and you > consider only continuation for reqs that have some leftovers but the > original plan was to deliver them in one release. ____ > > __ __ > > So do we really let requirements to be split into many releases by > design? I have an impression that no because nobody plans > non-intentional delays in the implementation by design.____ > > __ __ > > Regards,____ > > __ __ > > Logo Orange____ > > > > *Łukasz Rajewski*, R&D Expert > Orange Labs Poland, Advanced Network Solutions Agency > *Mob.: +48 519 310 854* > Orange Polska, Obrzeżna 7, 02-691 Warsaw > www.orange.pl <http://www.orange.pl/>____ > > *From:*David McBride <dmcbr...@linuxfoundation.org > <mailto:dmcbr...@linuxfoundation.org>> > *Sent:* Wednesday, December 2, 2020 6:51 PM > *To:* Rajewski Łukasz - Hurt <lukasz.rajew...@orange.com > <mailto:lukasz.rajew...@orange.com>> > *Cc:* onap-tsc@lists.onap.org <mailto:onap-tsc@lists.onap.org>; > onap-release <onap-rele...@lists.onap.org > <mailto:onap-rele...@lists.onap.org>>; > onap-usecase...@lists.onap.org > <mailto:onap-usecase...@lists.onap.org>; Kenny Paul > <kp...@linuxfoundation.org <mailto:kp...@linuxfoundation.org>> > *Subject:* Re: [onap-requirements-sub] [onap-tsc] Continuing a REQ > from one release to the next #guilin #honolulu____ > > __ __ > > I respectfully disagree. ____ > > __ __ > > It's fine to plan implementation of a requirement over multiple > releases. Nothing in this process contradicts that. However, the > scope defined in the Jira issue, should be the scope that you expect > to complete _for that release_, and not the entire requirement. ____ > > __ __ > > David____ > > __ __ > > On Wed, Dec 2, 2020 at 9:45 AM Lukasz Rajewski via lists.onap.org > > <https://protect2.fireeye.com/v1/url?k=5a58f1b2-05c3c8be-5a597afd-000babff3563-899c330ddc3a7129&q=1&e=b87cfa09-afb3-498f-b5f1-2fdf2ae616c2&u=http%3A%2F%2Flists.onap.org%2F> > <lukasz.rajewski=orange....@lists.onap.org > <mailto:orange....@lists.onap.org>> wrote:____ > > Hi,____ > > ____ > > one major remark. I believe this is wrong assumption that REQ by > „design” must be completed in one release. If feature is big and > releases are more frequent it is impossible to deliver bigger > changes in one release. In consequence, such feature by default > must be split into several consecutive releases and setting the > scope status “reduced scope” is wrong.____ > > ____ > > Regards,____ > > ____ > > Logo Orange____ > > > > *Łukasz Rajewski*, R&D Expert > Orange Labs Poland, Advanced Network Solutions Agency > *Mob.: +48 519 310 854* > Orange Polska, Obrzeżna 7, 02-691 Warsaw > www.orange.pl <http://www.orange.pl/> ____ > > ____ > > *From:*onap-tsc@lists.onap.org <mailto:onap-tsc@lists.onap.org> > <onap-tsc@lists.onap.org <mailto:onap-tsc@lists.onap.org>> *On > Behalf Of *David McBride > *Sent:* Wednesday, December 2, 2020 5:58 PM > *To:* onap-release <onap-rele...@lists.onap.org > <mailto:onap-rele...@lists.onap.org>>; > onap-usecase...@lists.onap.org > <mailto:onap-usecase...@lists.onap.org> > *Cc:* onap-tsc <onap-tsc@lists.onap.org > <mailto:onap-tsc@lists.onap.org>>; Kenny Paul > <kp...@linuxfoundation.org <mailto:kp...@linuxfoundation.org>> > *Subject:* [onap-tsc] Continuing a REQ from one release to the > next #guilin #honolulu____ > > ____ > > Team,____ > > ____ > > I've gotten some questions about continuing a requirement from > one release to the next. So, for example, from Guilin to > Honolulu.____ > > ____ > > In order to track history, we decided that it would be better to > create a new issue, rather than change the "fixversion" field on > the original field. That way, the history of the scorecards, > tsc approvals, scope, etc. does not get reset.____ > > ____ > > Process:____ > > Current Issue:____ > > 1. Add a comment:____ > > * What was completed____ > * What remains to be done____ > * Assert that the requirement will be continued in the > next release____ > > 2. Change the "scope status" to "reduced scope"____ > 3. Update the Jira status as "Done"____ > > New Issue____ > > 1. Create a new issue with identical summary as the previous > issue. ____ > 2. Set fixversion to the target release version (e.g., Honolulu > Release).____ > 3. In the "Issue Links" field, add a link to the previous > issue.____ > 4. Add a comment indicating that this issue is a continuation > of a previous issue (add Jira reference)____ > > Please let me know if you have any questions.____ > > ____ > > David____ > > ____ > > -- ____ > > *David McBride*____ > > Release Manager____ > > Linux Foundation Networking (LFN)____ > > Mobile: +1.805.276.8018 <tel:%2B1.805.276.8018>____ > > Email: dmcbr...@linuxfoundation.org > <mailto:dmcbr...@linuxfoundation.org>____ > > IRC: dmcbride____ > > __ > > > ____ > > __ __ > > -- ____ > > *David McBride*____ > > Release Manager____ > > Linux Foundation Networking (LFN)____ > > Mobile: +1.805.276.8018 <tel:%2B1.805.276.8018>____ > > Email: dmcbr...@linuxfoundation.org > <mailto:dmcbr...@linuxfoundation.org>____ > > IRC: dmcbride____ > > > > -- > *David McBride* > Release Manager > Linux Foundation Networking (LFN) > Mobile: +1.805.276.8018 <tel:%2B1.805.276.8018> > Email: dmcbr...@linuxfoundation.org <mailto:dmcbr...@linuxfoundation.org> > IRC: dmcbride > -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#7343): https://lists.onap.org/g/onap-tsc/message/7343 Mute This Topic: https://lists.onap.org/mt/78665769/21656 Mute #guilin:https://lists.onap.org/g/onap-tsc/mutehashtag/guilin Mute #honolulu:https://lists.onap.org/g/onap-tsc/mutehashtag/honolulu Group Owner: onap-tsc+ow...@lists.onap.org Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
