[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Summary of the LTS BoF held during DebConf


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
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:
And he suggested that we should probably exclude Openstack from the
set of supported packages:

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: