On Fri, May 20, 2022 at 3:04 AM Enrico Olivelli <eolive...@gmail.com> wrote: > > Andras, > even if our rules allow to close a vote with a binding -1, we should > have to reach consensus and understand better Lari's motivations > > we are a community and accepting something with a -1 must be handled carefully > > I suggest to try to continue the discussion and try to converge
The place for reaching consensus is the [DISCUSSION] thread, and the discussion thread was out for many days before the vote was started, without any negative feedback. When questions were asked on this voting thread, the clarifications were posted. No one person has a "veto" power, and I don't think that Lari was asking for that either. This is a concrete proposal that removes a current limitation in the system, in a way that does not impact existing users and provides a simple mechanism for bucketing that can later be expanded to address more complex scenarios (like migrations, enable/disable, splitting/merging). I've read through the points raised by Lari on the other thread and I will reply on the ideas for MetadataStore API there, but I don't think the concerns are related to this PIP-157 proposal and I don't see in there a different suggestion on how to solve the problem raised by PIP-157. This PIP-157 is not about limitations of MetadataStore API, rather is addressing limitations that are in the backend implementations (eg: ZooKeeper) where the number of z-nodes in a single directory has to be limited by the frame-size, or the getChildren() operation will fail. Yes, there are matters that could be improved in the MetadataStore API or implementation but I don't see how these can be tied with the fact that we need to split the children in a directory. Because of that, I don't think we should turn upside-down the PIP process, which here was followed to the letter and to the spirit, and we should still consider this PIP-157 as approved. As I mentioned in an earlier thread, it's important to stick by the decisions taken (unless new elements arise that were not initially considered), or otherwise this PIP process would be just a pointless exercise. Matteo -- Matteo Merli <matteo.me...@gmail.com>
