On Sat, Jun 08, 2019 at 10:29:29AM -0400, Stephen John Smoogen wrote: > On Sat, Jun 8, 2019 at 6:12 AM Igor Gnatenko < > ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote: > > > 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. > > > > Once any of us finished with side tag, we merge it. Let's say that was > > KDE rebase. That means, new kf5-ktexteditor is merged into the rawhide > > which is built against old libgit2. Then I finish with libgit2 things > > and we merge it into the rawhide.. That means it just downgrades > > kf5-ktexteditor version because koji looks at the build time and not > > the NVR. Is that true? If yes, that seems to be the wrong thing to do. Instead, koji should say "not merging a-nn.rpm, because a-nn.rpm is already in the tag", or "... a-nn+1.rpm is already in the tag". Ideally, this would cause the whole merge to be rejected, and you can bump and rebuild the offending packages, and try to merge again later. > And even if it did, that would mean I have to manually go and > rebuild all packages which are handled in multiple side tags. Yes. But I think that'd be OK. This isn't *that* much work, and at least there'd be a clear result and a precise list of packages that need to be rebuilt. That's much better than a partial merge that breaks the next compose. > > Do you think that scales? > > > So I believe at one point we only allowed one side tag at a time, but > people complained that most of the time we were wasting packagers time > waiting for someone else to get stuff done. There was an idea about trying > to solve conflicts but that was seen as too much time to solve and too much > bureaucracy to live with. Instead we assumed that these would happen and > that packagers would work things out between themselves. > > So no it doesn’t scale. The various solutions to make it scale are not > written and will not be written in any near time as they will need some > sort of project, some amount of resources added and a backlog of more > critical work done first. Until then packagers need to realize that there > are going to be build conflicts every now and then and factor in that they > will have to work out between themselves how to solve them. Yeah, I don't think any technical solution is worth the trouble here. But we can coordinate, e.g. by announcing on fedora-devel. Zbyszek _______________________________________________ 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
