On 08. 06. 19 19:20, Zbigniew Jędrzejewski-Szmek wrote:
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@fedoraproject.org> 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.
If this would block the merge, we would be stuck in an endless loop with big side tags (read Python). While I would be rebuilding the 200 merge conflicts, I would already get 100 more. Once libreoffice or clang conflicts, I would get 500. It's easier to just merge and than rebuild the remaining packages once more.
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.
Last time (Python 3.7) I've asked maintainers not to rebuild Python packages in rawhide unless really necessary. Some probably even read it, but mostly it was just ignored. This time, I plan to CC everybody who's involved.