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

Debian LTS - impressions and thoughs from my first month involvement

# Debian LTS - impressions and thoughs from my first month involvement

originally posted at 

## About LTS - we want feedback and more companies supporting it financially

Squeeze LTS, and even more [Debian LTS](https://wiki.debian.org/LTS), is a 
pretty young project, started in May 2014, so it's still a bit unclear where 
exactly we'll be going :) One purpose of this post is to spread some 
information about the initiative and invite you to tell us what you think 
about it or what your needs are. 

LTS stands for "Long Term Support" and the goal of the project is to extend 
the security support for Squeeze (aka the current oldstable distribution) by 
two years. If it weren't for Squeeze LTS, the security support for it would 
have been stopped in May 2014 (=one year after the release of the current 
stable distribution), which for many is a too short timespan after it's 
release in February 2011. It's an experiment, we hope that there will be a 
similar Wheezy LTS initiative in future, but the future is unwritten and 
things will change based on our experiences and your needs. 

If you have feedback on the direction LTS should take (or anything else LTS 
related), please comment on the [lts mailing list]
(https://lists.debian.org/debian-lts/). For immediate feedback there is also 
the #debian-lts IRC channel.

Another quite pragmatic way to express your needs is to [read more about how 
to financially contribute to LTS](http://www.freexian.com/services/debian-
lts.html) and then doing exactly that - and unsurprisingly we are prioritizing 
the updates based on the needs expressed from our paying customers.

## My LTS work in July 2014

So, "somehow" I started working for money on Debian LTS in July, which means 
there were 10h I got paid, and probably another 10h where I did LTS related 
work unpaid.  I used those to release four updates for squeeze-lts 
announce/2014/07/msg00002.html), [file](https://lists.debian.org/debian-lts-
announce/2014/07/msg00013.html), [munin](https://lists.debian.org/debian-lts-
announce/2014/08/msg00004.html) and [reportbug]
(https://lists.debian.org/debian-lts-announce/2014/08/msg00005.html)) fixing 
22 CVEs in total. 

The unpaid work was mostly spent on unsuccessfully working on security updates 
and on adding support for LTS to the [security team tracker](https://security-
tracker.debian.org/tracker/), which I improved but couldn't fully address and 
which I haven't properly shared / committed yet... but at least I have a local 
instance of the tracker now, which - for LTS - is more useful than the 
.debian.org one. Hopefully during DebConf14 we'll manage to fix the tracker 
for good.

Without success I've looked at libtasn1-3 (where the first fixes applied 
easily but then the code had changed too much from what was in squeeze 
compared to the available patches that I gave up) and libxstream-java (which 
is at version 1.3, while patches exist for upstream branches 1.4 and 2.x, but 
those need newer java to build and maybe if I'll spend two more hours I'll can 
get it build and then I'll have to find a useful test case, which looked quite 
difficult on a brief look.. so maybe I give up on libxstream-java too.... 
OTOH, if you use it and can do some testing, please do tell me.

Working on all these updates turned out to be more team work than expected and 
a lot of work involving code (which I did expect), and often code which I'd 
normally not look at... similarily with tools: one has to deal with tools one 
doesnt like, eg I had to install cdbs... :-) And as I usually like challenges, 
this has actually been a lot of fun! Though it's also pretty cool to use 
common best practices, easy and understandable workflows. I love README.Source 
(or better yet, when it's not needed). And while git is of course really 
really great, it's still very desirable if your package builds twice (=many 
times) in a row, without resetting it via git.

## Some more observations

The first 16 updates (until July 19th) didn't have a DLA ID, until I suggested 
to introduce them and insisted until we agreed. So now we agreed to put the 
DLA ID in the subject of the announcement mails and there is also some tool 
support for generating the templates/mails, but enforcing proper subjects is 
not done, as silent bounces are useless (and non silent ones can be abused too 
easily). I'm not really happy about this, but who is happy with the way email 
works today? And I agree, it's not the end of the world if an LTS announcement 
is done without a proper ID, but it looks unprofessional and could be avoided, 
but we have more important work to do. But one day we should automate this 

Another detail I'm not entirely happy is the policy/current decision that 
"almost everything is fine to upload if deemed sensible by the uploader" 
(which is everyone in the Debian upload keyring(s)). In discussions before 
actually having the archive some people suggested the desire to upload new 
upstream versions too (eg newer kernels, iceweasel or other software to keep 
running a squeeze desktop in the modern world were discussed). I sincerely 
hope for most intrusive new upstream versions squeeze-(sloppy-)backports is 
used instead, and squeeze-lts rather not. Luckily so far all uploads were 
(IMHO) sensible and so, right now, I will just say that I hope it will stay 
this way. And it's true, one also has to install these upgrades in the first 
place. But people do that blindly all the time...

So by design/desire currently there is no gatekeeping mechanism whatsover (no 
NEW, no proposed updates), except that only some selected "few" can upload. 
What is uploaded (and signed correctly), gets pushed to archive, buildds and 
the mirrors, and hopefully maybe someone will send an announcement. So far 
this has worked remarkedly well - and it's also the way the Debian Security 
team works, as I'm told. Looking at this from a process quality / 
automatisation perspective, all this manual and errorprone labour seems very 
strange to me. ;-)

And then there is another thing: as already mentioned, the people working paid 
hours for this, are prioritizing their work based on customer requests. So we 
did two updates (python-scipy and file), which are not fixed in wheezy yet. I 
think this is unfortunate and while I could probably prepare the wheezy DSA 
for file, I don't really want to join the Security Team... or maybe I 
want/should join the Security Team and be a seldomly active member (eg fixing 
file in wheezy now....)

A note related to this: out of those 37 uploads done until today, 16 were done 
by those [two people](http://blog.alteholz.eu/2014/07/my-debian-activities-in-
july-2014/) being paid, while the other 21 uploads were done by 10 volunteers 
(or at least not paid by Debian LTS). It will be interesting to see how this 
statistics evolves over time.

Last, but not least, there is also this can of worms (aka: the discussion) 
about paying people to work on Debian... I do agree it's work we didnt find 
volunteers for and I also see how the (financial side of the) setup is done 
outside of Debian (and well too, btw!), but... then we also use Debian 
ressources like buildds, the archive itself and official mailing lists. Also 
I'm currently biased in this discussion, as I directly (and happily) profit 
from it. I'm mentioning this here, because I believe it's important we discuss 
this and come to both good and practical conclusions. FWIW, we have also 
discussed this on the list, feel free to search the archives for it.

To bring this post to an end: for those attending DebConf14 (directly or 
[thanks to some ninjas]
(https://wiki.debconf.org/wiki/DebConf10/Videoteam/Thanks)), there will be an 
event about LTS in Portland, though I'm not sure yet what I will have to talk 
about what hasn't been already covered here :-) But this probably means that 
will be a good opportunity for *you* to do lots of talking instead! I'm 
curious what you will have to say!

Thanks for reading this far. I think I can promise that my next LTS report 
will be shorter :-D


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: