LF Technical Communities,
The LFN Developer & Testing Forum will be held virtually over four days,
February 1 - 4, 2021. Once again we will be gathering the LFN project
technical communities to progress our releases; discuss project
architecture, direction, and integration points; and further inno
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
w
All,
With the new release cadence, one of the things we were promised is more
streamlined multi-release use case & requirements management. There is a *LOT*
of overhead in introducing new requirements/use cases. It requires a
requirements & architecture presentations, and many web pages to
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
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"
Sent: Wednesday, 2 December 2020 20:22
To: David McBride
Cc: onap-tsc@lists.onap.org
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
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
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 consecut
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,
Hi
it is possible to indicate old use cases re-tested in Guilin, there is a
special section for them in the use case documentation.
So if you can re-test your use case on a guilin lab, please let me know - 2
guilin staging labs are available for testing (windriver SB-00 and Staging
Azure) if n
10 matches
Mail list logo
