On Sun, 23 Apr 2006, Frederik Schueler wrote:
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.
I've heard the security argument before and I'm totally not buying it.
As it takes at best a few weeks to get the updated kernels into our
*stable* distribution, I don't think it makes a lot of sense to issue an
update for every possible security problem (including those which are
only theoretically exploitable) for the unstable distribution, which is
not supposed to be used in the production environment anyway.
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?
One day is definitely not enough. That's another reason why regular
uploads would be beneficial: every arch maintainer could plan the
necessary building and testing individually, depending on how fast is the
arch.
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?
Previous discussion on module handling converged towards a view that
out-of-tree module maintainers should build the binary modules against the
official kernels and upload them (or they should be binNMU'd if no source
changes are required). Frequent kernel uploads will make it all harder for
them to keep up.
I'm slowly working on the draft of the policy and on a sample
policy-compliant module package. At the moment it can be found under
people/jurij/sample-module-package in svn.
Yes, I am a friend of frequent updates and I want to track upstream as
closes as possible.
In my opinion, weekly uploads are frequent enough, when we are talking
about such a complicated package as the kernel.
Best regards,
Jurij Smakov [EMAIL PROTECTED]
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
