Re: Future of the linux udebs
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bastian Blank <waldi@debian.org> writes:
> On Fri, Feb 15, 2008 at 12:31:05PM -0200, Otavio Salvador wrote:
<...>
>> - Is impossible to release d-i with a different kernel from sid
>> without a lot of hassle
>
> d-i releases are built with testing udebs. Or do you mean something
> else?
Not during development cycle.
And the udebs on testing migrated to it from sid. I hope to not need
to do uploads to t-p-u for d-i kernel ;-)
<...>
>> - If a bad kernel, with a bunch of ugly bugs, gets uploaded, all d-i
>> development is affected
>
> If a bad glibc is uploaded, anything is affected. With such sort of
> arguments you can kill anything because the propability that something
> will get wrong is always larger than zero. We do a lot to not let really
> broken things through and I don't think you will be able to catch more
> problems.
Right. But it is a cons since currently we only migrate to the new
kernel when it's already widly tested on sid.
>> For it to work testing images, _before_ the kernel
>> upload to happen, would be required to at least reduce the risk of a
>> kernel upload to stop all d-i development until it gets fixed.
>
> We provide a snapshots archive which can be used through the whole
> development cycle.
Yes, right. We'd need to setup some way to get d-i builds against
those images and do testing using it before major kernel version
uploads.
>> Another thihk that I see as a _must_ is that d-i team could nack a
>> kernel upload. This is requred since d-i won't be allowed to diverge
>> from sid kernels anymore (I mean during development) and those
>> migrations would need to be much more coordinated with d-i RM and d-i
>> porters.
>
> We coordinate the uploads on d-kernel@, for security uploads the waiting
> period is usualy a lot shorter. If someone have a problem, he can speak
> up and his concerns will get heard.
I'm not wondering about security uploads but about ABI changes and
major kernel version updates. Those would need to be coordinated on
debian-boot too.
I guess that a notice about upload, few days before, to debian-boot ml
should be enough, for ABI changes. For major versions, we'd need much
larger coordination since it would affect whole d-i.
Obviously, as already spot by you, we can get images built against the
kernel snapshots but we'd need to get an infrastructure to get d-i
images built against it and tested before approval for the kernel
upload.
>> linux-2.6/linux-modules-extra-2.6 would build the udebs using what
>> list? Still using kernel-wedge?
>
> They need to include the list themself, it will get version dependant.
So your idea is to this list be placed inside each source package?
This means kernel-wedge will be useless and _any_ change would be need
to be done on kernel team svn. This is a big regression from my POV
since d-i team does need to be able to change the list by himself.
>> How the uploads of kernel would be coordinated? Will kernel team allow
>> d-i to _nack_ a kernel upload?
>
> Not for uploads which fixes bugs like CVE-2008-0600. A "nack" without
> anything may also not have any effect. But if there are concerns we
> should be able to find a solution which both sides can live with.
I agree that security uploads are exception here however any other ABI
or major version update would must to be acked by d-i team. This looks
logical since we'll be directly affected by it and the installer might
break.
- --
O T A V I O S A L V A D O R
- ---------------------------------------------
E-mail: otavio@debian.org UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://otavio.ossystems.com.br
- ---------------------------------------------
"Microsoft sells you Windows ... Linux gives
you the whole house."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>
iD8DBQFHtboLLqiZQEml+FURAonUAJwNMZNYsOEqYLvNFrf+brBOMdOvXgCghMdX
Tr/IltraJ/QKXpLXLlRwVis=
=9+UD
-----END PGP SIGNATURE-----
Reply to: