On Mon, 17 Jun 2013 11:40:35 -0700 Toshio Kuratomi <a.badger@xxxxxxxxx> 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-backend/files/badges/ > > > > 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
