On Wed, 12 Aug 2020 at 10:29, Pavel Raiskup <praiskup(a)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