Bug#971515: marked as done (kubernetes: excessive vendoring (private libraries))

2021-01-21 Thread Dmitry Smirnov
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/

> 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 

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 
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 

> 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 


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/

Description: This is a digitally signed message part.

Bug#971515: Status as of last tech-ctte meeting

2021-01-21 Thread Dmitry Smirnov
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

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

Description: This is a digitally signed message part.