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

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
> 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: