On 06/22/2012 12:34 PM, Dave Neary wrote:
On 06/22/2012 02:45 PM, Dan Kenigsberg wrote:
> I am not aware of any other trick beyond building up reputation. Your
> personal involvement in the project goes a long way to prove that you
> indeed care for it.
The difficulty with something like access to servers is that if you
don't have permission to do damage, you also can't do much good :)
How do you go from unknown and untrusted to known? In code, you get it
by checking out the project, compiling it, making changes and
submitting those changes for review.
In Maemo, all of the source code for the website was in revision
control, and in theory someone could check it out and use a sample
data dump to get something like the website working locally, and then
create and propose patches against that. In reality, no-one really did
that, our website was a little too complicated. But we still got
things like CSS patches against the website.
With something like Puppet, we could conceivably publish all of the
configuration files for services and ask for patches for new features
- Wikipedia just opened up their infrastructure this way.
But really there's no substitute to giving someone (once you do a
rudimentary check of their credentials) some server space where they
can't do any harm to anyone else, and evaluate how they manage when
administering a service that is under consideration. If we have the
facilities to spin up half a dozen "test service" VMs, that would be
perfect. Someone like Robert could administer some service (say, an
alternative Gerrit install or whatever), and then the sysadmins could
check out how it's set up, whether it scales, integrate it into any
SSO set-up that's there, whatever.
I have done in in-house by given people access to the staging / testing
servers then having more trusted people push to production. You can
always clone production to create a new testings box but from what I can
tell ovirt hasn't gotten to that point yet. There have there kitchen
sink server, Gerrit, Jenkins, and Jenkins slaves. All changes are
current on the live box. And to be honest for the current project size
this makes some since why pay double the cost of having a testing
environment. The project would be better off using money like that for
having more jenkin slaves to better testing.
> However, I do not know to quantify how much reputation would one
> get a root access, a permission that is very easy to abuse and very hard
> to take away.
> Another important issue beyond trust is NEED. Do you really need full su
> access? I personally do not have such an access, and have to ask
> for every little host tweak specifically.
That might be fine. There are a lot of things you can do without root
access. Perhaps not without shell access :) I can't help thinking that
some kind of sandbox which could be for staging new services or
testing upgrades would be the ideal place to allow people to gain
trust progressively - first by getting shell access and permissions to
configure one service, for example, and eventually, as they need and
earn it, root access.
A shell and limited sudo access might be a good place to start.
Wouldn't be able to fix everything but might be able to help in area's
were the current group isn't strong or able to fix some outage problems.