[GitHub] [airflow-configure-aws-credentials] dependabot[bot] opened a new pull request #5: chore: Bump aws-sdk from 2.815.0 to 2.825.0

dependabot[bot] opened a new pull request #5: URL: https://github.com/apache/airflow-configure-aws-credentials/pull/5 Bumps [aws-sdk](https://github.com/aws/aws-sdk-js) from 2.815.0 to 2.825.0. Release notes Sourced from https://github.com/aws/aws-sdk-js/releases";>aws-sdk's relea

[GitHub] [airflow-configure-aws-credentials] dependabot[bot] closed pull request #4: chore: Bump aws-sdk from 2.815.0 to 2.821.0

dependabot[bot] closed pull request #4: URL: https://github.com/apache/airflow-configure-aws-credentials/pull/4 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and

[GitHub] [airflow-configure-aws-credentials] dependabot[bot] commented on pull request #4: chore: Bump aws-sdk from 2.815.0 to 2.821.0

dependabot[bot] commented on pull request #4: URL: https://github.com/apache/airflow-configure-aws-credentials/pull/4#issuecomment-758427165 Superseded by #5. This is an automated message from the Apache Git Service. To resp

Re: Airflow Summit 2021 looks for co-organizers

Hi all, We originally thought of only 2 community members to help us with the organization of the summit. I am happy to see great enthusiasm from so many people, but before adding all of you to our weekly meetings, I would like to think of the areas of responsibilities and create a concrete list o

Re: Provider naming: Specifically Salesforce, Tableau and Slack

Seems like we are converging :). I prepared an issue describing it. Let me know if that looks good (seems that we can have backwards-compatible snowflake provider 1.0.1 if we do it well). https://github.com/apache/airflow/issues/13614 I am happy to help if we agree anyone wants to take that issu

Re: Provider naming: Specifically Salesforce, Tableau and Slack

Talked with Ash and yes I think it make sense as a separate provider. A good example is Google -- It is under Alphabet Inc but Google itself is a separate entity and different from its other services like Google Fiber. I am happy for them to be separate providers On Mon, Jan 11, 2021 at 2:36 PM P

Re: Provider naming: Specifically Salesforce, Tableau and Slack

+1 for separate providers. Extending the Salesforce example, it wouldn’t make sense to me to turn the Segment provider into a module of a Twilio provider, as Segment still exists as its standalone product- it is unlikely that a user would get utility from having both Segment and Twilio modules i

Re: Provider naming: Specifically Salesforce, Tableau and Slack

If we go for separate "slack" "salesforce" "tableau" - (which I am also OK with - i have no strong opinion), then we just need to create a separate provider for Tablea'u and de-deprecate the "tableau' extra (plus likely deprecate Hooks/OPerators from Salesforce (which I see that we actually have).

Re: Provider naming: Specifically Salesforce, Tableau and Slack

I'm in favor of separate packages for tableau and slack. Until now I didn't know they are owned by salesforce and I would not even dare to look for them in salesforce provider. In my opinion we should prefer user experience over "business correctness". While amazon and google are big and most of t

Re: Provider naming: Specifically Salesforce, Tableau and Slack

On Mon, 11 Jan, 2021 at 14:04, Elad Kalif wrote: At least for me, most of my ETLs don't use all 3 providers in a single DAG. I'm not sure if most tableau users are aware of it being owned by salesforce, for the end user of tableau it doesn't really mean anything. My thoughts exactly. On Mon

Re: Provider naming: Specifically Salesforce, Tableau and Slack

As a user of all of these 3 providers I think that Ash's suggestion makes sense. At least for me, most of my ETLs don't use all 3 providers in a single DAG. I'm not sure if most tableau users are aware of it being owned by salesforce, for the end user of tableau it doesn't really mean anything. Is

Re: Provider naming: Specifically Salesforce, Tableau and Slack

We do not have (or at least I am not aware of) the Tableau operators - but if we have them, I am rather ok with having a separate provider. I am also for making it 'salescorce.crm, 'salesforce.tableau' salesforce.slack' providers if we think it makes sense. It would be akin to what we have with mi

Re: Provider naming: Specifically Salesforce, Tableau and Slack

This also means we need to rename slack to salesforce.slack On Mon, 11 Jan, 2021 at 11:44, Kaxil Naik wrote: My 2 cents: Personally, I would like `salesforce.tableau` (and `salesforce.crm`). This makes it easier to have a single rule that Providers are Grouped via Org / Owner at the top leve

Re: Provider naming: Specifically Salesforce, Tableau and Slack

My 2 cents: Personally, I would like `salesforce.tableau` (and `salesforce.crm`). This makes it easier to have a single rule that Providers are Grouped via Org / Owner at the top level, but further grouped via Product line. Otherwise, it get's a bit confusing, both from a Dev and User standpoint

Provider naming: Specifically Salesforce, Tableau and Slack

re: So, Salesforce have bought Tableau and Slack. But they are entirely unrelated products -- users of the Slack hooks are unlikely to want to do anything with the Salesforce CRM suite of tools, so I think our naming should be along "product" line