> Project karma implemented; Logged-in users can give > thumbs-up/thumbs-down to the existing copr projects. This is just > another way to give feedback about a particular Copr project quality. > This is merely subjective. We do not give you guidance what "thumbs > up/down" means. When it is good for you - for whatever reason - give it > thumbs up. It may be just feedback for the maintainer or other users. > Or we may automatically select and group high-quality projects in the > future - and e.g. revive the idea of the Playground [1]. The options > are open. We would like to hear your feedback about this feature!
For anyone interested, I wrote a blog post about this feature http://frostyx.cz/posts/upvoting-projects-in-copr Jakub On Wed, Aug 12, 2020 at 3:38 PM Pavel Raiskup <prais...@redhat.com> wrote: > > On Wednesday, August 12, 2020 2:29:25 PM CEST Vít Ondruch wrote: > > Dne 12. 08. 20 v 10:29 Pavel Raiskup napsal(a): > > > - Copr newly provides a build-time macro %buildtag. Its format is > > > `.copr<BUILD_ID>` and is useable for auto-incrementing the package's NVR > > > in subsequent builds. It may be used in spec file like: > > > > > > Release: 1%{?dist}%{?buildtag} > > > > Not bad, but I think we don't want to promote new (and more over Copr > > specific) macro in Fedora. IHO, it would be much better if Copr modified > > the %{dist} macro appending the %{buildtag}. > > It's good idea, but not as trivial as the additional tag. You need knobs > turning this on/off, etc. Patches towards this are welcome I think, but > it will not be cheap (and it will collide with e.g. %forgemeta and > others). > > This isn't really a promoting of something, but mostly R&D && RFC. As a > potential _compromise_ solving the auto-bumping problem cheaply. Yeah, on > one-hand it is awesome to see how much energy our community has to to > solve the problem, but OTOH it really hurts, ... that many man-hours on > such trivial thing ... > > > lso, %{buildtag} is such generic name which on one hand does not say > > anything about its purposed > > Do you have ideas how to change this? > > > while there is chance it might collide with something. > > Yes. Unlikely, but yes. Ideas how to prevent this? > > > So why you have not chosen %{buildid} or even %{coprbuildid}. > > Because we didn't want to create copr-only solution. It's R&D, but if > successful, we can just use the tag as is elsewhere.. > > Pavel > > > _______________________________________________ > copr-devel mailing list -- copr-devel@lists.fedorahosted.org > To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org _______________________________________________ copr-devel mailing list -- copr-devel@lists.fedorahosted.org To unsubscribe send an email to copr-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/copr-devel@lists.fedorahosted.org
