Re: Fedora/EPEL GitHub Badges

2017-12-15 Thread Mikolaj Izdebski 
On 12/15/2017 04:56 PM, Avram Lubkin wrote:
> Anyone have a better way to generate dynamic badges? Should badge
> generation be a part of the Fedora infrastructure?
> 
> For an alternative approach, would it be better to show the latest stable
> version in the latest Fedora. Something like this, but dynamic:
> 
> https://img.shields.io/badge/Fedora_27-1.0.7-lightgrey.svg

Dynamic version of this badge:

https://img.shields.io/badge/dynamic/json.svg?uri=https://apps.fedoraproject.org/mdapi/f27/pkg/python3-enlighten=$.version=Fedora+27


Some apps already implement their own badges, like Copr, or Koschei,
which tells you whether your package builds in Fedora or not:

https://apps.fedoraproject.org/koschei/badge/f27/python-enlighten.svg


-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora/EPEL GitHub Badges

2017-12-15 Thread Christopher 
On Fri, Dec 15, 2017 at 11:04 AM Avram Lubkin  wrote:

> Badges are pretty popular in GitHub though there don't seem to be many
> that provide information on distros that have packages for a project. This
> would be very useful because, at least for me, the first thing I do when I
> want to try a new project is see if a package is available for the distro
> I'm working with, usually Fedora or CentOS.
>
> I searched around, but couldn't find anything that existed already (please
> let me know if I missed it), so I made static badges for one of my
> projects, python-enlighten[1], but this requires remembering to update them
> when a new version of Fedora comes out.
>
> I tried to create a dynamic one, but it isn't exactly what I want. It's
> based on if a branch exists and starts with 'f' or 'e', not if there is a
> stable package for that branch. Also, the branch names are not consistent
> between EPEL 6 and EPEL 7, so it would be better to just get the number.
> Might as well just use the number for Fedora too for consistency.
>
> Static Fedora:
> https://img.shields.io/badge/Fedora-26,_27-lightgrey.svg
>
> Static EPEL:
> https://img.shields.io/badge/EPEL-6,_7-lightgrey.svg
>
>
> Dynamic Fedora:
>
> https://img.shields.io/badge/dynamic/json.svg?uri=https://pdc.fedoraproject.org/rest_api/v1/component-branches/?global_component=python-enlighten;fields=name;active=true;type=rpm=$.results[?(@.name.startsWith(
> "f"))].name=Fedora
>
> Dynamic EPEL:
>
> https://img.shields.io/badge/dynamic/json.svg?uri=https://pdc.fedoraproject.org/rest_api/v1/component-branches/?global_component=python-enlighten;fields=name;active=true;type=rpm=$.results[?(@.name.startsWith(
> "e"))].name=EPEL
>
> I'm also not sure the best place to point them to. shields.io does let
> you set a target for both the left and the right sides, but I just set the
> target within readme.rst and pointed both badges to the Bodhi updates page
> for the package.
>
> Anyone have a better way to generate dynamic badges? Should badge
> generation be a part of the Fedora infrastructure?
>
> For an alternative approach, would it be better to show the latest stable
> version in the latest Fedora. Something like this, but dynamic:
>
> https://img.shields.io/badge/Fedora_27-1.0.7-lightgrey.svg
>
>
> [1] https://github.com/Rockhopper-Technologies/enlighten
>
>
I would be very interested in this if it were dynamic. My preference would
be for a dynamic badge service which shows the latest stable `nevr` for
either a specific Fedora/EPEL, with the option to use keywords like
"latest" and "rawhide" in addition to specific releases like "F27".
Upstream users could choose to add a Fedora 26 badge, a Fedora 27 badge,
and a Fedora Rawhide badge to advertise the available versions in each of
those, or they could just advertise the latest stable with a badge for the
latest released Fedora version.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora/EPEL GitHub Badges

2017-12-15 Thread Matthew Miller 
On Fri, Dec 15, 2017 at 10:56:10AM -0500, Avram Lubkin wrote:
> I'm also not sure the best place to point them to. shields.io does let you
> set a target for both the left and the right sides, but I just set the
> target within readme.rst and pointed both badges to the Bodhi updates page
> for the package.
> 
> Anyone have a better way to generate dynamic badges? Should badge
> generation be a part of the Fedora infrastructure?

I'm for us serving them. Full transparency: shields.io says "no
tracking" but that doesn't mean they don't do _counting_. I also have
no interest in tracking, but a lot of interest in counting. (How many
distinct projects use this? How many people look at them?
Super-interesting!)

It seems like they don't really need to be dynamic and _could_ just be
static content we serve from https://getfedora.org/static/, right? That
way, we wouldn't need to stand up a new service or anything ongoing
except an update when we put out a new release.

That wouldn't allow per-project linking though. If you are doing
something dynamic, I'd suggest https://src.fedoraproject.org/ as a
target, and then include a README.md with instructions on how to dnf
install your package.


Anyway: can you file an infrastructure ticket for this? I doubt it will
be high priority, but on the other hand, it seems like something an
infrastructure apprentice could tackle.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora/EPEL GitHub Badges

2017-12-15 Thread Avram Lubkin 
Badges are pretty popular in GitHub though there don't seem to be many that
provide information on distros that have packages for a project. This would
be very useful because, at least for me, the first thing I do when I want
to try a new project is see if a package is available for the distro I'm
working with, usually Fedora or CentOS.

I searched around, but couldn't find anything that existed already (please
let me know if I missed it), so I made static badges for one of my
projects, python-enlighten[1], but this requires remembering to update them
when a new version of Fedora comes out.

I tried to create a dynamic one, but it isn't exactly what I want. It's
based on if a branch exists and starts with 'f' or 'e', not if there is a
stable package for that branch. Also, the branch names are not consistent
between EPEL 6 and EPEL 7, so it would be better to just get the number.
Might as well just use the number for Fedora too for consistency.

Static Fedora:
https://img.shields.io/badge/Fedora-26,_27-lightgrey.svg

Static EPEL:
https://img.shields.io/badge/EPEL-6,_7-lightgrey.svg


Dynamic Fedora:
https://img.shields.io/badge/dynamic/json.svg?uri=https://pdc.fedoraproject.org/rest_api/v1/component-branches/?global_component=python-enlighten;fields=name;active=true;type=rpm=$.results[?(@.name.startsWith(
"f"))].name=Fedora

Dynamic EPEL:
https://img.shields.io/badge/dynamic/json.svg?uri=https://pdc.fedoraproject.org/rest_api/v1/component-branches/?global_component=python-enlighten;fields=name;active=true;type=rpm=$.results[?(@.name.startsWith(
"e"))].name=EPEL

I'm also not sure the best place to point them to. shields.io does let you
set a target for both the left and the right sides, but I just set the
target within readme.rst and pointed both badges to the Bodhi updates page
for the package.

Anyone have a better way to generate dynamic badges? Should badge
generation be a part of the Fedora infrastructure?

For an alternative approach, would it be better to show the latest stable
version in the latest Fedora. Something like this, but dynamic:

https://img.shields.io/badge/Fedora_27-1.0.7-lightgrey.svg


[1] https://github.com/Rockhopper-Technologies/enlighten
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org