Hi Georg,

Responses inline.

On Mon, Aug 29, 2016 at 4:54 AM, Georg Kunz <[email protected]> wrote:

> Hi David,
>
>
>
> One question: Can we add additional version strings to our project as
> needed?
>
[DJM] I'd prefer that you don't do that.  I want all of the projects to use
a common set of release strings so that we can generate reports, across all
projects, on status for a particular release. Obviously, if each project
generates its own strings, then this becomes much more difficult.  Also, I
am now able to programmatically update all of the projects' version
strings, so I'll be maintaining that from now on.  You will just need to
assign your issues to those common releases, using the "fix version" field.

>
>
> Background: I am wondering how to handle issues that do not naturally map
> to a particular OPNFV release. For instance, we have recently started to
> add items to the NetReady Jira project which allow us to track work items
> such as “prepare demo for OpenStack Summit”. These issues obviously do not
> correspond to a particular OPNFV release.
>
>
>
> I see the point that all issues should be assigned a particular fix
> version string to allow you to check if an item is not being forgotten.
> Would you be ok if I add new version strings to our project to handle such
> items as the ones described above? What alternatives do you propose
> otherwise?
>
[DJM] I added a new version string called "future release"; however, this
doesn't really address the case where the task is independent of the OPNFV
release cadence and, therefore, will never be associated with an OPNFV
rlease.  In that case, I suppose that it's okay to define your own release
string.

>
>
> Thanks
>
> Georg
>
>
>
> *From:* [email protected] [mailto:
> [email protected]] *On Behalf Of *David McBride
> *Sent:* Friday, August 26, 2016 10:59 PM
> *To:* TECH-DISCUSS OPNFV; [email protected]
> *Subject:* [opnfv-project-leads] [release][jira] JIRA process status
> report
>
>
>
> Team,
>
>
>
> Some updates for this week's report:
>
>    1. My script will how automatically add any missing versions to your
>    project, so you no longer need to worry about that task.  To be clear, the
>    script simply makes the version strings available for selection in your
>    project.  It does not assign any issues to those versions.
>    2. The script also now determines the ratio of unresolved issues to
>    total issues assigned to the current release (i.e. Colorado 1.0)
>
> Observations:
>
>    - The percentage of projects with no unassigned issues improved
>    slightly from 15% to 25% since my first report.
>
>
>    - However, this still means that 3/4 of OPNFV projects still have
>       unassigned issues.  We cannot do meaningful analysis of progress without
>       knowing which version issues are assigned.
>       - Note that all projects now have the "Future Release" version
>       string.  So, if you do not plan to resolve an issue for the current
>       release, and you aren't sure that you will do it in the next release, 
> then
>       assign it to "Future Release".
>
>
>    - We are less than one month out from the Colorado 1.0 release, yet
>    there are a startling large number of issues assigned to the release that
>    are unresolved.
>
>
>    - Please make sure that you are updating the status of your JIRA
>       issues whenever there is a relevant change.  Don't let fixed issues 
> remain
>       reported as unresolved in JIRA.  This creates a lot of ambiguity when
>       trying to understand the status of the project.
>       - For issues assigned to Colorado 1.0 that you don't believe will
>       be resolved by the release date, you should start reassigning those to
>       Colorado 2.0, or some other future release.  Our goal is to have zero
>       issues assigned to Colorado 1.0 by the date of the release.  Don't wait
>       until the last minute to move the issues.
>       - Alternatively, if you believe that an issue is no longer relevant
>       or important, then simply close it.  If you're wrong and the issue is
>       important enough, then it will resurface.  In the mean time, there's no 
> use
>       in suffering the overhead.
>
> Let me know if you have any comments or questions.
>
>
>
> --
>
> *David McBride*
>
> Release Manager, OPNFV
>
> Mobile: +1.805.276.8018
>
> Email/Google Talk: [email protected]
>
> Skype: davidjmcbride1
>
> IRC: dmcbride
>



-- 
*David McBride*
Release Manager, OPNFV
Mobile: +1.805.276.8018
Email/Google Talk: [email protected]
Skype: davidjmcbride1
IRC: dmcbride
_______________________________________________
opnfv-tech-discuss mailing list
[email protected]
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss

Reply via email to