Yup, sorry for not replying, happy with this - we can work out exact details in
a few weeks!
-a
On 16 September 2020 19:03:42 BST, Jarek Potiuk
wrote:
>Unless Ash has still some objections to my answer the vote has passed
>with
>5 "+1" votes.
>
>On Mon, Sep 14, 2020 at 1:23 PM Jarek Potiuk
>w
Unless Ash has still some objections to my answer the vote has passed with
5 "+1" votes.
On Mon, Sep 14, 2020 at 1:23 PM Jarek Potiuk
wrote:
> Thanks Ash.
>
> Some good points Indeed. I am more and more convinced to SEMVER. I do
> agree that consistently following SEMVER has some really nice pro
Thanks Ash.
Some good points Indeed. I am more and more convinced to SEMVER. I do agree
that consistently following SEMVER has some really nice properties and
makes user decisions easier. CALVER kind of passes the problem to the users
rather than solve it by the maintainers. But the problem remain
On Sep 14 2020, at 11:01 am, Jarek Potiuk wrote:
>>
>>
>> > We have to make sure that we have no dependencies core -> providers
>>
>> How do we handle writing logs to S3/GCS/Azure Blob storage, which
>> depends on the hook from the provider to work?
>>
>
> Good point. I will make sure tha
I added the point about logging to the AIP.
I'd love to hear more thoughts on how the SEMVER process might work for
those numerous packages - Ash I'd love to understand what scheme you think
is the best.
One more comment for my options - I really like the point that Vikram made
about the "lack" o
>
>
> > We have to make sure that we have no dependencies core -> providers
>
> How do we handle writing logs to S3/GCS/Azure Blob storage, which
> depends on the hook from the provider to work?
>
Good point. I will make sure that I address it in the PR as well. I think
those should only work when
Two unanswered questions from me I'd like to see resolved first.
In the AIP you say:
> We have to make sure that we have no dependencies core -> providers
How do we handle writing logs to S3/GCS/Azure Blob storage, which
depends on the hook from the provider to work?
> Versioning proposal is C
+1 non-binding
On Sun, Sep 13, 2020 at 2:20 PM Kaxil Naik wrote:
> +1 binding
>
> On Sun, Sep 13, 2020 at 10:18 PM Daniel Imberman <
> daniel.imber...@gmail.com>
> wrote:
>
> > +1 (binding).
> >
> > via Newton Mail
> > [
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.50&pv=10.15.6&sourc
+1 binding
On Sun, Sep 13, 2020 at 10:18 PM Daniel Imberman
wrote:
> +1 (binding).
>
> via Newton Mail
> [
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.50&pv=10.15.6&source=email_footer_2
> ]
> On Sun, Sep 13, 2020 at 1:57 PM, Kevin Yang wrote:
> +1 (binding)
>
> On Sun, Sep 13, 2020 at 1
+1 (binding).
via Newton Mail
[https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.50&pv=10.15.6&source=email_footer_2]
On Sun, Sep 13, 2020 at 1:57 PM, Kevin Yang wrote:
+1 (binding)
On Sun, Sep 13, 2020 at 1:29 PM Jarek Potiuk
wrote:
> Hello Everyone,
>
> Last week, at the Airflow 2.0 meetin
+1 (binding)
On Sun, Sep 13, 2020 at 1:29 PM Jarek Potiuk
wrote:
> Hello Everyone,
>
> Last week, at the Airflow 2.0 meeting the people involved made a decision
> that we are releasing Airlow 2.0 as a set of separate "core" and
> "providers" packages - similarly to the 1.10 "backport providers"
Hello Everyone,
Last week, at the Airflow 2.0 meeting the people involved made a decision
that we are releasing Airlow 2.0 as a set of separate "core" and
"providers" packages - similarly to the 1.10 "backport providers" packages.
This decision effectively implements the "spirit" of the AIP-8 pro
12 matches
Mail list logo
