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. 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
Attachment:
pgpjvRnVU_lfb.pgp
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
