-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/18/2012 10:00 AM, Robert Middleswarth wrote:
> I am on the opposite side of this issue. Maybe I have been
> attacked by 1 to many bot's or been a manager when someone I
> know and trusted stole from the company. I need trust to be
> earned so I +1 on whitelist. With that said I think getting on
> the whitelist should be pretty easy. We are not talking about
> blocking there commit's we are talking about should the
> automated system run test/code against there patch. I am still
> learning Jekins when using a whitelist is there a way to flag
> commits for users not in the list? I wonder if there is some way
> to create a list that someone can go though and whitelist the
> user or reject the user for commits not in the whitelist?
Perhaps this is just an example of my limited dimensional thinking
around SCMs. I tend to think by default, "There should be a well
described pathway to committer status. Once achieved, you can commit,
that's it." Old school thinking. :) However, I get that more complex
infrastructure may have other considerations. In Fedora, for example,
things went from a wide open SCM where anyone could commit to any
package, to a more segregated system with the idea of an over-packager
status that one can attain, which provides the now rare ability to
commit to any package. Similarly here, oVirt may say, "Fine, you can
commit code to the main git repo, but you have to earn Level Q to be
able to kick-off automated testing."
I just want us to be careful how we contextualize, too. While trust is
one reason we don't give root to everyone, another reason is we want
to be sure they know how to be safe and sane in that position. People
may need e.g. training or testing that they are not going to
accidentally do something that makes Jenkins fall down and cry.
- - 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/
iD8DBQFQByDf2ZIOBq0ODEERAp3OAJ9JTiBDnhgW9zRbwD9T17S55FAbeQCg4XaD
C1qHTKUnqo6kgixjOUbQ4A4=
=0tIA
-----END PGP SIGNATURE-----