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!
- 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.
- The /status page has a new "Starting" tab [3] which shows all the binary builds where the worker process is already started, but appropriate builder VM is not yet assigned to it (issue/1429).
- Group avatars (user-icons assigned to an e-mail) were fixed to really use the groups' emails, not the administrators' (issue/1419).
- 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).
- 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.
- 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.
Related copr client Fedora/EPEL updates:
F32 - https://bodhi.fedoraproject.org/updates/FEDORA-2020-ce81a9539d F31 - https://bodhi.fedoraproject.org/updates/FEDORA-2020-76bfc383c3 EPEL8 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-4c313586d8 EPEL7 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-6a77e31d06 EPEL6 - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-78e089fe70
Should you have any related issues, please report them to us as usual.
[1] https://fedoraproject.org/wiki/Playground [2] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/... [3] https://copr.fedorainfracloud.org/status/starting/
Happy building! Copr Team
On 12. 08. 20 10:29, Pavel Raiskup 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!
Assuming the arrows up and down near the copr name are for karma, I find the UI for this is a tad confusing. I've seen it before reading your announcement and had no idea what it is.
(This is true especially before refreshing the browser cache, it gets a bit better after.)
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.
This is really interesting feature for some of the projects. Can this be used in official Fedora specfiles or does it need a guideline?
- 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).
Thanks, I'll test it instead of my "parse-HTML-by-regex" mad script :)
On Wednesday, August 12, 2020 10:51:56 AM CEST Miro Hrončok wrote:
On 12. 08. 20 10:29, Pavel Raiskup wrote:
- Project karma implemented; Logged-in users can give thumbs-up/thumbs-down to the existing copr projects. [snip] This is just
Assuming the arrows up and down near the copr name are for karma, I find the UI for this is a tad confusing. I've seen it before reading your announcement and had no idea what it is.
(This is true especially before refreshing the browser cache, it gets a bit better after.)
Bleh, I faced the cache issue as well. Let's take a look if we can do something about it...
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.
This is really interesting feature for some of the projects. Can this be used in official Fedora specfiles
It is meant to be no-op as long as build system doesn't define it. So at least technically there's no problem.
or does it need a guideline?
I don't think it is forbidden by guidelines (we can not use macros for other distributions, but that is a different topic). Dunno if we need to have an explicit ACK for this. Ideas?
Pavel
On 12. 08. 20 11:20, Pavel Raiskup wrote:
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.
This is really interesting feature for some of the projects. Can this be used in official Fedora specfiles
It is meant to be no-op as long as build system doesn't define it. So at least technically there's no problem.
or does it need a guideline?
I don't think it is forbidden by guidelines (we can not use macros for other distributions, but that is a different topic). Dunno if we need to have an explicit ACK for this. Ideas?
Most likely we don't. I was just trying to think ahead.
On Wed, 12 Aug 2020 at 10:29, Pavel Raiskup praiskup@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. :)
On 12. 08. 20 11:19, Iñaki Ucar wrote:
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?
It's actually <pkg>-<version>-<release>.fcXX.copr<id> in the example above. An that sorts higher.
$ rpmdev-vercmp e:v-r.fc34.copr1234567 e:v-r.fc34 e:v-r.fc34.copr1234567 > e:v-r.fc34
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@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
On Wed, 12 Aug 2020 at 12:32, Pavel Raiskup praiskup@redhat.com wrote:
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@redhat.com wrote:
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.
Oh, yeap, right, I pasted the dist tag in the wrong place.
- 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.
I think both options are fine (background source builds with higher or lower priority), as I said in prior discussions, provided that non-background normal builds get prioritized over background normal builds. :)
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}.
lso, %{buildtag} is such generic name which on one hand does not say anything about its purposed while there is chance it might collide with something. So why you have not chosen %{buildid} or even %{coprbuildid}.
Vít
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
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 praiskup@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-leave@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.o...
copr-devel@lists.fedorahosted.org
-
Iñaki Ucar -
Jakub Kadlcik -
Miro Hrončok -
Pavel Raiskup -
Vít Ondruch