> The only way I'd be in favor of a release that removes all other committed > patches Couldn't we just have a snapshot branch for each supported major/minor release branch that we patch for hotfixes and we bump up whenever we have a GA on a parent branch?
Shouldn't be any extra burden other than having three extra branches to remember exist; wouldn't need to merge to them or patch to them other than a fast-forward on a given GA. On Tue, Feb 15, 2022, at 10:48 AM, Jeff Jirsa wrote: > We've done concurrent releases without security before, and you follow much > closer than others. I feel most people, if they saw all of the changes > reverted and a release of a single fix, would either instantly know it's > security (high confidence pointer to exactly which patch) OR assume someone > botched the release prep and draw attention to it. So we're trading "someone > who's very involved has a high confidence it's security but has to dig > through 30 patches to find it" vs "everyone knows exactly what's going on", > the former seems better > > The only way I'd be in favor of a release that removes all other committed > patches is if the vote happened in private@ . I don't see any prohibition on > that in https://www.apache.org/foundation/voting.html#ReleaseVotes , so that > seems like an alternate, easy workaround to privacy. > > > > On Tue, Feb 15, 2022 at 7:42 AM J. D. Jordan <jeremiah.jor...@gmail.com> > wrote: >> >> We already advertise that we are preparing a security release when ever we >> release all of our patch versions at the same time. So I don’t think there >> is an issue there. >> I was not involved in any PMC discussions and had no knowledge of the CVE, >> but when three branches got release votes at the same moment I knew one of >> the final couple patches that was on all three must be an un-announced CVE. >> It is especially more obvious when said patches mention JIRA ticket numbers >> with no information in the ticket. Nobody is being sneaky here as long as >> the vote and code are in the open. >> >>> On Feb 15, 2022, at 9:15 AM, bened...@apache.org wrote: >>> >>> One issue with this approach is that we are advertising that we are >>> preparing a security release by preparing such a release candidate.____ >>> __ __ >>> I wonder if we need to find a way to produce binaries without leaving an >>> obvious public mark (i.e. private CI, private branch)____ >>> __ __ >>> __ __ >>> *From: *Josh McKenzie <jmcken...@apache.org> >>> *Date: *Tuesday, 15 February 2022 at 14:09 >>> *To: *dev@cassandra.apache.org <dev@cassandra.apache.org> >>> *Subject: *[DISCUSS] Hotfix release procedure____ >>> On the release thread for 4.0.2 Jeremiah brought up a point about hotfix >>> releases and CI: ____ >>> https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr____ >>> __ __ >>>> If we are making this release for a security incident/data loss/hot fix >>>> reason, then I would expect to see the related change set only containing >>>> those patches. But the change set in the tag here the latest 4.0-dev >>>> commits.____ >>> __ __ >>> I'd like to propose that in the future, regardless of the state of CI, if >>> we need to cut a hotfix release we do so from the previous released SHA + >>> only the changes required to address the hotfix to minimally impact our end >>> users and provide them with as minimally disruptive a fix as possible.____
