The_Debian_Long_Term_Support_Team_Past_Present_and_Future.webm

[announcer] Welcome, our next talk will
be about the Debian Long Term support

team and the speaker is
Raphaël Hertzog.

[Raphaël Hertzog] Hello.

Today I will speak a bit about Debian
long term support.

I guess most of you already know about
it.

Are there some people who have no
idea what this is about?

No, good.

I will make my talk in 3 parts.

First I will present the team, how it
works

I will give some facts about how it
evolved over the first years.

I took some time to collect statistics
and believe they are rather interesting

I will also speak about the future

but there will be a separate discussion
about this in a BoF later this week.

I will show you how to help because, like
any other team in Debian it is open

to anyone. We welcome help.

At the end I will answer your questions.

What is LTS about?

The idea is really simple.

We wanted to extend the support period
of all Debian releases.

Currently it is basically for 1 year after
the next stable release comes out.

We wanted to extend this to 5 years to
match, at least, Ubuntu's offering.

which is not our competitor, but for the
companies that are making choices

it is one of the important criteria.
So we wanted to do as well.

Since we publish new stable releases
every 2 years it is roughly 3 years.

A nice side benefit is that the user can
skip a full release.

We don't officially support dist-upgrade
over going from Debian 6 to 8

but you can do 2 dist-upgrades at
the same time, limiting the downtime

to once every 5 years.

By the way, in practice, in simple server
configurations, dist-upgrades tend to

work rather well even across 2 releases.

Keeping a distribution secure for 5 years
is a real challenge.

It is hard work that not everybody is
willing to do.

In Debian all the work is done by
volunteers who do the work they enjoy.

Generally we enjoy working on new
features on top of latest releases

and not really on backporting patches to
crud that was written 5 years ago.

The security team has limited resources
so we could not just ask the security

team to now do twice the work.

But they were still really interested in
the project and wanted to support the idea

and really helped to get it bootstrapped.

The security team has a slightly larger
scope.

They support all architectures, which
means you have lots of problems of

coordination when security updates do
not compile and stuff like that.

What did we do?

We restricted the scope by picking
the 2 most popular architectures

that most users care about.

We have had some demand for ARM
architectures but up to now we only

support amd64 and i386.

We also excluded some packages from
security support.

Either because they are taking too much
time, like a security issue every 2 weeks

or that upstream is not cooperative
enough to be able to support it.

This list was basically made by the
current security team based on their

experience of doing security support.

If you look at the list there are some
important restrictions.

There's no xen, no kvm, no rails,
no browser. It sucks a bit.

But it's a way to get it started.

I think we can do better for wheezy.

Basically there is no virtualization
support on the host, only on the guest.

The security team helped to bootstrap
the LTS team but it is not the same team.

Obviously there are members of the
security team who also work on the LTS

team. They work in close collaboration.

We have regular contact and they watch our
mailing lists etc.

But the policies are different and the
infrastructure is separate,

which is a problem but I will talk about
that later.

We have a dedicated mailing list

and a dedicated IRC channel as well.

You are welcome to subscribe and to
join.

It's a new team which means new people
and new members.

Where do they come from?

The first idea was to get help from
people in various companies

who are already doing such in-house
support.

We had contact with EDF, and still have,
but they were one of the first

companies who were pushing for this
because they basically said

we are doing this already and we can
share with other companies.

The idea was to pool security support of
multiple companies.

We sent a press release asking
companies to join.

We had a few responses.

But I'll come back later to how it evolved
It's not really satisfying.

The other thing that we did is that we
offered companies the option to

fund the project to bring money and use
this to pay the work of

actual Debian contributors to do the
security updates that we need.

We have wiki pages listing all the ways
that companies can help with money.

In practice, most of the (wanting to be)
paid contributors joined together

under a single offer managed by
Freexian SARL which is my own company.

I'll quickly explain how this works.

Most companies don't want to bother
bringing human resources ??? (08:25)