On 4/10/20 9:50 AM, Marc Haber wrote: > A package without upstream support is bound to be a zombie.
There's many examples of this in Debian. It all depends, and you cannot make a generality like this. On 4/10/20 9:43 AM, Marc Haber wrote: > On Thu, 9 Apr 2020 08:47:16 +0200, Thomas Goirand <z...@debian.org> > wrote: >> On 4/8/20 10:44 PM, Peter Silva wrote: >>> doesn´t this whole discussion just mean that k8 should just not be in >>> Debian? >> >> IMO no. It means that if we have enough packaging resources (which >> probably we don't, I can't tell), > > We don't. That's the problem: We might have the personpower to > _PACKAGE_ a monster like openstack, docker or k2s, but we definetely > dont have the resources to actually SUPPORT the software for the > entire stable-oldstable etc lifecycle. Thanks, but I believe I'm doing well regarding security fixes of OpenStack in Debian. Sure, I have given-up on old-stable, but stable has been fine for at least the last 2 or 3 releases. I'm even trying to push for more stable updates, but it isn't easy to get them accepted by the stable release team. If you want to help there, please review the changes and convince the SRT we need them... > We NEED upstream support for > that, and if we even don't have that right after our release (when the > software is already half a year old), then we are not doing ourselves > and our users a favor by providing packages at all. I believe you're wrong here, sorry. Let me attempt to explain from my experience with maintaining OpenStack in Debian over the last 9 years. Packaging is actually the *much* bigger part, compared to security fixes. The first early years of OpenStack were terrible, because on each release, I had 20 to 30 new Python dependencies to package. But after that initial period, it all settled, as the upstream designed was more or less done. It eventually became smoother. I don't see why it wouldn't be the same pattern with Kubernetes. Maintaining a big amount of language libraries isn't *that* difficult and time demanding. It's a bit time demanding at first, to prepare the initial packages, then it eventually gets better once you've done the bulk of the work. If you have an optimized workflow, it is possible to upload dozens of time a day (yes, *multiple* dozens of packages) to get everything updated. So, that's some kind of commitment. I'm not sure if Janos is ready for it, or even paid for doing it (which IMO is necessary in this case), and has enough time, but you probably should at least give him a chance and let him try, or simply ask him directly. Today, with a few more dependencies getting in, the OpenStack team just reached the milestone of 500 packages. It used to scare me. It doesn't anymore. Especially since I've met other people in Debian maintaining so many packages, like for example Andreas Tile, or when I heard about what Jeremy Bicha is doing with Gnome. I'm also impressed with what Mike Grabriel has been doing too! On the opposite side, most security fixes need a tiny small fix of a few lines. Most of the time, easy to backport. There's indeed these rare cases where the security fix needs a more deep change in the code, and in such case, we may need the help from upstream. But we can't tell in advance if this is going to be needed during the life of Debian stable. The only thing we can do is survey how many big security issue we've seen over let's say the last year, and how many of them needed a big patch to fix it. I don't know Kubernetes enough to tell, and even less its security record, so this really is an open question! >> As a user, I'd prefer Kubernetes to be in Stable if possible. I'd be one >> of these users who don't care about the latest shiny feature, and prefer >> something stable, supported for YEARS to come, not just 3 months. > > That a big package in Debian stable that has been abandoned by > upstream months or even years ago is actually supported is fairy tale. It depends on many factors, like the security record which I just talked about above. In many cases, I was able to backport security fixes for versions of OpenStack that were EOLed a long time ago, because security fixes were 2 liners. And OpenStack got a WAY better than it used to be (understand: one CVE each 3 to 6 months instead of each 3 weeks, literally). > You're lying to yourself if you believe that you'd get full security > support for a two years old kubernetes release in Debian stable. Is Kubernetes *that* bad regarding security?!? Gosh, it's a call for never using it then, whatever the method of deployment! > The utmost you'd get would be an occasional security fix where an > upstream fix would get _flagged_ as security relevant _AND_ > coincidentially backportable to our version. Don't you also think that, over time, Kubernetes will mature, and its upstream will eventually learn from their mistakes of never willing to help downstream distros? How will they learn it if we don't show them the way we're doing things? Influencing the way upstream is doing release management is not easy, but possible. It may require attending design sessions (is there such things in Kubernetes?) and being involved with the discussions happening upstream. Sometimes, just opening thread to explain what Debian needs. Also, I'm having a hard time believing that *all* contributors of Kubernetes behave as badly as described in this thread. I'm sure that there must be some Debian lovers being deeply involved in Kubernetes. Last, there's also the option which Dmitry is advocating for: having the packages in Testing only. Debian Testing is also a nice place to consume Debian, I see no problem with that. Cheers, Thomas Goirand (zigo)
