On Sun, 20 Feb 2005, Ola Lundqvist wrote: > > > An example would be the difference between kernel-patch-2.4-grsecurity > > > (for 2.4 kernels and old grsec) and kernel-patch-grsecurity2 (for 2.6 > > > kernels and new grsec). Obviously the maintainer of the -ctx patch and > > > the util-vserver does not find the newer patch and utilities important > > > or stable enough, but everyone else does. > > I have argued about this lot of times. I think the current development > branch is really good. The problem is that I do not see a timeline for the > Debian release and I would like a couple of months of testing (with the > package in testing) before I would like to release vserver to Debian > stable.
I believe that it is possible to provide the new kernel patch and utilities in Sid (unstable) that do *not* migrate into Sarge, simply tag them as having an RC bug... However, if we could say that Debian will not freeze in the next two months, would you consider putting the new kernel patches and utilities into Sid and letting them migrate into testing so that they can be tested for two months? > > And, again, the current maintainer seems active, a little suprised he > > hasn't commented on this thread... > > I do not read this mailinglist every day. :) > > I want to explain this as it get up to discussion from time to time. > > 1) I'm interested in the development branch. Great... > 2) I really would like "upstream" to release this development branch > in some kind of stable version. We have discussed this quite a lot > and it do not seem too far away. The upstream has mentioned and commented in this thread that the 1.9.4 release that has recently happened is "stable", it is a matter of semantics here. > 3) I want the development branch to have at least a couple of months of > testing in the Debian distribution to catch the most critical issues before > sarge is released as stable. And right now I have no clue when this > is going to happen. I have a fairly decent idea because I am working on the sarge-testing security team trying to resolve all remaining security holes in sarge while the security buildd infrastructure is setup. Its not far off, but it is not inconceivable that it could be two months before everything is ready. However, I think the repository for testing is the unstable respository, put things there, let us who want to use it use it. Tag it with a RC bug so it doesn't merge into Sarge and then everyone will be happy. > 4) I will release a util-vservers and kernel-patch-ctx (or similar name) > to exprimental soon. I hope I can get some time, maybe tomorrow. Experimental is a good first step. I highly recommend changing the name to kernel-patch-vserver as the "ctx" name has not been used in a really long time, the website doesn't mention it and the project is known as vservers. Additionally, if you do an apt-cache search vserver you do *not* find kernel-patch-ctx, I thought that the vserver patch wasn't included in debian and was about to file an ITP before I found the kernel-patch-ctx package. Two and a half years from now, when Sarge is as old as Woody is now, the kernel-patch-ctx is going to be very outdated and it will have been about 4 years since anyone had referred to the project as CTX. > 5) My main focus before the release of sarge as stable, is to not get any > release critical bugs to my packages. It would be _very_ sad if > util-vserver > will not be released at all becuase of build problems, RC bugs or similar. > Such decisions is FTP-masters and I can not do anything about it more than > having a really stable package. No problem... this makes perfect sense, however you can keep the newer version out of Sarge, and leave the one in there as it is and it will be fine. > 1) Have heard of build problems on some arches. Can you elaborate so they can be fixed? > 3) Handling of /var/lib/vserver with backward compatibility mode. What needs to be done here? > So please do not hijack my package. I have quite long experience with Debian > Development and I know that changing things just before a release is a _very_ > bad > thing. I did so just before the last release (and during a security update) > and I > have learnt a big lesson there. As I have said over and over and over again, and will say so here again, I do not want to hijack your package. I simply wanted to either encourage you to update it before it was too late, or to put together a different package. Micah
signature.asc
Description: Digital signature
_______________________________________________ Vserver mailing list [email protected] http://list.linux-vserver.org/mailman/listinfo/vserver
