If it's possible, I would also appreciate it if we could add a pre-commit hook to our repository that rejects a commit whose title does not match our prescribed pattern. Doing so would go a long way toward simplifying the parsing tools.
-n On Fri, Jan 15, 2021 at 3:18 PM Nick Dimiduk <ndimi...@apache.org> wrote: > > 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 >
