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
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.
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.