[Debian] Re: OpenVZ and the kernel package

dann frazier dannf at dannf.org
Mon Feb 16 16:53:58 EST 2009


(Adding debian-kernel to the CC)

On Mon, Feb 16, 2009 at 09:28:07PM +0100, Ola Lundqvist wrote:
> Hi Dann

hey Ola!

> Now when Lenny is "out of the door" it is time to start looking for the
> ABI breakers... I have located the patch file and I think I have
> determine where to change, however I have a few questions:

You might want to keep debian-kernel in the loop as well, just to make
sure noone else is duplicating your effort.

> 1) in svn://svn.debian.org/svn/kernel/dists there is a lenny directory
>  that is currently empty. Is this where my changes (when filled) or
>  should we continue to develop the sid track?

I just announced my intent to populate the lenny and lenny-security
branches - they should appear soon. In the meantime, you can develop
against the sid branch - any work you do there will be easy to move
over.

> 2) What test procedures do you require for a patch to be applied or
>  a change committed? Build, run on target or other?

Well, we don't have a strict list of policies for such things. I think
everyone expects the tree to build, and for you to test build your
changes before they get released. There is a snapshot build system in
place (see http://wiki.debian.org/DebianKernel) which provides daily
builds for a subset of suites for a subset of archs. That occasionally
catches build problems we miss during testing, and provides binaries
for testing purposes.

For releases targeting oldstable/stable, there needs to be a
corresponding bug of >= important severity, and there needs to be a
very low risk of regression. Sometimes this is easy to verify by
reading the code (e.g., adding pci ids for new hardware), other times
we just need to make sure we do sufficient testing. If its a fix for a
user-reported bug, I try and post builds for the reporter(s) to test,
etc.

>  Also do you have any recommendation for build test, as my machine
>  is not fast enough to build a bunch of kernel versions in a reasonable time frame.

You can always try the developer chroots. Also, try disabling any
subarchs/features in the defines file to make sure you're not building
any flavors that you're not going to test.

> 3) What kind of requirements in general do you require on the patches,
>  such as change size compared to previous version, similarity to upstream
>  or other?

Our guideline is that all patches should be upstream first. Of course,
there are exceptions to this - sometimes a backport needs to be
handled differently on an older kernel and we need to diverge from
upstream, or we need to do something specifically for debian that
isn't fitting for upstream.

Of course we're happy to review your proposed changes on
debian-kernel at l.d.o.


-- 
dann frazier



More information about the Debian mailing list