On Wednesday, August 12, 2020 11:19:00 AM CEST IƱaki Ucar wrote:
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.
Yes, we looked at several popular sites and the voting UI, and picked one
of the existing variants.
> - 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?
No need to do batch-updates.
$ rpmdev-vercmp 1-1.fc32.copr1234 1-1.fc32
1-1.fc32.copr1234 > 1-1.fc32
But note I proposed to use %buildtag after %dist, not vice versa. Moving
%buildtag before %dist would mean that we loose the benefit of dist
tag -- when both fcNN and fcNN-1 builds exist in multiple repositories
(notable example is 'fedora' and 'updates') fcNN is the preferred variant
for installation.
> - 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.
No problems to admit a change of mind ;-) that happens all the time.
Mainly I was afraid that source background builds will eat too much of the
frontend storage. But there don't seem to be that huge performance
problems, and that worry was probably a bit over-pessimistic.
Also, source builds are not yet visible in statistics, so if there's any
problem with source builds - it isn't anyhow obvious (Dominik is working
on the fix in issue 295).
Pavel