On Tue, May 19, 2020 at 8:37 AM Miro Hrončok <mhron...@redhat.com> wrote:
> On 19. 05. 20 15:19, Richard Shaw wrote: > > Ask upstream to always test with develop version of Python, I believe > > that services like Travis CI have 3.9-dev prepared so that they can > > test early and adopt. > > > > Meanwhile, if they can just link all relevant fixes - just backport > > them in Rawhide. > > > > > > Those more familiar with the changes implemented could do a better job > at > > helping me inform upstream (and maybe help provide solutions?) But I > think that > > comes with being more organized in how to do major component updates. > > We are doing our best to analyze the failures and provide as much > information as > we can, so informing upstream should be easy. When the build fails with an > actual error, we are able to do this. In case of bz1837011, this seems > like an > hesienbug and we are not there yet. > Yes, but we still have time on that one as it's COPR only at this point. > I also sincerely believe, that this is organized very well. Where do you > think > this could be organized better? I honestly believe that we go way beyond > what > other stacks do when they are updated to their new major versions > (sometimes > simply updating the compiler/interpreter and than going away). > I think that's both true, but it says more about some of the other stacks :) For one, Python is an extremely important part of the distribution so it warrants the effort. Secondly, in the specific case of Python 3.8 / PySide 5.13, we blindly patched the builder to accept Python 3.8 and assumed because it built, that it was functional. Now it would be fair to say upstream could improve unit testing and should have caught it, but to be fair to them, they explicitly said Python 3.8 was not supported. So perhaps the solution is when we patch a build system, we ask ourselves (me included), "What can we do to make sure it's functional?" I think here we need better ways of testing software in Rawhide other than well, running Rawhide (VM or bare metal), besides the old mock chroot xnest hack. I'm open to suggestion here. Random thought... Would it be allowable to abuse the rawhide test instance to install software and test via SSH/remote X? Thanks, Richard
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
