Hello, here's a small summary of what has been discussed during the LTS BoF at DebConf 15 in Heidelberg.
Usage of security.debian.org for Wheezy's lts period ---------------------------------------------------- We want to the usual security repository on security.debian.org for Wheezy LTS: - users don't have to change anything in their sources.list - there is no delay for mirroring after an update has been pushed The main possible problems that this poses have been identified: 1/ if LTS team members have shell access to the host, they could see embargoed issues that they should not have access to 2/ also related to handling of embargoed updates, all the ACCEPTED mails are currently redirected to [email protected] and as such the uploader is not aware when its upload has been accepted 3/ there's a risk that non-LTS architectures get out of sync 4/ if the suites are kept in the same configuration, someones needs to approve the upload that end up in the "policy queue" Given all this, we decided that: 1/ the ftpmasters would reconfigure the suite to drop the "policy queue" in front of the repositories so that uploads are immediately accepted exactly like the current squeeze-lts repository (Ansgar told us this was easy to do) This solves problems 4 and 1 because LTS members no longer need shell access if there is "approval" step in the workflow. 2/ the non-LTS architectures would be dropped from security.debian.org when the normal support period ends (solving problem 3) (Ftpmasters might want to do this for the normal wheezy repository too since they had to do it for squeeze recently as well to reclaim some disk space) 3/ the ftpmasters will fix dak to also send the ACCEPTED mails to the person who signed the upload (this was already part of their plans even before this discussion, this now gives them one reason more to actually do it before the Wheezy LTS period start, aka in February 2016) 4/ We assume that we would not use EMBARGOED queues and just upload at the right time. Downside: some builds will come a bit later. Packages / architectures supported for wheezy LTS ------------------------------------------------- We discussed first whether we want to support more architectures. I mentioned that some people asked about getting support for "armhf" and someone else asked why we don't support all architectures. The decision to only support a subset of architectures is maintained. Supporting the full set of architectures would mean spending much more time on ensuring that the updated packages are built everywhere and given the limited resources of the LTS team, our time is better spent on other kind of activities. For the specific case of "armhf", the discussion concluded that armhf support in wheezy was not so good and that the kind of users that are interested by LTS on armhf would likely be using a Jessie base. Thus the plan is to reconsider the question in the future and possibly start supporting that architecture (and arm64?) for Jessie LTS. Then we discussed the set of packages that we would like to support during Wheezy LTS. I provided a list of unsupported package in Squeeze for review but that was not very helpful. Instead we should start again from the current wheezy support list[1] and work it out from there on a case by case basis. We agreed that we should aim to not exclude virtualization related packages from support, even if at the cost of upgrading to a newer upstream version. [1] http://anonscm.debian.org/cgit/collab-maint/debian-security-support.git/plain/security-support-ended.deb7 The case-by-case analysis still needs to happen but as starting point we should consider the list of packages unsupported in squeeze after having dropped the packages which are no longer in Wheezy. Moritz did some triage/analysis already: http://lists.debian.org/[email protected] And he suggested that we should probably exclude Openstack from the set of supported packages: http://lists.debian.org/[email protected] But we should cross-check that with the list of packages that sponsors are actually using and with the support level we have within Debian (it's easier to support package with active package maintainers which are interested in LTS support too). How to handle embargoed issues? ------------------------------- This was the continuation of a discussion that actually started on the list a few months before. Moritz explained that we have many Debian persons on the closed "linux-distros" mailing list already and that we might be able to add one more for LTS support. In any case, it's not possible to subscribe an alias to this list. We decided that we would create an alias on the Debian side (which ended up as [email protected] even though that was not the name suggested at that time) so that we can have multiple members of the LTS team behind this alias to handle any private discussion related to handling of embargoed security updates. The security team (or a designated member of the LTS team that would get subscribed to the closed linux-distros list) would then forward the information required so that the volunteers behind the alias can prepare the updates and release them together with all other vendors. For now, the security team will stay our gateway to linux-distros but if we want we could designate someone to be our representant on the linux-distros mailing list. Misc questions -------------- We had no time left to handle those questions: - What to do when issue is not fixed in unstable? - What to do when issue is not fixed in stable? -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
