Hi Steven, As a general rule, we don't freeze KIPs after the vote passes. It's reasonably common for things to come up during code review, for example. If we think of improvements, we shouldn't refrain from doing them because of of the vote. If we do minor changes after the KIP passes, we usually send a follow-up to the vote thread and assume it's all good if no objections are raised. Only significant changes require a vote from scratch (this tends to be rare). More inline.
On Tue, Dec 19, 2017 at 7:58 PM, Steven Aerts <steven.ae...@gmail.com> wrote: > > > 1. The KIP seems to rely on the pull request for some of the details of > the > > proposal. Generally, the KIP should stand on its own. > > Looking back at what I wrote in the KIP, I agree that its style is too > descriptive > and relies too much on the content of the PR. > I will keep it in mind, and try to do better next time. But as the > voting is over I > assume I better not alter it any more. > I think we should fix this. At a minimum, the public interfaces section should include the signature of interfaces and methods being added (as I said before). > 2. Do we really need to deprecate `Function`? This will add build noise to > > any library that builds with 1.1+ but also wants to support 0.11 and 1.0. > > No we don't. It is all a matter of how fast we can and want an api tagged > with > @Evolving, to evolve. > As we know, that it will evolve again when KIP-118 (dropping java 7) is > implemented. > For widely used APIs like the AdminClient, it's better to be conservative. We can look at deprecations once we drop Java 7 so that we do them all at once. > > 3. `FunctionInterface` is a bit of a clunky name. Due to lambdas, users > > don't have to type the name themselves, so maybe it's fine as it is. An > > alternative would be `BaseFunction` or something like that. > > I share a little bit your feeling, as the best name for me would just be > `Function`. But that one is taken. > Yeah, it's a case of choosing the second best option. Ismael
