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

Re: uncoordinated upload



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                                        jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC



Reply to: