jenkins slaves

[Karsten 'quaid' Wade]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/12/2012 02:44 AM, Dan Kenigsberg wrote:
> On Wed, Jul 11, 2012 at 02:45:44PM -0400, Douglas Landgraf wrote:
>> Hi Karsten,
>> 
>> On 07/11/2012 12:18 PM, Karsten 'quaid' Wade wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>> 
>>> On 07/11/2012 10:08 AM, Douglas Landgraf wrote:
>>>> Hi Karsten,
>>>> 
>>>> On 07/11/2012 10:26 AM, Karsten 'quaid' Wade wrote:
>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>> 
>>>>> On 07/10/2012 10:41 PM, Douglas Landgraf wrote:
>>>>>> Hi Eyal,
>>>>>> 
>>>>>> On 07/10/2012 02:53 AM, Eyal Edri wrote:
>>>>>>> Hi Douglas,
>>>>>>> 
>>>>>>> If any dependency is missing you can always send an
>>>>>>> email to infra at ovirt.org and request to install it.
>>>>>> ok
>>>>>>> As for getting access to Jenkins slaves in ovirt ->
>>>>>>> that requires being a member of the infra team and
>>>>>>> approval of its memebers/trust seeds.
>>>>>>> 
>>>>>>> If you feel you want to contribute to the oVirt infra
>>>>>>> team, please send a request to infra at ovirt.org with
>>>>>>> some background (team, project, redhat exp,etc...).
>>>>>> hum, could you please provide a detailed example?
>>>>> Douglas, sorry, you happened to arrive just as we are more 
>>>>> formally creating the Infra team, which means we are just 
>>>>> figuring out how to give out access, and so forth. Your
>>>>> question is a good one, we need to get that up on our wiki
>>>>> page so it's clear what we mean by contributing to get
>>>>> involved.
>>>> Thanks for the feedback. If I could suggest a possible
>>>> evaluation for cases like mine (which require shell access):
>>>> 
>>>> * This person contain contributions in the upstream project?
>>>> (git log, wiki, QA, documentation, etc. Could help to
>>>> determine) * The upstream maintainer of project [agree/trust]
>>>> with that? (need to contact maintainer)
>>> Agreed those are valuable. Question is, would that same
>>> criteria help get me commit access to ovirt-engine?
>> I am not the right person to answer that question but from my
>> point of view should apply to the same/similar criteria. However,
>> I see your point of view. :-) Upstream maintainers (ovirt-engine,
>> vdsm) could help to resolve this puzzle.
> 
> I'm not sure I understand the puzzle. Technically speaking, a host
> administer can do everything he wants. We *trust* him not do use
> his powers unecessarily.
> 
> Preferably, there should be various levels of permissions - being
> able to setup Jenkins slaves should not mean automatically being
> able to `git rm` our repo.
> 
> Since I've known Douglas for a year or so now, I trust him to
> never abuse his admin rights. I'm looking forward to see him in the
> infra team, being able to quickly fix infrastructural problems in
> our testing framework.

Any puzzle here is merely a matter of timing. We just happen to be
forming the initial maintainers of the Infra team project. Those
maintainers need to figure out how to add other maintainers.

I think the considerations Douglas suggested are good ones to consider
in accepting a new maintainer, but I don't think they are the only
ones. Just as you would expect me to submit patches to e.g.
ovirt-engine before you would give me more commit/control access,
we're creating the same kind of thing for the Infra team. That means
using Puppet, configurations stored in Gerrit, distributed Jenkins
admins, and so forth - ways for people to get things done.

Getting things done is at the core of merit-based governance. At the
moment, the only way to get things done directly is to run a set of
Jenkins slaves, or be given ssh+sudo to one of the existing production
hosts. But we can look at giving out limited ssh access, if that helps
people like Douglas start getting things done in Infra so he can get
the merit with the existing maintainers.

- - Karsten
- -- 
Karsten 'quaid' Wade, Sr. Analyst - Community Growth
http://TheOpenSourceWay.org  .^\  http://community.redhat.com
@quaid (identi.ca/twitter/IRC)  \v'  gpg: AD0E0C41


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFP/u9u2ZIOBq0ODEERAphIAKDInY5NuabMOztGFhzlhy3f92QD/QCgwd6M
8VtMlefP4wPgVahkVyZ+++w=
=+L2n
-----END PGP SIGNATURE-----