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

http://layer-acht.org/thinking/blog/20140819-lts-july-2014/



-----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-----

Reply to: