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 wedo 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 futileThis 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
