I basically agree with all of this, except: - I believe committers are going to have a hard time with fix version management and we should not trust this
- Git as source of truth was discussed in the Yetus context IIRC but docmaker uses the JIRA API, so JIRA remains the effective source of truth without a good replacement (there is no replacement for docmaker), unless there is a GitHub API I'm not aware of (there could be). - I would prefer to resolve API compatibility or changelog inconsistencies before tagging the RC and publishing this tag - Unless the git branches are locked there is a race between prep and RC/tag publish. This part is fine as long as the RM can detect the collision (git rejects the push) and so ultimately this requires all prep happen locally with the tag/push/publish as final atomic step. On Fri, Jan 15, 2021 at 3:19 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 > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
