tracking linux-2.6 upstream [was Re: Handling of trunk]
hello,
There are many ways tracking linux-2.6 upstream development.
First let me analyse the current situation and then explain
the up- and downsides of different upstream sync approaches.
Debian is known for outdated kernels.
2.6.8 got out with Sarge release. By then this kernel
was about a year old and wouldn't install on SATA boxes.
2.6.18 is the Etch kernel, it was half a year old when
we released.
2.6.19 wasn't the most stable release so the pick was
mostly good (tbm sorting the arm troubles with -mm
fedora patches).
Currently d-i has been based for half a year on 2.6.22 and
doesn't install on many recent boxes like Dell Optiplex
755 offered by hardware vendors or semi-current Intel
desktop boards DG33FB. When Debian fails on the first
try people usually try another distribution only very
few debootstrap back to Debian.
Etch and a half being based on 2.6.24 should bring
relief to those who have not yet switched to other
distributions like Ubuntu or Fedora.
Realistically, we see good progress in linux-2.6 landing
in unstable, often the same day as it is released,
but the Testing migration is badly out of sync.
The Debian BTS has a large number of bugs, see
http://ftp.es.debian.org/~ender/kernel_bugs/graphs/total-year.png
The upstream development is heavily speeding up,
(2.6.25-rc1 yet to be released) see
~/src/linux-2.6$ git diff --shortstat v2.6.22..v2.6.23
7203 files changed, 406271 insertions(+), 339074 deletions(-)
~/src/linux-2.6$ git diff --shortstat v2.6.23..v2.6.24
10209 files changed, 776097 insertions(+), 483021 deletions(-)
~/src/linux-2.6$ git diff --shortstat v2.6.24..
6849 files changed, 554939 insertions(+), 290672 deletions(-)
Now on the methods of tracking upstream one can choose
a) base our development work on rc releases
b) base our development work on git snapshots
Method a) is the conservative as rc's are usually released with
less known compile/runtime failures. Archs are normally synced.
orig tarball build infrastructure exists. DFSG patches need to
be synced first for orig tarball generation and afterwards all
the other patches. rc1 being the most work intensive one due to
the upstream staircase pattern match. A whole lot of patches that
were not merged are disabled and need work. This development
pattern sees config options synced and only set by rc6 time,
due to their big new number and changes.
Method b) allows to push latest upstream with all new goodies,
but also failures. Upstream development has shown that some none
mainstream archs like s390 fail to compile for about a week
until the relevant s390 git is pulled in. Due to upstream merge
errors, some drivers need to be disabled for a few days. The work
share spreads almost equally over the days as soon as you get the
git-commits-head mail you can set the respective config variables,
fix corresponding patch or drop if it is merged.
debian-kernel always had the policy to stick to Linus patches.
By using method b) we quickly allow bug reporter to really
test latest upstream version and either pass their bug report
on to upstream Maintainer or to close it on next upload.
It was said that SVN cannot cope with the git snapshot patches,
due to their size. I seriously doubt that as Fedora manages
even up to rc9-gitX all the patches, relative to the previous
release in CVS. Also, if the tools are the limitation I happily
would suggest and endorse a switch to git.
Sam Hocevar has been elected as DPL to make Debian sexy.
Method b) allows to bring latest upstream goodies to
the biggest percentage of our user base (x86_32 and x86_64).
Other archs are synced along the way and recover once
upstream fixes flow in. Users won't notice as trunk is never
uploaded to unstable and snapshots in between are built.
Rik van Riel -mm author and kernelnewbies creator showed up
lately again in #debian-kernel expressing his admiration for
being so close to upstream development.
For me it is personally clear that method b) is the superior
way of tracking linux-2.6 due to daily overseeable work
of staying in sync with the rapid upstream development.
Bug reports with method a) mostly sit idle and have no
newer upstream to test. I'm asking the Debian linux-2.6
Maintainers for their point of view on upstream tracking?
I may add that I endorse method b) and have happily worked
that way for the last few months.
I will continue to work on linux-2.6, no matter which method
is chosen, but after Lenny I do not want to maintain the work
overhead of method a). Heavy backlog cleaning on rc1 is no fun.
Concerning the allegations that git snapshots hinder Maintainer
scripts work. Any patch and it's dependency in our tree is very
easily disabled in the series file. Thus it is for anyone with
a bit of knowledge of our build system easy to do "infrastructure"
work on any arch against trunk.
Concerning build kernelserver we have offer of adding an alpha
and an hppa arch to current (amd64, i386, powerpc, sparc, s390).
Looking forward to have more archs daily build and their build logs
thus easily checked.
Debian kernel security work is under admirable conditions thanks
to dannf and the security team. Back in the days users complained
about no security upgrades. It is hard to believe that nowadays
our users get them pushed out so fast and quickly.
best regards
--
maks
Reply to: