English sous-titres

← The_Debian_Long_Term_Support_Team_Past_Present_and_Future.webm

Obtenir le code d’intégration
1 langue

Afficher la révision 17 créée 09/23/2015 par tvincent.

  1. [Talkmeister]: Welcome, our next talk will
    be about the Debian Long Term support
  2. team and the speaker is
    Raphaël Hertzog.
  3. [Raphaël Hertzog]: Hello.
  4. Today I will speak a bit about Debian
    long term support.
  5. I guess most of you already know about
  6. Are there some people who have no
    idea what this is about?
  7. No, good.
  8. I will make my talk in 3 parts.
  9. First I will present the team, how it
  10. I will give some facts about how it
    evolved over the first years.
  11. I took some time to collect statistics
    and believe they are rather interesting
  12. I will also speak about the future
  13. but there will be a separate discussion
    about this in a BoF later this week.
  14. I will show you how to help because, like
    any other team in Debian it is open
  15. to anyone. We welcome help.
  16. At the end I will answer your questions.
  17. What is LTS about?
  18. The idea is really simple.
  19. We wanted to extend the support period
    of all Debian releases.
  20. Currently it is basically for 1 year after
    the next stable release comes out.
  21. We wanted to extend this to 5 years to
    match, at least, Ubuntu's offering.
  22. which is not our competitor, but for the
    companies that are making choices
  23. it is one of the important criteria.
    So we wanted to do as well.
  24. Since we publish new stable releases
    every 2 years it is roughly 3 years.
  25. A nice side benefit is that the user can
    skip a full release.
  26. We don't officially support dist-upgrade
    over going from Debian 6 to 8
  27. but you can do 2 dist-upgrades at
    the same time, limiting the downtime
  28. to once every 5 years.
  29. By the way, in practice, in simple server
    configurations, dist-upgrades tend to
  30. work rather well even across 2 releases.
  31. Keeping a distribution secure for 5 years
    is a real challenge.
  32. It is hard work that not everybody is
    willing to do.
  33. In Debian all the work is done by
    volunteers who do the work they enjoy.
  34. Generally we enjoy working on new
    features on top of latest releases
  35. and not really on backporting patches to
    crud that was written 5 years ago.
  36. The security team has limited resources
    so we could not just ask the security
  37. team to now do twice the work.
  38. But they were still really interested in
    the project and wanted to support the idea
  39. and really helped to get it bootstrapped.
  40. The security team has a slightly larger
  41. They support all architectures, which
    means you have lots of problems of
  42. coordination when security updates do
    not compile and stuff like that.
  43. What did we do?
  44. We restricted the scope by picking
    the 2 most popular architectures
  45. that most users care about.
  46. We have had some demand for ARM
    architectures but up to now we only
  47. support amd64 and i386.
  48. We also excluded some packages from
    security support.
  49. Either because they are taking too much
    time, like a security issue every 2 weeks
  50. or that upstream is not cooperative
    enough to be able to support it.
  51. This list was basically made by the
    current security team based on their
  52. experience of doing security support.
  53. If you look at the list there are some
    important restrictions.
  54. There's no xen, no kvm, no rails,
    no browser. It sucks a bit.
  55. But it's a way to get it started.
  56. I think we can do better for wheezy.
  57. Basically there is no virtualization
    support on the host, only on the guest.
  58. The security team helped to bootstrap
    the LTS team but it is not the same team.
  59. Obviously there are members of the
    security team who also work on the LTS
  60. team. They work in close collaboration.
  61. We have regular contact and they watch our
    mailing lists etc.
  62. But the policies are different and the
    infrastructure is separate,
  63. which is a problem but I will talk about
    that later.
  64. We have a dedicated mailing list
  65. and a dedicated IRC channel as well.
  66. You are welcome to subscribe and to
  67. It's a new team which means new people
    and new members.
  68. Where do they come from?
  69. The first idea was to get help from
    people in various companies
  70. who are already doing such in-house
  71. We had contact with EDF, and still have,
    but they were one of the first
  72. companies who were pushing for this
    because they basically said
  73. we are doing this already and we can
    share with other companies.
  74. The idea was to pool security support of
    multiple companies.
  75. We sent a press release asking
    companies to join.
  76. We had a few responses.
  77. But I'll come back later to how it evolved
    It's not really satisfying.
  78. The other thing that we did is that we
    offered companies the option to
  79. fund the project to bring money and use
    this to pay the work of
  80. actual Debian contributors to do the
    security updates that we need.
  81. We have wiki pages listing all the ways
    that companies can help with money.
  82. In practice, most of the (wanting to be)
    paid contributors joined together
  83. under a single offer managed by
    Freexian SARL which is my own company.
  84. I'll quickly explain how this works.
  85. Most companies don't want to bother
    bringing human resources
  86. They buy long term support contracts
    from Freexian.
  87. We have a rate. When you give €85 you
    fund 1 hour of LTS work.
  88. This is the current list of sponsors.
  89. Top level gold sponsors sponsoring
    more than 1 day of work per month.
  90. On the other side we have Debian
    contributors that are doing the work
  91. and Freexian is paying them. There is a
    small difference between the rate
  92. to cover administration costs because I
    have to handle the invoices
  93. and some customers are using Paypal
    which is taking a cut.
  94. We ask contributors to follow some rules.
  95. There is a requirement to publish a
    monthly report on work done
  96. on paid time. So they won't get paid until
    they have published a report.
  97. So everybody can know how the money
    has been spent.
  98. Currently we have 7 Debian contributors
    and about 30 sponsors.
  99. Some figures.
  100. Who uploaded packages?
    How has it evolved since June last year?
  101. How is the funding evolving?
  102. I just updated those figures a few
    days ago.
  103. I used this talk before at the mini
    DebConf in Lyon in March,
  104. but I updated it again.
  105. The number of uploads is roughly over
    one year since we started last year.
  106. Over 300 uploads so it is not so much
    but it is almost 1 per day.
  107. So it is significant work.
  108. I have given a state here of who paid
    for the work and who did it on the left
  109. The sponsors of Freexian are paying for
    most of the uploads.
  110. None is a separate category grouping all
    Debian maintainers.
  111. There are maintainers who are taking
    care of their own packages in LTS.
  112. Security team is members of the security
    team who also work within the LTS team.
  113. EDF is Électricité de France
  114. Individuals are Debian developers that
    have listed themselves as members of
  115. the LTS team and did uploads for packages
    of other maintainers not their own.
  116. Credativ is a German company that you
    probably know.
  117. They have a booth here if you want a
  118. Toshiba, Univention, Catalyst etc
    are other lower figures.
  119. On the right are people. The top 5 people
    are paid by Freexian.
  120. Raphaël Geissert is working for EDF.
  121. Thijs is a member of the security team.
  122. Kurt is openssl maintainer so he maintains
    his own packages.
  123. He has a lot of work.
  124. Mike Gabriel is also paid by Freexian.
  125. Christoph Bieldl is mainly maintaining
    the debian-security-support in Squeeze LTS
  126. Nguyen Cong is employed by Toshiba.
  127. Christoph Berg is employed by credativ
    doing PostGreSQL maintainance.
  128. How did it evolve over the year?
  129. Again it is by affiliation.
  130. The big blue part is paid contributors
  131. You don't see it very well but the part
    about maintainers is this one [points]
  132. It tends to do better over the months
    because here we started to
  133. contact maintainers every time that we
    have a new upload coming up
  134. and ask them first 'do you want to handle
    it yourself' so it slightly increased.
  135. but the contribution of other companies
    has not really increased over time.
  136. Rather it has disappeared. It is
    unfortunate but it looks like paid
  137. contributors are more productive than
  138. In particular with EDF, they do the work,
    but with some lag and we are faster
  139. so they just reuse what we have done. I
    want to talk to Raphaël to see
  140. how we can do better towards this.
  141. How did the sponsorship level evolve?
  142. We have a steady increase, which is
    rather nice. It is not a huge amount but
  143. it is significant because we fund almost
    80 hours per month.
  144. It is close to our first goal. We wanted
    that amount to be able to sustain
  145. ourselves.
  146. If you look at the sponsors, we have a
    few big ones, possibly one very big
  147. We can't give the name officially yet so
    I won't.It will be a big jump in the graph
  148. A few gold and many small sponsors.
  149. I don't want to be dependent too much on
    one big sponsor. I really prefer many
  150. sponsors who are doing small donations
    but donations which are sustainable
  151. year after year because we are not here
    for 1 year or 2.
  152. We want to do it over the long term.
  153. We have some figures about how many
    hours have been funded since the start
  154. Feel free to interrupt me if you have any
    questions. I can take them at any time
  155. That's it for evolution. Now, the future.
  156. What do we expect for the future?
  157. First keep doing what we have been up
  158. Keep supporting the current set of packages.
  159. But for wheezy long term support we
    would really like to have more
  160. supported packages. A browser would
    be nice for desktop deployment.
  161. Virtualization support is also important
    for many companies so we should be
  162. able to support something here.
  163. Also we want to avoid some pitfalls that
    we had with squeeze LTS.
  164. As you know LTS users are currently
    required to add a separate source
  165. list entry with squeeze-lts repository. The
    security.debian.org squeeze
  166. repository is unused. It should be
    possible for the LTS team to
  167. continue using the same repository as
    the security team once it no longer
  168. use it. This will be the topic of a BoF
    next week on Tue at 1800.
  169. What's the problem with supporting the
    current set of packages?
  170. For example, we have MySQL right now in
    Squeeze LTS in version 5.1
  171. which is no longer supported by Oracle.
  172. We don't even know if it's affected by
    security issues because
  173. Oracle doesn't give info on
    non supported releases.
  174. This is a problem, we should consider
    switching to a newer version,
  175. but newer versions involve library
    transition, which is not really nice
  176. in Long Term Support releases.
  177. There is some work to do here if we want
    to do something serious.
  178. And we have other problems, other
    packages which are similar.
  179. From time to time, we backport, we take
    newer upstream versions.
  180. We did that for wireshark for example.
  181. This is what I said before, the limited
    scope sucks, we want to be able to
  182. support more packages and we need more
    support for this.
  183. [Q] Speaking of wireshark, we switched to
    Wheezy's version, so it's solved.
  184. [Raphael] Yes, exactly, that's what I just
  185. It used to be a problem.
  186. That's a part I did no update since March.
  187. Additionally, the problem with a separate
    repository is that
  188. there is a propagation delay to the
  189. that we don't have with
  190. I will speak a bit of how the team works.
  191. Basically, the first step is triaging new
    security issues.
  192. We have a list of CVEs that comes in and
    there are added to a text file
  193. data/CVE/list.
  194. Someone dispatches those on source
    packages and then someone else reviews
  195. status in each release.
  196. Then the LTS team reviews the status in
    Squeeze and members of security team
  197. review status in Wheezy and Jessie.
  198. And then, we decide what we must do with
    the package.
  199. Depending on the analysis, either we say
  200. "We need to prepare an update", so we add
    it to data/dla-needed.txt
  201. and someone will have to take care of
    preparing the update.
  202. Or we say "The issue does not apply, does
    not affect the current version"
  203. or we ignore it because the package is
    unsupported or because
  204. the issue is really minor, not severe
  205. Sometimes, it can be that the issue is
    already fixed in Debian
  206. due to some maintainer choices.
  207. When we do this classification, we contact
    the maintainer to keep him in the loop
  208. and offer him the possibility to help us.
  209. Here's what such a text file looks like.
  210. The bold line is the line that we are
    adding when we have decided
  211. what we're doing with the packages.
  212. This is all in the Subversion repository
    on Alioth.
  213. Then, someone has to prepare the security
  214. Basically, looking for a patch, it's often
    useful to be able to look up at
  215. RedHat or Ubuntu or upstream.
  216. Best case is upstream because there are
    nice upstream who are providing
  217. patches also for older versions.
  218. Usually there are already patches
  219. not always for the good version.
  220. Sometimes we have to backport it.
  221. Then we prepare an upload with this
    +deb6uX suffix that we're using now
  222. for security updates, stable updates.
  223. This is a rather known territory for
    package maintainers.
  224. This is the hardest part sometimes,
  225. testing the update, making sure the issue
    is fixed.
  226. When tools have test suites, it's nice,
  227. but sometimes we have to set it up
  228. Sometimes it is too hard, so we tend to,
    out of safety measure,
  229. to mail the mailing list and say
  230. "Ok, I've done my best, but please double
  231. It doesn't happen often that we have
  232. but some lts users are willing to test it
    before ???
  233. It would be really nice if we had
    more of those.
  234. And if we don't get any negative feedback,
  235. then we upload.
  236. Then, you have to send
    an announce.
  237. We call that DLA for Debian LTS
  238. We have a little script
  239. that generates the template mail
    and you have to add
  240. a little bit of description
  241. and basically send it to
  242. with a GPG signature of someone in the
    DD or DM keyring.
  243. The process is rather open to
    all maintainers
  244. even the write rights to the secure
    testing repository
  245. where we have this data/DLA/list file
  246. is writable by all Debian Developpers on
  247. so, really, the entrance barrier is
    rather low for Debian Maintainers
  248. and Debian Developpers.
  249. There's a file which is automatically
    updated when you generate this template
  250. and which will update the tracker on the
    web pages
  251. because all this data is nicely browsable
    on security-tracker.debian.org.
  252. And it's all linked from the package
  253. That's it. If you have a few questions,
    I'm here to answer you.
  254. [inaudible question]
  255. … library and operating server,
  256. so that you have same API for clients,
    or same ABI for clients and
  257. a newer server that actually gets
    security patches.
  258. [RH] In my head, yes, but we did not look
    further yet.
  259. I really want to use the BOF that is
    upcoming to discuss it
  260. As I said, the amount of funding we have
    allows us right now
  261. to keep up with security update but
    we do not have many spare cycles
  262. for dealing with such things.
  263. But it's slowly coming up,
  264. as I said there's potentially a new
    platinum sponsor.
  265. We will have a few hours free to look
    into this and I think
  266. it's probably the best solution
  267. but I don't know if it works in practice,
    I have not tried it.
  268. And since LTS, the end of life of Squeeze
    happens in February,
  269. it's not too far away so it's possibly
    a nice solution
  270. because upgrading to a newer upstream
    version is harder.
  271. [Q] I've heard ???
    Freexian ???
  272. you have enough contributors
    but you could do more work
  273. but you don't have the funding or
    is it, like, you also need
  274. more developpers?
  275. [RH] A bit of both, actually,
  276. the web page has always been very clear
    on the rules
  277. That means any Debian Developper who has
    made security uploads on its own already
  278. can apply and join the program and
    be funded.
  279. Fortunately, I did not have too many
  280. because it would have been hard,
  281. but it has been steadily growing over
    the months.
  282. Last year, there was only Thorsten,
    Holger and me,
  283. but in the meantime we got Ben Hutchings
    who is helping us on the kernel
  284. and a few more.
  285. I'm always looking, trying to make sure
    that we don't give too much money
  286. to a single person
  287. because it's Debian, there has been
    ??? in the past.
  288. I've been involved, I know it.
  289. I don't want anyone to have their life
    depend on LTS work, really.
  290. And I don't want the opposite way also,
    LTS to depend on a single person
  291. that can go away.
  292. I try to limit it to maximum 20 ???
    per month for each person
  293. and right now, we're well below that
    so it's good.
  294. By the way, most Debian Developpers are
    currently european,
  295. the fact that everything is euro-based
    is fine
  296. but one developer is american and it's
    no problem to pay in dollars
  297. So the amount will vary with the rates
    but it's not a problem.
  298. And even more, I'm surprised to have no
  299. in the countries where the rate of labor
    is well bellow.
  300. I mean, if we have south american
  301. or african or I don't know, I don't want
    to stigmatize anyone,
  302. but if there are people who could live
    for much more,
  303. if they would be payed 10 hours and
    have made their month,
  304. they can still join, it's not a problem,
  305. it's not a high rate because we want only
  306. it's because we want to allow everybody
  307. and if they can be payed for 10 hours
    by Freexian and then spend
  308. the rest of the month doing free work
    on Debian, the better.
  309. If you want to join the program,
    get in touch,
  310. there are details on the webpages
  311. and the more people funded
    the better.
  312. [Q] How do you or other developers
    motivate yourself
  313. to do this kind of LTS work,
  314. because obviously it's important
    for companies to have
  315. stable releases,
  316. but it also, to me at least, doesn't seem
    very exciting from a technology standpoint
  317. [RH] Do you think it's exciting or
    not exciting?
  318. I'm not sure I understood.
  319. Not exciting, ok.
  320. I agree, it's not exciting.
  321. [laughter]
  322. [inaudible question]
  323. [RH] A bit of both.
  324. I want Debian to succeed and I know that
  325. LTS support is important for Debian
    to succeed
  326. so I want to make sure the project is
    working well and alive
  327. but clearly, I'm doing it because…
  328. Let's say, the security support work,
    providing security update,
  329. backporting code, it's for money and
    because I need to live.
  330. But organizing the LTS project is
    something I do for free
  331. because I want it for Debian
  332. because Debian needs it.
  333. [Q] I have a question.
  334. Who announces the public relation,
    the marketing stuff of
  335. the Debian Long Term Support?
  336. Do you do it yourself or do you have some
    professional help?
  337. [RH] I do not have any professional help.
  338. Basically, the way we…
  339. Well, we could do much better, I mean,
    in number of sponsors.
  340. There are almost no US-based sponsors,
  341. there are lots of US companies
    that could help.
  342. It's true, I'm fighting between my time
  343. spending free time on Debian,
    doing LTS Debian.
  344. I contact a few companies that people
    suggest me to contact,
  345. but I'm not doing much things
    by myself.
  346. [Q] So, you would benefit a lot from
    some professional help
  347. in the marketing department or
  348. [RH] Yes
  349. [Q] public relation
  350. [RH] Yes, but I don't have money
    to fund this or not much.
  351. The 10€ difference is for
    administrative cost.
  352. Maybe a bit for this kind of stuff but
    it doesn't look like a lot for this.
  353. [Q] I just wanted to ask to the previous
    questioner about
  354. finding motivation for providing patches
    for LTS packages and in my view
  355. it's not very different from providing
    security patches for stable.
  356. Sometimes it's a bit harder because the
    software is a bit older
  357. but we overcame this situation
    for wireshark for example
  358. by updating wireshark because it was
    quite impossible to backport older
  359. security fixes.
  360. I think it's part of the maintainance.
  361. If you maintain a project, you should
    maintain the security issues in stable
  362. and if you care a bit more and if you have
    a little more time,
  363. you can care about the package in LTS
    as well.
  364. I did it for wireshark for free, because
    it's easy for me.
  365. [RH] I'm grateful, thank you.
  366. I want to point out that it's a good
    thing that
  367. LTS and security are different,
  368. because we have different policies like
    we said,
  369. importing a new upstream version is
    something we can do
  370. when it doesn't break too much.
  371. The command line interface had not changed
    so badly between both versions
  372. so it was possible.
  373. It's not possible for all projects, but we
    are not so strict on new upstream versions
  374. And if you look at what others have been
    doing, RedHat,
  375. they too import new upstream version
    quite often, in fact,
  376. even on libraries like nss.
  377. [Q] Due to lack of browsers in LTS support
    and Xen support
  378. was it an issue with companies you are
    working on, who are sponsoring Freexian?
  379. [RH] I'm not sure I understood.
  380. [Q] The lack of browsers support and
    Xen support in the LTS version,
  381. was that an issue with the companies
    who you work with,
  382. who are sponsoring your work?
  383. [RH] Browsers, not so much.
  384. Most sponsors are hosters and
    stuff like that
  385. but they were annoyed by the lack of
    qemu or Xen support.
  386. They did upgrade their host machines
    but not their guest machines
  387. for their customers.
  388. Obviously, that would be
    the first priority to fix.
  389. Browser is nice, but it's also one of
    those cases where we just need to
  390. integrate newer upstream versions
  391. ??? doing it.
  392. And I was hoping for Raphael Geissert
    to do it because he does it for
  393. Électricité de France.
  394. I'll catch him.
  395. Convince him.
  396. I know him quite well, he's working in
    Lyon near me, not far away.
  397. [Q] Having sponsors for doing the LTS
    work is a signal of
  398. the need for LTS versions,
  399. but do you have additional statistics on
    the usage of LTS?
  400. [RH] Not really.
  401. Since LTS is not hosted in security
    mirrors but on all mirrors,
  402. we don't have access to all the
  403. But I know from mails, thank mails and
    stuff like that
  404. that it's really appreciated and used
    quite a lot,
  405. even from end users.
  406. There are users who like the antiquated
    GNOME stuff.
  407. I'm fine with GNOME 3, by the way.
  408. Yes, it's really widely used and widely
  409. [Rhonda] Thanks for your attention.
  410. [Applause]