On Mon, 13 Apr 2020 at 14:48, Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Mon, Apr 13, 2020 at 5:15 AM Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > > > > On Mon, Apr 13, 2020 at 10:55 AM Dan Čermák > > <dan.cermak@xxxxxxxxxxxxxxxxxxx> wrote: > > > > > > Hi list, > > > > > > my question is pretty much $subject: Why doesn't Koschei kick of > > > real builds off packages on dependency changes? From my naive POV that > > > looks like the missing piece to give us the "OBS-experience". Having > > > that at least in Rawhide sounds like a good thing to me. > > > > It *might* be a good idea to help deal with rebuilds, but I see some > > problems with that. > > > > - koschei would need to add "rebuilt by koschei" commits to dist-git > > for this (OBS doesn't have a real VCS, so it's not a problem there) > > - those changes would add a lot of churn to .spec files, possibly > > angering a lot of packagers, and would also create possible conflicts > > between local changes and koschei builds > > - the builds add a lot of load to koji already (although at lower > > priority), which will probably be a problem when there's reduced > > capacity (e.g. the upcoming datacenter move) > > > > I think the fundamental premise here is that rebuilds this way > requires commits into Dist-Git. Assuming we have tooling for it, commits is not the only option. The other option might be tags. You don't create a new (potentially empty) commit, but instead, you create a new tag from koschei environment and if you succeed, you build that tag. That tag can also automatically populate changelog with the reason for rebuild. But then I think it would be good to have some name separation of the user tags vs. the koschei tags and technical details of this need to be figured out, i.e. it would require more discussion and brainstorming to determine if the separation is technically possible and how to do it. Both, the commit and the tag approach try to maintain dist-git as the single source of truth [1] to provide basic package information such as name-version-release, which is beneficial for local build reproducibility, it makes the result easier to calculate and predict, and it also makes services less intertwined. [1] https://en.wikipedia.org/wiki/Single_source_of_truth > With what Pierre-Yves and his group > released last week for testing[1], that may no longer be an issue. > > [1]: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/LWE4URIRWVTEZKXKP7QOK5JXFNVJRUNW/ > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
