By the Apache rules, this is 100% up to the PMC member managing this release.
Also by the Apache rules, any PMC member can choose to create another release that contains this, at any time. So, hypothetically a `2.1-zstd` can follow this if deemed important enough by any individual PMC member. As an aside, I'll probably fork and build such a release for private use if it does not make it. This feature is just too good -- its going to save us a LOT of money. edit: Thoughts on dealing with this sort of thing in the future: * Linux style: the release window is a little bit flexible, and the person managing the release has 100% authority to block / add / delay as they see fit, though delays are much more rare than kicking items out. Subjectivity in judgement is assumed, and eventually people don't complain, since there can be no universal objective measures of "small" or "low risk". * Tiered: Two or three deadlines: For example one for PRs to be available for review, one for merging 'big' or 'risky' things, and a final one for 'small' or 'low risk' things. There is risk to letting things slip past deadlies, but there is also risk with strict deadlines -- what if a committer / reviewer is purposely sandbagging to delay something? Or if the reviewer just dissapears for a coupe weeks for personal reasons? If the PMC member managing the release has authority to bend deadline a little, they can manage what comes up on a case by case basis. My understanding is that is why the Apache rules basically hand all power to the PMC member managing the release. [ Full content available at: https://github.com/apache/kafka/pull/2267 ] This message was relayed via gitbox.apache.org for devnull@infra.apache.org