On Fri, 2010-06-04 at 11:03 +0100, Karanbir Singh wrote: > - w.r.t VM's - if we need to do that, the main box has 8 gigs of ram, > and dual opterons; so it could handle a few, I am just not sure we need > VM's as long as we are not doing builds on the same machine. I think the > hetzner machine that Dag has is a *much* better build host than surya > will be.
I think VMs are definitively the way to go for service isolation. We had a setup which was basically an OpenVZ cluster with isolated VMs for website, database etc. and it was very nice to be able to upgrade them separately, move the nodes around the machines without downtime whenever the maintenance had to be performed etc. And certainly a VM is a nice playground for testing by an unprivileged / untrusted person such as I am. Also we can offload the administration of different parts of the system (Redmine, SCM, mirrors, buildhosts) to different groups of people without too much compromising the security of the environment. This is just a suggestion though. Who is going to administrate the thing will make final decisions probably with the consultation of the list. > - w.r.t keysigning; thats a seperate issue and needs some level of > discussion. Hey, I don't think we necessarily need to invent something on our own here. There are several models that work fine, we just need to evaluate them and chose which one will suit us better. (1) I do maintain some packages for Debian. The way it works is that basically any seemingly sane person can get access to any SCM. There is a number of people that have their keys in the keyring (Debian Developers). Once I want to get my package in the distro I need to ask for sponsorship and one of them will review / push my package. Eventually you can become a DD if you think it's worth it. (2) The packages are signed by the build host and the privileges to push packages and get them signed are distributed on a per-package basis. To my mind, this works when you have a rather large number of people responsible for individual packages and almost no jacks of all trades. Which one is better? It's up to the discussion. > - version control is a policy issue, hosting it is as close to free as > free can get, either with svn or git or Hg ( which is an easier > migration from svn, and comes with most benefits that git has for the > 'average' user ) Well, hg is not so different in terms of speed from svn, so in such a case the question pops up why would we migrate from svn at all?, given that as I outlined above we don't have a proper SCM workflow, but what we're doing now is basically using it as an authenticated archiving backend with integrated diff viewer. -- Sincerely yours, Yury V. Zaytsev _______________________________________________ users mailing list [email protected] http://lists.rpmforge.net/mailman/listinfo/users
