On Thu, Nov 19, 2020 at 09:35:23PM -0800, Elana Hashman wrote: > 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. Sorry, I'd to say I disagree on this. Disclaim: I'm a long term user of kubernetes, and contribute to container related upstream for a long time. We should think what kubernetes means to Debian. Yes, it's popular enough, but is the Debian packaged kubernetes popular enough? But supplying kubernetes in Debian, we are offering a kubernetes distribution. Let's prove it works well, then consider special-case it, eg to include it in stable, and do security backport etc. IMO, the current kubernetes package only has an usable kubectl package. I don't think anyone can set up a kubernetes cluster using the Debian packaged one. Firefox is special, since for Debian desktop users, they need a browser. Is kubernetes same here? There are projects popular as kubernetes, that have difficulty to be included in stable release, like Gitlab, which Debian uses as well. PS, Gitlab itself has vendor issue, but the current maintainer does a well job to unvendor. -- Shengjing Zhu
Attachment:
signature.asc
Description: PGP signature