Hi David, One question: Can we add additional version strings to our project as needed?
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? Thanks Georg From: opnfv-project-leads-boun...@lists.opnfv.org [mailto:opnfv-project-leads-boun...@lists.opnfv.org] On Behalf Of David McBride Sent: Friday, August 26, 2016 10:59 PM To: TECH-DISCUSS OPNFV; opnfv-project-le...@lists.opnfv.org 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<tel:%2B1.805.276.8018> Email/Google Talk: dmcbr...@linuxfoundation.org<mailto: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
