Hello Dmitry, others, On Thu 01 Oct 2020 at 11:15am +10, Dmitry Smirnov wrote:
> 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. I think that my message [1] is what makes you think that the package would not have got through NEW? There are a few issues tangled together here. NEW is mainly about license and DFSG compliance, and secondarily about the idea that we want to avoid accepting packages where doing so would make Debian worse, even if it would also make Debian better along other dimensions. As a simple example, we try to avoid accepting a package that is already packaged under a slightly different name, because in most cases it is worse for both users and contributors to have the same thing in the archive twice (not talking about vendoring here). In this case, the reason I wrote in [1] that I would probably have rejected the package, had I come across it in NEW, is that it seemed to me that having this package in Debian would make the archive less maintainable by contributors other than Janos who might need to work with the package. (After the discussion on -devel, I'm no longer so sure about that opinion of mine.) It's not correct to say, however, that the package "is in violation of ftpmaster's policy for inclusion of new packages". That could only be true is if the package met one of the "serious violations" listed in the REJECT-FAQ, which is basically DFSG and licensing issues, and a few obvious clangers. Instead, what we have is a situation in which there is reason to be worried about the way the package is put together, but the opinion of one FTP team member at one particular point in time carries about the same weight as the opinion of any experienced packager. In other words, I suggest that we ignore the NEW issue entirely, and just consider whether the way the package is currently put together imposes an unreasonable burden on Debian contributors other than Janos who want to work on the package, or users who want to patch it, etc. The sorts of questions we should try to answer: - does the vendoring make Debian security support harder (discussion on -devel suggests it makes it easier) - everyone seems to think the level of vendoring is at best a necessary evil; if someone wants to try to reduce the level of vendoring (as Dmitry did when he was maintainer), is the current way the package is built going to make it harder for people to work on making that sort of contribution? - are people trying to do cross-archive work going to find the packaging of kubernetes getting in their way? (e.g. other Go team members trying to update things, improve our binNMU techniques and machinery, etc.) ... and this is to be weighed against the negative impact of having kubernetes in Debian lag so seriously behind upstream such that almost no-one would want to bother installing it. Are there issues the TC should think about which do not fall under this way of looking at things? I.e., weighing the impact on people other than Janos who want to work on the package, vs. the impact on people who want recent kubernetes to be part in the archive at all? If I'm right about what the question for the TC is, I hope that Janos and Dmitry can both help us discuss it in a way which sets aside the heat which characterised the -devel thread. It is completely understandable to (a) feel very frustrated at Debian not including recent versions of a useful piece of free software; and also (b) feel very frustrated when someone chooses to accept a less-than-ideal approach as necessary when one has put a lot of time into trying to find workable alternatives. The thing is, both (a) and (b) are motivated by the same basic desire to make Debian better and more useful, so perhaps we can focus on that point of commonality. [1] https://lists.debian.org/debian-devel/2020/03/msg00363.html -- Sean Whitton