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

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: