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

Re: Future of the linux udebs



Frederik Schueler <fs@debian.org> writes:

> Hello,
>
> On Fri, Feb 15, 2008 at 12:31:05PM -0200, Otavio Salvador wrote:
>> Bastian Blank <waldi@debian.org> writes:
>>>  - Is impossible to release d-i with a different kernel from sid
>>>    without a lot of hassle
>>>  - If a bad kernel, with a bunch of ugly bugs, gets uploaded, all d-i
>>>    development is affected
>>
>> This last item is where I worry a lot. Obviously, kernel team want to
>> put newest kernel on sid however, when he does it, d-i will be forced
>> to change it too.
>
> Coordination is already needed now, and will be needed even more when
> this change is implemented. 
> If this means waiting with a new upstream kernel version for a week or 
> two until the next beta of d-i is done, we will of course wait, no one
> wants to break d-i development by purpose.

Exactly however for that to work we, d-i team, need to be able to nack
a kernel upload.

Please read the thread we had about 2.6.24 kernel testing
migration... this is what worries me.

>> 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 have the kernel-snapshots archive to test new images before uploading
> them. This infrastructure could be extended, by adding buildds for all 
> missing architectures, and whatever else is needed to get daily d-i
> snapshots built with these kernels. 

Yes, that's one thing that do like. This would allow us to have a
current d-i image and one using the next kernel, just released.

>> 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.
>
> Nobody will insist on uploading a new kernel version if this breaks the 
> release schedule, just think of 2.6.19, which never was uploaded to the
> archive because we where in the middle of releasing etch. 

I guess so but we had a hard time about 2.6.24.

This needs to get an agreement from both sides to be able to work.

I personally have a good relation with all active people in
debian-kernel but I think that we might have a "policy" to avoid
problems to happen. Good will isn't enough, IMO.

-- 
        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."


Reply to: