Hi Vikram,
Thank you for taking the time to review the proposal. I appreciate your
insights — I will make sure to reach out to you directly in the future for
feedback as that would've undoubtedly saved us some time and effort.
In regards to the separation of user management, I understand your
Hey Vikram,
Don’t worry about the delay and thanks for sharing your thoughts!
My overall feeling here tends to agree with you (after a discussion with Jarek
I confess __). I like this idea of separating the user management to external
providers, it allows more features and more user management
Would be great to comment on the JiRA ticket. I think there is somewhat
misunderstanding of the problem on the side of INFRA and i think we need to
convince them they have not assessed the consequences properly
wt., 14 lut 2023, 01:02 użytkownik Pierre Jeambrun
napisał:
> Hello,
>
> I share
Hello,
I share Jarek and Dennis' concerns.
It would be very hard to maintain enough responsiveness to not discourage
external contributions while still trying to actually check the changes
before approving a workflow.
We have hundreds of workflows a day (~150 - 200 in the last 24hours, it
would
For others who might also share the same concerns, my ticket where I
explain what effects it will have on our project, and in comment I
also respond to Greg's worries about stealing individual accounts.
https://issues.apache.org/jira/browse/INFRA-24200
Maybe for other projects it is not as
BTW. I am going to strongly oppose that (ticket is coming)
-- Forwarded message -
From: Jarek Potiuk
Date: Mon, Feb 13, 2023 at 8:55 PM
Subject: Re: [NOTICE] Upcoming global changes to default GitHub
Actions behavior for outside collaborators
To:
Cc:
I will raise a ticket and
Very detailed, thanks.I think I want to lean towards whatever the official
support for the package is and not measure ourselves by what the various SaaS
options are doing. I think there will always be some cloud provider lagging or
keeping some old legacy version alive well beyond it's
Cool
On Mon, Feb 13, 2023 at 6:24 PM Julien Le Dem
wrote:
>
> [changing the subject line to separate this discussion from the voting thread]
> Thank you Jarek,
> Yes, I am expecting most of the testing coverage to be in unit tests.
> I think following up on tickets and PRs is appropriate to make
Hey Vikram,
I think it's brilliant and I wonder how it happened that had not
occurred to us earlier. And I believe that is due to the natural
tendency of "following as we always did" rather than thinking
completely out-of-the-box. Thanks Vikram for bringing it up.
The funny thing is that when I
+1 (binding)
Overall I think this will make future development and growth for OL in Airflow
much easier which will hopefully lead to more adoption!
From: Vikram Koka
Sent: Monday, February 13, 2023 8:20:23 AM
To: dev@airflow.apache.org
Subject: RE:
[changing the subject line to separate this discussion from the voting
thread]
Thank you Jarek,
Yes, I am expecting most of the testing coverage to be in unit tests.
I think following up on tickets and PRs is appropriate to make sure
coverage is at the right level and tests are in the right place.
Shubham and Vincent,
Let me start by saying that I apologize for my delayed response to your
original email.
I appreciate the detailed write-up and the thought behind it. I completely
agree with your use case and understand how this is applicable to
enterprises with multiple data teams using
+1 binding.
I have been looking at the doc and having lineage integrated with Airflow
as a provider makes sense to me.
On Mon, Feb 13, 2023 at 2:38 AM Kaxil Naik wrote:
> +1 binding , this should make lineage a first-class citizen for Airflow
> users. Excited for this one
>
> On Sun, 12 Feb
+1 binding , this should make lineage a first-class citizen for Airflow
users. Excited for this one
On Sun, 12 Feb 2023 at 07:57, Jarek Potiuk wrote:
> A little side-track., small comment to what Shubham wrote
>
> Yeah. I also noticed AIP-47 mentioned - but I considered that
> implementation
Fine for me to start this way :)
On Mon, Feb 13, 2023 at 10:56 AM Elad Kalif wrote:
>
> 1) The committer/PMC/Triage member will remove the needs-triage label. This
> is not really an additional step.
> We are already relabeling when we triage an issue. The removal of the label
> doesn't have
1) The committer/PMC/Triage member will remove the needs-triage label. This
is not really an additional step.
We are already relabeling when we triage an issue. The removal of the label
doesn't have to happen on the first touchdown.
Sometimes the triager doesn't have the full knowledge so tagging
Yes. I agree it is a good first step. Let's just not stop on that.
Once we have it, I think starting measuring "responsiveness" is
crucial.
Also - even if it is the first, step, it has to be well defined.
Adding such labels should be accompanied with some way of explaining
and educating those who
> Setting the label does not mean that someone will have eyes on it.
True. but that is just about creating a work queue so when someone does
spend time on triage the issues can be found easily.
This will also address your other points of needing data. By having the
label can measure several
18 matches
Mail list logo
