On Thursday 31 January 2008, Otavio Salvador wrote:
> - kernel to release
> We have 2.6.22 as a safe bed on lenny now and their udebs are there
> too however since EtchAndHalf intends to release with 2.6.24 and it
> has been uploaded to sid already I'm considering a better option to
> us to release with it.
It it _way_ too early to switch to 2.6.24:
- experience has shown that the first new upstream kernel release always
has important issues and, looking at lkml, this one is no exception;
for D-I to switch, _especially_ for a release, normally requires at least
a .2 or .3 upstream release
- even if upstream was perfect, you still have initial Debian packaging
issues that will need to be sorted out
- switching to 2.6.24 only for unstable is not a good idea because, as long
as there has not been a D-I upload, we don't have any working builds from
testing, so effectively _all_ our images would be switched to 2.6.24,
which is not good for release testing
- with your current schedule we'd have not nearly enough testing of D-I
with 2.6.24
> linux-2.6 has been built in all architectures and
> linux-modules-extra-2.6 has been fastly processed (thanks
> ftpmasters) and then we could manage to get a massbuild done in few
> days (+- 5 of febuary or even before). I've started to check the
> new modules and prepare the patches for kernel-wedge for it and
> hope to get it ready for tomorrow or so.
Did you discuss with Joey whether he wanted to do that or not? Joey of
course has huge experience with doing that.
Also note that I have _never_ intended the massbuild script to be used for
mass uploads when switching to a new kernel minor version [1]. I still feel
that porters should be responsible for checking their configurations and
included modules when switching from one upstream kernel release to the
next, and that goes double when we are skipping a version.
If you want to change that policy, that's fine. But in that case that policy
change should first be discussed and agreed with the porters.
My conclusion is that unless you are willing to significantly delay the Beta
release, I don't see any way you can do the release with 2.6.24.
I would suggest to do the release with 2.6.22 and keep the option to do a
quick new release based on 2.6.24.
> - e2fsprogs inode size change
>
> Lastest release[1] changed the default inode size to 256
> bytes. This is not yet on lenny but is already available on sid and
> will hit lenny in few days.
>
> 1. http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.40.5
>
> Currently, there's a know problem with GRUB[2] and the safest solution
> is to change the current inode size back to 128 bytes using -I
> option of mke2fs for Beta1 release and then work on GRUB or GRUB2
> to support it for lenny Beta2 release with 256 bytes again.
>
> 2. http://bugs.debian.org/463236
What about the option to just apply the recent patch from Stefan
Lippers-Hollmann to grub and go with that? I very much disliked the
reaction from Robert basically saying that the patch would not even be
considered because grub was dead.
AFAIK, grub is still very much the major bootloader for x86 and issues such
as this definitely should be resolved.
> |2/15/2007|mass upload of translation updates |
[...]
> |2/16/2007|mass migration of udebs |
This is completely impossible, especially for packages that also produce
regular debs. You are forgetting time needed to build, test and age new
uploads. Do you really expect packages to be built for all arches within
one day?
Cheers,
FJP
[1] http://lists.debian.org/debian-boot/2006/08/msg00631.html
http://lists.debian.org/debian-boot/2006/09/msg00660.html
[2] http://lists.debian.org/debian-boot/2008/01/msg00830.html
Attachment:
signature.asc
Description: This is a digitally signed message part.