Re: Separate Repo vs MonoRepo for Dockerfile & Helm Chart

2020-07-02 Thread Ry Walker
One reason to have a monorepo is for project branding, and end user experience. But for component development experience, it's nice to have a small, dedicated repo. I think the git submodule approach is technically sound, but is at odds with making the project easy to consume/understand from the e

Re: Separate Repo vs MonoRepo for Dockerfile & Helm Chart

2020-07-02 Thread Kaxil Naik
Let's come to a consensus first before we do anything :-) Is everyone happy with separate repo approach? Let's wait for 72 hours to hear from all and then have a plan on how we do it? WDYT? But indeed git submodules approach sounds good. We do it for for *Airflow Site *( https://github.com/apache

Re: [VOTE] Release Apache Airflow 1.10.11 based on 1.10.11rc1

2020-07-02 Thread Kaxil Naik
@daniel - This vote is just for Python Wheel and tar.gz not for Dockerfile. Check the separate thread https://lists.apache.org/thread.html/r0a2c68b07775f2401a397ebdc5826ec89a51a4ea4acfadd96e4b7d46%40%3Cdev.airflow.apache.org%3E where I mention about releasing Docker Images and Helm Chart separatel

Re: [VOTE] Release Apache Airflow 1.10.11 based on 1.10.11rc1

2020-07-02 Thread Daniel Imberman
@kaxil could we post release candidates to our docker hub? Would make it easier to test via the helm chart. via Newton Mail [https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.50&pv=10.14.6&source=email_footer_2] On Thu, Jul 2, 2020 at 7:59 AM, Kaxil Naik wrote: Hello Airflow Community, This i

Re: Separate Repo vs MonoRepo for Dockerfile & Helm Chart

2020-07-02 Thread Jarek Potiuk
Absolutely - I am happy to add "best practices" and short "howto do stuff with git submodules" - and this knowledge will only be needed for interacting with prod image/helmchart/running kubernetes tests. For all the other purposes it should be "business as usual". On Thu, Jul 2, 2020 at 4:53 PM D

[VOTE] Release Apache Airflow 1.10.11 based on 1.10.11rc1

2020-07-02 Thread Kaxil Naik
Hello Airflow Community, This is a call for the vote to release Apache Airflow version 1.10.11 from 1.10.11rc1. The release candidate: https://dist.apache.org/repos/dist/dev/airflow/1.10.11rc1/ *apache-airflow-1.10.11rc1-source.tar.gz* is a source release that comes with INSTALL instructions. *a

Re: Separate Repo vs MonoRepo for Dockerfile & Helm Chart

2020-07-02 Thread Daniel Imberman
I think git submodules sounds like a great idea. We would need to write this into the CONTRIBUTING.md to let people know how to do it but It’s a “teach once” situation. via Newton Mail [https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.50&pv=10.14.6&source=email_footer_2] On Thu, Jul 2, 2020 at

Re: Bring all the "non-official" binaries under Airflow Community control

2020-07-02 Thread Jarek Potiuk
And the right Greg here :(, J. On Thu, Jul 2, 2020 at 12:18 PM Jarek Potiuk wrote: > Hey Ash, Greg, Daniel, > > So I understand there is no problem with licenses for those images and we > can get/use the sources for those? > > I would love to add the scripts/Dockerfiles to the sources - to be

Re: Bring all the "non-official" binaries under Airflow Community control

2020-07-02 Thread Jarek Potiuk
Hey Ash, Greg, Daniel, So I understand there is no problem with licenses for those images and we can get/use the sources for those? I would love to add the scripts/Dockerfiles to the sources - to be able to rebuild the images. I have some of those already and would like to make a PR, but It would

Re: Separate Repo vs MonoRepo for Dockerfile & Helm Chart

2020-07-02 Thread Tomasz Urbaszek
I support the idea of separate repos. The git submodules mentioned by Jarek sounds like an interesting solution. It may add some complexity for new contributors but it's not rocket science. If we agree on using this we should add small how-to in contributing.rst I think (i.e. do I have to have fork

Re: Separate Repo vs MonoRepo for Dockerfile & Helm Chart

2020-07-02 Thread Jarek Potiuk
On Thu, Jul 2, 2020 at 3:16 AM Daniel Imberman wrote: I’m fine with keeping it as three separate repos but merging testing > somehow (e.g. the source code chart would pull the helm/docker chart into > .build) but we need to do it in a way that doesn’t make testing too > difficult. > > So for exam