On 19. 05. 20 14:03, Richard Shaw wrote:
So I get the whole Fedora first, but...
Backstory:
FreeCAD has been in a terrible state in Fedora for a couple of years now and
I've nearly given up on trying to maintain the package a few times now. The
previous battle was with the Coin3D stack which finally got updated to Coin4 in
f32 (then Rawhide). I constantly got bugs submitted that freecad was broken in
f31 and my answer was, "Be patient it'll finally be fixed in Fedora 32 where the
Coin3D stack is updated!".
However, that was a lie. Unintentional, but a lie nonetheless.
Fedora 32 releases and I'm enthusiastic that freecad will finally be *fixed*!
And then I get my first BZ, now PySide2 is broken... Why?
Because Qt 5.13.x / PySide2 5.13.x is NOT compatible with Python 3.8. But
instead of asking ourselves, "should we push in the VERY latest Python and hope
it's ok?", we just patch the build system to accept it anyway and hope for the
best.
Qt (et all) is a pretty organized upstream, so when asked about Python 3.8
support in 5.13.x, they said, "Nope. Wait for 5.14.x."
What good does that do me? At the time it wasn't released, and once it was only
Rawhide got it. And I get why. Updating the whole Qt stack and rebuilding all
the dependencies is pretty a pretty painful process.
So all that to say, we seem to be taking "Fedora First" to mean, we're going to
update regardless of what it breaks.
This is a little more ranty that I intended it to be, and no, I'm not going to
go research and paste a bunch of BZ urls, this isn't about asking for help, it's
more policy related.
Hell, I still have one project that all but refuses to update to Python 3!
Fortuantly a user found a github project that had the needed patches backported
from 5.14.x! Fingers crossed freecad will work again for more than 5 seconds.
Now I'm being told PySide2 doesn't build with Python 3.9 pre-release. I'm not
surprised! It's not even released yet. I can (and will) inform upstream. But
what do you think their answer is going to be? Wait for 5.15?
Ok, rant over.
Obviously, updating to latest Python as it is released might not be the only
available approach. We could stay at 3.7 until it gets security only and then
update to 3.8 etc. Security support for old Python releases is long enough for
us to do this. (I am intentionally leaving the EL-support related problem out.)
Question is, whether this model would suit Fedora better. At this point, we are
following the "(b)leading edge" approach. In my point of view, this means that
as distributors and integrators, we take the bumpy road for the benefits of the
projects we package. Often, it's Fedora who drives Python 3.N+1 support in
various upstream projects. It also means bugs are found in Python itself (and
significant libraries) before the "stable" version is released. If we integrate
new Python versions later, this "trying hard" will just shift from alphas and
betas to .1 and .2.
OTOH There are always projects that won't be able to keep up with this and the
maintainers of such (like you) are caught in the cross fire.
The current approach also means that we can actually drive improvements in
CPython upstream. If we slow down significantly, it means we can only drive
changes in downstream patches or wait for our projects to land in years.
I am obviously biased here, so I won't argue that the current approach is better
-- it has pros and cons. But I'll follow the discussion and try answer questions
to the best of my abilities.
Thanks for your feedback, even when you call it "rant", it was pretty on topic ;)
--
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://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
