A related factor is the practice of holding a JIRA open until all backports are complete. This is something RMs will already be familiar with, so isn't more than an inconvenience, but it does lend itself to fix version inaccuracy. Say you merge a PR or commit a cherry pick to some of the active branches, but not all, and do not resolve the JIRA. If someone wants to release from one of the branches where the commit was committed, the change will not appear in the change log. The JIRA status for the issue must be set to resolved in order for the issue to be included in the change log.
What I do as RM, and what I expect all RMs do, is run a report of all issues with a fix version of what I am about to release, and if any are in unresolved state, will resolve the JIRA at that time and advise further commits be made on subtasks or new issues. It would be better, when you are considering holding an issue open for a while for some backport to come in, to not hold the issue open, to resolve it at the time the first commits are complete. Open new issues for any additional backporting work. On Fri, Jan 15, 2021 at 10:39 AM Andrew Purtell <apurt...@apache.org> wrote: > We do not have a single source of truth as to what are active branches and > what was the most recent release by version number made from each branch. > If we had such a resource, then committers could refer to it whenever > merging PRs or cherry picking commits backward. Perhaps something can be > created that takes the union of git branch listing and reporter.a.o release > version history. The downside of course it this would be something new to > maintain. Committers would also need to be educated about the existence of > this tool and the requirement to use it, but that could be solved with an > update to the How To Release section of the online book. I filed > HBASE-25515 for this idea. > > > > On Fri, Jan 15, 2021 at 10:05 AM Andrew Purtell <apurt...@apache.org> > wrote: > >> I have now had to sink two 2.4.1 RCs because of errors in the change log. >> >> I made a pass over git history and ensured every commit was included. I >> had also made a pass over JIRA to move out any unresolved issues or >> complete the resolution of same. What I did not do is check that every >> resolved JIRA corresponded to an actual commit. This is not something RMs >> have had to do in the past and it asks a lot of them. >> >> I know NOW that as RM I cannot currently trust committers to get fix >> versions right or care about this. >> >> That's right... Commtters cannot be trusted to correctly maintain issue >> metadata in JIRA. >> >> That is not a good situation for the project to be in. Up until now it >> has not been the responsibility of the RM to check each and every JIRA >> status. It has been the collective responsibility of committers to care >> about the project's release tracking insofar as to correctly update fix >> versions in JIRA. For releases containing relatively few changes, like >> 2.4.1, with ~50 changes, I suppose it is possible for the RM to remove all >> 2.4.1 fix versions, walk the commit history, and set back fix versions on >> JIRA to actually correspond with what was truly committed. However, for >> minor releases, with hundreds of commits, this will not be possible. >> >> I think the root cause is GitHub and JIRA are two separate change >> tracking systems with only a minimal amount of integration. It requires >> manual effort. More and more, new committers are familiar with GitHub and >> PRs and are not familiar with JIRA and the Apache way of using JIRA to >> build change logs. We need to better educate new and existing committers on >> their responsibilities with regards to maintaining JIRA metadata correctly. >> >> -- >> Best regards, >> Andrew >> >> Words like orphans lost among the crosstalk, meaning torn from truth's >> decrepit hands >> - A23, Crosstalk >> > > > -- > Best regards, > Andrew > > Words like orphans lost among the crosstalk, meaning torn from truth's > decrepit hands > - A23, Crosstalk > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
