Samuel Cassiba wrote: >> On Jun 22, 2017, at 03:01, Sean Dague <[email protected]> wrote: >> The micro repositories for config management and packaging create this >> overwhelming wall of projects from the outside. I realize that git repos >> are cheap from a dev perspective, but they are expensive from a concept >> perspective. > > I ask, then, what about those communities that do advocate one repo per > subproject? Chef is one such case in which monolithic all-in-one repos used to > be the mainstay, and are now frowned upon and actively discouraged in the Chef > community due to real pain felt in finding the right patterns. In the past, we > (Chef OpenStack) experimented with the One Repo To Rule Them All idea, but > that > didn’t get much traction and wasn’t further fostered. Right now, what works > for > us is a hybrid model of community best practices doing one repo per > cookbook/subproject and a single “meta” repo that ties the whole thing > together. Maybe that one repo per subproject pattern is an anti-pattern to > OpenStack’s use case and we’re now getting to the point of criticality. Past > iterations of the Chef method include using git submodules and the GitHub > workflow, as well as One Repo To Rule Them All. They’re in the past, gone and > left to the ages. Those didn’t work because they tried to be too opinionated, > or too clever, without looking at the user experience. > > While I agree that the repo creep is real, there has to be a balance. The Chef > method to OpenStack has been around for a long time in both Chef and OpenStack > terms, and has generally followed the same pattern of one repo per subproject. > We still have users[1], most of whom have adopted this pattern and have been > in > production, some for years, myself included. What, I ask, happens to their > future if Chef were to shake things up and pivot to a One Repo To Rule Them > All > model? Not everyone can pivot, and some would be effectively left to rot with > what would now be considered tech debt by those closer to upstream. “If it > ain’t broke, don’t fix it” is still a strong force to contend with, whether we > like it or not. Providing smooth, clear paths to a production-grade open cloud > should be the aim, not what the definition of is, is, even if that is what > comes naturally to groups of highly skilled, highly technical people.
I don't think Sean was advocating for "one repo per project". I just think he was pointing to the hidden cost of multiplying repositories. I certainly wouldn't support a push to regroup repositories where it doesn't make sense, just to make a GitHub organization page incrementally more navigable. -- Thierry Carrez (ttx)
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
