Adam Majer wrote: > Hey all, > > Would it be helpful if we actually have a public GIT server setup and > have the patches there instead one giant, unworkable monster patch? I'm > willing to set this up provided people will use it. Or at least people > send patches and commits to it instead of that kernel-diff-monster! We already have git.linux-vserver.org, what's wrong with that? You also have the split patches instead of the "giant monster patch", with one delta per feature (essentially). > As to paying Herbert to port vserver to latest kernel, no offense, but > that may not be a good idea unless you want to hire Herbert. I've seen > this already in other projects and it did not work out so well. For > example, grsecurity. As far as I can tell, development stalled there. > Kind of like it stalled in vserver. Rebasing is _usually_ not a super big deal, it takes a couple of days to get it right. Recent kernels changed too much though, requiring certain core functionality to be rewritten from scratch (XFS attributes, CPU scheduler, etc.). > If you are willing to hire a vserver developer to get things moving, > please do. But one-time "contract" doesn't work long term. > > So, either, > > 1. people start paying people to get vserver work done, or > 2. people start to volunteer time to get things done. > > Either way works. But having pledge drives (or what seem to be pledge > drives) just indicates the project is in its death-throws. This is a special case. When large chunks need to be rewritten, it takes longer to get it done. And when real life interferes... > Now, regarding actual work on stuff. Adrian Bunk has been maintaining > the 2.6.16.x kernel tree and will continue to maintain it for a bit. Is > it feasible to backport vs.2.2 branch back to that stable tree? 2.2 uses namespaces that are not present in the 2.6.16 kernel. You'd be better off basing it on 2.0.3-rc1 for 2.6.16. -- Daniel Hokka Zakrisson