On a personal level, I'd like to see this in 2.1 because it's a great compression algorithm to replace gzip and complement lz4. However, I agree with @lindong28 that it's important to have a fair process for all features. As it happens, this is a bit of a grey area. The time-based releases wiki page (https://cwiki.apache.org/confluence/display/KAFKA/Time+Based+Release+Plan) says:
> A month before the release date, the release manager will cut branches and > also publish (preferably on the wiki) a list of features that will be > included in the release (these will typically be KIPs, but not always). We > will leave another week for "minor" features to get in (see below for > definitions) ... > Minor Feature - Feature that takes less than 2 weeks to develop and > stabilize. Requires mostly one PR to complete the feature. This PR seems to be low risk unless zstd is used, it's a single PR, it's medium sized (~+600 lines) so it _could_ be classed as a minor feature. The bit where it should take less than 2 weeks to develop and stabilize is less clear though since development was not all done in one go. Either way can be justified. @lindong28, I think you should make the call as the RM. [ Full content available at: https://github.com/apache/kafka/pull/2267 ] This message was relayed via gitbox.apache.org for [email protected]
