Hi Ajay, I think you captured it, but I'll explain once more to be sure:
* RDM looks for JIRAs resolved as "Fixed" when making the release notes * In the Hadoop dev workflow, sometimes patch is committed to a branch, then there's a delay before it's backported to another branch. * We want to run precommit on the backported patch, and the precommit script requires the JIRA to be open and in "Patch Available" status. Thus, until the JIRA is fully backported, it needs to be open and "Patch Available". RDM won't pick up these JIRAs for any fix version since they're not in "Fixed" state. This means the release notes will be incomplete, and we can't do a release. Getting back to the proposals, I suggested relaxing either RDM or precommit to be more permissive as to the JIRA status. Thinking about it more, I'd prefer to relax precommit, since relaxing RDM means we potentially need to edit a lot of JIRA fix versions. There's also value from having a fix version set even for JIRAs not resolved as "Fixed" (e.g. "Duplicate"). Filing an additional JIRA for any unclean backport introduces overhead to the happy path and complicates tracking, so I'm not a fan. We've never been able to avoid typos in commit messages, so we don't have a reliable mapping from git log -> JIRAs. I don't think RDM wants to be in the business of trying to solve this either. Best, Andrew On Thu, Jan 5, 2017 at 12:35 PM, Ajay Yadava <[email protected]> wrote: > 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 >
