-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 18 Jun 2013 08:49:19 -0400 Stephen Gallagher <sgallagh@xxxxxxxxxx> 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@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. > > > > 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----- _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
