I am not sure if I understand the problem that you are facing or your proposal completely, so please feel free to correct me.
I think what Allen has suggested is perhaps the best way to workaround this problem. However, if for some reason that's not possible/desirable, then one option may be to fall back to git commit log to determine the true status of such issues i.e. if apart from target release version, an open JIRA has other versions also in fix-versions field of JIRA, then it means it *may* be committed to the branch. So for such cases, we check commit log of the branch for such cases. However, this requires a way to identify the commit for the JIRA e.g. by assuming a convention of mentioning JIRA ID in the commit message. Are you suggesting this change in RDM or proposing another script to identify such JIRAs? Or did I misunderstood the issue completely? Regards Ajay Yadava On Wed, Jan 4, 2017 at 4:11 PM Andrew Wang <[email protected]> wrote: On Wed, Jan 4, 2017 at 1:07 PM, Andrew Wang <[email protected]> wrote: > > On Wed, Jan 4, 2017 at 12:58 PM, Allen Wittenauer < > [email protected]> wrote: > >> >> > On Jan 4, 2017, at 12:00 PM, Andrew Wang <[email protected]> >> wrote: >> > >> > Thoughts? >> >> If a back port is taking that long, it's probably better to open >> another JIRA for it. >> >> It's not that any individual backport takes that long, but there are > enough patches flying around that there's always at least one JIRA in this > state. > > My goal is for the branch (and JIRA) to always be in a releaseable state. > BTW, one example is that I wrote a script to reconcile JIRA information with git state. I'd like to turn on an email when the tool detects an error, but it's never passed successfully due to the above issue. https://builds.apache.org/view/H-L/view/Hadoop/job/Hadoop-trunk-versions/ -- Regards Ajay Yadava
