On Wed, Dec 16, 2020 at 3:34 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > On Wed, Dec 16, 2020 at 07:15:21PM +0000, Jonathan Wakely wrote: > > On 15/12/20 23:46 +0100, Miro Hrončok wrote: > > > On 12/15/20 11:29 PM, Miroslav Suchý wrote: > > > > I am looking for challenges for upcoming year - what I and my team should enhance. I have some ideas, but I want to hear > > > > yours. > > > > > > Thanks for doing this! > > > > > > > What you - as Fedora packager - find most time consuming on packaging? > > > > > > Coordination and communication ;) > > > > > > > Where you will welcome more simplicity or automation? > > > > > > In testing an impact of a change. E.g. a simple "upgrade to newer > > > version" change might be a problem if it breaks other packages. I > > > usually spin up a copr repo and try to rebuild every dependent package > > > > ^ This. > > > > The individual steps of doing a single package are insignificant > > compared to the days or WEEKS it takes for a systemwide change that > > requires rebuilding hundreds of dependencies. I know not many of us > > actually have this problem, but for those who do, it's very, very time > > consuming. > > > > Since we're apparently not allowed to use a side tag to do a test > > rebuild for this kind of thing, I end up doing it locally on my own > > machines. Copr is another option, but I don't think it would be any > > quicker or simpler. > > You actually can use a side tag, but it's not very streamlined. > 1. make side-tag > 2. push your changes to a whatever branch on the package that you are > changing. > 3. build package from that branch into the sidetag > 4. scratch build all the dependent packages in the sidetag and they will > use the changed package. Get them all working. > 5. merge your branch back on the package, bump release again > 5. actually bump and officially rebuild all the packages in the side tag > 6. merge sidetag > 7. ask releng to delete the branch you made (or not if you don't care) > > But I agree thats not great. ;( > > > What I'd really like would be a "test mass rebuild" process, where a > > prospective package is uploaded and everything that depends on it is > > automatically rebuilt (ideally after creating the dependency graph so > > each individual package doesn't get rebuilt until its dependencies are > > finished building). > > > > Creating the dependency graph by hand is fairly tedious, but maybe I'm > > missing an automated way. The point of creating that graph is to avoid > > wasting time and power doing and redoing builds that will fail until > > something else has been built (which is the problem with mock's > > --chain command, if I understand correctly). > > > > Once I have that graph, I use Make to control the process, because it > > handles the dependency graph, as well as parallelism, and not > > rebuilding things unnecessarily. > > Yeah, all this ^ > So I've written tools for doing this, and Igor has written tools for doing this, but it seems like people think that this is "impossible" and so the effort goes nowhere despite several PoCs. If we're interested in this again for real this time, I could try to dig out my old code for it, but we might be better off just pulling out Koschei's code and turning it into something that Koji's chain-build command and Mock's --chain option use to sort through package sets and build them correctly. > > > in it. However, there are time consuming challenges with this: > > > > > > 1) False failures. Sometimes, the copr build fails for random reason > > > (Koji repo is not available, etc.). I need to read the logs and figure > > > it out, resubmit the build. > > > > > > 2) Unrelated failures. Many packages FTBFS for unrelated reasons. I need > > > to spin up another (control) copr and rebuild all failures there as well > > > to make sure it's indeed unrelated. > > > > Yes, that's a real pain. Can we just add everything to Koschei instead > > of having it opt-in? > > Thats worth considering in the new year. I would like that. :) > Yes please! -- 真実はいつも一つ！/ 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
