On Thu, Aug 19, 2021 at 12:49 AM Enrico Olivelli <eolive...@gmail.com> wrote: > I agree that the CLI is really an API, but sometimes we add options in a > very straightforward way, > I am not sure we must require a PIP for every option, especially if we are > simply exposition some Pulsar Client feature that is not available on the > CLI tools.
I agree. Just was not very sure on how to structure the wording to ensure that adding a single flag is ok, while adding new tools or subcommands will require discussion. I'll iterate a bit on this point. > > > ## When is a PIP *not* required? > > > > > > * Bug-fixes > > > * Simple enhancements that won't affect the APIs or the semantic > > > > I believe that this 'simple' is the key to understanding why a PIP is > required. > Probably it is better to keep this document simple and leave to the > judgment of the reviewers to ask for a PIP or not. > I am afraid that we will need too many PIPs even for small changes that > formally are touching the APIs The mention of API changes of any scale is intentional. I would say that every change to APIs should be double-checked because the process of fixing it later would be too heavy and disruptive (introducing new corrected API, deprecating and removing after a while). > > > 4. Once some consensus is reached, there will be a vote to formally > > > approve > > > the proposal. > > > The vote will be held on the dev@pulsar.apache.org mailing list. > > > Everyone > > > is welcome to vote on the proposal, though it will considered to be > > > binding > > > only the vote of PMC members. > > > I would be required to have a lazy majority of at least 3 binding +1s > > > votes. > > > The vote should stay open for at least 48 hours. > > > > This is too hard from my point of view. > We need PMC members to vote on a release, this is the ASF rules and this is > needed to guarantee the quality (at every level, legal, code...) of a > release. > I believe that even for an API change when you have 2 or 3 "committers" > that are supporting the change it is enough. > Otherwise the process will become like a "release", that usually is > perceived as a "heavy weight" process. > If you approve a PIP, and even if you commit some patch about it you can > always "git revert", so the committer role is enough to approve this kind > of decisions. > > so my proposal is to change "PMC members" to "committers" I understand the concerns on keeping the process lightweight. However the intent here is to improve the detection of eventual problems earlier on in the release cycle. It has proven to be infeasible to check every PR change for API changes at the moment of a release. Also that would block the release process. The goal here would be to avoid having API changes getting unnoticed until it is either already released or too late to adjust. Regarding the approval process, it is very similar to the process used by other ASF projects that have a PIP equivalent. In all cases I've seen, the PMC vote is considered binding. * Kafka: https://cwiki.apache.org/confluence/display/kafka/kafka+improvement+proposals#KafkaImprovementProposals-Process * Flink: https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals#FlinkImprovementProposals-Process * Spark: https://spark.apache.org/improvement-proposals.html * RocketMQ: https://github.com/apache/rocketmq/wiki/RocketMQ-Improvement-Proposal The only differences with respect to the vote are: * Some of these projects require "Consensus" (meaning a binding -1 is a veto). I believe "Lazy Majority" (At least 3 +1s and more +1s than -1s) is a better model here to avoid stalls. * I reduced the vote time 48 hours instead of 72 hours, in order to ensure a slightly quicker turnaround. Matteo Matteo
