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.
>>>
>>>
>>>
>>>

Reply via email to