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
