Thanks Jarek, much clearer. I have voted there too. -ash
> On 29 Jul 2019, at 08:13, Driesprong, Fokko <fo...@driesprong.frl> wrote: > > Thanks Jarek, the Wiki works much better for me. I've added my vote there > as well. > > You've convinced me on the second case. I've changed my vote on Case 2 from > A to B :-) > > Maybe we should leave the vote open a bit longer since it involves quite > some reading, and I would like to get some proper feedback and opinions on > this. Plus I only see two votes right now. If we don't think this through, > it might be that we're having this vote again in the near future :-) > > Cheers, Fokko > > Op zo 28 jul. 2019 om 10:49 schreef Jarek Potiuk <jarek.pot...@polidea.com>: > >> I updated the AIP-21 proposal in the way that should answer all the >> concerns in this thread. >> >> NOTE! There is an action for all of those who are interested: Please >> fill-in your voting in the voting table till Tuesday 30th of July 6pm CEST >> (5pm BST, 9 am PST). >> >> I created a summary of the proposal >> < >> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-21%3A+Changes+in+import+paths#AIP-21:Changesinimportpaths-Summaryoftheproposal >>> >> in table form - which contains also examples for each case. >> >> I added a voting table >> < >> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-21%3A+Changes+in+import+paths#AIP-21:Changesinimportpaths-Voting >>> >> where you should add your votes: >> >> I propose this voting mechanism: >> >> Voting will take place till *Tuesday* 30 Jul 2019 6pm CEST (5 pm BST, 9am >> PST) . >> >> After the choice, the final consistent set of choices will be announced >> (taking into account majority of binding vote, also including potential >> vetos and consistency between the choices. Non-binding votes will be taken >> into account in case there is a draw. The final set of choices will be >> announced at devlist thread >> < >> https://lists.apache.org/thread.html/4cedc94bee53ad908eee8333a56b58be8b5641881e73f69b97e436a9@%3Cdev.airflow.apache.org%3E >>> >> after >> the voting completes. >> >> Unless there is a veto raised to the final proposal, the final proposal is >> accepted by Lazy Consensus >> <https://community.apache.org/committers/lazyConsensus.html> on *Friday* >> 02 >> Aug 2019 at 6pm CEST (5 pm BST, 9am PST). >> >> Please let me know if what I proposed can be further improved to avoid >> chaos. >> >> J. >> >> On Sat, Jul 27, 2019 at 11:41 AM Jarek Potiuk <jarek.pot...@polidea.com> >> wrote: >> >>> Ok. I see that indeed voting could have been organised a bit better - dev >>> list does not seem to cope well with such a complex case :). >>> >>> As Kamil noticed - we already have a formal AIP-21 >>> < >> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-21%3A+Changes+in+import+paths >>> >>> in the Wiki - which I should have mentioned before. I have not much time >>> today - but tomorrow I will try to summarise the options - based on some >>> real code examples (to make it easier to digest). I think the best >> approach >>> will be to make a voting matrix in the AIP-21 Wiki page where people will >>> be able to state their preferences for each case (by adding a row to the >>> table). I think that might provide much better clarity and a single place >>> which will show the current aggregated state of voting. >>> >>> However - as Ash also stated - some of the options are inter-dependent so >>> at the end we will have to adjust the results in case they are not >>> consistent - and make final voting on aggregated set of cases - but I >>> think in this case following "lasy consensus" - i,e. if noone objects to >>> final set of cases, we will proceed with it.. >>> >>> Do you think that will work better ? >>> >>> J. >>> >>> Principal Software Engineer >>> Phone: +48660796129 >>> >>> sob., 27 lip 2019, 09:26 użytkownik Kamil Breguła < >>> kamil.breg...@polidea.com> napisał: >>> >>>> Document is also available as AIP on wiki: >>>> >>>> >> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-21%3A+Changes+in+import+paths >>>> >>>> On Sat, Jul 27, 2019, 9:07 AM Driesprong, Fokko <fo...@driesprong.frl> >>>> wrote: >>>> >>>>> I agree with all, this is a bit chaotic. For the sake of clarity, I >>>> would >>>>> suggest moving the Google Doc to the Wiki as an AIP. Create a >> structural >>>>> code improvement AIP and then and add a matrix of users/cases where >>>>> everybody can add his vote per case. This gives also the opportunity >> for >>>>> changing your vote on a specific case. WDYT? >>>>> >>>>> Cheers, Fokko >>>>> >>>>> Op vr 26 jul. 2019 om 22:28 schreef Chen Tong <cix...@gmail.com>: >>>>> >>>>>> I agree with Ash. It is clear to vote on each case rather than all >>>>>> together. >>>>>> >>>>>> On Fri, Jul 26, 2019 at 3:54 PM Ash Berlin-Taylor <a...@apache.org> >>>>> wrote: >>>>>> >>>>>>> A number of proposals overlap or add on to each other, so I think >>>> (?) a >>>>>>> single vote makes sense. >>>>>>> >>>>>>> To be clear, my vote is -1 until it's clear exactly what we are >>>> voting >>>>> on. >>>>>>> >>>>>>> On 26 July 2019 20:39:56 BST, Kaxil Naik <kaxiln...@gmail.com> >>>> wrote: >>>>>>>> I agree with Ash and instead of voting on all 7 Cases together, >> how >>>>>>>> about >>>>>>>> separate vote emails for all the cases? Each email can have the >>>>>>>> description >>>>>>>> copied over from the doc. >>>>>>>> >>>>>>>> It would probably be a bit easier to track a decision in the >> future >>>> as >>>>>>>> well. >>>>>>>> >>>>>>>> What do you guys think? @Jarek Potiuk <jarek.pot...@polidea.com> >>>>>>>> @Driesprong, >>>>>>>> Fokko <fo...@driesprong.frl> >>>>>>>> >>>>>>>> On Sat, Jul 27, 2019 at 1:03 AM Kaxil Naik <kaxiln...@gmail.com> >>>>> wrote: >>>>>>>> >>>>>>>>> *Case #1* airflow.contrib.{resources} : *Solution A * >>>>>>>>> >>>>>>>>> *Case #2* git *_{operator/sensor}{/s}.py : *Solution A * >>>>>>>>> >>>>>>>>> *Case #3* {aws/azure/gcp}_* : *Solution C* >>>>>>>>> >>>>>>>>> *Case #4* Separate namespace for resources : >>>>>>>>> *Solution A* >>>>>>>>> >>>>>>>>> *Case #5* *Operator : *Solution A* >>>>>>>>> >>>>>>>>> *Case #7* : *Solution A* >>>>>>>>> >>>>>>>>> On Fri, Jul 26, 2019 at 11:09 PM Daniel Standish >>>>>>>> <dpstand...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I have tried to add some clarification to Jarek's summary, but >> I >>>> am >>>>>>>> a >>>>>>>>>> little fuzzy on exact proposal for case 3 so hopefully Jarek >> can >>>>>>>> further >>>>>>>>>> clarify. >>>>>>>>>> >>>>>>>>>> According to my reading, in this motion cases 4,5,6 are all >>>> either >>>>>>>>>> proposal >>>>>>>>>> *rejections* or otherwise have no effect, so attention can be >>>>>>>> focused on >>>>>>>>>> cases 1,2,3 and 7. >>>>>>>>>> >>>>>>>>>> *Motion is to adopt the following:* >>>>>>>>>> >>>>>>>>>> Case 1 - Solution A - Get rid of contrib >>>>>>>>>> All objects will be moved out of contrib folder and into >>>> respective >>>>>>>>>> non-contrib folder. >>>>>>>>>> >>>>>>>>>> Case 2 - Solution A - Remove object type suffix from modules >>>>>>>>>> Example: >>>>>>>>>> Airflow.operators.foo_operator.FooOperator becomes >>>>>>>>>> airflow.operators.foo.FooOperator >>>>>>>>>> Example: >>>>>>>>>> Airflow.hooks.foo_hook.FooOperator becomes >>>> airflow.hooks.foo.FooHook >>>>>>>>>> >>>>>>>>>> Case 3 - conventions for cloud provider etc prefixes >>>>>>>>>> *I am not sure exactly what the proposal is.* >>>>>>>>>> Example case is >>>> airflow/contrib/operators/gcp_bigtable_operator.py >>>>>>>>>> Since motion adopts case 1 solution A, we can assume it is now >>>> named >>>>>>>> like >>>>>>>>>> so: airflow/operators/gcp_bigtable_operator.py >>>>>>>>>> So what is proposed for this case? >>>>>>>>>> >>>>>>>>>> Case 4 - Solution B - *no change* >>>>>>>>>> This proposal was about namespaces but the motion is to reject >>>> the >>>>>>>>>> proposal. >>>>>>>>>> >>>>>>>>>> Case 5 - Solution B - *no change* >>>>>>>>>> The proposal was to remove class type suffix e.g. remove the >>>>>>>> Operator in >>>>>>>>>> FooOperator, but the motion is to reject this proposal -- i.e. >>>>>>>> motion is >>>>>>>>>> no >>>>>>>>>> change on this case, i.e. we resolve to keep "Operator" (and >>>>>>>> "Sensor") >>>>>>>>>> suffixes on class names >>>>>>>>>> >>>>>>>>>> Case 6 - *No change* >>>>>>>>>> This case concerns object naming inconsistencies, but motion >> does >>>>>>>> not >>>>>>>>>> enact >>>>>>>>>> any specific proposal. >>>>>>>>>> >>>>>>>>>> Case 7 - Solution A - use warnings.warn template for >> deprecation >>>>>>>> warnings >>>>>>>>>> (instead of zope) >>>>>>>>>> Example: >>>>>>>>>> >>>>>>>>>> # in old_package/old_mod.py >>>>>>>>>> >>>>>>>>>> import warnings >>>>>>>>>> from new_package.new_mod import * >>>>>>>>>> warnings.warn("old_package.old_mod has moved to >>>> new_package.new_mod. >>>>>>>>>> Import >>>>>>>>>> of " >>>>>>>>>> "old_package.old_mod will become unsupported in version 2", >>>>>>>>>> DeprecationWarning, 2) >>>>>>>>>> >>>>>>>>>> Reference implementation here: >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >> https://github.com/mik-laj/airflow-deprecation-sample/tree/master/solution1 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> FWIW +1 (non-binding) on 1,2,7 -- unsure on 3. >>>>>>>>>> >>>>>>>>>> I am very happy that this motion now gets rid of contrib. >> Thank >>>> you >>>>>>>>>> Sergio >>>>>>>>>> for turning the tide with your effective argumentation ;) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Jul 26, 2019 at 3:16 AM Ash Berlin-Taylor < >>>> a...@apache.org> >>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Could someone summarise what the proposed name changes are, >>>> here, >>>>>>>> in >>>>>>>>>> this >>>>>>>>>>> thread? Pointing at a google doc and only giving partial >>>> examples >>>>>>>> is 1) >>>>>>>>>> a >>>>>>>>>>> bit difficult to quickly work out what we are voting on, and >> 2) >>>>>>>> using a >>>>>>>>>>> google doc isn't great for a longer term record. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Ash >>>>>>>>>>> >>>>>>>>>>>> On 26 Jul 2019, at 09:14, Jarek Potiuk >>>>>>>> <jarek.pot...@polidea.com> >>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> I would like to recast the vote. Let's start from 0 :) . I >>>> would >>>>>>>> like >>>>>>>>>> to >>>>>>>>>>>> keep the July 30th 6pm CEST date, and at least three +1 >>>>>>>> (binding) >>>>>>>>>> votes >>>>>>>>>>> are >>>>>>>>>>>> needed to pass. I marked in red the modifications to the >>>>>>>> previous >>>>>>>>>>> proposal. >>>>>>>>>>>> >>>>>>>>>>>> Here is the proposal (details here >>>>>>>>>>>> < >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >> https://docs.google.com/document/d/1F8zve5S78DXcjpPttW89HnqT0M0iKjT6fo9jX57Ef6A/edit#heading=h.j4jc3i70qszo >>>>>>>>>>>> >>>>>>>>>>>> ) >>>>>>>>>>>> >>>>>>>>>>>> - *Case 1: A: Get rid of contrib,* >>>>>>>>>>>> - *Case 2: A: Airflow.operators.foo_operator.FooOperator >>>> could >>>>>>>>>>>> become airflow.operators.foo.FooOperator* >>>>>>>>>>>> - *Case 3: C: >>>>>>>>>>>> >>>>>>>> airflow.contrib.operators.gcp_bigtable_operator.BigTableOperator >>>>>>>>>> could >>>>>>>>>>>> become airflow.gcp.operators.bigtable.BigTableOperator* >>>>>>>>>>>> - *Case 4: B: no namespace introduction* >>>>>>>>>>>> - *Case 5: B: Keep "Operator" (and "Sensor") suffixes on >>>> class >>>>>>>>>> names* >>>>>>>>>>>> - *Case 6: We will treat isolated cases on case-by-case >>>> (and >>>>>>>> my team >>>>>>>>>>> can >>>>>>>>>>>> do the job of GCP-related operators)* >>>>>>>>>>>> - *Case 7: Native python solution (with better IDE >>>>>>>> integration)* >>>>>>>>>>>> >>>>>>>>>>>> This is my binding (+1) vote. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Jul 26, 2019 at 10:08 AM Jarek Potiuk < >>>>>>>>>> jarek.pot...@polidea.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hey Felix, >>>>>>>>>>>>> >>>>>>>>>>>>> For 7* -> I am in favour of trying the native one as well >> (I >>>>>>>> use IDE >>>>>>>>>>> quite >>>>>>>>>>>>> often ;) ) >>>>>>>>>>>>> >>>>>>>>>>>>> J. >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Jul 24, 2019 at 9:34 AM Driesprong, Fokko >>>>>>>>>> <fo...@driesprong.frl >>>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks Kamil for putting the document together. I wasn't >>>> able >>>>>>>> to >>>>>>>>>>> respond >>>>>>>>>>>>>> earlier since I was giving Airflow workshops throughout >>>> Europe >>>>>>>> :-) >>>>>>>>>>>>>> >>>>>>>>>>>>>> *Case 1: *Solution A → Remove everything from contrib >> into >>>> a >>>>>>>> single >>>>>>>>>>>>>> package. >>>>>>>>>>>>>> >>>>>>>>>>>>>> To make it easier to the end-user, my preference would be >>>> to >>>>>>>> get >>>>>>>>>> rid of >>>>>>>>>>>>>> the >>>>>>>>>>>>>> contrib package altogether. What's in contrib or not is a >>>>>>>> tricky >>>>>>>>>>> question, >>>>>>>>>>>>>> I think this is already reflected in the document since >>>>>>>> "maturity" >>>>>>>>>> is >>>>>>>>>>> in >>>>>>>>>>>>>> quotes. What would be the moment to transfer the operator >>>> to >>>>>>>> the >>>>>>>>>> core >>>>>>>>>>> or >>>>>>>>>>>>>> vice versa? I'm afraid that renaming contrib to >> incubating >>>>>>>> will >>>>>>>>>> confuse >>>>>>>>>>>>>> the >>>>>>>>>>>>>> user even more. For people who aren't as known with >>>> Airflow it >>>>>>>> isn't >>>>>>>>>>> that >>>>>>>>>>>>>> transparent which operator lives where, especially if you >>>>>>>> don't use >>>>>>>>>> an >>>>>>>>>>> IDE >>>>>>>>>>>>>> such as Ash ;) Besides that I don't think it is worth >>>> changing >>>>>>>> the >>>>>>>>>>> public >>>>>>>>>>>>>> API just for a different name. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Ok. I am convinced. I will re-cast the vote with this. It >>>> will >>>>>>>> make >>>>>>>>>>> easier >>>>>>>>>>>>> as we will not have to define other rules as those that we >>>>>>>> already >>>>>>>>>> have. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> *Case 2:* Slight preference to Solution B (let's say a >> +0) >>>>>>>>>>>>>> >>>>>>>>>>>>>> I like to search on Github with t, and then search for >>>>>>>> BashOperator. >>>>>>>>>>> After >>>>>>>>>>>>>> the change, you should search for Operator/Bash. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jarek, I'm confused with your vote on this, from your >> mail >>>> you >>>>>>>>>> state: - >>>>>>>>>>>>>> *Case 2: B: Airflow.operators.foo_operator.FooOperator >>>> could >>>>>>>> become >>>>>>>>>>>>>> airflow.operators.foo.FooOperator*. But the B solution is >>>>>>>> keeping it >>>>>>>>>>> the >>>>>>>>>>>>>> same, so that would mean - *Case 2: B: >>>>>>>>>>>>>> Airflow.operators.foo_operator.FooOperator *would stay >>>>>>>>>>>>>> airflow.operators.foo_operator*.FooOperator* >>>>>>>>>>>>>> >>>>>>>>>>>>>> My mistake. It was of course A. I think there is a little >>>>>>>> confusion >>>>>>>>>>> here. >>>>>>>>>>>>> This case is not for changing BashOperator into Bash but >> for >>>>>>>> changing >>>>>>>>>>> the >>>>>>>>>>>>> *module* name not the *class* name. So >>>>>>>> bash_operator.BashOperator -> >>>>>>>>>>>>> bash.BashOperator :) . you will still search for >>>> BashOperator >>>>>>>> in this >>>>>>>>>>> case. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> *Case 3:* I'm leaning towards B >>>>>>>>>>>>>> >>>>>>>>>>>>>> Mostly because it isn't as trivial to decide when it gets >>>> its >>>>>>>> own >>>>>>>>>>> package >>>>>>>>>>>>>> or not. Besides the cloud providers, there are companies >>>> like >>>>>>>>>>> Databricks >>>>>>>>>>>>>> and Qubole which might also end up with their own package >>>>>>>> because >>>>>>>>>> their >>>>>>>>>>>>>> integration is getting richer over time. Moving this is a >>>> bit >>>>>>>>>> painful >>>>>>>>>>>>>> because we need to deprecate the old path and move >>>> everything >>>>>>>> which >>>>>>>>>>>>>> introduces noise into version control etc. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I'd say, we should go for C. As I proposed. It's not as >>>>>>>> difficult as >>>>>>>>>> it >>>>>>>>>>>>> seems to group operators in packages and it has numerous >>>>>>>> advantages. >>>>>>>>>> The >>>>>>>>>>>>> nice thing about deprecations - we can do them in the >>>>>>>> __init__.py of >>>>>>>>>> the >>>>>>>>>>>>> packages which causes the noise fairly small (Git will >>>> actually >>>>>>>>>> realise >>>>>>>>>>>>> that the file has been moved and you can follow that. >> Maybe >>>> not >>>>>>>> as >>>>>>>>>> super >>>>>>>>>>>>> easy to merge changes later to 1.10.4 but it's not a >> rocket >>>>>>>> science >>>>>>>>>>> either. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> *Case 7:* Python native solution >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Yes. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> >>>>>>>>>>>>>> Apart from all, great work! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cheers, Fokko >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Op di 23 jul. 2019 om 21:27 schreef Felix Uellendall >>>>>>>>>>>>>> <felue...@pm.me.invalid >>>>>>>>>>>>>>> : >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have no strong "No" against any proposed change of >> these >>>>>>>> cases. >>>>>>>>>> So I >>>>>>>>>>>>>> go >>>>>>>>>>>>>>> with +1 (non-binding). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> P.S. Thanks Jarek for bringing this up again and your >>>> intense >>>>>>>> work >>>>>>>>>>>>>> towards >>>>>>>>>>>>>>> airflow currently :) and thanks to Kamil for even >> creating >>>>>>>> this >>>>>>>>>>>>>> document. I >>>>>>>>>>>>>>> like how the code is getting more and more consistent >> and >>>>>>>> clean :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Kind regards, >>>>>>>>>>>>>>> Felix >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sent from ProtonMail mobile >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -------- Original Message -------- >>>>>>>>>>>>>>> On Jul 23, 2019, 18:34, Jarek Potiuk wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello everyone, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This email is calling a vote on the changes in import >>>> paths. >>>>>>>> It's >>>>>>>>>>> been >>>>>>>>>>>>>>>> discussed in >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >> https://lists.apache.org/thread.html/4e648d9421c792d4537f5ac66f1a16dce468f816fc5221a9f9db9433@%3Cdev.airflow.apache.org%3E >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The vote will last for at least 1 week (July 30th 6pm >>>> CEST), >>>>>>>> and >>>>>>>>>> at >>>>>>>>>>>>>> least >>>>>>>>>>>>>>>> three +1 (binding) votes have been cast. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The proposal to vote is based on the document from >> Kamil >>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >> https://docs.google.com/document/d/1F8zve5S78DXcjpPttW89HnqT0M0iKjT6fo9jX57Ef6A/edit# >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The proposed solution is: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> - *Case 1: B: Contrib vs not: we move all that are >> "well" >>>>>>>> tested >>>>>>>>>> and >>>>>>>>>>>>>>>> rename contrib to "incubating" or similar.* >>>>>>>>>>>>>>>> - *Case 2: B: >> Airflow.operators.foo_operator.FooOperator >>>>>>>> could >>>>>>>>>>>>>>>> become airflow.operators.foo.FooOperator* >>>>>>>>>>>>>>>> - *Case 3: C: >>>>>>>>>>>>>>>> >>>>>>>> airflow.contrib.operators.gcp_bigtable_operator.BigTableOperator >>>>>>>>>>> could >>>>>>>>>>>>>>>> become airflow.gcp.operators.bigtable.BigTableOperator* >>>>>>>>>>>>>>>> - *Case 4: B: no namespace introduction* >>>>>>>>>>>>>>>> - *Case 5: B: Keep "Operator" (and "Sensor") suffixes >> on >>>>>>>> class >>>>>>>>>> names* >>>>>>>>>>>>>>>> - *Case 6: We will treat isolated cases on case-by-case >>>> (and >>>>>>>> my >>>>>>>>>> team >>>>>>>>>>>>>> can >>>>>>>>>>>>>>>> do the job of GCP-related operators)* >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This is my (binding) +1 vote. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> J. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Jarek Potiuk >>>>>>>>>>>>>>>> Polidea <https://www.polidea.com/> | Principal >> Software >>>>>>>> Engineer >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> M: [+48 660 796 129](tel:+48660796129) >>>>>>>>>>>>>> <[+48660796129](tel:+48660796129)> >>>>>>>>>>>>>>>> [image: Polidea] <https://www.polidea.com/> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> >>>>>>>>>>>>> Jarek Potiuk >>>>>>>>>>>>> Polidea <https://www.polidea.com/> | Principal Software >>>>>>>> Engineer >>>>>>>>>>>>> >>>>>>>>>>>>> M: +48 660 796 129 <+48660796129> >>>>>>>>>>>>> [image: Polidea] <https://www.polidea.com/> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> Jarek Potiuk >>>>>>>>>>>> Polidea <https://www.polidea.com/> | Principal Software >>>>> Engineer >>>>>>>>>>>> >>>>>>>>>>>> M: +48 660 796 129 <+48660796129> >>>>>>>>>>>> [image: Polidea] <https://www.polidea.com/> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *Kaxil Naik* >>>>>>>>> *Big Data Consultant | DevOps Data Engineer* >>>>>>>>> *Certified *Google Cloud Data Engineer | *Certified* Apache >> Spark >>>> & >>>>>>>> Neo4j >>>>>>>>> Developer >>>>>>>>> *LinkedIn*: https://www.linkedin.com/in/kaxil >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Kaxil Naik* >>>>>>>> *Big Data Consultant | DevOps Data Engineer* >>>>>>>> *Certified *Google Cloud Data Engineer | *Certified* Apache Spark >> & >>>>>>>> Neo4j >>>>>>>> Developer >>>>>>>> *LinkedIn*: https://www.linkedin.com/in/kaxil >>>>>>> >>>>>> >>>>> >>>> >>> >> >> -- >> >> Jarek Potiuk >> Polidea <https://www.polidea.com/> | Principal Software Engineer >> >> M: +48 660 796 129 <+48660796129> >> [image: Polidea] <https://www.polidea.com/> >>
