-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi, guys, actually this is the first time, I hear about paid work in Debian apart from the job of the DPL. I only found the archive of DebCenf14-videos today and started watching today with this item: http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/tasksel_default_desktop_requalification.webm [partial] and this: http://meetings-archive.debian.net/pub/debian-meetings/2014/debconf14/webm/bugsdebianorg_Database_Ho.webm So you might call it a bottom-up approach to that list of content. I also think, that it is important work, to provide long-term-support for oldstable. And I also think it is a plus, when oldstable versions are more stable than Ubuntu-LTS. My son has Ubuntu 12.04-LTS on his notebook and recently the kernel and the graphics stack had to be upgraded to recent versions in order to further receive security-updates. I think there is the danger of having users run into regressions this way, that occur only when doing dist-upgrades normally. I do not have any experience as a package-maintainer yet, so I am afraid I cannot help there with that. It is a plus, when more recent kernel-versions can be retrieved from backports, but users should not be forced to install those. CentOS (and also RHEL) have a similar policy, I think, they provide newer dot-releases only with backported security-updates, but no major kernel-upgrades for their distribution, so that is also more stable than Ubuntu-LTS. I am going to watch that LTS-video and subscribe to the list. Cheers. Andreas > Debian LTS - impressions and thoughts from my first month involvement > > About LTS - we want feedback and more companies supporting it financially > > Squeeze LTS, and even more Debian 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. 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 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 (linux-2.6, file, munin and > reportbug) > 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, 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 better. > > 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 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), 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlQJvIwACgkQ5+rBHyUt5wuHFACghwWvveuWn5PIwawoK3pXAvdT +XMAnRHvaJqVz6YQxPlTTqoL1kchexYN =Ciep -----END PGP SIGNATURE-----
