Matteo, thank you for your clarification I agree that having 3 +1 from PMC members is good for a PIP
I am +1 in the current form of this proposal. Enrico Il giorno gio 19 ago 2021 alle ore 21:35 Matteo Merli <mme...@apache.org> ha scritto: > 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 >
