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,[0] 1000 voters,[1] 100 committers (which I define as members of
> the milestone-maintainers team),[2] and over 50,000 contributors.[3] The
> project has its own security[4] and release teams,[5] 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 [1] (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?
[1]: 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/
Attachment:
signature.asc
Description: This is a digitally signed message part.