Where to keep the badges repo?

Toshio Kuratomi a.badger at gmail.com
Mon Jun 17 18:40:35 UTC 2013


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20130617/e74c8583/attachment.sig>


More information about the infrastructure mailing list