About this list Date view Thread view Subject view Author view Attachment view

From: Ola Lundqvist (opal_at_debian.org)
Date: Sun 20 Feb 2005 - 20:40:52 GMT


On Sun, Feb 20, 2005 at 04:11:57AM -0500, Stephen Frost wrote:
> * Micah Anderson (micah_at_riseup.net) wrote:
> > Stephen Frost schrieb am Thursday, den 17. February 2005:
> >
> > > This is certainly something I'm all for, and were the Debian maintainer
> > > of vserver going to upload a kernel-patch for 1.9.4 I'd be happy to help
> > > him create that package such that it patches cleanly against Debian
> > > kernel sources (again, not hard to do, really).
> >
> > What is to stop us (both debian developers), as well as other debian
> > developers who are wanting this, from creating our own kernel-patch
> > package that implements the patches for 1.9.4 and the updated tools?
You would start a really nice little flamewar :)

> > 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

> > If the maintainer of the -ctx patch and of util-vserver wishes to
> > continue to maintain those old packages and does not wish to maintain
> > the package for the newer kernel patch and newer utilities, we should
> > have no problem with that. We simply solve what is obviously our
> > problem, rather than try to make it Ola Lundqvist and Ron Lee's problem.
> In general I feel it's:
> a) bad form to hijack packages from active maintainers
> b) Have multiple source packages in the archive for the same programs
> c) effectively go around the existing maintainer
> It's not entirely the case that the existing maintainer is totally
> uninterested in the 1.9.x vserver series or I'd be more concerned. He's
> shown interest and seemed to be working with some others on a better
> solution to the current situation (which might involve what you're
> suggesting, but I'd really hope not..). I don't know that we've given
> them quite enough time yet to claim that nothing's happening and that we
> need to move forward independently - it's only been maybe a month or so
> as I recall since serious discussion of 1.9.x was brought up to the
> maintainer.
> 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.
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.
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.
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.
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.

There are a couple of issues that have to be fixed before uploading to unstable.
Exprimental is ok though.

1) Have heard of build problems on some arches.
2) debian-vservertools and integration with the development version of util-vserver?
3) Handling of /var/lib/vserver with backward compatibility mode.
4) I think there are some more.

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.

You just can not imaging how many bug reports and email you can get on the same
issue if the package is popular.

So if I knew that Debian sarge will be released as stable on ... say august I
would not have a big problem with this. But right now I only know that it is
not next week (probably).


// Ola

> Stephen

> _______________________________________________
> Vserver mailing list
> Vserver_at_list.linux-vserver.org
> http://list.linux-vserver.org/mailman/listinfo/vserver

 --------------------- Ola Lundqvist ---------------------------
/  opal_at_debian.org                     Annebergsslingan 37      \
|  opal_at_lysator.liu.se                 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

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Sun 20 Feb 2005 - 20:42:56 GMT by hypermail 2.1.3