Re: Beta1 missing decisions and possible timeline
Frans Pop <elendil@planet.nl> writes:
Before begin to answer, I want to say that I agree with you and will
follow your advice of do a 2.6.22 based release and prepare a beta2
changing the kernel just after beta1 release.
> 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
Yes, sure. But we could redo massbuilds once new kernels were upload.
> - 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
Agreed. You would give us problem to work with a safe bed.
>> 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.
I did it last time and coordinated the changes with Joey before commiting.
> 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.
Right. I wasn't going to change architecture specific packages but
going to update kernel-wedge recipes only.
It would be nice if people say if they prefer to me to do a first look
on the modules and then porters review it again or prefer to do it themselfs.
> 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.
Right. I agree with you conclusion. Talking with Dann, I realised that
Etch 1/2 isn't going to be release before mid march or so, giving us
time for it.
Besides that, I think I was wrongly mixing both releases. While
they're more or less related I still think I were wrong to change the
kernel so near of the release. Ack!
>> - 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.
Yes, Robert will handle it for us.
I understand and share the feeling that GRUB is in legacy mode for
Debian but I also think this is a important change and, if the patch
gives no know problems, it could be considered and then we could allow
it to go in as an exception.
>> |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?
After mips problem was fix, this happened but I agree I could give a
bigger slot of time to be able to deal with problems and
exceptions. Will update it.
--
O T A V I O S A L V A D O R
---------------------------------------------
E-mail: otavio@debian.org UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
---------------------------------------------
"Microsoft sells you Windows ... Linux gives
you the whole house."
Reply to: