Open Stack

Samuel Cassiba wrote:
>> On Jun 22, 2017, at 03:01, Sean Dague <sean at dague.net> 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)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170622/6cbb7950/attachment.sig>