Frans Pop <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] 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." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]