On Sat, Jun 8, 2019 at 3:21 PM 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. That means we get huge bottleneck, why don't we just fix this problem by automated rebuilding of packages like koschei does, but for all side-tags in real mode (not scratch). > Fabio > > > > Regards, > > > > > > -- > > > Nicolas Mailhot > > > _______________________________________________ > > > 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 > > _______________________________________________ > > 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 > _______________________________________________ > 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 _______________________________________________ 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
