On Wednesday, August 12, 2020 11:19:00 AM CEST Iñaki Ucar wrote:
> 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.
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
_______________________________________________
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
