The_Debian_Long_Term_Support_Team_Past_Present_and_Future.webm

[Talkmeister]: 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)

They buy long term support contracts
from Freexian.

We have a rate. When you give €85 you
fund 1 hour of LTS work.

This is the current list of sponsors.

Top level gold sponsors sponsoring
more than 1 day of work per month.

On the other side we have Debian
contributors that are doing the work

and Freexian is paying them. There is a
small difference between the rate

to cover administration costs because I
have to handle the invoices

and some customers are using Paypal
which is taking a cut.

We ask contributors to follow some rules.

There is a requirement to publish a
monthly report on work done

on paid time. So they won't get paid until
they have published a report.

So everybody can know how the money
has been spent.

Currently we have 7 Debian contributors
and about 30 sponsors.

Some figures.

Who uploaded packages?
How has it evolved since June last year?

How is the funding evolving?

I just updated those figures a few
days ago.

I used this talk before at the mini
DebConf in Lyon in March,

but I updated it again.

The number of uploads is roughly over
one year since we started last year.

Over 300 uploads so it is not so much
but it is almost 1 per day.

So it is significant work.

I have given a state here of who paid
for the work and who did it on the left

The sponsors of Freexian are paying for
most of the uploads. ???

None is a separate category grouping all
Debian maintainers.

There are maintainers who are taking
care of their own packages in LTS.

Security team is members of the security
team who also work within the LTS team.

EDF is Électricité de France

Individuals are Debian developers that
have listed themselves as members of

the LTS team and did uploads for packages
of other maintainers not their own.

Credativ is a German company that you
probably know.

They have a booth here if you want a
job.

Toshiba, Univention, Catalyst etc
are other lower ???

On the right are people. The top 5 people
are paid by Freexian.

Raphaël Geissert is working for EDF.

Thijs is a member of the security team.

Kurt is openssl maintainer ???

Mike Gabriel is also paid by Freexian.

Christoph Bieldl is mainly maintaining
the debian-security-support in Squeeze LTS

Nguyen Cong is employed by Toshiba.

Christoph Berg is employed by creditv
doing postgresql maintainence.

How did it evolve over the year?

Again it is by affiliation.

The big blue part is paid contributors

You don't see it very well but the part
about maintainers is this one [points]

It tends to do better over the months
because here we started to

contact maintainers every time that we
have a new upload coming up

and ask them first 'do you want to handle
it yourself' so it slightly increased.

but the contribution of other companies
has not really increased over time.

Rather it has disappeared. It is
unfortunate but it looks like paid

contributors are more productive than
others.

In particular with EDF, they do the work,
but with some lag and we are faster

so they just reuse what we have done. I
want to talk to Raphaël to see

how we can do better towards this.

How did the sponsorship level evolve?

We have a steady increase, which is
rather nice. It is not a huge amount but

it is significant because we fund almost
80 hours per month.

It is close to our first goal. We wanted
that amount to be able to sustain

ourselves.

If you look at the sponsors, we have a
few big ones, possibly one very big

We can't give the name officially yet so
I won't.It will be a big jump in the graph

A few gold and many small sponsors.

I don't want to be dependent too much on
one big sponsor. I really prefer many

sponsors who are doing small donations
but donations which are sustainable

year after year because we are not here
for 1 year or 2.

We want to do it over the long term.

We have some figures about how many
hours have been funded since the start

Feel free to interrupt me if you have any
questions. I can take them at any time

That's it for evolution. Now, the future.

What do we expect for the future?

First keep doing what we have been up
to

Keep supporting the current set of packages.

But for wheezy long term support we
would really like to have more

supported packages. A browser would
be nice for desktop deployment.

Virtualization support is also important
for many companies so we should be

able to support something here.

Also we want to avoid some pitfalls that
we had with squeeze LTS.

As you know LTS users are currently
required to add a separate source

list entry with squeeze-lts repository. The
security.debian.org squeeze

repository is unused. It should be
possible for the LTS team to

continue using the same repository as
the security team once it no longer

use it. This will be the topic of a BoF
next week on Tue at 1800.

What's the problem with supporting the
current set of packages?

For example, we have MySQL right now in
Squeeze LTS in version 5.1

which is no longer supported by Oracle.

We don't even know if it's affected by
security issues because

Oracle doesn't give info on
??? release.

This is a problem, we should consider
switching to a newer version,

but newer versions involve library
transition, which is not really nice

in Long Term Support releases.

There is some work to do here if we want
to do something serious.

And we have other problems, other
packages which are similar.

From time to time, we backport, we take
newer upstream versions.

We did that for wireshark for example.

This is what I said before, the limited
scope sucks, we want to be able to

support more packages and we need more
support for this.

[Q] Speaking of wireshark, we switched to
Wheezy's version, so it's solved.

[Raphael] Yes, exactly, that's what I just
said.

It used to be a problem.

That's a part I did no update since March.

Additionally, the problem with a separate
repository is that

there is a propagation delay to the
mirrors

that we don't have with
security.debian.org.

I will speak a bit of how the team works.

Basically, the first step is triaging new
security issues.

We have a list of CVEs that comes in and
there are added to a text file

data/CVE/list.

Some dispatches those on source packages
and then someone else reviews

status in each release.

Then the LTS team reviews the status in
Squeeze and members of security team

review status in Wheezy and Jessie.

And then, we decide what we must do with
the package.

Depending on the analysis, either we say

"We need to prepare an update", so we add
it to data/dla-needed.txt

and someone will have to take care of
preparing the update.

Or we say "The issue does not apply, does
not affect the current version"

or we ignore it because the package is
unsupported or because

the issue is really minor, not severe
enough.

Sometimes, it can be that the issue is
already fixed in Debian

due to some maintainer choices.

When we do this classification, we contact
the maintainer to keep him in the loop

and offer him the possibility to help us.

Here's what such a text file looks like.

The bold line is the line that we are
adding when we have decided

what we're doing with the packages.

This is all in the Subversion repository
on Alioth.

Then, someone has to prepare the security
update.

Basically, looking for a patch, it's often
useful to be able to look up at

RedHat or Ubuntu or upstream.

Best case is upstream because there are
nice upstream who are providing

patches also for older versions.

Usually there are already patches
available,

not always for the good version.

Sometimes we have to backport it.

Then we prepare an upload with this
+deb6uX suffix that we're using now

for security updates, stable updates.

This is a rather known territory for
package maintainers.

This is the hardest part sometimes,

testing the update, making sure the issue
is fixed.

When tools have test suites, it's nice,

but sometimes we have to set it up
ourselves.

Sometimes it is too hard, so we tend to,
out of safety measure,

to mail the mailing list and say

"Ok, I've done my best, but please double
check"

It doesn't happen often that we have
testers

but some lts users are willing to test it
before ???

It would be really nice if we had
more of those.

And if we don't get any negative feedback,

then we upload.

Then, you have to send
an announce.

We call that DLA for Debian LTS
Advisory.

We have a python script
./bin/gen-DLA

that generates the template mail
and you have to add

a little bit of description

and basically send it to
debian-lts-announce

with a GPG signature of someone in the
DD or DM keyring.

The process is rather open to
all maintainers

even the write rights to the secure
testing repository

where we hate this data/DLA/list file

is writable by all Debian Developpers on
Alioth

so, really, the entrance barrier is
rather low for Debian Maintainers

and Debian Developpers.

There's a file which is automatically
updated when you generate this template

and which will update the tracker on the
web pages

because all this data is nicely browsable
on security-tracker.debian.org.

And it's all linked from the package
tracker.

That's it. If you have a few questions,
I'm here to answer you.

[inaudible question]

… library and operating server,

so that you have same API for clients,
or same ABI for clients and

a newer server that actually gets
security patches.

[RH] In my head, yes, but we did not look
further yet.

I really want to use the BOF that is
upcoming to discuss it

As I said, the amount of funding we have
allows us right now

to keep up with security update we do not
have many spare cycles

for dealing with such things.

But it's slowly coming up,

as I said there's potentially a new
platinum sponsor.

We will have a few hours free to look
into this and I think

it's probably the best solution

but I don't know if it works in practice,
I have not tried it.

And since LTS, the end of life of Squeeze
happens in February,

it's not too far away so it's possibly
a nice solution

because upgrading to a newer upstream
version is harder.

[Q] I've heard ???
Freexian ???

you have enough contributors
but you could do more work

but you don't have the funding or
is it, like, you also need

more developpers?

[RH] A bit of both, actually,

the web page has always been very clear
on the rules

That means any Debian Developper who has
made uploads on its own already

can apply and join the program and
be funded.

Fortunately, I did not have too many

because it would have been hard,

but it has been steadily growing over
the months.

Last year, there was only Thorsten,
Holger and me,

but in the meantime we got Ben Hutchings
who is helping us on the kernel

and a few more.

I'm always looking, trying to make sure
that we don't give too much money

to a single person

because it's Debian, there has been
??? in the past.

I've been involved, I know it.

I don't want anyone to have their life
depend on LTS work, really.

And I don't want the opposite way also,
LTS to depend on a single person

that can go away.

I try to limit it to maximum 20 ???
per month for each person

and right now, we're well below that
so it's good.

By the way, most Debian Developpers are
currently european,

the fact that everything is euro-based
is fine

but one developer is american and it's
no problem to pay in dollars

So the amount will vary with the rates
but it's not a problem.

And even more, I'm surprised to have no
contributors

in the countries where the rate of labor
is well bellow.

I mean, if we have south american
contributors,

or african or I don't know, I don't want
to stigmatize anyone,

but if there are people who could live
for much more,

if they would be payed 10 hours and
have made their month,

they can still join, it's not a problem,

it's not a high rate because we want only
europeans,

it's because we want to allow everybody

and if they can be payed for 10 hours
by Freexian and then spend

the rest of the month doing free work
on Debian, the better.

If you want to join the program,
get in touch,

there are details on the webpages

and the more people ???
the better.

[Q] How do you or other developers
motivate yourself

to do this kind of LTS work,

because obviously it's important
for companies to have

stable releases,

but it also, to me at least, doesn't seem
very exciting from a technology standpoint

[RH] Do you think it's exciting or
not exciting?

I'm not sure I understood.

Not exciting, ok.

I agree, it's not exciting.

[laughter]

[inaudible question]

[RH] A bit of both.

I want Debian to succeed and I know that

LTS support is important for Debian
to succeed

so I want to make sure the project is
working well and alive

but clearly, I'm doing it because…

Let's say, the security support work,
providing security update,

backporting code, it's for money and
because I need to live.

But organizing the LTS project is
something I do for free

because I want it for Debian

because Debian needs it.

[Q] I have a question.

Who announces the public relation,
the marketing stuff of

the Debian Long Term Support?

Do you do it yourself or do you have some
professional help?

[RH] I do not have any professional help.

Basically, the way we…

Well, we could do much better, I mean,
in number of sponsors.

There are almost no US-based sponsors,

there are lots of US companies
that could help.

It's true, I'm fighting between my time

spending free time on Debian,
doing LTS Debian.

I contact a few companies that people
suggest me to contact,

but I'm not doing much things
by myself.

[Q] So, you would benefit a lot from
some professional help

in the marketing department or

[RH] Yes

[Q] public relation

[RH] Yes, but I don't have money
to fund this or not much.

The 10€ difference is for
administrative cost.

Maybe a bit for this kind of stuff but
it doesn't look like a lot for this.

[Q] I just wanted to ask to the previous
questioner about

finding motivation for providing patches
for LTS packages and in my view

it's not very different from providing
security patches for stable.

Sometimes it's a bit harder because the
software is a bit older

but we overcame this situation
for wireshark for example

by updating wireshark because it was
quite impossible to backport older

security fixes.

I think it's part of the maintainers.

If you maintain a project, you should
maintain the security issues in stable

and if you care a bit more and if you have
a little more time,

you can care about the package in LTS
as well.

I did it for wireshark for free, because
it's easy for me.

[RH] I'm grateful, thank you.

I want to point out that it's a good
thing that

LTS and security are different,

because we have different policies like
we said,

importing a new upstream version is
something we can do

when it doesn't break too much.

The command line interface had not changed
so badly between both versions

so it was possible.

It's not possible for all projects, but we
are not so strict on new upstream versions

And if you look at what others have been
doing, RedHat,

they too import new upstream version
quite often, in fact,

even on libraries like dnss.

[Q] Due to lack of browsers in LTS support
and Xen support

was it an issue with companies you are
working on, who are sponsoring Freexian?

[RH] I'm not sure I understood.

[Q] The lack of browsers support and
Xen support in the LTS version,

was that an issue with the companies
who you work with,

who are sponsoring your work?

[RH] Browsers, not so much.

Most sponsors are hosters and
stuff like that

but they were annoyed by the lack of
qemu or Xen support.

They did upgrade their host machines
but not their guest machines

for their customers.

Obviously, that would be
the first priority to fix.

Browser is nice, but it's also one of
those cases where we just need to

integrate newer upstream versions

??? doing it.

And I was hoping for Raphael Geissert
to do it because he does it for

Électricité de France.

I'll catch him.

Convince him.

I know him quite well, he's working in
Lyon near me, not far away.

[Q] Having sponsors for doing the LTS
work is a signal of

the need for LTS versions,

but do you have additional statistics on
the usage of LTS?

[RH] Not really.

Since LTS is not hosted in security
mirrors but on all mirrors,

we don't have access to all the
statistics.

But I know from mails, thank mails and
stuff like that

that it's really appreciated and used
quite a lot,

even from end users.

There are users who like the antiquated
GNOME stuff.

I'm fine with GNOME 3, by the way.

Yes, it's really widely used and widely
appreciated.

[Rhonda] Thanks for your attention.

[Applause]