> On Jan 7, 2022, at 2:59 PM, Matteo Merli <matteo.me...@gmail.com> wrote:
>
> On Fri, Jan 7, 2022 at 9:27 AM Dave Fisher <w...@apache.org> wrote:
>>> I believe 48 hours vote is only for PIP, which was agreed in the dev@.
>>
>> I would like to understand why Matteo chose 48 hours for this process.
>> What’s the hurry?
>
> Since we went from no formal process to "some" process, and since any
> change to public APIs and tools is subject to PIP process, the concern
> was to not impose a too long delay in getting smaller changes approved
> and merged.
Some process is great. But a PIP is for something larger than a PR, correct?
>
> From the original text:
>
> | It is not a goal for PIP to add undue process or slow-down the development.
>
>> (Also, I’m not sure what is meant by "Lazy Voting” I don’t find that defined
>> in ASF documentation.)
>
> Where is the term "lazy voting" coming from? I did use "lazy majority"
> which is the term that indicates that you only need a majority among
> the PMC votes, not across all the PMC members (most of which will not
> vote on all the PIPs).
Most PMC members don’t VOTE on much.
>
> | 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.
The trouble with 48 hours is that it can be too short a time for people to have
time to review - the project is global and a vote over a weekend may not get
the attention it deserves.
That said as long as PMC members are clearly marking their votes as binding
then the vote can go for a minimum of 48 hours.
I do think that anyone who is -1 ought to be making their technical veto
understood during the discussion phase and a VOTE should not happen if there is
a technically valid reason not to proceed. Technically valid reasons could
include security issues and invalid licensing, etc.
I hope that discussion can be just that instead of additional +1 (but then I’m
a grumpy old guy)
Regards,
Dave
>
>
> --
> Matteo Merli
> <matteo.me...@gmail.com>
