> I have now had to sink two 2.4.1 RCs because of errors in the change log.
IIRC, it's a relatively new phenomenon that we sink an RC because the CHANGES file is incomplete. > That's right... Commtters cannot be trusted to correctly maintain issue metadata in JIRA. I wouldn't go so far as to make a blanket statement such as this... I suspect there's a couple new people who missed this message. In my experience, a polite nudge from the RM on the affected JIRA issue to the offending committer resolves the knowledge gap. > 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. This I 100% agree with. But then, even before GitHub, Jira and SVN were two separate systems, and we managed fine. Maybe, as you say, the committer mentality around attention to detail has laxed. Or maybe, as I suggest, there's just an education gap involving a couple people, which can be addressed. > 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. Ah, now the discussion gets interesting! IMHO, we do have a source of truth re: this information -- it's git. > Perhaps something can be created that takes the union of git branch listing and reporter.a.o release version history. I did create such a tool, it scrapes git and Jira and produces a database containing this information, from which reports are generated and ad-hoc queries are issued. I committed it (nearly a year ago to the day) via HBASE-22853 (Viraj, you signed off on this commit...). As I mentioned earlier, it's still young, but it was invaluable for me in establishing a baseline for 2.3.0, and includes a readme with lots of examples. I am of the opinion that the git repository is the authority on what is in a release. After all, a release is defined as a permanent "rel" tag in git (plus some ASF ceremony). IMHO, Jira needs to follow git, not the other way around. Likewise, tracking the CHANGES file in git -- a file generated from a Jira query -- is very silly. Instead, I propose that the changes file be generated on demand, perhaps as part building the tarball. The only alternative, if you want to retain the CHANGES file in git, is to include an update to the CHANGES file with every git commit, which I think is completely untenable. One other stumbling point is that our release notes are generated from a field in Jira. We could generate release notes from git commit messages, but I think that is an unrealistic burden to place on committers at the time of commit. Following the logic that git is the source of truth, I propose a change to our release generation process so that it looks something like 1. set the version number in poms, commit. 2. apply the RC tag. 3. run the audit tool to generate a report. 4. resolve inconsistencies (manually for now, eventually the tool could update Jira -- it has an API) 5. build artifacts, including generating any files from metadata in Jira. Step 3, when automated, can even be run during our nightly branch builds. At that point, a committer doesn't need to worry at all about a fixVersion, they just commit to their branches and automation takes care of the rest. The above has the issue around when to close a ticket. IMHO, a ticket should be closed as soon as there's a commit to any branch, but maybe there are other complexities to consider. Thanks for bringing this up, Andrew. It's bothered me since 2.3.0 :) -n
