Hello all,
Well, as you may have noticed, we uploaded 2.6.14-1 to unstable yesterday, we
needed 6 hours from when i was made aware of the upstream release and the
moment it entered NEW, and missed dinstall only by a couple of hours, so the
packages are now in incoming and not unstable, we should coordinate better
with the ftp-masters next time to achieve the 0-day upload i wanted :)
Anyway, this was possible thanks to all the work which has gone into the
experimental -rc trees by all involved these past two weeks or so, and bodes
well for the future of kernel maintenance and uploads. Let's just provide a
choice quote about the issue :
11:33 < horms> i'm very pleased with how this release went
11:33 < horms> even if it turns out to be a disaster from here
11:33 < horms> i still think its a success
11:34 < horms> svenl: i think we fulfilled your dream of uploading the same
day Linus does
11:34 < horms> and people (me) said it couldn't be done
Also, this was a particularly hairy transition, since due to devfs being
obsoleted, we had to move away from initrd-tools, and find a solution for easy
migration to yaird or initramfs-tools, which i think is solved in a
satisfactory way.
Still, not everything is perfect, so there is room for improvement for next
time. But in particular, 4 arches are FTBFS (m68, alpha, hppa and arm). Of
these m68k was expected and will come in once upstream porting has happened,
or if it delays too much maybe we will be able to look into it, but alpha,
hppa and arm all three had commits fixing the FTBFS a few hours after the
upload, so as soon as we get confirmation of the build success, we can do -2.
Then there is the issue of mips/mipsel, but Thiemo mentioned that most changes
may be merged into 2.6.15, so maybe we should try for bringing mips/mipsel
back into the fold for next time ? Comments Thiemo ?
Ok, that was for the past and near future, let's me outline the plan for how
we continue.
The plan is to hold in the next time 2.6.12-1 in testing while we iron out the
last glitches of 2.6.14-1, and for a regular upload of 2.6.15-rc packages to
experimental. Parallel to that, we have 2.6.8 in stable, and also the security
updates for it, and we will provide sarge backports for the latest etch/sid
kernels, and related packages (initrd-tool, yaird, initramfs-tools, udev,
kernel-package), the former being in the official archive, and the later will
be on kernel.debian.net, which is planed to reuse the experimental/volatile
auto-builder network, and the experimental packages can soon move there too.
So, basically, there will be 2/3 trees for non-sarge in the subversion repo
and 2 for sarge :
- sarge security
- sarge proposed updates
- etch (when it diverges from sid).
- sid
- experimental.
Knowing that the latest will not have security updates applied, as it follows
upstream closely, and is well, experimental :).
Ok, let's finish with the next things to work on :
- clear the external module situation. Propose a policy explaining how to
build external modules, and ask all packagers of external modules to build
modules for all official flavours that make sense, and coordinate with
them for new abi-uploads. Also think about non-packaged modules.
- go over the bug reports fixed in 2.6.14-1 and make sure they are closed,
in particular there where a few missed close tags in the changelog for
2.6.13-2 and 2.6.14-rc5-2 which where never uploaded, so need to be
manually closed.
- once we have more clarity of the situation with the ramdisk generation
tool, we need to take a decision about the tool used as default, and the
upgrade path from sarge concerning them. Right now yaird is used as
default, but only because at the time of packaging initramfs-tools was
still having build and install problems. Both are easy installable and
usable, and choice is left to the user, but we need to provide sane
default.
- also, i want to make a Bits from the kernel team post to d-d-a, and
altough this mail has some material for that, it needs fleshing out, and
maybe we should announce something about kernel.debian.net and the
security status. Let's do this early next week, but comments welcome.
Well, that is basically it, again thanks to everyone who made this possible.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
