Summary of the LTS BoF held during DebConf
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 team@security.debian.org
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/20150819110259.GA8358@pisco.westfalen.local
And he suggested that we should probably exclude Openstack from the
set of supported packages:
http://lists.debian.org/20150820090919.GA5373@pisco.westfalen.local
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 lts-security@debian.org 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/
Reply to: