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
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
@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
@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
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
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
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
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
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
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
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
11 matches
Mail list logo