Yeah, after multiple release efforts of 2.3.4 failed, I finally did a manual check. 1. got git logs for jiras from 2.3.3. 2. did a dry-run to generate CHANGES.md.
I compared these two outputs and removed the common ones. The one left in 1) are issues in git and fixVersion not correctly setup in jira. The one left in 2) is fixVersion set to 2.3.4 but patch is not committed to the branch. The logic is essentially based on the fact that git is the only source of truth. On Fri, Jan 15, 2021 at 11:30 AM Nick Dimiduk <ndimi...@apache.org> wrote: > Hi Andrew, > > I had a conversation on this same topic yesterday with Huaxiang and, I > believe, came to a similar conclusion. I was advocating that git be the > source of truth and Jira follow, and there be no CHANGES file in the > repository at all. > > I’m on mobile at the moment. Let me spend some time this afternoon to catch > up this thread and write up my own thoughts. I actually planned to raise a > discuss thread today anyway. > > Thank you all for caring about this! > -n > > On Fri, Jan 15, 2021 at 11:20 Viraj Jasani <vjas...@apache.org> wrote: > > > Thanks Andrew and Zach. > > The script tries to identify these issues: > > > > 1. commit is reverted as per commit message > > 2. commit does not contain Jira number format HBASE-XXXX in message > > 3. Jira does not have expected fixVersion > > 4. Jira has expected fixVersion, but it is not yet resolved > > 5. Jiras that are marked resolved with given fixVersion but have no > > corresponding > > commit present > > > > IMHO, issues like > > 1. reverted commit and relevant Jira being resolved with > > expected fixVersion which it is actually reverted but Jira is > > not reopened > > 2. some false alarm like preparation of snapshot version > > which is not tied to any Jira > > > > might make it bit difficult to automate this script with > > create-release or nightly build because these kind of discrepancies > > are for committers/RMs to manually check and resolve. > > Having said that, I am sure we can make something better and > > meaningful out of this that will make our life easier going forward. > > > > > > On 2021/01/15 19:07:35, Zach York <zyork.contribut...@gmail.com> wrote: > > > Awesome Viraj! Also if we have confidence in the script we could > probably > > > add it to run during a nightly run to try to catch issues earlier and > > > remove the burden on the RM (if there isn't too much noise from open > > > issues). > > > > > > On Fri, Jan 15, 2021 at 10:55 AM Andrew Purtell <apurt...@apache.org> > > wrote: > > > > > > > Thanks, Viraj. A script like that will be super helpful. > > > > > > > > On Fri, Jan 15, 2021 at 10:50 AM Viraj Jasani <vjas...@apache.org> > > wrote: > > > > > > > > > > This is not something RMs have had to do > > > > > > in the past and it asks a lot of them. > > > > > > > > > > +1. It is too much for RM to do if RM alone is responsible for > > > > > maintaining Git/Jira in sync. > > > > > > > > > > The reason why I was able to get the diffs for 2.3.4 and 2.4.1 > > > > > RCs is because I used a small script that a) goes through all > > > > > commits, b) gets Jira number, c) search for the Jira fields using > > it's > > > > > API and d) finds the diff. And similarly using JQL, it finds all > > Jiras > > > > > with expected fixVersion but has no git commit present. Mostly I > > > > > will raise PR for this script tomorrow early as part of > HBASE-25514. > > > > > > > > > > If we have enough trust on this, when RM given heads up on > > > > > dev mailing list for a new release, more committers can be > > > > > encouraged to start using this script to find any discrepancy, > > resolve > > > > > it if possible and keep in mind the upcoming release version while > > > > > resolving a Jira. > > > > > However, this is just a script that can help specifically just > before > > > > > spinning RCs. More precautionary steps would be bringing > > > > > awareness of all active branches and how they relate to active > > > > > releases as mentioned by Andrew. > > > > > > > > > > > > > > > On 2021/01/15 18:39:18, 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 > > > > > > > > > >
