Re: Aggressive updating (Python 3.9): Are we trying to hard?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, May 19, 2020 at 8:37 AM Miro Hrončok <mhroncok@xxxxxxxxxx> 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@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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux