Let me refer you to the Foundation guidance on voting: https://www.apache.org/foundation/voting.html , and specifically the section on vetos:
A code-modification proposal may be stopped dead in its tracks by a -1 vote by a qualified voter. This constitutes a veto, and it cannot be overruled nor overridden by anyone. Vetos stand until and unless withdrawn by their casters. To prevent vetos from being used capriciously, they must be accompanied by a technical justification showing why the change is bad (opens a security exposure, negatively affects performance, *etc.* ). A veto without a justification is invalid and has no weight. The Merriam-Webster dictionary defines 'capricious' as a sudden, unpredictable, and impulsive act <https://www.merriam-webster.com/dictionary/caprice>. To guard against this kind of chaos in voting on technical matters, a technical veto must have a clear and compelling reason. Neither on the earlier thread nor the JIRA is a clear and compelling concern about the to-be-merged feature, clearly communicated. A technical veto must also be accompanied with clear and actionable feedback for the contributors, which in my view is also absent. A veto because one participant in the discussion does not understand the change or its motivation, or simply expresses an opinion that it is not ideal and/or needed, is not a valid reason for a technical veto and certainly does not provide actionable guidance for curing the veto. The burden of the technical veto is not on the contributors to convince the vetoing voter; the burden of proof is on the vetoing voter. In my view, as things stand the veto here is not yet valid but can be made valid by offering the following: - A clear and compelling reason why the proposed change is harmful or undesirable - One or more clear and specific action items which would allow the contributors to cure the reason for the veto Otherwise, the veto should be given no weight. To explain further my reason for concern, I have reviewed the discussion thread and JIRA in question here and the reason given for veto seems to me a relatively minor technical matter that can easily be cured, to the extent it has been described (the reason is somewhat unclear), with a simple and straightforward follow up. There is no blocking functional, performance, regression, or security related reason. However we have a repeat of a pattern of disagreement related to a personal problem between two participants in the discussion, including the vetoing voter. On Tue, Nov 17, 2020 at 8:03 PM Andrew Purtell <[email protected]> wrote: > I am concerned this is not a valid technical veto and it’s time for the > PMC to take a more active role. This is poison to collaboration and it is > affecting multiple people. > > > On Nov 17, 2020, at 5:43 PM, 张铎 <[email protected]> wrote: > > > > Hi, bring my -1 from the HEAD-UP thread, this is a veto. > > > > My concerns have not been fully resolved. Let's work it out on jira. > > > > Thanks. > > > > clara xiong <[email protected]> 于2020年11月18日周三 上午1:51写道： > > > >> +1 > >> > >>> On Tue, Nov 17, 2020 at 9:49 AM Huaxiang Sun <[email protected]> > >>> wrote: > >>> > >>> +1 > >>> > >>> On Tue, Nov 17, 2020 at 9:21 AM Bharath Vissapragada < > >> [email protected]> > >>> wrote: > >>> > >>>> +1. Reviewed the design doc and the consolidated patch, great > >>> improvement, > >>>> thanks for putting this together. > >>>> > >>>> On Tue, Nov 17, 2020 at 9:09 AM Stack <[email protected]> wrote: > >>>> > >>>>> +1 > >>>>> S > >>>>> > >>>>> On Tue, Nov 17, 2020 at 8:43 AM Stack <[email protected]> wrote: > >>>>> > >>>>>> Please VOTE on whether to merge HBASE-18070 feature branch to > >> master > >>>> (and > >>>>>> HBASE-18070.branch-2 to branch-2). The VOTE runs for 24 hours. The > >>>>> majority > >>>>>> prevails (+ or -). > >>>>>> > >>>>>> Quoting the design lead-in: > >>>>>> > >>>>>> Read Replicas on the hbase:meta Table currently only does primitive > >>>> read > >>>>>> of the primary’s hfiles refreshing every (configurable) N seconds. > >>> This > >>>>>> issue is about making it so we can do the Async WAL Replication > >>>>>> <http://hbase.apache.org/book.html#_asnyc_wal_replication> > >> ability, > >>>>>> currently only available for user-space Tables, against the > >>> hbase:meta > >>>>>> system Tables too; i.e. the primary replica pushes edits to its > >>>> Replicas > >>>>> so > >>>>>> they run much closer to the primaries’ state. If clients could be > >>>>> satisfied > >>>>>> reading from Replicas, then we could have improved hbase:meta > >> uptimes > >>>> but > >>>>>> also, we can distribute load off of the primary and alleviate > >>>> hbase:meta > >>>>>> Table (read) hotspotting. > >>>>>> > >>>>>> Each PR that comprises the feature branch has been reviewed before > >>>>> commit. > >>>>>> > >>>>>> * For the design, see [2]. > >>>>>> * For an amalgamated PR of the 5 or 6 reviewed PRs that comprise > >>> this > >>>>>> feature, see [3]. > >>>>>> * For a PE report that compared performance before and after, see > >>>>>> HBASE-25127 (no regression). > >>>>>> * A report on ITBLL runs is pending to be attached to HBASE-18070 > >>> but > >>>>>> runs so far show no regression with the feature enabled (ITBLL runs > >>>> were > >>>>>> done against a backport of this feature to branch-2 as the ITBLL > >>> state > >>>> of > >>>>>> master is currently an unknown). > >>>>>> > >>>>>> Testing continues mainly looking for further improvement and to > >>> better > >>>>>> understand this feature in operation. Documentation is included. > >>> There > >>>>> are > >>>>>> some follow-ons that have been identified but these can land later. > >>>>>> > >>>>>> Thanks and thanks to all who contributed to this feature; the > >>> reviewers > >>>>>> and the testers in particular. > >>>>>> > >>>>>> S > >>>>>> > >>>>>> 1. http://hbase.apache.org/book.html#_asnyc_wal_replication > >>>>>> 2. > >>>>>> > >>>>> > >>>> > >>> > >> > https://docs.google.com/document/d/1jJWVc-idHhhgL4KDRpjMsQJKCl_NRaCLGiH3Wqwd3O8/edit# > >>>>>> This patch is currently missing HBASE-25280, a bug found in > >> testing. > >>>>>> 3. https://github.com/apache/hbase/pull/2643 > >>>>>> > >>>>> > >>>> > >>> > >> > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
