On Mon, Feb 21, 2005 at 06:58:40PM -0600, Micah Anderson wrote: > 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... > :) Yes but then the package may be removed by the FTP masters. That has happend to be before.
> 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? Two months is a bit short but if I knew that it is at least two months until a freeze I would consider it. > > > 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. Yes, I know that and as you have noted it has been discussed. Both on this list and on IRC. > > 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. Ok. This was good information to know. > 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. Well then I would use exprimental instead. Let us start there at least. > > 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. Agree with the name change. It will add a number of extra weeks to the process as the ftp masters still have not approved my horde3 package that I uploaded a week or two ago. > > 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. I do not want to use unstable as I probably need to make some uploads to the sarge version before the release. There might be issues needed to take care of. > > 1) Have heard of build problems on some arches. > > Can you elaborate so they can be fixed? The problem right now is that I do not have access to machines to test on. > > 3) Handling of /var/lib/vserver with backward compatibility mode. > > What needs to be done here? I'm not sure. I think I have found a way to accomplish it but some testing needed. > > 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. Good to hear. :) Regards, // Ola > > Micah > _______________________________________________ > Vserver mailing list > [email protected] > http://list.linux-vserver.org/mailman/listinfo/vserver -- --------------------- Ola Lundqvist --------------------------- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --------------------------------------------------------------- _______________________________________________ Vserver mailing list [email protected] http://list.linux-vserver.org/mailman/listinfo/vserver
