From: Micah Anderson (micah_at_riseup.net)
Date: Tue 22 Feb 2005 - 00:58:40 GMT
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
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver