(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 [email protected]. -- dann frazier -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
