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@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.
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.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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
