12:45 p.m.
I spent some time last week learning ansible and setting up the new
badges-backend01.stg. There's a daemon that runs there that reads in
a number of yaml files. Each one defines a badge and a set of rules
that must pass for the badge to be automatically awarded to a
contributor (based on fedmsg activity).
Up to now, I've been keeping all these badges in the ansible repo;
ansible copies them into /usr/share/badges on the managed node.
You can find the ones I have so far here:
http://infrastructure.fedoraproject.org/infra/ansible/roles/badges-backen...
I need to get them out of the ansible repo. There's going to be too
many of them, and we're going to be iterating on them and changing
them often. I was thinking of creating another git repo on lockbox at
/git/badges/ for this.
In the longrun though, we want contributors from every corner of the
community to contribute new badge ideas (come up with some artwork,
make their own yaml definition -- and make it real). We'll have a
process for debating and vetting new badges.
GitHub's pull request work flow could be a good fit here. It would
however set a new precedent for our degree of integration with gh.com.
Any thoughts?
12:58 p.m.
Hi!
I usually tend to create a separate WS for such things (and separate repo). This way you
can easily move it wherever you want (changing CNAME records only). Fully featuring the
ideas of SOA.
Anyway. Only my way to do it...
-of (mobile)
Am 17.06.2013 um 19:45 schrieb "Ralph Bean"
<rbean@redhat.com<mailto:rbean@redhat.com>>:
I spent some time last week learning ansible and setting up the new
badges-backend01.stg. There's a daemon that runs there that reads in
a number of yaml files. Each one defines a badge and a set of rules
that must pass for the badge to be automatically awarded to a
contributor (based on fedmsg activity).
Up to now, I've been keeping all these badges in the ansible repo;
ansible copies them into /usr/share/badges on the managed node.
You can find the ones I have so far here:
http://infrastructure.fedoraproject.org/infra/ansible/roles/badges-backen...
I need to get them out of the ansible repo. There's going to be too
many of them, and we're going to be iterating on them and changing
them often. I was thinking of creating another git repo on lockbox at
/git/badges/ for this.
In the longrun though, we want contributors from every corner of the
community to contribute new badge ideas (come up with some artwork,
make their own yaml definition -- and make it real). We'll have a
process for debating and vetting new badges.
GitHub's pull request work flow could be a good fit here. It would
however set a new precedent for our degree of integration with
gh.com<http://gh.com>.
Any thoughts?
_______________________________________________
infrastructure mailing list
infrastructure@lists.fedoraproject.org<mailto:infrastructure@lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
<inline.txt>
1:40 p.m.
On Mon, Jun 17, 2013 at 01:45:09PM -0400, Ralph Bean wrote:
I spent some time last week learning ansible and setting up the new
badges-backend01.stg. There's a daemon that runs there that reads in
a number of yaml files. Each one defines a badge and a set of rules
that must pass for the badge to be automatically awarded to a
contributor (based on fedmsg activity).
Up to now, I've been keeping all these badges in the ansible repo;
ansible copies them into /usr/share/badges on the managed node.
You can find the ones I have so far here:
http://infrastructure.fedoraproject.org/infra/ansible/roles/badges-backen...
I need to get them out of the ansible repo. There's going to be too
many of them, and we're going to be iterating on them and changing
them often. I was thinking of creating another git repo on lockbox at
/git/badges/ for this.
In the longrun though, we want contributors from every corner of the
community to contribute new badge ideas (come up with some artwork,
make their own yaml definition -- and make it real). We'll have a
process for debating and vetting new badges.
GitHub's pull request work flow could be a good fit here. It would
however set a new precedent for our degree of integration with gh.com.
Any thoughts?
I agree with the implied nervousness towards this degree of integration.
Repository-wise, I think we need a public repository so, although lockbox
can have public repos, something already doing public repos is probably
better (fedorahosted, for instance).
Workflow-wise, it sounds like comps.xml has similar requirements. That's
hosted at fedorahosted and changes are discussed o nthe mailing lists. So
it's possible to shoehorn that into our existing infrastructure. I bet that
both comps.xml and badges would be more efficient on github, though.
Unlike code where it's only the developers of the code that will be impacted
if github changes their policies or stability degrades, this would be
something that is used by people who are more end-users of the badge
application which is a slightly wider audience. We've changed that sort of
thing before, though -- translations for Fedora went from elvis.rh.com to
transifex.fp.o to transifex.net. So we could switch people to a different
platform if we had to in the future....
The repo would also be consumed by our services -- the badges application
would need to have some sort of access to the data stored there. I think,
for that, it might be better to use our own infrastructure as that leaves us
in control of the stability, etc.
Perhaps, as a minimum, we need to get the github-fedorahosted mirroring setup
if we want to host the workflow on github? That way we'd have a repo in our
control that we can have our services work against. And we'd be ready to
switch the canonical source of hte data if we needed to. (I'm open to also
saying no to github for this use but I don't want to stand in the way
either).
-Toshio
1:50 p.m.
On Mon, 17 Jun 2013 11:40:35 -0700
Toshio Kuratomi <a.badger(a)gmail.com> wrote:
On Mon, Jun 17, 2013 at 01:45:09PM -0400, Ralph Bean wrote:
> I spent some time last week learning ansible and setting up the new
> badges-backend01.stg. There's a daemon that runs there that reads
> in a number of yaml files. Each one defines a badge and a set of
> rules that must pass for the badge to be automatically awarded to a
> contributor (based on fedmsg activity).
>
> Up to now, I've been keeping all these badges in the ansible repo;
> ansible copies them into /usr/share/badges on the managed node.
>
> You can find the ones I have so far here:
>
http://infrastructure.fedoraproject.org/infra/ansible/roles/badges-backen...
>
> I need to get them out of the ansible repo. There's going to be too
> many of them, and we're going to be iterating on them and changing
> them often. I was thinking of creating another git repo on lockbox
> at /git/badges/ for this.
>
> In the longrun though, we want contributors from every corner of the
> community to contribute new badge ideas (come up with some artwork,
> make their own yaml definition -- and make it real). We'll have a
> process for debating and vetting new badges.
>
> GitHub's pull request work flow could be a good fit here. It would
> however set a new precedent for our degree of integration with
> gh.com. Any thoughts?
I agree with the implied nervousness towards this degree of
integration.
Repository-wise, I think we need a public repository so, although
lockbox can have public repos, something already doing public repos
is probably better (fedorahosted, for instance).
Workflow-wise, it sounds like comps.xml has similar requirements.
That's hosted at fedorahosted and changes are discussed o nthe
mailing lists. So it's possible to shoehorn that into our existing
infrastructure. I bet that both comps.xml and badges would be more
efficient on github, though.
The problem with both gh and hosted for comps or for this is that it
means those resources need to 'freeze' when we freeze. That's rotten,
imo, for comps alone - but if we needed to freeze and were counting on
gh being up right before a release? It would be painful to have that
dep hung up that way.
I think we cannot rely on external services and I'm not even enamored
of relying on fedorahosted b/c, ostensibly, it doesn't freeze.
-sv
7:49 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/17/2013 02:50 PM, seth vidal wrote:
On Mon, 17 Jun 2013 11:40:35 -0700 Toshio Kuratomi
<a.badger(a)gmail.com> wrote:
> On Mon, Jun 17, 2013 at 01:45:09PM -0400, Ralph Bean wrote:
>> I spent some time last week learning ansible and setting up the
>> new badges-backend01.stg. There's a daemon that runs there
>> that reads in a number of yaml files. Each one defines a badge
>> and a set of rules that must pass for the badge to be
>> automatically awarded to a contributor (based on fedmsg
>> activity).
>>
>> Up to now, I've been keeping all these badges in the ansible
>> repo; ansible copies them into /usr/share/badges on the managed
>> node.
>>
>> You can find the ones I have so far here:
>>
http://infrastructure.fedoraproject.org/infra/ansible/roles/badges-backen...
>>
>>
>>
I need to get them out of the ansible repo. There's going to be too
>> many of them, and we're going to be iterating on them
and
>> changing them often. I was thinking of creating another git
>> repo on lockbox at /git/badges/ for this.
>>
>> In the longrun though, we want contributors from every corner
>> of the community to contribute new badge ideas (come up with
>> some artwork, make their own yaml definition -- and make it
>> real). We'll have a process for debating and vetting new
>> badges.
>>
>> GitHub's pull request work flow could be a good fit here. It
>> would however set a new precedent for our degree of integration
>> with gh.com. Any thoughts?
>
> I agree with the implied nervousness towards this degree of
> integration.
>
> Repository-wise, I think we need a public repository so,
> although lockbox can have public repos, something already doing
> public repos is probably better (fedorahosted, for instance).
>
> Workflow-wise, it sounds like comps.xml has similar
> requirements. That's hosted at fedorahosted and changes are
> discussed o nthe mailing lists. So it's possible to shoehorn
> that into our existing infrastructure. I bet that both comps.xml
> and badges would be more efficient on github, though.
>
The problem with both gh and hosted for comps or for this is that
it means those resources need to 'freeze' when we freeze. That's
rotten, imo, for comps alone - but if we needed to freeze and were
counting on gh being up right before a release? It would be painful
to have that dep hung up that way.
I think we cannot rely on external services and I'm not even
enamored of relying on fedorahosted b/c, ostensibly, it doesn't
freeze.
It doesn't freeze, but thanks to git we *can* just lock it to a commit ID.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlHAV08ACgkQeiVVYja6o6MyjwCfaI5miePnEXgaSsonGH0DeOaV
TNkAnRUxnsOzKZoVnWjMPkksxwxIH8wg
=zE6Z
-----END PGP SIGNATURE-----
8:50 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, 18 Jun 2013 08:49:19 -0400
Stephen Gallagher <sgallagh(a)redhat.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/17/2013 02:50 PM, seth vidal wrote:
> On Mon, 17 Jun 2013 11:40:35 -0700 Toshio Kuratomi
> <a.badger(a)gmail.com> wrote:
>
>> On Mon, Jun 17, 2013 at 01:45:09PM -0400, Ralph Bean wrote:
>>> I spent some time last week learning ansible and setting up the
>>> new badges-backend01.stg. There's a daemon that runs there
>>> that reads in a number of yaml files. Each one defines a badge
>>> and a set of rules that must pass for the badge to be
>>> automatically awarded to a contributor (based on fedmsg
>>> activity).
>>>
>>> Up to now, I've been keeping all these badges in the ansible
>>> repo; ansible copies them into /usr/share/badges on the managed
>>> node.
>>>
>>> You can find the ones I have so far here:
>>>
http://infrastructure.fedoraproject.org/infra/ansible/roles/badges-backen...
>>>
>>>
>>>
I need to get them out of the ansible repo. There's going to be too
>>> many of them, and we're going to be iterating on them and
>>> changing them often. I was thinking of creating another git
>>> repo on lockbox at /git/badges/ for this.
>>>
>>> In the longrun though, we want contributors from every corner
>>> of the community to contribute new badge ideas (come up with
>>> some artwork, make their own yaml definition -- and make it
>>> real). We'll have a process for debating and vetting new
>>> badges.
>>>
>>> GitHub's pull request work flow could be a good fit here. It
>>> would however set a new precedent for our degree of integration
>>> with gh.com. Any thoughts?
>>
>> I agree with the implied nervousness towards this degree of
>> integration.
>>
>> Repository-wise, I think we need a public repository so,
>> although lockbox can have public repos, something already doing
>> public repos is probably better (fedorahosted, for instance).
>>
>> Workflow-wise, it sounds like comps.xml has similar
>> requirements. That's hosted at fedorahosted and changes are
>> discussed o nthe mailing lists. So it's possible to shoehorn
>> that into our existing infrastructure. I bet that both comps.xml
>> and badges would be more efficient on github, though.
>>
>
> The problem with both gh and hosted for comps or for this is that
> it means those resources need to 'freeze' when we freeze. That's
> rotten, imo, for comps alone - but if we needed to freeze and were
> counting on gh being up right before a release? It would be painful
> to have that dep hung up that way.
>
> I think we cannot rely on external services and I'm not even
> enamored of relying on fedorahosted b/c, ostensibly, it doesn't
> freeze.
>
It doesn't freeze, but thanks to git we *can* just lock it to a
commit ID.
Provided it is available. Part of the reason we freeze is so we don't
break it :)
- -sv
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iD8DBQFRwGWo1Aj3x2mIbMcRAsn1AJ99ww0muYpXYsWDKAPGuGrPqZRk3QCggRqB
yJFMwJeLYfLftwkmDWX4sD0=
=Lpri
-----END PGP SIGNATURE-----
1:47 p.m.
On Mon, 17 Jun 2013 13:45:09 -0400
Ralph Bean <rbean(a)redhat.com> wrote:
...snip...
GitHub's pull request work flow could be a good fit here. It
would
however set a new precedent for our degree of integration with gh.com.
Any thoughts?
Yeah, I could see github's flow being nice here for proposing new
badges, etc... but somehow it feels strange to me to directly depend on
them in this way.
So, I guess I'd say lets do a lockbox01 repo for now, and reevaluate
after freeze is over?
kevin
2:27 p.m.
On Mon, Jun 17, 2013 at 12:47:44PM -0600, Kevin Fenzi wrote:
Yeah, I could see github's flow being nice here for proposing
new
badges, etc... but somehow it feels strange to me to directly depend on
them in this way.
Ricky E had some good points in channel which I'll re-post here for
posterity:
re: using github for badges, I think it'd be neat if we could get to that
point (but like nirik said, probably something to talk about after the
freeze). I'm wondering if we couldn't either 1) Just have a cron pull
the badges files from github every few hours, or 2) Set up a tiny POST hook
listener from github and pull based on that.
In either of those cases, we have a local copy of the repo, since we're just
pulling from github
if github goes down, we still have a copy of it for use in infra.
So, I guess I'd say lets do a lockbox01 repo for now, and
reevaluate
after freeze is over?
Agreed. I've setup a lockbox01 repo for now.
11:28 a.m.
On 06/17/2013 03:27 PM, Ralph Bean wrote:
On Mon, Jun 17, 2013 at 12:47:44PM -0600, Kevin Fenzi wrote:
> Yeah, I could see github's flow being nice here for proposing new
> badges, etc... but somehow it feels strange to me to directly depend on
> them in this way.
Ricky E had some good points in channel which I'll re-post here for
posterity:
re: using github for badges, I think it'd be neat if we could get to that
point (but like nirik said, probably something to talk about after the
freeze). I'm wondering if we couldn't either 1) Just have a cron pull
the badges files from github every few hours, or 2) Set up a tiny POST hook
listener from github and pull based on that.
In either of those cases, we have a local copy of the repo, since we're just
pulling from github
if github goes down, we still have a copy of it for use in infra.
> So, I guess I'd say lets do a lockbox01 repo for now, and reevaluate
> after freeze is over?
Agreed. I've setup a lockbox01 repo for now.
_______________________________________________
infrastructure mailing list
infrastructure(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
My input is that if we make use of GitHub, there should be another means
of contributing that is at least as effective. I don't like the idea of
basing a Fedora structure on GitHub's structure.
-- oddshocks
11:33 a.m.
On Tue, 18 Jun 2013 12:28:45 -0400
David Gay <oddshocks(a)riseup.net> wrote:
My input is that if we make use of GitHub, there should be another
means of contributing that is at least as effective. I don't like the
idea of basing a Fedora structure on GitHub's structure.
Thinking about this... would it be possible to have a interface on the
badges web side that allowed submitting new badge ideas?
ie, fill in fields and needed info and it dumps out the rough code of
what is needed for that badge and if admins find it good, just add it?
Or even, something that uses datanommer's interface to create the exact
query that would be used to award the badge...
I don't know how complex that would end up being...
kevin
11:56 a.m.
On 06/18/2013 12:33 PM, Kevin Fenzi wrote:
On Tue, 18 Jun 2013 12:28:45 -0400
David Gay <oddshocks(a)riseup.net> wrote:
> My input is that if we make use of GitHub, there should be another
> means of contributing that is at least as effective. I don't like the
> idea of basing a Fedora structure on GitHub's structure.
Thinking about this... would it be possible to have a interface on the
badges web side that allowed submitting new badge ideas?
ie, fill in fields and needed info and it dumps out the rough code of
what is needed for that badge and if admins find it good, just add it?
Or even, something that uses datanommer's interface to create the exact
query that would be used to award the badge...
I don't know how complex that would end up being...
kevin
_______________________________________________
infrastructure mailing list
infrastructure(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/infrastructure
Actually, Threebean and I have discussed this. It is not only possible,
but what I plan to do. :) Threebean has made a lot of progress on the
yaml files for each badge, and I believe I can develop a form that would
generate a yaml file for the badge, so that it can be reviewed and
implemented easily.
-- David
3965
days inactive
3966
days old
infrastructure@lists.fedoraproject.org
10 comments
7 participants
participants (7)
-
David Gay -
Falk, Oliver -
Kevin Fenzi -
Ralph Bean -
Seth Vidal -
Stephen Gallagher -
Toshio Kuratomi