 This talk is about long-term support and squeeze. In brief, I guess, I will not really introduce me. I use Debian since many years. Most I run stable all the time. How many of you use old stable at the moment? Wow. How many of you have used old stable in the past? I guess everybody. And who's still running Lenny system somewhere? Edge. You're still running Edge. Sarts anyone? How many of you use squeeze LTS? Everybody who's using squeeze, I guess. How many of you plan already plan to use Weezy LTS? Because it's a nice idea, but currently it's just a plan. How many of you have uploaded packages to squeeze LTS? Wow. Who's planning to upload packages? So LTS means long-term support, extending the lifetime of squeeze by two years to five. It's hosted on the FTP archive, like all the other suits, and it's currently two architectures only, I386 and MB64. Using LTS is pretty simple. You just add this to the sources list and be done. Supposed to May 2016, they should try to give new packages. Formerly, it's organized by Frisian, or the paid part of it. Add a new line, squeeze LTS. How does that relate to security? Do we keep both of them? Do we remove security? Why do we still have security if we're going to have squeeze LTS? For historic reasons. You keep squeeze in the sources list, you keep the security archive there, but there will be no more security archives there, so you can also remove them. I'm not sure whether there's the packages in there or whether... Maybe the question should be, are the packages that are going to go into the security archive and squeeze cycle also going into the squeeze LTS archive? No, there are no packages going in security anymore. And the LTS packages stay in LTS. Frisian is the company of Raphael Herzog. Yes, this page explains LTS quite well. It's also very suitable for this page to show potential sponsors. The aim is to get 160 hours per month funded. So far there is funding for 36 hours, I think. This is also on this web page. This bar is the aim and this is updated manually because the idea is to find paid developers to do the security updates. The microphone for Kona, please. The microphone. I'm not saying that for myself by far, but looking at the hourly rates and that you're looking to be able to hire people, it would be nice if you considered hiring, looking for people in countries less expensive than Europe. People in my country would be happy to have that salary per day instead of per hour. I'm aware that we discussed this also on the list. So far nobody else has replied to this request. The only people having applied are actually from Europe. Nobody else has applied. So it's five people so far. And you could apply, of course. Maybe not you because you have a different job. Technically we use one Git repository at Freesian which is mostly for the bookkeeping stuff and for find work which looks for packages which sponsors have indicated they need support for that so that we prioritize work based on that. Besides that we use the normal SVN repository secure testing which is also used by the security team. And so we also share the security tracker to find, to track CVEs and track which is buckets fixed in which package and version. The security team is as a team not participating in LTS, though individual members like Raphael Geissert or Moritz Mühlenhoff are participating in LTS. There's uploads can be done by any DD. And besides that there are no restrictions. There's no new queue. There's no proposed updates. What gets uploaded goes directly to the archive. And the only thing then the announcement mail has to be sent manually besides that. So we did this to keep the barrier for entry low. There are some packages in squeeze which are unsupported already. This is the list. You get that when you install the Debian security support package. There's a space missing which is currently available. I'm not sure if it's available for squeeze already because it's not in VC definitely. Maybe it's only in LTS. But this is the list currently. So most of the packages are supported. There's also... Sorry to interrupt again. I see there one package that I am not directly maintaining, but I could perfectly upload as I use it and I keep it updated on my system. Is there a specific reason why it's listed? I have no idea. Therefore you need to talk to the security team. I don't know why the group is not supporting. But the security team doesn't support the LTS. So why would the security team decide which things can't be supported in LTS? Good question. I think it's for historic reasons. Of course, if GUNA wants to decide to support Group R6, they can do that. And then probably that would be changed because it's not true anymore. There have been things where the security team has said we can no longer support this in stable even before the end of regular stable support. Perhaps some of those fall into that. Pardon? There have been cases where security support has been dropped even before the end of regular stable because it became impossible to backport fixes. Can you repeat the question for the stream? When this list was made, basically, or updated? I don't know actually. As you see, this package is also really new. It's only available in Jessie and Sid. Also this idea of having a package installed which takes your system whether there's unsupported software is really new and not really fleshed out well. There are also some special packages which are updated not by just applying patches but by getting new upstream versions. PHP5 and Tomcat 6 are in this boat. For Wheezy, it would also be Tomcat 7 where just a new upstream version is done. Iceweasers are the same in Squeeze as basically unsupportable or unfixable. If we want to support Iceweasers on Squeeze, then it would be just a new upstream version. FMPEG would be in the same boat but it's dropped from the security support so that's not playing. The ways to contribute once is becoming a sponsor. What you get for is that we prioritize the packages being worked on based on the wishes of the sponsors and the money they give. There's on this page the sponsors are listed who are contributing now and there's more direct access to us which so far has not happened but LTS is only two months old or three. And for the highest sponsor class we also accept test cases. That's your test case. We do work normally on the open mailing list on the Debian list server and we have an IRC channel as well. Other ways to contribute is of course just fixing your package or sending patches, reviewing them or testing packages. Future plans, of course VZ LTS is an option. But I'm not sure if Squeeze LTS is a good suit name. Maybe change this again though on the other hand I'm not a fan of changing suit's name all the time. But I don't know. Would it be an option to reuse the existing Squeeze suit instead of having everyone having an old stable add a source, drop other sources to make sure the key doesn't expire and all that. Basically a takeover from the old stable by the LTS team instead of doing a migration. I mean for users that don't care they would be automatically migrating to LTS and if they do then fine. I think the current process of having a new source a different repository, a different suit while the other one isn't used anymore anyway is a little bulky for the users. Yes but that way you would get LTS upgrades even if you don't want them. And on my Squeeze systems I run a copy of Squeeze LTS because I don't want all updates because there is no restrictions on what gets into the archive so I look manually at the packages. So I wouldn't be happy if Squeeze LTS would replace Squeeze. It's more work this way yes. You need to touch your system once. That's the end of my talk already. So more questions. Is there a work list of sort of a wish list of things that need doing for Squeeze LTS? Yes. There is this find work script that uses network and the secure testing repository also. Maybe not that slow. Live demo is always brave. The security tracker is at the moment broken in regards of LTS. It simply doesn't know LTS. I've got a fixed version on my laptop which is half working with LTS which I hope to finish this week with Rafa here so that the security tracker will support LTS completely. And then it's easy to see which packages, like which CVE. While it's loading can we get back to old stable versus LTS? Can you give an example of why would you want to not pull an update from LTS on your old stable system? For example, a new ice freezer version. Is it not supported in LTS anyway? Well, it is, but a new ice freezer I wouldn't mind. But whatever, that's the idea of fixing PHP 5 with a new upstream version with a minor version, so 5.3, I don't know. But this has behavioural changes because some bug fixes are intrusive. So maybe your code doesn't work with that PHP version anymore. That would be an example. So in other words, LTS scope is much wider than that of SecurityDepend.org. So it's not just longer in time, it's also wider in scope. Is that what you're saying? Yeah. Thanks. Given the scope distinction that the LTS could include changes that are larger in scope scale than SecurityUpdates, if I am running, let's say, a couple of servers that are running squeeze LTS, what is the recommended workflow? Because usually, at least my experience with, say, other distributions with LTS is I can run app get dist upgrade or the equivalent. And if anything on my system breaks, either there's a regression or there was literally no other way to solve the security issue and I'm happy or afford to have the regression. What should I be doing? Should I be setting up my own app archive like you do and importing things as a user of the LTS? You should basically read what's on the screen when you do an upgrade. Sure. Because there's the packages being upgraded so far all upgrades have been good. What happens if one is not good? Well, at the moment it's a theoretically risk I see because there is no mechanism, no gate keeping, nothing. But so far all uploads were good. I just don't like it for philosophical or theoretical reasons that in theory any DD can upload anything and it will hit the archives. And of course we do it to provide long-term support so we don't plan to break it. Right. That is a potential user of this. If you are telling me as a maintainer of the project now I am uncomfortable with running unrestricted upgrades on the LTS I'm saying well I will just stick with Ubuntu. I would be much more enthusiastic about switching some systems from Ubuntu to Debian if you said yeah I'm going to change it so not every DD can upload. So there is review or whatever it takes to get to the point where you don't say oh it's too fragile to be part of the regular stable distribution. We can't upload there because it might break something. That's not how it's done at the moment because we want to have lower barrier of entry. Sure. But I think we should change that. Okay. But this is my opinion at the moment. Is there any activity on fundraising for LTS or is that because you said there was not that much money raised at the moment? There is companies are being approached individually. Okay. So there is not as far as I know not a concerned action plan. Can you share a word about how the bugs are supposed to be done? Is that the same as backports we made to list or is that bugs configured to work with old stable LTS then? That bugs works with old stable LTS. And there are no bugs. So I've seen just monitoring the backports list over the last couple of months there have been numerous packages that it is where dependencies aren't met, where there are all sorts of problems, and I think backports desperately needs a staging area and it seems kind of absurd to think something even more targeted at a stable wouldn't have some sort of staging area. And it sounded like you were amenable to that, but I just figured I mentioned like, well, nothing's happened yet, but there's also a lot fewer uploads than with like backports, which is kind of proving that model in my opinion doesn't work very well. I agree. Although I will argue a bit to the other side, backports are meant to disrupt in some way. They're introducing new versions. LTS is not introducing new versions just patching, so it should not break anything. It's just less likely to. Not should not. LTS does version upgrades. Miner version upgrades, but yeah. Like security also. Security doesn't. Security does as well. Postgres is also another example of a package which gets new... Not for all packages. Well, so Postgres got whitelisted by the security team for minor version upgrades, right? And actually, we from Creator Chief plan on providing further support for Postgres, if possible, because it also ran out in upstream, but we're working on that just as an information. It's not really announced or anything, but we try to do that. But isn't there another... Shouldn't there be a list from the security team that the packages have been approved or whitelisted for minor version upgrades and then that should be taken over to LTS? I mean, I think that would be the sensible approach. It sounds to me a little from this discussion that we need a clear policy on what we're doing for LTS in terms of are we trying to avoid minor version upgrades wherever possible or something like that. It seems like there's a bit of uncertainty about exactly what we're trying to do with LTS. Clearly stated policy of, you know, when do we do bug fixes or when do we allow minor version upgrades? Because there does seem to be a lack of clarity about that. The policy follows the security team policy mostly. And maybe it's a good idea to do it a bit more relaxed later, because then, I don't know, but you're all invited to voice your concerns on the mailing list because what's been said here is most likely to be forgotten. Your fine work script, is this a public repo? No. That would be a good start, I guess. Will there be a exact date given for how long each, say, Weezy, for instance, would be supported in advance so that people can plan on how long the LTS is supported? No, because it's not fully clear how long Weezy will be supported, because that is dependent on the Jesse release date. But maybe something vague, like, so once it comes out, then five years, or something like that? That's the plan, roughly. And it's quite clear when Jesse will be released, more or less, hopefully. It's very precise. Yeah. So, say 2021, no, not 21. That's just how long Jesse will be supported then. But 2018, if there are no more questions, we can finish this.