0:00:00.260,0:00:06.321
[Talkmeister]: Welcome, our next talk will[br]be about the Debian Long Term support
0:00:06.321,0:00:09.981
team and the speaker is[br]Raphaël Hertzog.
0:00:11.340,0:00:12.481
[Raphaël Hertzog]: Hello.
0:00:13.701,0:00:16.741
Today I will speak a bit about Debian[br]long term support.
0:00:17.080,0:00:19.801
I guess most of you already know about[br]it.
0:00:20.241,0:00:23.962
Are there some people who have no[br]idea what this is about?
0:00:24.841,0:00:26.202
No, good.
0:00:30.901,0:00:34.461
I will make my talk in 3 parts.
0:00:35.060,0:00:38.221
First I will present the team, how it[br]works
0:00:38.221,0:00:45.861
I will give some facts about how it[br]evolved over the first years.
0:00:47.361,0:00:50.662
I took some time to collect statistics[br]and believe they are rather interesting
0:00:53.181,0:00:54.621
I will also speak about the future
0:00:55.121,0:00:59.902
but there will be a separate discussion[br]about this in a BoF later this week.
0:01:01.401,0:01:06.901
I will show you how to help because, like[br]any other team in Debian it is open
0:01:06.901,0:01:10.161
to anyone. We welcome help.
0:01:11.081,0:01:13.321
At the end I will answer your questions.
0:01:15.961,0:01:20.300
What is LTS about?
0:01:29.801,0:01:31.041
The idea is really simple.
0:01:31.842,0:01:37.461
We wanted to extend the support period[br]of all Debian releases.
0:01:39.020,0:01:43.801
Currently it is basically for 1 year after[br]the next stable release comes out.
0:01:44.381,0:01:50.501
We wanted to extend this to 5 years to[br]match, at least, Ubuntu's offering.
0:01:51.381,0:01:58.861
which is not our competitor, but for the[br]companies that are making choices
0:01:59.020,0:02:03.702
it is one of the important criteria.[br]So we wanted to do as well.
0:02:09.921,0:02:15.981
Since we publish new stable releases[br]every 2 years it is roughly 3 years.
0:02:19.320,0:02:23.941
A nice side benefit is that the user can[br]skip a full release.
0:02:26.041,0:02:32.260
We don't officially support dist-upgrade[br]over going from Debian 6 to 8
0:02:33.382,0:02:38.221
but you can do 2 dist-upgrades at[br]the same time, limiting the downtime
0:02:38.221,0:02:40.541
to once every 5 years.
0:02:42.921,0:02:49.142
By the way, in practice, in simple server[br]configurations, dist-upgrades tend to
0:02:49.280,0:02:54.081
work rather well even across 2 releases.
0:03:00.081,0:03:04.361
Keeping a distribution secure for 5 years[br]is a real challenge.
0:03:05.601,0:03:09.121
It is hard work that not everybody is[br]willing to do.
0:03:10.821,0:03:17.001
In Debian all the work is done by[br]volunteers who do the work they enjoy.
0:03:17.361,0:03:22.901
Generally we enjoy working on new[br]features on top of latest releases
0:03:22.901,0:03:28.761
and not really on backporting patches to[br]crud that was written 5 years ago.
0:03:31.780,0:03:38.022
The security team has limited resources[br]so we could not just ask the security
0:03:38.022,0:03:41.061
team to now do twice the work.
0:03:42.161,0:03:49.122
But they were still really interested in[br]the project and wanted to support the idea
0:03:49.441,0:03:52.361
and really helped to get it bootstrapped.
0:03:54.901,0:03:58.781
The security team has a slightly larger[br]scope.
0:03:59.560,0:04:06.361
They support all architectures, which[br]means you have lots of problems of
0:04:06.361,0:04:11.261
coordination when security updates do[br]not compile and stuff like that.
0:04:12.820,0:04:14.102
What did we do?
0:04:14.901,0:04:22.062
We restricted the scope by picking[br]the 2 most popular architectures
0:04:22.062,0:04:24.821
that most users care about.[br]
0:04:26.601,0:04:31.800
We have had some demand for ARM[br]architectures but up to now we only
0:04:31.800,0:04:35.621
support amd64 and i386.
0:04:37.020,0:04:40.942
We also excluded some packages from[br]security support.
0:04:41.400,0:04:50.241
Either because they are taking too much[br]time, like a security issue every 2 weeks
0:04:54.811,0:05:02.581
or that upstream is not cooperative[br]enough to be able to support it.
0:05:04.380,0:05:08.581
This list was basically made by the[br]current security team based on their
0:05:08.581,0:05:12.721
experience of doing security support.
0:05:17.021,0:05:20.240
If you look at the list there are some[br]important restrictions.
0:05:20.961,0:05:33.321
There's no xen, no kvm, no rails,[br]no browser. It sucks a bit.
0:05:33.681,0:05:35.941
But it's a way to get it started.
0:05:37.181,0:05:39.900
I think we can do better for wheezy.
0:05:41.700,0:05:48.501
Basically there is no virtualization[br]support on the host, only on the guest.
0:05:54.201,0:05:58.861
The security team helped to bootstrap[br]the LTS team but it is not the same team.
0:05:59.880,0:06:03.881
Obviously there are members of the[br]security team who also work on the LTS
0:06:03.881,0:06:09.080
team. They work in close collaboration.
0:06:09.982,0:06:14.241
We have regular contact and they watch our[br]mailing lists etc.
0:06:14.862,0:06:18.221
But the policies are different and the[br]infrastructure is separate,
0:06:19.681,0:06:23.301
which is a problem but I will talk about[br]that later.
0:06:23.701,0:06:27.481
We have a dedicated mailing list[br]debian-lts@lists.debian.org
0:06:28.673,0:06:31.142
and a dedicated IRC channel as well.
0:06:31.441,0:06:33.541
You are welcome to subscribe and to[br]join.
0:06:39.702,0:06:42.480
It's a new team which means new people[br]and new members.
0:06:42.800,0:06:44.221
Where do they come from?
0:06:46.681,0:06:52.081
The first idea was to get help from[br]people in various companies
0:06:52.281,0:06:55.281
who are already doing such in-house[br]support.
0:06:55.822,0:07:04.601
We had contact with EDF, and still have,[br]but they were one of the first
0:07:04.601,0:07:07.421
companies who were pushing for this[br]because they basically said
0:07:07.421,0:07:11.141
we are doing this already and we can[br]share with other companies.
0:07:11.701,0:07:15.761
The idea was to pool security support of[br]multiple companies.
0:07:16.722,0:07:19.701
We sent a press release asking[br]companies to join.
0:07:19.961,0:07:22.041
We had a few responses.
0:07:23.761,0:07:28.522
But I'll come back later to how it evolved[br]It's not really satisfying.
0:07:29.021,0:07:34.081
The other thing that we did is that we[br]offered companies the option to
0:07:34.261,0:07:41.321
fund the project to bring money and use[br]this to pay the work of
0:07:41.321,0:07:47.661
actual Debian contributors to do the[br]security updates that we need.
0:07:49.441,0:07:56.261
We have wiki pages listing all the ways[br]that companies can help with money.
0:08:00.751,0:08:06.741
In practice, most of the (wanting to be)[br]paid contributors joined together
0:08:07.400,0:08:12.841
under a single offer managed by[br]Freexian SARL which is my own company.
0:08:15.861,0:08:19.301
I'll quickly explain how this works.
0:08:22.882,0:08:31.401
Most companies don't want to bother[br]bringing human resources
0:08:34.130,0:08:38.560
They buy long term support contracts[br]from Freexian.
0:08:40.421,0:08:49.261
We have a rate. When you give €85 you[br]fund 1 hour of LTS work.
0:08:51.601,0:08:53.340
This is the current list of sponsors.
0:08:55.001,0:09:01.382
Top level gold sponsors sponsoring[br]more than 1 day of work per month.
0:09:09.162,0:09:13.541
On the other side we have Debian [br]contributors that are doing the work
0:09:13.541,0:09:16.761
and Freexian is paying them. There is a[br]small difference between the rate
0:09:16.761,0:09:22.520
to cover administration costs because I[br]have to handle the invoices
0:09:22.520,0:09:25.501
and some customers are using Paypal[br]which is taking a cut.
0:09:33.761,0:09:37.901
We ask contributors to follow some rules.
0:09:38.902,0:09:43.180
There is a requirement to publish a[br]monthly report on work done
0:09:43.180,0:09:47.601
on paid time. So they won't get paid until[br]they have published a report.
0:09:48.721,0:09:53.041
So everybody can know how the money[br]has been spent.
0:10:01.081,0:10:05.441
Currently we have 7 Debian contributors[br]and about 30 sponsors.
0:10:08.921,0:10:10.201
Some figures.
0:10:11.321,0:10:17.861
Who uploaded packages?[br]How has it evolved since June last year?
0:10:18.282,0:10:20.401
How is the funding evolving?
0:10:20.721,0:10:23.561
I just updated those figures a few[br]days ago.
0:10:24.840,0:10:28.360
I used this talk before at the mini[br]DebConf in Lyon in March,
0:10:28.700,0:10:30.881
but I updated it again.
0:10:34.581,0:10:42.781
The number of uploads is roughly over[br]one year since we started last year.
0:10:46.521,0:10:53.061
Over 300 uploads so it is not so much[br]but it is almost 1 per day.
0:10:54.221,0:10:55.960
So it is significant work.
0:10:57.602,0:11:07.221
I have given a state here of who paid[br]for the work and who did it on the left
0:11:09.260,0:11:21.761
The sponsors of Freexian are paying for[br]most of the uploads.
0:11:21.922,0:11:25.601
None is a separate category grouping all[br]Debian maintainers.
0:11:25.900,0:11:31.761
There are maintainers who are taking[br]care of their own packages in LTS.
0:11:33.521,0:11:39.301
Security team is members of the security[br]team who also work within the LTS team.
0:11:40.240,0:11:42.261
EDF is Électricité de France
0:11:42.541,0:11:48.561
Individuals are Debian developers that[br]have listed themselves as members of
0:11:48.561,0:11:55.141
the LTS team and did uploads for packages[br]of other maintainers not their own.
0:11:56.101,0:11:59.180
Credativ is a German company that you[br]probably know.
0:12:01.020,0:12:03.860
They have a booth here if you want a[br]job.
0:12:05.801,0:12:11.001
Toshiba, Univention, Catalyst etc[br]are other lower figures.
0:12:13.281,0:12:21.301
On the right are people. The top 5 people[br]are paid by Freexian.
0:12:21.541,0:12:24.521
Raphaël Geissert is working for EDF.
0:12:27.041,0:12:30.321
Thijs is a member of the security team.
0:12:31.561,0:12:37.700
Kurt is openssl maintainer so he maintains[br]his own packages.
0:12:38.021,0:12:38.721
He has a lot of work.
0:12:39.821,0:12:41.661
Mike Gabriel is also paid by Freexian.
0:12:42.161,0:12:47.861
Christoph Bieldl is mainly maintaining[br]the debian-security-support in Squeeze LTS
0:12:48.641,0:12:51.280
Nguyen Cong is employed by Toshiba.
0:12:53.461,0:12:59.760
Christoph Berg is employed by credativ[br]doing PostGreSQL maintainance.
0:13:03.021,0:13:05.122
How did it evolve over the year?
0:13:06.741,0:13:08.381
Again it is by affiliation.
0:13:08.721,0:13:12.321
The big blue part is paid contributors
0:13:14.900,0:13:22.861
You don't see it very well but the part[br]about maintainers is this one [points]
0:13:23.061,0:13:28.141
It tends to do better over the months[br]because here we started to
0:13:28.141,0:13:33.681
contact maintainers every time that we[br]have a new upload coming up
0:13:33.681,0:13:41.121
and ask them first 'do you want to handle[br]it yourself' so it slightly increased.
0:13:43.441,0:13:50.120
but the contribution of other companies[br]has not really increased over time.
0:13:50.581,0:13:57.361
Rather it has disappeared. It is[br]unfortunate but it looks like paid
0:13:57.361,0:14:01.461
contributors are more productive than[br]others.
0:14:05.081,0:14:12.741
In particular with EDF, they do the work,[br]but with some lag and we are faster
0:14:12.741,0:14:21.321
so they just reuse what we have done. I[br]want to talk to Raphaël to see
0:14:21.321,0:14:23.441
how we can do better towards this.
0:14:26.221,0:14:29.821
How did the sponsorship level evolve?
0:14:30.361,0:14:35.120
We have a steady increase, which is[br]rather nice. It is not a huge amount but
0:14:35.120,0:14:41.241
it is significant because we fund almost[br]80 hours per month.
0:14:43.481,0:14:50.560
It is close to our first goal. We wanted[br]that amount to be able to sustain
0:14:50.560,0:14:51.621
ourselves.
0:14:54.081,0:15:03.461
If you look at the sponsors, we have a[br]few big ones, possibly one very big
0:15:03.940,0:15:10.501
We can't give the name officially yet so[br]I won't.It will be a big jump in the graph
0:15:11.141,0:15:15.561
A few gold and many small sponsors.
0:15:15.880,0:15:23.060
I don't want to be dependent too much on[br]one big sponsor. I really prefer many
0:15:23.060,0:15:28.461
sponsors who are doing small donations[br]but donations which are sustainable
0:15:28.461,0:15:32.420
year after year because we are not here[br]for 1 year or 2.
0:15:32.940,0:15:36.102
We want to do it over the long term.
0:15:40.301,0:15:45.121
We have some figures about how many[br]hours have been funded since the start
0:15:47.501,0:15:52.581
Feel free to interrupt me if you have any[br]questions. I can take them at any time
0:15:55.501,0:16:01.141
That's it for evolution. Now, the future.
0:16:01.741,0:16:04.221
What do we expect for the future?
0:16:04.721,0:16:07.560
First keep doing what we have been up[br]to[br]
0:16:07.721,0:16:09.780
Keep supporting the current set of packages.
0:16:10.421,0:16:13.761
But for wheezy long term support we[br]would really like to have more
0:16:13.961,0:16:18.660
supported packages. A browser would[br]be nice for desktop deployment.
0:16:22.161,0:16:29.921
Virtualization support is also important[br]for many companies so we should be
0:16:29.921,0:16:31.880
able to support something here.
0:16:32.981,0:16:39.662
Also we want to avoid some pitfalls that[br]we had with squeeze LTS.
0:16:40.241,0:16:45.821
As you know LTS users are currently[br]required to add a separate source
0:16:45.821,0:16:55.101
list entry with squeeze-lts repository. The[br]security.debian.org squeeze
0:16:55.101,0:17:01.641
repository is unused. It should be[br]possible for the LTS team to
0:17:01.641,0:17:06.521
continue using the same repository as[br]the security team once it no longer
0:17:06.521,0:17:18.401
use it. This will be the topic of a BoF[br]next week on Tue at 1800.
0:17:25.901,0:17:29.661
What's the problem with supporting the[br]current set of packages?
0:17:30.221,0:17:36.221
For example, we have MySQL right now in[br]Squeeze LTS in version 5.1
0:17:36.221,0:17:38.521
which is no longer supported by Oracle.
0:17:40.901,0:17:45.121
We don't even know if it's affected by[br]security issues because
0:17:45.121,0:17:48.660
Oracle doesn't give info on[br]non supported releases.
0:17:49.941,0:17:53.622
This is a problem, we should consider[br]switching to a newer version,
0:17:53.622,0:17:58.461
but newer versions involve library[br]transition, which is not really nice
0:17:58.461,0:18:00.201
in Long Term Support releases.
0:18:02.261,0:18:07.060
There is some work to do here if we want[br]to do something serious.
0:18:08.721,0:18:12.120
And we have other problems, other[br]packages which are similar.
0:18:15.121,0:18:18.741
From time to time, we backport, we take[br]newer upstream versions.
0:18:20.261,0:18:23.101
We did that for wireshark for example.
0:18:24.621,0:18:30.142
This is what I said before, the limited[br]scope sucks, we want to be able to
0:18:30.142,0:18:33.241
support more packages and we need more[br]support for this.
0:18:38.501,0:18:46.721
[Q] Speaking of wireshark, we switched to[br]Wheezy's version, so it's solved.
0:18:47.361,0:18:50.121
[Raphael] Yes, exactly, that's what I just[br]said.
0:18:51.502,0:18:53.001
It used to be a problem.
0:18:53.161,0:18:56.482
That's a part I did no update since March.
0:19:03.561,0:19:07.061
Additionally, the problem with a separate[br]repository is that
0:19:07.061,0:19:09.535
there is a propagation delay to the[br]mirrors
0:19:09.535,0:19:11.881
that we don't have with[br]security.debian.org.
0:19:15.541,0:19:18.840
I will speak a bit of how the team works.
0:19:20.781,0:19:24.061
Basically, the first step is triaging new[br]security issues.
0:19:24.061,0:19:29.541
We have a list of CVEs that comes in and[br]there are added to a text file
0:19:29.541,0:19:33.441
data/CVE/list.
0:19:34.600,0:19:41.241
Someone dispatches those on source[br]packages and then someone else reviews
0:19:41.241,0:19:45.761
status in each release.
0:19:46.421,0:19:50.780
Then the LTS team reviews the status in[br]Squeeze and members of security team
0:19:50.780,0:19:52.640
review status in Wheezy and Jessie.
0:19:53.781,0:19:56.701
And then, we decide what we must do with[br]the package.
0:19:57.961,0:20:01.302
Depending on the analysis, either we say
0:20:01.302,0:20:08.421
"We need to prepare an update", so we add[br]it to data/dla-needed.txt
0:20:08.981,0:20:12.281
and someone will have to take care of[br]preparing the update.
0:20:12.761,0:20:18.042
Or we say "The issue does not apply, does[br]not affect the current version"
0:20:18.361,0:20:23.762
or we ignore it because the package is[br]unsupported or because
0:20:23.762,0:20:27.801
the issue is really minor, not severe[br]enough.
0:20:29.321,0:20:33.861
Sometimes, it can be that the issue is[br]already fixed in Debian
0:20:33.861,0:20:36.101
due to some maintainer choices.
0:20:40.161,0:20:44.921
When we do this classification, we contact[br]the maintainer to keep him in the loop
0:20:44.921,0:20:48.081
and offer him the possibility to help us.
0:20:49.160,0:20:52.241
Here's what such a text file looks like.
0:20:54.441,0:20:58.621
The bold line is the line that we are[br]adding when we have decided
0:20:58.621,0:21:01.921
what we're doing with the packages.
0:21:03.281,0:21:06.781
This is all in the Subversion repository[br]on Alioth.
0:21:10.262,0:21:13.961
Then, someone has to prepare the security[br]update.
0:21:14.440,0:21:20.181
Basically, looking for a patch, it's often[br]useful to be able to look up at
0:21:20.181,0:21:23.501
RedHat or Ubuntu or upstream.
0:21:23.921,0:21:27.021
Best case is upstream because there are[br]nice upstream who are providing
0:21:27.021,0:21:28.902
patches also for older versions.
0:21:31.521,0:21:35.381
Usually there are already patches[br]available,
0:21:35.600,0:21:37.561
not always for the good version.
0:21:37.901,0:21:40.101
Sometimes we have to backport it.
0:21:41.041,0:21:47.521
Then we prepare an upload with this[br]+deb6uX suffix that we're using now
0:21:47.521,0:21:50.221
for security updates, stable updates.
0:21:52.360,0:21:56.441
This is a rather known territory for[br]package maintainers.
0:21:58.881,0:22:01.521
This is the hardest part sometimes,
0:22:01.521,0:22:05.241
testing the update, making sure the issue[br]is fixed.
0:22:08.461,0:22:11.861
When tools have test suites, it's nice,
0:22:11.861,0:22:14.381
but sometimes we have to set it up[br]ourselves.
0:22:16.900,0:22:20.501
Sometimes it is too hard, so we tend to,[br]out of safety measure,
0:22:20.501,0:22:22.962
to mail the mailing list and say
0:22:22.962,0:22:26.741
"Ok, I've done my best, but please double[br]check"
0:22:29.120,0:22:31.722
It doesn't happen often that we have[br]testers
0:22:31.722,0:22:36.180
but some lts users are willing to test it[br]before ???
0:22:37.061,0:22:39.101
It would be really nice if we had[br]more of those.
0:22:40.402,0:22:42.600
And if we don't get any negative feedback,
0:22:42.600,0:22:43.961
then we upload.
0:22:45.581,0:22:49.181
Then, you have to send[br]an announce.
0:22:49.901,0:22:53.002
We call that DLA for Debian LTS[br]Advisory.
0:22:53.861,0:22:57.961
We have a little script[br]./bin/gen-DLA
0:22:57.961,0:23:00.861
that generates the template mail[br]and you have to add
0:23:01.041,0:23:03.002
a little bit of description
0:23:03.280,0:23:06.001
and basically send it to[br]debian-lts-announce
0:23:06.222,0:23:13.140
with a GPG signature of someone in the[br]DD or DM keyring.
0:23:16.301,0:23:20.542
The process is rather open to[br]all maintainers
0:23:20.542,0:23:26.161
even the write rights to the secure[br]testing repository
0:23:26.161,0:23:28.861
where we have this data/DLA/list file
0:23:29.520,0:23:32.101
is writable by all Debian Developpers on[br]Alioth
0:23:32.682,0:23:39.241
so, really, the entrance barrier is[br]rather low for Debian Maintainers
0:23:40.001,0:23:41.221
and Debian Developpers.
0:23:45.700,0:23:49.760
There's a file which is automatically[br]updated when you generate this template
0:23:49.760,0:23:55.081
and which will update the tracker on the[br]web pages
0:23:55.081,0:24:01.741
because all this data is nicely browsable[br]on security-tracker.debian.org.
0:24:03.561,0:24:08.021
And it's all linked from the package[br]tracker.
0:24:11.382,0:24:15.860
That's it. If you have a few questions,[br]I'm here to answer you.
0:24:30.301,0:24:39.541
[inaudible question]
0:24:39.541,0:24:41.641
… library and operating server,
0:24:41.641,0:24:48.861
so that you have same API for clients,[br]or same ABI for clients and
0:24:48.861,0:24:51.541
a newer server that actually gets[br]security patches.
0:24:52.261,0:24:55.521
[RH] In my head, yes, but we did not look[br]further yet.
0:24:55.800,0:25:02.521
I really want to use the BOF that is[br]upcoming to discuss it
0:25:03.961,0:25:11.220
As I said, the amount of funding we have[br]allows us right now
0:25:11.220,0:25:15.621
to keep up with security update but[br]we do not have many spare cycles
0:25:16.041,0:25:19.481
for dealing with such things.
0:25:20.320,0:25:22.380
But it's slowly coming up,
0:25:22.380,0:25:25.861
as I said there's potentially a new[br]platinum sponsor.
0:25:27.061,0:25:32.221
We will have a few hours free to look[br]into this and I think
0:25:32.221,0:25:34.121
it's probably the best solution
0:25:34.481,0:25:37.481
but I don't know if it works in practice,[br]I have not tried it.
0:25:42.181,0:25:47.061
And since LTS, the end of life of Squeeze[br]happens in February,
0:25:47.061,0:25:51.682
it's not too far away so it's possibly[br]a nice solution
0:25:51.682,0:25:55.181
because upgrading to a newer upstream[br]version is harder.
0:25:56.821,0:26:00.122
[Q] I've heard ???[br]Freexian ???
0:26:00.122,0:26:04.161
you have enough contributors[br]but you could do more work
0:26:04.161,0:26:08.411
but you don't have the funding or[br]is it, like, you also need
0:26:08.411,0:26:10.381
more developpers?
0:26:10.680,0:26:12.701
[RH] A bit of both, actually,
0:26:18.581,0:26:21.661
the web page has always been very clear[br]on the rules
0:26:22.680,0:26:28.421
That means any Debian Developper who has[br]made security uploads on its own already
0:26:28.421,0:26:31.701
can apply and join the program and[br]be funded.
0:26:33.461,0:26:35.321
Fortunately, I did not have too many
0:26:35.321,0:26:36.821
because it would have been hard,
0:26:36.821,0:26:39.681
but it has been steadily growing over[br]the months.
0:26:41.080,0:26:44.661
Last year, there was only Thorsten,[br]Holger and me,
0:26:45.481,0:26:49.821
but in the meantime we got Ben Hutchings[br]who is helping us on the kernel
0:26:50.781,0:26:52.081
and a few more.
0:26:53.301,0:26:58.301
I'm always looking, trying to make sure[br]that we don't give too much money
0:26:58.301,0:26:59.841
to a single person
0:27:00.241,0:27:04.201
because it's Debian, there has been[br]??? in the past.
0:27:04.622,0:27:06.761
I've been involved, I know it.
0:27:07.981,0:27:14.221
I don't want anyone to have their life[br]depend on LTS work, really.
0:27:14.601,0:27:17.841
And I don't want the opposite way also,[br]LTS to depend on a single person
0:27:18.001,0:27:19.241
that can go away.
0:27:19.501,0:27:26.161
I try to limit it to maximum 20 ???[br]per month for each person
0:27:26.161,0:27:29.641
and right now, we're well below that[br]so it's good.
0:27:31.941,0:27:37.460
By the way, most Debian Developpers are[br]currently european,
0:27:37.460,0:27:39.761
the fact that everything is euro-based[br]is fine
0:27:40.561,0:27:46.162
but one developer is american and it's[br]no problem to pay in dollars
0:27:46.881,0:27:51.921
So the amount will vary with the rates[br]but it's not a problem.
0:27:52.561,0:27:56.120
And even more, I'm surprised to have no[br]contributors
0:27:56.120,0:28:02.181
in the countries where the rate of labor[br]is well bellow.
0:28:02.501,0:28:07.041
I mean, if we have south american[br]contributors,
0:28:07.041,0:28:10.421
or african or I don't know, I don't want[br]to stigmatize anyone,
0:28:10.421,0:28:15.641
but if there are people who could live[br]for much more,
0:28:19.041,0:28:22.180
if they would be payed 10 hours and[br]have made their month,
0:28:23.281,0:28:25.522
they can still join, it's not a problem,
0:28:25.522,0:28:30.061
it's not a high rate because we want only[br]europeans,
0:28:30.061,0:28:34.042
it's because we want to allow everybody
0:28:34.042,0:28:38.221
and if they can be payed for 10 hours[br]by Freexian and then spend
0:28:38.221,0:28:41.201
the rest of the month doing free work[br]on Debian, the better.
0:28:43.400,0:28:45.741
If you want to join the program,[br]get in touch,
0:28:46.362,0:28:48.940
there are details on the webpages
0:28:48.940,0:28:52.341
and the more people funded[br]the better.
0:28:58.181,0:29:01.621
[Q] How do you or other developers[br]motivate yourself
0:29:01.621,0:29:03.641
to do this kind of LTS work,
0:29:03.641,0:29:07.222
because obviously it's important[br]for companies to have
0:29:07.222,0:29:08.621
stable releases,
0:29:08.621,0:29:13.922
but it also, to me at least, doesn't seem[br]very exciting from a technology standpoint
0:29:17.101,0:29:20.321
[RH] Do you think it's exciting or[br]not exciting?
0:29:20.941,0:29:22.021
I'm not sure I understood.
0:29:22.181,0:29:23.220
Not exciting, ok.
0:29:23.361,0:29:24.760
I agree, it's not exciting.
0:29:25.281,0:29:27.281
[laughter]
0:29:28.141,0:29:30.781
[inaudible question]
0:29:31.061,0:29:32.460
[RH] A bit of both.
0:29:32.881,0:29:35.781
I want Debian to succeed and I know that
0:29:35.781,0:29:38.201
LTS support is important for Debian[br]to succeed
0:29:38.201,0:29:41.681
so I want to make sure the project is[br]working well and alive
0:29:41.681,0:29:45.401
but clearly, I'm doing it because…
0:29:46.761,0:29:51.581
Let's say, the security support work,[br]providing security update,
0:29:51.581,0:29:54.761
backporting code, it's for money and[br]because I need to live.
0:29:55.561,0:30:00.740
But organizing the LTS project is[br]something I do for free
0:30:00.740,0:30:03.200
because I want it for Debian
0:30:03.200,0:30:04.481
because Debian needs it.
0:30:06.381,0:30:07.981
[Q] I have a question.
0:30:08.222,0:30:12.101
Who announces the public relation,[br]the marketing stuff of
0:30:12.101,0:30:14.581
the Debian Long Term Support?
0:30:14.861,0:30:18.781
Do you do it yourself or do you have some[br]professional help?
0:30:19.880,0:30:21.741
[RH] I do not have any professional help.
0:30:22.461,0:30:24.061
Basically, the way we…
0:30:25.660,0:30:29.380
Well, we could do much better, I mean,[br]in number of sponsors.
0:30:29.920,0:30:32.861
There are almost no US-based sponsors,
0:30:32.861,0:30:35.361
there are lots of US companies[br]that could help.
0:30:38.202,0:30:43.761
It's true, I'm fighting between my time
0:30:43.761,0:30:46.641
spending free time on Debian,[br]doing LTS Debian.
0:30:49.121,0:30:51.940
I contact a few companies that people[br]suggest me to contact,
0:30:51.940,0:30:54.582
but I'm not doing much things[br]by myself.
0:30:56.041,0:30:58.701
[Q] So, you would benefit a lot from[br]some professional help
0:30:58.701,0:31:00.261
in the marketing department or
0:31:00.460,0:31:01.041
[RH] Yes
0:31:01.181,0:31:02.001
[Q] public relation
0:31:02.341,0:31:06.921
[RH] Yes, but I don't have money[br]to fund this or not much.
0:31:07.421,0:31:10.101
The 10€ difference is for[br]administrative cost.
0:31:10.882,0:31:17.642
Maybe a bit for this kind of stuff but[br]it doesn't look like a lot for this.
0:31:19.660,0:31:22.320
[Q] I just wanted to ask to the previous[br]questioner about
0:31:22.320,0:31:27.521
finding motivation for providing patches[br]for LTS packages and in my view
0:31:27.521,0:31:31.100
it's not very different from providing[br]security patches for stable.
0:31:32.400,0:31:36.662
Sometimes it's a bit harder because the[br]software is a bit older
0:31:36.662,0:31:41.041
but we overcame this situation[br]for wireshark for example
0:31:41.041,0:31:46.221
by updating wireshark because it was[br]quite impossible to backport older
0:31:46.221,0:31:47.801
security fixes.
0:31:50.261,0:31:52.300
I think it's part of the maintainance.
0:31:52.960,0:31:57.880
If you maintain a project, you should[br]maintain the security issues in stable
0:31:57.880,0:32:01.661
and if you care a bit more and if you have[br]a little more time,
0:32:01.661,0:32:05.221
you can care about the package in LTS[br]as well.
0:32:06.281,0:32:09.781
I did it for wireshark for free, because[br]it's easy for me.
0:32:11.321,0:32:12.761
[RH] I'm grateful, thank you.
0:32:16.561,0:32:19.502
I want to point out that it's a good[br]thing that
0:32:19.502,0:32:21.421
LTS and security are different,
0:32:21.421,0:32:24.502
because we have different policies like[br]we said,
0:32:24.502,0:32:27.521
importing a new upstream version is[br]something we can do
0:32:27.521,0:32:30.581
when it doesn't break too much.
0:32:31.381,0:32:35.581
The command line interface had not changed[br]so badly between both versions
0:32:35.581,0:32:37.001
so it was possible.
0:32:37.361,0:32:43.260
It's not possible for all projects, but we[br]are not so strict on new upstream versions
0:32:43.441,0:32:47.521
And if you look at what others have been[br]doing, RedHat,
0:32:47.521,0:32:52.681
they too import new upstream version[br]quite often, in fact,
0:32:52.681,0:32:55.401
even on libraries like nss.
0:33:02.781,0:33:06.801
[Q] Due to lack of browsers in LTS support[br]and Xen support
0:33:06.801,0:33:10.862
was it an issue with companies you are[br]working on, who are sponsoring Freexian?
0:33:12.521,0:33:14.101
[RH] I'm not sure I understood.
0:33:14.681,0:33:21.441
[Q] The lack of browsers support and[br]Xen support in the LTS version,
0:33:21.441,0:33:25.201
was that an issue with the companies[br]who you work with,
0:33:25.201,0:33:27.181
who are sponsoring your work?
0:33:29.581,0:33:31.181
[RH] Browsers, not so much.
0:33:31.561,0:33:35.921
Most sponsors are hosters and[br]stuff like that
0:33:35.921,0:33:40.401
but they were annoyed by the lack of[br]qemu or Xen support.
0:33:41.221,0:33:45.661
They did upgrade their host machines[br]but not their guest machines
0:33:45.661,0:33:47.882
for their customers.
0:33:48.741,0:33:51.821
Obviously, that would be[br]the first priority to fix.
0:33:52.001,0:33:57.901
Browser is nice, but it's also one of[br]those cases where we just need to
0:33:57.901,0:33:59.641
integrate newer upstream versions
0:34:01.261,0:34:03.381
??? doing it.
0:34:03.841,0:34:08.300
And I was hoping for Raphael Geissert[br]to do it because he does it for
0:34:08.300,0:34:09.860
Électricité de France.
0:34:11.781,0:34:13.381
I'll catch him.
0:34:16.501,0:34:17.561
Convince him.
0:34:18.981,0:34:24.540
I know him quite well, he's working in[br]Lyon near me, not far away.
0:34:32.641,0:34:38.321
[Q] Having sponsors for doing the LTS[br]work is a signal of
0:34:38.321,0:34:41.461
the need for LTS versions,
0:34:41.461,0:34:46.522
but do you have additional statistics on[br]the usage of LTS?
0:34:49.861,0:34:51.621
[RH] Not really.
0:34:52.081,0:34:56.201
Since LTS is not hosted in security[br]mirrors but on all mirrors,
0:34:56.201,0:34:58.161
we don't have access to all the[br]statistics.
0:34:59.562,0:35:05.401
But I know from mails, thank mails and[br]stuff like that
0:35:05.401,0:35:08.621
that it's really appreciated and used[br]quite a lot,
0:35:08.621,0:35:10.240
even from end users.
0:35:10.462,0:35:14.381
There are users who like the antiquated[br]GNOME stuff.
0:35:16.961,0:35:19.281
I'm fine with GNOME 3, by the way.
0:35:21.281,0:35:25.441
Yes, it's really widely used and widely[br]appreciated.
0:35:34.261,0:35:36.720
[Rhonda] Thanks for your attention.
0:35:44.401,0:35:49.362
[Applause]