Remigiusz Modrzejewski wrote: > On Tuesday 12 of August 2008 08:29:43 Herbert Poetzl wrote: >>> 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 fine with the current patches, deltas and splits > > Well, and why GIT? People who've tried both (I'm still good with Subversion) > say, that Mercurial is much less of a PITA... I'd say because GIT is used by kernel developers. It makes maintaining patches A LOT easier and you can see exactly what upstream is doing that is breaking vserver patches (as an example). I've used all sort of different revision control systems, from CVS to SVN to Arch to GIT. And I have to say GIT is by far the best. You can change your current checked out version in-tree without changing directories like with others. It is a very nice system. Basic GIT operation like pull, checkout, push, commit, diff, are all *very* simple. And I did not jump on the GIT bandwagon until almost forced recently - I will I was forced earlier :) Anyway, I'll maintain the GIT version of the patches. This means essentially vs. Linus' kernel from http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=summary >>> 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? >> sure, but that's definitely something I won't spend time >> on, unless it is well payed ... > > Now, could you undertake the effort and try to estimate how much work it is > for an experienced C developer, but without great knowledge of Linux kernel > and especially little knowledge of Linux-Vserver? I will not have the time to > jump in, but there are other developers around who match this description... Jump-in is *exactly* what is needed. With both feet. And if you screw up, no big deal. Part of the learning process. I'm not sure how large the vserver community is, but people will really need to run test versions and report problems back. That is the minimum. Reading the patches and learning this stuff is even better. Any Debian kernel maintainers reading this? Debian's Sid is an excellent testing location (beta testing, not alpha testing!) - Adam