On Wed, May 27, 2009 at 10:36:53PM -0400, Micah Anderson wrote: > > Hi, > > I wanted to start a discussion about the plans for the stable kernel > in the next point release, specifically where it relates to the > Linux-Vserver patch-set. > > As we all know, the 2.6.26 kernel is the version that Lenny ended up > with and the Linux-Vserver patch that was under development (and was > still highly experimental and not complete) at that time was *not* > released for that kernel, and so the version of the patch that Debian > used was a backport of a snapshot of where things were at the latest > point. > > It was decided by the Linux-Vserver project to do long-term maintenance > of the 2.6.27 patches, to coincide with the long-term maintenance of > mainline 2.6.27. The reasons why this situation arose was related to the > heavy virtualization changes in upstream kernel, causing major patch > changes. > > As a result of this unfortunate timing situation, the remains in the > Lenny kernel some significant issues that continually come up in > upstream support channels, as well as in the Debian BTS. The main > problem is the wrong filesystem attributes being used which cause major > grief for people switching to or from that kernel. However there are a > number of other issues that are also significant: > > - the missing TB scheduler > - the PID 1 parent being wrong (initpid) > - netnamespace (not a big deal, as it is broken in 2.6.26 mainline > anyway, so it cannot really be used) > - signalling fix (delta-sigkill-fix01.diff) > - memory info (delta-cached-fix01.diff) > > Most of these issues could be solved by backporting the Linux-Vserver > patches to resolve them to 2.6.26, leaving only the mainline 2.6.26 > issues. > > So I am writing to ask what we can do to fix these issues, if the issues > were backported, could we get them included in a point release? Or are > there other plans that would resolve these problems? With a diff against > mainline, this could be sorted out, but I don't know if such work would > be used?
hey Micah, Each issue needs to be considered on its own merit - how important is the fix and what is the risk of regression. I think the best way to start would be to file a bug for each issue of >= important severity and attach a patch. -- dann frazier -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
