On Wed, Nov 18, 2020 at 11:36:09AM -0600, Gunnar Wolf wrote: > ... > I'm pasting here a bit of the discussion that happened later during > the meeting: having this discussion K8S-specific, Elana mentioned that > "that is a big part of the tension. sometimes, you have an upstream > where the authors are less resourced and responsive than the > downstream. this case is almost certainly the opposite". To better illustrate this quote, I agreed to provide more context on the scale of the Kubernetes project. 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. I am a SIG Chair and milestone maintainer in the upstream Kubernetes project, which is comparable to being a team lead and uploading developer in Debian. As such, the scale of Kubernetes is similar to that of Debian itself. Kubernetes as an upstream project is much better resourced than the single downstream maintainer in Debian. [0]: https://github.com/orgs/kubernetes/people [1]: https://github.com/kubernetes/community/blob/8bdeb0a4d6e7a3fc9afdb874aa2cefa2ba88bc9c/events/elections/2020/voters.md [2]: https://github.com/kubernetes/org/blob/adc0166a081ec7a613ebc8422d9676ff4035fc31/config/kubernetes/sig-release/teams.yaml#L17-L141 [3]: https://k8s.devstats.cncf.io/d/24/overall-project-statistics?orgId=1 [4]: https://github.com/kubernetes/security [5]: https://github.com/kubernetes/community/tree/master/sig-release > At this point, we found some friction as to _what_ we are discussing > on: Is this bug specifically on Kubernetes, which should be taken as a > special case? Or would we try to rule as the Technical Committee on > vendoring in general in the Debian ecosystem? Elana repeated her > assurance that the Kubernetes team is thorough in their > freeness-checking and security practices; I insisted on "not > discussing about K8S, but about a bundling practice to which K8S > subscribes". The scope of the bug as submitted is limited to the Kubernetes package. I think it is better to try to limit our decision to that scope, as Kubernetes is not comparable to a single-maintainer Golang project that might have a similar number of vendored dependencies. The resourcing and scale of the Kubernetes project gives us better assurances that upstream has done due diligence for dependency management. I don't think we could assume this for an arbitrary package. Per yesterday's TC discussion,[6] I think it makes sense to handle Kubernetes with consideration to its size and importance to users, similar to how we special-case Firefox. - e [6]: http://meetbot.debian.net/debian-ctte/2020/debian-ctte.2020-11-18-17.58.html
Attachment:
signature.asc
Description: PGP signature