Thank you Andrew. I think my last comment clearly describe the two questions given by you.
A clear and compelling reason why the proposed change is harmful or > undesirable It is about the fundamental of this issue. Due to the back and forth on how a test could used to verify the feature, I'm concerned whether the main developer has the same opinion on the problems we want to solve for this issue. This is a very critical problem, as if we can not even reach an agreement on what to solve, I do not think we should allow the merge of the branch. One or more clear and specific action items which would allow the > contributors to cure the reason for the veto This is also very very clear even before we started this vote thread? I asked 4 technical questions and waited for an answer, but seems the main developer refused to answer the questions and let me to read the design doc of all the related issues. The design doc is not all written by him so I do not think this is a constructive suggestion to solve the concerns here. Thanks. Sean Busbey <bus...@apache.org> 于2020年11月19日周四 上午4:27写道： > Pause a moment Huaxiang and give some time for the PMC to talk in > private a bit. > > On Wed, Nov 18, 2020 at 12:44 PM Huaxiang Sun <huaxiang...@gmail.com> > wrote: > > > > This vote passed 24 hours deadline. We got 5 +1s and 1 -1. What is the > path > > to move forward? Anything we (as feature developers) can do to revert the > > -1? > > As it blocks 2.4 release, I think we need a decision asap. > > > > Thanks, > > Huaxiang > > > > On Wed, Nov 18, 2020 at 8:46 AM Andrew Purtell <andrew.purt...@gmail.com > > > > wrote: > > > > > 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 < > andrew.purt...@gmail.com> > > > 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, 张铎 <palomino...@gmail.com> 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 <clarax98...@gmail.com> 于2020年11月18日周三 上午1:51写道： > > > > > > > > > >> +1 > > > > >> > > > > >>> On Tue, Nov 17, 2020 at 9:49 AM Huaxiang Sun < > huaxiang...@gmail.com> > > > > >>> wrote: > > > > >>> > > > > >>> +1 > > > > >>> > > > > >>> On Tue, Nov 17, 2020 at 9:21 AM Bharath Vissapragada < > > > > >> bhara...@apache.org> > > > > >>> 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 <st...@duboce.net> wrote: > > > > >>>> > > > > >>>>> +1 > > > > >>>>> S > > > > >>>>> > > > > >>>>> On Tue, Nov 17, 2020 at 8:43 AM Stack <st...@duboce.net> > 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 > > > >
