Re: [RFC] Build tag in RPM: from NVR to NVRB

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Dne 23. 06. 22 v 15:10 Miro Hrončok napsal(a):
On 23. 06. 22 14:24, Aleksandra Fedorova wrote:
3) If every Fedora packager can rebuild anything without a commit, what do we
do prevent accidental builds?
I think each rebuild should be treated as a new package, thus it would
require a new bodhi update, testing, and signing. Which means it will
be less likely to accidentally ship it.

But as I mentioned in the post, right now we'd like to propose the
refactoring, and not a change of the development workflow. Thus I
would initially restrict the rebuild possibility to the admin group
which handles mass-rebuilds and other admin tasks. Then I would
gradually open it up case by case, each case through a separate
conversation.

Saying that, probably the first case, which I would consider is: is
there a problem of an accidental rebuild of a merged code for Fedora
Rawhide? What would be the reasons for us to_not_  allow it?


A specific example is this workflow:

Imagine 200 packages need to be rebuilt with boost 1.99.

 1) I build boost 1.99 in a side tag

 2) I commit a bump to 200 packages

 3) I submit a side tag build for 200 packages

 4) I repeat (3) until it seems futile


This solves the dependency order issues quite well. I also don't need to think about that much and scripting it is trivial. If the build previously succeeded, it won't do anything. If it failed, it will try again.


Isn't similar mechanism used by MBS?

Anyway, this is quite common mechanism for mass rebuilds of all kinds. Just hammer the builds.


Vít



I realize this isn't a very clever workflow. In fact, that isn't my exact workflow. Really, in (4) I exclude the packages that already rebuilt successfully. But I don't need to be that careful when checking. Is my list of finished builds slightly out of date? No problem. Are some builds still running and I try to submit them again? No problem. Nothing happens.

With the proposed build ID think, every workflow like this would either need to be extremely more robust, or we would end up with 20 useless concurrent libreoffice builds very soon.




Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/packaging@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux