Worth noting that git has the ability to cherry-pick only specific directories.
If we keep all of helm + tests in one directory, docker + tests in another, and
core + tests in a third directory it would be pretty simple to automate
splitting them.
https://stackoverflow.com/questions/19821749/gi
I can’t agree with this enough :). I think writing a few bots to separate out
sections will be MUCH easier in the long run than maintaining multiple repos.
Will also prevent the difficulty of setting up a proper dev environment for new
contributors.
via Newton Mail
[https://cloudmagic.com/k/d/m
Yeah. I think that the "monorepo" is the only way for now - until (or if)
we reach the size (and maturity) that different teams take care of the
different projects. Which might even not happen.
But I would love to try the separate repos to publish/release still (maybe
not immediately, but it is a
Hmm.. I agree the git-sync would have been a difficult one to solve if we
had separate repositories.
Well, in that case, the mono repo approach (like we have now) indeed makes
more sense.
Regarding the Kubernetes approach, I feel the ones in staging (
https://github.com/kubernetes/kubernetes/tree
And one more perfect illustration of what I am talking about.
A very good thing just happened. I was running the PR while writing the
email (long time as you might imagine) and the new K8S tests with 1.10.11
just failed. https://github.com/apache/airflow/pull/9663
If had released the helm chart b
I just have another example of a case where splitting the repos and using
only "released versions" across repositories might be a complete overkill
when it comes to development complexity.
We have this change from Aneesh:
https://github.com/apache/airflow/pull/9371 about
adding a git-sync option t
Monorepo FTW.
Yes, it gets a little bit messier around release, but the approach of
automatically extracting out the commits (or parts of commits) to a
separate repo for releasing may be the solution to that problem
-ash
On Jul 3 2020, at 7:51 pm, Kaxil Naik wrote:
> I will take a look at t
I will take a look at the Kubernetes approach and get back to this thread.
We had a discussion with Daniel yesterday and we are both concerned about
> all the overhead for people like us who work on all three "entities" at the
> same time. Even just explaining how to work with Pull Requests and in
I think Ry's point is an important one - I thought about writing a longer
post but I looked at the Kubernetes structure and I really like it so just
wanted to comment on this last one.
Seems that it is simply one "authoritative" (or source of truth) repo where
everything is developed in monorepo f
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
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
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
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
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 example: How do I test/integration test a change that involves a ch
Sure. We can work with such an approach. There will be some dependencies
that we might find are problematic, but If we all see that it's
worth trying, there is a clear benefit that it makes for a "clean"
split between those different "entities". And possibly once we release
first versions of both i
I think we should have "separate repos for development" too.
3 Repos in total:
1) apache/airflow
2) apache/airflow-docker-image
3) apache/airflow-helm-chart
(1) *apache/airflow* should use a pinned stable version of Airflow Helm
chart to run Kubernetes tests
(2) *apache/airflow* already has *Do
I do not think it's only the question of Mono/Multi repos. While I clearly
see the benefit of separate repos I also see some drawbacks.
And if it bothers others, I am happy to follow the majority. If we think
that a bit more complexity in testing justifies separating those three
completely and hav
Thanks Kaxil.
Both ideas (having separate repos and having separate voting) sounds sensible
to me. Cannot really think of significant drawbacks.
XD
> On 1 Jul 2020, at 9:35 PM, Kaxil Naik wrote:
>
> Forgot to mention, having them in separate repo also helps in better
> managing each individ
Forgot to mention, having them in separate repo also helps in better
managing each individual artifacts.
Each repo would have a separate Github Issue where we can track the issue
specific to Helm chart or Dockerfile.
Regards,
Kaxil
On Wed, Jul 1, 2020 at 8:30 PM Kaxil Naik wrote:
> The PMC als
The PMC also needs to agree if we want separate VOTING for Docker Image and
Helm chart, I think we do.
Regards,
Kaxil
On Wed, Jul 1, 2020 at 8:06 PM Kaxil Naik wrote:
> Hi all,
>
> What do you all think about having Dockerfile and Helm chart in the same
> "Airflow" Repo vs separate?
>
> I feel
Hi all,
What do you all think about having Dockerfile and Helm chart in the same
"Airflow" Repo vs separate?
I feel having a separate repo for Airflow Dockerfile and Helm chart have
more benefits like easy to track changes (via Changelog), easy for new
contributors, separate release cadence.
Cur
23 matches
Mail list logo
