On Sat, Jun 8, 2019 at 9:15 AM Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > > On Sat, Jun 8, 2019 at 2:10 PM Igor Gnatenko > <ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote: > > > > On Sat, Jun 8, 2019 at 12:54 PM Nicolas Mailhot via devel > > <devel@xxxxxxxxxxxxxxxxxxxxxxx> 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. -- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx