Hello, On Sat, Apr 22, 2006 at 04:00:08PM -0700, Jurij Smakov wrote: > On Sun, 23 Apr 2006, Bastian Blank wrote: > >2.6.16.10 is scheduled for tomorrow. More than one upload per day is not > >good for the buildd network. > > I would say that more than one upload per *week* is too much for the > buildds, especially now, when stable releases often consist of a single > few-line patch. This could be a too harsh restriction when it comes to security updates. Noone of us could anticipate the release frequency upstream had during the past days, and it should still be an exception (which we have to deal with in the future, though). As we need to find a consensus on how to handle upstream bugfix releases, I propose the following: - security updates and FTBFS fixes should be uploaded asap (read: send an announcement scheduling the upload for the next day) - for other changes, we need to make sure they don't break the ABI as happend with 2.6.16-7 when we disabled SECCOMP, and don't introduce build failures as 2.6.16.6 did on alpha. I suspect one day is not enough for every arch maintainer to check the changes and possibly veto the upload. What is a decent compromise here? Two days? Is this possible at all, considering we do not have more than one active developer for most architectures? Do we have the resources to check the next upload for all architectures within a day or two? The checks would consist of the followings (where applicable): - does it still build on $arch - do the various kernel images boot and run - do external modules built against a previous version still work - do external modules still build TBF here: which modules? Is a newly introduced FTBFS in nvidia modules worth a delay? Which tests should we do to ensure the kernel runs, compile something? Or just boot and make sure I can login? > My proposals to introduce some kind of saner upload scheme > (like have an upload every Sunday, leaving Saturday for the test builds > and at least minimal testing) have been consistently ignored. I think setting a fixed day in the week for uploads is a bad idea, it has at least two drawbacks: 1. security fixes might take a week to be uploaded 2. what are we going to do with upstream changes released the same day or the day before the upload? Add another deadline? Yes, I am a friend of frequent updates and I want to track upstream as closes as possible. Unlike the majority of distros, we do not do amd64/i386/ppc only but have to take more care in what we put together - I do not want to "vancouver" architectures from the checklist to have the upload done sooner, but this means every arch needs to build snapshots and perform the tests we define. Best regards Frederik Schueler -- ENOSIG
Attachment:
signature.asc
Description: Digital signature