Where to keep the badges repo?
Stephen Gallagher
sgallagh at redhat.com
Tue Jun 18 12:49:19 UTC 2013
-----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 at 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-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.
-----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-----
More information about the infrastructure
mailing list