I second David opinion. Mira description should include what is planned for 
specific Release only.


Best regards, Alla

Sent from Nine
________________________________
From: "Lukasz Rajewski via lists.onap.org" 
<[email protected]>
Sent: Wednesday, 2 December 2020 20:22
To: David McBride
Cc: [email protected]; onap-release; [email protected]; 
Kenny Paul
Subject: Re: [onap-requirements-sub] [onap-tsc] Continuing a REQ from one 
release to the next #guilin #honolulu

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<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.orange.pl%2F&data=04%7C01%7CAlla.Goldner%40amdocs.com%7Cc5f56b09d75a4371977f08d896ef397c%7Cc8eca3ca127646d59d9da0f2a028920f%7C0%7C0%7C637425301498132818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1DJpEIW3o%2BfYvISYJu5WryJAesViSr%2BSz04gCdRaR3s%3D&reserved=0>
From: David McBride <[email protected]>
Sent: Wednesday, December 2, 2020 6:51 PM
To: Rajewski Łukasz - Hurt <[email protected]>
Cc: [email protected]; onap-release <[email protected]>; 
[email protected]; Kenny Paul <[email protected]>
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://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.onap.org%2F&data=04%7C01%7CAlla.Goldner%40amdocs.com%7Cc5f56b09d75a4371977f08d896ef397c%7Cc8eca3ca127646d59d9da0f2a028920f%7C0%7C0%7C637425301498132818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ca8StHFm8nIF3sxM9eEDd5dkWb3SndbzKjqmUd8PVw0%3D&reserved=0>
 <[email protected]<mailto:[email protected]>> 
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<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.orange.pl%2F&data=04%7C01%7CAlla.Goldner%40amdocs.com%7Cc5f56b09d75a4371977f08d896ef397c%7Cc8eca3ca127646d59d9da0f2a028920f%7C0%7C0%7C637425301498132818%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1DJpEIW3o%2BfYvISYJu5WryJAesViSr%2BSz04gCdRaR3s%3D&reserved=0>

From: [email protected]<mailto:[email protected]> 
<[email protected]<mailto:[email protected]>> On Behalf Of David 
McBride
Sent: Wednesday, December 2, 2020 5:58 PM
To: onap-release 
<[email protected]<mailto:[email protected]>>; 
[email protected]<mailto:[email protected]>
Cc: onap-tsc <[email protected]<mailto:[email protected]>>; Kenny 
Paul <[email protected]<mailto:[email protected]>>
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

  1.  Change the "scope status" to "reduced scope"
  2.  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: [email protected]<mailto:[email protected]>
IRC: dmcbride


--
David McBride
Release Manager
Linux Foundation Networking (LFN)
Mobile: +1.805.276.8018<tel:%2B1.805.276.8018>
Email: [email protected]<mailto:[email protected]>
IRC: dmcbride

This email and the information contained herein is proprietary and confidential 
and subject to the Amdocs Email Terms of Service, which you may review at 
https://www.amdocs.com/about/email-terms-of-service 
<https://www.amdocs.com/about/email-terms-of-service>


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#7340): https://lists.onap.org/g/onap-tsc/message/7340
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: [email protected]
Unsubscribe: https://lists.onap.org/g/onap-tsc/leave/2743226/1412191262/xyzzy 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to