Re: Grace period for kernel-source uploads
On Sat, 09 Apr 2005 16:55:23 -0400, Jurij Smakov wrote:
> On Sat, 9 Apr 2005, Andres Salomon wrote:
>
>> The way this works in practice is; I get i386 in shape, release k-s
>> 2.6.x-1. Svenl gets powerpc ready, and dannf gets ia64 ready (though
>> they don't coordinate), and Sven releases k-s 2.6.x-2. Horms throws
>> some security fixes in SVN; Joshk gets sparc ready, and releases k-s
>> 2.6.x-3. Due to the security patches, other archs rebuild against
>> 2.6.x-3. And so on.
>
> Don't you think that the way you described (and that's the way it works
> now) is the major reason behind the very long times it takes to push
> through the security updates on all architectures? That way it make take
Not at all. Security updates would still take a long time if you had to
announce a k-s release, wait for 8 or so architectures to say "ok, we're
ready to go!", do a release, and then wait for their uploads. What causes
this process to take so long is the fact that kernels aren't built for
every k-s upgrade; that should be fixed once we have k-s generating images.
> people a long time to make k-i even build against 2.6.x-3 due to
broken
> arch-specific patches, missing/added kernel options, etc. I would rather
> proactively track the changes in k-s, making sure that new k-i may be
> built against it immediately.
>
That should always be the case, unless a security update affects something
on your architecture, or you screw up something on your arch w/ a prior
patch. :)
>> If people want to give advance notice of a k-s release, that's fine,
>> but it shouldn't be a requirement.
>
> I am not saying that it should be a requirement, just something everyone
> can benefit from (especially in the case of ABI-breaking changes in
> k-s).
ABI-breaking changes are a special case; unfortunately, we don't have any
infrastructure in place to handle that right now. ABI breaking changes
should definitely be given more consideration, and announced on d-k so
that arch kernel maintainers know to bump the ABINAME on their packages.
Reply to: