Oh yeah :) On Wed, Aug 10, 2022 at 7:23 PM Ping Zhang <pin...@umich.edu> wrote:
> ah, good call. > > I guess the email template can be updated: > > Only votes from PMC members are binding, but members of the community are >> encouraged to check the AIP and vote with "(non-binding)". > > > > +1 (binding) > > Thanks, > > Ping > > > On Wed, Aug 10, 2022 at 10:20 AM Jarek Potiuk <ja...@potiuk.com> wrote: > >> Thank you . And BTW. It's binding Ping :). For AIP's commiter's votes are >> binding. See >> https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst#commit-policy >> :D >> >> On Wed, Aug 10, 2022 at 7:16 PM Ping Zhang <pin...@umich.edu> wrote: >> >>> +1 (non-binding) >>> >>> Thanks, >>> >>> Ping >>> >>> >>> On Thu, Aug 4, 2022 at 1:42 AM Jarek Potiuk <ja...@potiuk.com> wrote: >>> >>>> Hey everyone, >>>> >>>> I would like to cast a vote for "AIP-44 - Airflow Internal API". >>>> >>>> The AIP-44 is here: >>>> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-44+Airflow+Internal+API >>>> >>>> Discussion thread: >>>> https://lists.apache.org/thread/nsmo339m618kjzsdkwq83z8omrt08zh3 >>>> >>>> The voting will last for 5 days (until 9th of August 2022 11:00 CEST), >>>> and until at least 3 binding votes have been cast. >>>> >>>> Please vote accordingly: >>>> >>>> [ ] + 1 approve >>>> [ ] + 0 no opinion >>>> [ ] - 1 disapprove with the reason >>>> >>>> Only votes from PMC members are binding, but members of the community >>>> are encouraged to check the AIP and vote with "(non-binding)". >>>> >>>> ---- >>>> >>>> Just a summary of where we are: >>>> >>>> It's been long in the making, but I think it might be a great >>>> step-forward to our long-term multi-tenancy goal. I believe the proposal I >>>> have is quite well thought out and discussed a lot in the past: >>>> >>>> * we have a working POC for implementation used for performance >>>> testing: https://github.com/apache/airflow/pull/25094 >>>> * it is based on on industry-standard open-source gRPC (which is >>>> already our dependency) which fits better the RPC "model" we need than our >>>> public REST API. >>>> * it has moderate performance impact and rather good >>>> maintainability features (very little impact on regular development effort) >>>> * it is fully backwards compatible - the new DB isolation will be an >>>> optional feature >>>> * has a solid plan for full test coverage in our CI >>>> * has a backing and plans for more extensive complete testing in "real" >>>> environment with Google Composer team support >>>> * allows for further extensions as part of AIP-1 (I am planning to >>>> re-establish sig-multitenancy effort for follow up AIPs once this one is >>>> well in progress). >>>> >>>> >>>> J. >>>> >>>> >>>> >>>>
