(Sorry for late reply.) On Sunday 16 July 2006 17:48, Andreas Barth wrote: > > So far, we can only say: one ABI bump will probably not be enough. > > Hm. Frans, how much effort is an ABI bump on the d-i side? An ABI bump is only a little bit more work for d-i than regular update, as long as it happens before the release. After the release it is a lot more work because it forces an update of the installer with the next point release while regular updates (without ABI change) can mostly be ignored. The main question about kernel updates is: what changes. If the change is only security updates or minor bug fixes, there is normally no or very little impact on the installer. However, if the kernel config is changed or the size of the image changes, the changes must be evaluated and the impact may only become apparent after building or even testing the installer. > Actually, there will be a time when the kernel is frozen hard, > independend of how late we try to have it. There is no way around that, > except by not releasing at all. As far as I'm concerned from a d-i point of view, we can do kernel updates until quite late in the game (both ABI changes and not), provided that: - there are no config changes or, if there are, they are discussed first - the size of the image does not change significantly (although sometimes even a very little change can make an installation image just too big) - there is still sufficient time for building and testing the installer (again, the main delaying factor there is the need for BYHAND processing) > When do you think is the latest chance for us to say "stop, we need to > exchange the kernel"? Before the final d-i build, before the last > britney run, before the symlink is moved, before the packages files are > generated, before the mirrors are pushed, before the CDs are built? > There will be a "sorry, it is too late"-date - we only can change when > it is. Perhaps we should really try to write down when this point in > time is going to be, that might make our decisions easier later on. Most important is the decision on a kernel version. Currently that looks to be 2.6.17. People should realize that we have no experience yet with 2.6.17 in d-i yet. Beta 3 needs to go out first before we can start on that. I'm a little bit apprehensive about 2.6.17 ATM as some bug reports against linux-2.6.17 seem to indicate that the SMP-alternatives support that is being activated in 2.6.17 (dropping separate SMP kernel flavors) is causing problems with some (older) hardware. > Actually, I think it's way more important that we make sure we have > infrastructure ready on each and every day to update the kernel, than > to try to delay this point in time for a few hours or days. Because we > will need that not only before release, but also after release, and if > I look at the amount of kernel root exploits, we will need it quite > fast. Agreed, but mostly we do. The infrastructure for point releases needs to be improved though. > AFAICS the round trip time is more than a week, because the resulting > d-i images need some heavy testing before we declare them stable. Again, that depends on the kind of changes. We do need heavy testing after changing to a new kernel minor release. We also need some testing after config changes. We need hardly any additional testing for security updates or minor bugfixes. > Also, what I considered quite problematic in sarge was that we had a > long time span of uncertainity, where we neither decided to exchange > the kernel nor decided to rather not, and then did it when it was even > later, which just makes the cost for all parties higher. That is > something I really want to avoid this time. I hope we can agree on > that. What happened during the Sarge release was that we were aiming all the time to release ASAP. If you do that, you cannot really relax your freeze selectively. Maybe the release team should instead say: "OK, we are not going to make the current planned date and looking at the issues it will take at least 3 weeks to fix if all goes well; so let's postpone the release by 2+ months which will allow us switch to a newer kernel". This needs thorough discussion though.
Attachment:
pgpq7NjaJEAK2.pgp
Description: PGP signature