On Sat, Jun 8, 2019 at 9:15 AM Fabio Valentini <decathorpe(a)gmail.com> wrote:
On Sat, Jun 8, 2019 at 2:10 PM Igor Gnatenko
<ignatenkobrain(a)fedoraproject.org> wrote:
>
> On Sat, Jun 8, 2019 at 12:54 PM Nicolas Mailhot via devel
> <devel(a)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.
--
真実はいつも一つ!/ Always, there's only one truth!