Hi Ernesto,
thanks for your feedback!
On 6/25/19 7:49 PM, Ernesto Puerta wrote:
Interesting debate you brought up here, Lenz!
Wouldn't want to divert
from the original question, but...
The interesting thing is that, as the paper says, BECAUSE of that
monolithic approach Google couldn't keep on using P4 (as it no longer
scaled enough) and had to build their own VCS.
Because they can :)
I personally think that git still scales quite well for a project of the
size of Ceph (in terms of contributors and code base).
Besides, P4 (not sure if Piper follows the same
approach) made really
easy to setup up workspaces with cherry-picked dirs to sync (instead
of whole repo clones). So IMHO the debate should not be only about
mono-repo vs. multi-repos, but centralized mono-repo vs DVCS
multi-repos.
But that would likely require more drastic changes, wouldn't it?
In my experience this is also about the practices
& cultures
allowed/fostered by mono-repo vs. multi-repo ecosystems:
- code, dirs & files vs. architecture, modules & interfaces
- atomic (backward-breaking) changes vs. extending functionality while
honoring APIs
- code sharing/reuse/ownership vs. functionality sharing/reuse/ownership *
- grep vs. documentation
- #include dependency management vs. declarative dep. mgmt
- build everything vs. delta builds
- E2E testing vs. integration testing
- 1 tool for everything (VCS) vs. pipelines (VCS, CI, artifact/release
management, CD, etc.)
* mono-repos make really hard to share/spread code beyond the repo,
BTW, here's (
https://www.youtube.com/watch?v=W71BTkUbdqE) a recorded
talk about that paper, and it contains a few 'gems' ("Google solves
dependencies by statically linking everything", "can do massive
backward-incompatible changes... atomically").
Thanks for sharing your insights! I guess we would have to start with
collecting current pain points and concerns and then figure out if any
of these approaches would help to alleviate them. In my case, I outlined
the reasons for my proposal in my initial message. Having worked on
openATTIC as an independent project before, we really enjoy working on
the dashboard as a "built-in" component. Less surprises...
This is a relief to hear (to collect pain points), because the
ceph-volume experience has been tremendously hard: it made testing
slower, it needed to release faster because fixes/improvements
were produced at a rate that the release cycle couldn't accommodate
(this has since slowed down though), and lastly the backporting of
everything in master all the way down to Luminous took
out a good chunk of our time that we never anticipated.
There has been talk of pulling ceph-volume out of the tree but I
frankly doubt that the enormous amount of work it would take would
benefit us. We wouldn't get the "we no longer need to backport" until
Nautilus (!) is no longer
supported.
Having a conversation about this is great though, happy to add more
details of what worked well and what didn't in the case of
ceph-volume.
>
> Lenz
>
> --
> SUSE Linux GmbH - Maxfeldstr. 5 - 90409 Nuernberg (Germany)
> GF: Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)
>
> _______________________________________________
> Dev mailing list -- dev(a)ceph.io
> To unsubscribe send an email to dev-leave(a)ceph.io