Bug#971515: marked as done (kubernetes: excessive vendoring (private libraries))
I'm disappointed with TC's decision. IMHO it is lacking depth of judgement. The original problem I reported is absolutism - "vendor everything". And TC apparently considered only that without trying to find the balance. What are the reasons for vendoring stable well maintained library like Logrus? None. That system library can by used easily with hardly any burden to maintenance. Same can be said probably about ~100 other libraries. We could do so much better with recommending at least to un-vendor trivial cases of 3rd party code... > The Committee declines to overrule the maintainer and accepts the level > of vendoring used in the 'kubernetes' source package. We also decline > to intervene in bugs requesting that vendored components in the > 'kubernetes' source package be installed in binary packages in such a > way that other packages can make use of them. > Our consensus is that Kubernetes ought to be considered special in the > same way that Firefox is considered special -- we treat the package > differently from most other source packages because (i) it is very large > and complex, and (ii) upstream has significantly more resources to keep > all those moving parts up-to-date than Debian does. That is based on misleading Elana's comparison that I've answered (regretfully too late) in the other email... > Our most basic reason for this point of view is that given how much > fewer resources we have than upstream Kubernetes, it is not feasible for > Kubernetes to make it into a stable release of Debian unless we take an > approach like this one. IMHO Kubernetes is not suitable for "stable" either way. > The same goes for the possibility of providing > security support. And given that a strategy for security support is > available, we do not see any reason why having the Kubernetes bundle in > a stable release alongside other copies of its vendored dependencies is > worse than not having Kubernetes in a stable release at all. It is not suppose to be "all or nothing" approach. We are talking about 3rd party code, not maintained by Kubernetes. At least some of it is perfectly feasible to take from packaged libraries instead of messy upstream bundle. > It should be noted that we think the greater resources of upstream Let's not praise greater resources unnecessarily. Upstream don't care about good versioning practices and even automatically closes bugs for inactivity without addressing them (e.g. https://github.com/kubernetes/ kubernetes/issues/17077). > is > relevant not only to keeping on top of patches and security fixes, but > also to license compliance. It is our belief that there is no reason at > the present time to be concerned that non-DFSG material would find its > way into the package, because Kubernetes upstream care about ensuring > that all vendored dependencies are free software, and they have the > resources to check. Since when we are delegating DFSG compliance to upstream based on faith?? FYI in case of "cadvisor" - a required Kubernetes component, DFSG compliance was difficult to achieve due to pre-minified source-less 3rd party javascript files... It was a hell of an effort to get Kubernetes through NEW process. Apparently I should not have bothered with all that because upstream is so "good" (it wasn't). Did you ask ftp-masters opinion/position on that?? Are they OK with volume of needless garbage in vendored bundle? Would they allow that before TC's conclusion? > This could change in the future and it may not be > true for other upstreams. I've spent about a year of effort for introducing Kubernetes to Debian - yes, I had that much faith in Kubernetes but ultimately the effort lead to disappointment in the technology and loss of confidence in upstream's ability to maintain the project. But in the course of the effort many new libraries were introduced as packages, the Debian Golang ecosystem was stabilised and we've gained a valuable experience with maintaining a complex Golang software. The hard work was accomplished and it was only the matter or maintaining Kubernetes properly... The TC's decision tells me that the effort was largely wasted because it was "too hard" to do things this way... Naturally the sloppy way is so much easier... :( -- Best wishes, Dmitry Smirnov GPG key : 4096R/52B6BBD953968D1B --- There are occasions when it pays better to fight and be beaten than not to fight at all. -- George Orwell --- "Increased Risk of Noninfluenza Respiratory Virus Infections Associated With Receipt of Inactivated Influenza Vaccine". -- https://pubmed.ncbi.nlm.nih.gov/22423139/ signature.asc Description: This is a digitally signed message part.
Bug#971515: marked as done (kubernetes: excessive vendoring (private libraries))
Your message dated Wed, 20 Jan 2021 12:28:46 -0700 with message-id <87mtx35rwx@melete.silentflame.com> and subject line CTTE decision on "kubernetes: excessive vendoring (private libraries)" has caused the Debian Bug report #971515, regarding kubernetes: excessive vendoring (private libraries) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 971515: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971515 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: tech-ctte Severity: normal X-Debbugs-CC: o...@debian.org Control: block 970717 by -1 Dear Technical Committee, Apologies that we were not able to resolve the problem without your help. I seek your judgement regarding excessive, unnecessary and unjustifiable vendoring of private libraries in Kubernetes package: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970717 Some relevant argumentation can be found in https://lists.debian.org/debian-devel/2020/03/msg00359.html https://lists.debian.org/debian-devel/2020/03/msg00400.html https://lists.debian.org/debian-devel/2020/03/msg00441.html In short, myself and Golang packaging team spent years on stabilising Golang ecosystem of packaged libraries for re-use by Golang software. To the best of my knowledge, all packaged Golang software, regardless of its sophistication, use some packages libraries. Except Kubernetes, that disconnected itself from cooperation by not using any packaged libraries, instead exclusively using only private libraries in numbers greater than any Debian package ever used. As a former Kubernetes maintainer and a developer who originally introduced Kubernetes to Debian, I know that it could be maintained with only few (or several) private libraries at most. Current state of Kubernetes package is in violation of ftp-master's policy for inclusion of new packages to Debian. Thank you. This matter is not urgent. -- Regards, Dmitry Smirnov --- We do our friends no favors by pretending not to notice flaws in their work, especially when those who are not their friends are bound to notice these same flaws. -- Sam Harris signature.asc Description: This is a digitally signed message part. --- End Message --- --- Begin Message --- Hello, The Committee declines to overrule the maintainer and accepts the level of vendoring used in the 'kubernetes' source package. We also decline to intervene in bugs requesting that vendored components in the 'kubernetes' source package be installed in binary packages in such a way that other packages can make use of them. Our consensus is that Kubernetes ought to be considered special in the same way that Firefox is considered special -- we treat the package differently from most other source packages because (i) it is very large and complex, and (ii) upstream has significantly more resources to keep all those moving parts up-to-date than Debian does. In the case of Kubernetes, what this means is that instead of breaking the package down into separate libraries connected together with dpkg dependency relationships, as is usual, we take updates of the whole set of sources directly from upstream and make a single upload to our archive. Our most basic reason for this point of view is that given how much fewer resources we have than upstream Kubernetes, it is not feasible for Kubernetes to make it into a stable release of Debian unless we take an approach like this one. The same goes for the possibility of providing security support. And given that a strategy for security support is available, we do not see any reason why having the Kubernetes bundle in a stable release alongside other copies of its vendored dependencies is worse than not having Kubernetes in a stable release at all. It should be noted that we think the greater resources of upstream is relevant not only to keeping on top of patches and security fixes, but also to license compliance. It is our belief that there is no reason at the present time to be concerned that non-DFSG material would find its way into the package, because Kubernetes upstream care about ensuring that all vendored dependencies are free software, and they have the resources to check. This could change in the future and it may not be true for other upstreams. -- Sean Whitton signature.asc Description: PGP signature --- End Message ---
