On Thu, Jun 27, 2019 at 5:00 AM Lenz Grimmer <lgrimmer@xxxxxxxx> wrote: > > 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@xxxxxxx > To unsubscribe send an email to dev-leave@xxxxxxx _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
