On Wed, 12 Aug 2020 at 10:29, Pavel Raiskup <prais...@redhat.com> wrote:
>
> Hello.
>
> On Aug 12 2020, a new Copr release landed production. Here is the list
> of visible changes:
>
> - 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!
I suppose that the UI looks for some resemblance to StackOverflow's
vote counter. SO's counter is more prominent in the first place
(larger arrows and number), but I don't even think that's a good UI.
We simply got accustomed to it because we know what it is.
> - 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}
>
> It could be useful as good-enough alternative for the Release
> auto-bumping proposal. See the fedora devel discussion [2] for more
> info. This is not any kind of encouragement to use it. We added it
> there to easy testing your ideas about the automatic filling of the
> Release tag.
Nice one! I understand that having a mix of builds with and without
this tag isn't an issue, right? I.e., would
<pkg>-<version>-<release>.copr<id>.fcXX be picked as an update of
<pkg>-<version>-<release>.fcXX? Or do we need to rebuild all with the
new tag and remove the old ones?
> - Command-line interface for the project package listing was significantly
> optimized, and should now be faster than the web-UI on large projects
> (issue/757).
Many thanks for this!
> - All the background jobs have now a lower priority than normal jobs.
> Previously, background source builds were still prioritized over normal
> builds. This should be the last step towards a fair build scheduler.
Change of mind? My understanding from the last time we discussed this
was that source builds needed to be prioritized no matter what.
> - Support for a new command 'copr-cli list-builds <project>' was added.
> It lists each build on a separate line, as a tab-separated list of
> <BUILD_ID> <PACKAGE_NAME> <BUILD_STATUS> items.
Just great! I'll try this instead of my "download a several-dozen-MB
HTML of builds, parse the table to get a dataframe and then regex the
columns" mad script. :)
--
Iñaki Úcar
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.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.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
