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

Reply via email to