On Sat, Jun 8, 2019 at 9:15 AM Fabio Valentini decathorpe@gmail.com wrote:
On Sat, Jun 8, 2019 at 2:10 PM Igor Gnatenko ignatenkobrain@fedoraproject.org wrote:
On Sat, Jun 8, 2019 at 12:54 PM Nicolas Mailhot via devel devel@lists.fedoraproject.org wrote:
Le samedi 08 juin 2019 à 11:23 +0200, Igor Gnatenko a écrit :
Hi,
Imagine situation that somebody is working on KDE rebase and me on libgit2 rebase. Both involve rebuilding/updating some package, let's say kf5-ktexteditor.
We both work in different side tags, in KDE rebase kf5-ktexteditor gets updated to a new version. In libgit2 rebase, old version gets rebuilt.
[…]
Do you think that scales?
But, what is different here from the Fedora circles / Fedora modules / etc endeavours? Isn’t the root problem synchronizing common code paths, because free software means pervasive code reuse, apps ends up being deployed together, and un-sharing generates collisions / API incompatibilities / behaviour incompatibilities / config file incompatibilities / un-adressed security issues?
What makes it possible in modules but not in side tags?
I never said that it is better / possible in modules. I just wanted to point out that expecting that people will do double, triple, … work in side tags is not something what I would like to see (see thread about libgit 0.28.x update). Also rawhide gating just makes this problem even worse.
Would it be possible to block builds of packages for certain target tags? Like a "mutex for packages"?
I'm thinking about specifying a list of packages at side-tag creation time, and then builds of these packages targeting any other tag could be blocked by koji, until the side "blocking" tag is merged back.
As far as I know, the best we could do is block packages from being built by other people (ACLs), but not block building in other tags.