On Friday, 20 November 2020 4:35:23 PM AEDT Elana Hashman wrote: > Kubernetes is a very large and active project. It has about 600 > members, 1000 voters, 100 committers (which I define as members of > the milestone-maintainers team), and over 50,000 contributors. The > project has its own security and release teams, and the release > team includes a software licensing team. > [...] > As such, the scale of Kubernetes is similar to that of Debian itself.
I was too slow to reply to this email but I'll leave some comments for the record. Comparison of Kubernetes' team size to Debian is misleading and the comparison is not in favour of Kubernetes. Debian is compartmentalised into relatively small (mostly) well coordinated teams. Kubernetes - the monolithic project - suffers from well known problem with coordinating large teams. Frederick Brooks described the problem well in his "The Mythical Man-Month" book. Regarding number of contributors, what is strength for Debian is a weakness for Kubernetes. Kubernetes bug tracker shows the scale of the problem and I don't have impression that the team is big enough to handle bug reports effectively or have them under control. It was my observation that vendoring problems in Kubernetes are worse than everything I've seen in other projects. Is that despite the size of the team or because of it? The particular example that I did not mention enough  (and it is not the only one) show how little that remarkably large team cares about dependency hygiene: a trivial library update with a patch was not done in a few years time and all that was produced by the large team are excuses for not doing the update, only to finally perform it in the end as advised. Who can have confidence in the Kubernetes dependency management after that? : https://github.com/kubernetes/kubernetes/issues/27543 Of course the problem have little to do with Kubernetes. The "use world" situation with over-dependency on large number of 3rd party libraries is a challenging one especially with historically poor Golang approach to dependency management a.k.a. "vendoring". I'm just saying that Kubernetes is not all that special in regards to vendoring because of the team size. > Kubernetes as an upstream project is much better resourced than the > single downstream maintainer in Debian. Nobody argues with that. But it is only "single maintainer" with monolitic packaging - a case that I'm arguing against. Golang team is strong and its capacity is impressive. Packages that use dependency libraries are always team-maintained. It is the same situation as with Kubernetes upstream where much of the 3rd party code is not maintained by Kubernetes team. > The resourcing and scale of the Kubernetes project gives us better > assurances that upstream has done due diligence for dependency > management. IMHO upstream demonstrated bad and terrible attitude with dependency management. But apparently nobody here considered that argument... :( -- Kind regards, Dmitry Smirnov GPG key : 4096R/52B6BBD953968D1B --- We often refuse to accept an idea merely because the way in which it has been expressed is unsympathetic to us. -- Friedrich Nietzsche --- COVID-19: The Trouble With PCR Tests https://swprs.org/the-trouble-with-pcr-tests/
Description: This is a digitally signed message part.