Hey Rajini, We took a long look at KIP-55 and decided that the time needed to review, stabilize, and add system testing might not be sufficient. Usually a somewhat large patch like that takes a couple weeks of iteration before landing in trunk. For a new security feature, it might be even longer. We could delay the release for a week, but it's hard to know if that's enough time and that might just put some other feature on edge (sort of by induction, we risk never cutting the release). That said, if one of the committers thinks it has a chance to get in and has the time to push it through review, then I'm happy to add it.
Thanks, Jason On Sat, Sep 10, 2016 at 1:06 AM, Rajini Sivaram < rajinisiva...@googlemail.com> wrote: > Would it be possible to include KIP-55: Secure Quotas > <https://cwiki.apache.org/confluence/display/KAFKA/KIP- > 55%3A+Secure+Quotas+for+Authenticated+Users> > as > well? The KIP was approved a while ago and the PR was submitted several > weeks ago. I was hoping it would get reviewed in time for the next release. > Jun had said he would take a look. > > > Thank you, > > Rajini > > On Sat, Sep 10, 2016 at 8:26 AM, Ismael Juma <ism...@juma.me.uk> wrote: > > > Jason, thanks for putting this together and driving the release. Your > > proposal sounds good to me. It would be nice to create a wiki page with > the > > information in this email. See the following for the one that Gwen put > > together for 0.10.0: > > > > https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+0.10.0 > > > > Also, you merged KIP-70 recently so that can be moved to the completed > > section. > > > > Ismael > > > > On Fri, Sep 9, 2016 at 11:45 PM, Jason Gustafson <ja...@confluent.io> > > wrote: > > > > > Hi All, > > > > > > I've volunteered to be release manager for the upcoming 0.10.1 release > > and > > > would like to propose the following timeline: > > > > > > Feature Freeze (Sep. 19): The 0.10.1 release branch will be created. > > > Code Freeze (Oct. 3): The first RC will go out. > > > Final Release (~Oct. 17): Assuming no blocking issues remain, the final > > > release will be cut. > > > > > > The purpose of the time between the feature freeze and code freeze is > to > > > stabilize the set of release features. We will continue to accept bug > > fixes > > > during this time and new system tests, but no new features will be > merged > > > into the release branch (they will continue to be accepted in trunk, > > > however). After the code freeze, only blocking bug fixes will be > > accepted. > > > Features which cannot be completed in time will have to await the next > > > release cycle. > > > > > > This is the first iteration of the time-based release plan: > > > https://cwiki.apache.org/confluence/display/KAFKA/Time+ > > Based+Release+Plan. > > > Note > > > that the final release is scheduled for October 17, so we have a little > > > more than a month to prepare. > > > > > > Features which have already been merged to trunk and will be included > in > > > this release include the following: > > > > > > KIP-4 (partial): Add request APIs to create and delete topics > > > KIP-33: Add time-based index > > > KIP-60: Make Java client classloading more flexible > > > KIP-62: Allow consumer to send heartbeats from a background thread > > > KIP-65: Expose timestamps to Connect > > > KIP-67: Queryable state for Kafka Streams > > > KIP-71: Enable log compaction and deletion to co-exist > > > KIP-75 - Add per-connector Converters > > > > > > Since this is the first time-based release, we propose to also include > > the > > > following KIPs which already have a patch available and have undergone > > some > > > review: > > > > > > KIP-58: Make log compaction point configurable > > > KIP-63: Unify store and downstream caching in streams > > > KIP-70: Revise consumer partition assignment semantics > > > KIP-73: Replication quotas > > > KIP-74: Add fetch response size limit in bytes > > > KIP-78: Add clusterId > > > > > > One of the goals of time-based releases is to avoid the rush to get > > > unstable features in before the release deadline. If a feature is not > > ready > > > now, the next release window is never far away. This helps to ensure > the > > > overall quality of the release. We've drawn the line for this release > > based > > > on feature progress and code review. For features which can't get in > this > > > time, don't worry since January will be here soon! > > > > > > Please let me know if you have any feedback on this plan. > > > > > > Thanks! > > > Jason > > > > > > > > > -- > Regards, > > Rajini >
