Dirk Müller píše v Čt 10. 12. 2020 v 16:42 +0100:
Yes, I get that (and I did that). the packages that I care about (need to search for the concrete examples), I hit like 5 packages in a row where the patch never went upstream, or where the patch was posted upstream but in conflicts and never rebased.
Either mistakes happen, or just I am not responsible for anybody's else work. Sorry.
One of the packages that I care about for example is eventlet. Now for reasons that I don't fully know we have updated dnspython to 2.x, which is incompatible (this is documented upstream). I tried to fork a dnspython1 package, which was deleted. patches to add dnspython 2.x support were added instead, which did not yet go upstream, and while they passed some of the unittests, it actually caused a lot of pain in real functionality. so effectively it broke eventlet.
There is probably one solution to this. Take over maintenance of packages you care about, and when you see submit request coming which is stupid or hurtful, make your opinion known. We are certainly not forcing the latest updates for packages which are known to break universe. What would break if we revert dnspython back to 1.* (although, I have built https://build.opensuse.org/project/show/home:mcepl:branches:devel:tools:scm with dnspython 2.0.0 and it seems to work)? Are there any patches whcih would help eventlet? I don't know, but I am very willing to be told.
Now, there were newer releases, and maybe there is a release now that supports the newer dnspython, but lets generalize the concern: every other distribution seems to stick dnspython on the older version if it breaks something major, and we instead have the conversation of "its outdated, needs to be updated".
Yes, because we don't have anybody who would actually be specialist for dnspython, eventlet, or many other crucial packages, and we who try to keep together d:l:p make a lot of mistakes from ignorance.
I do feel like this was frustrating for both sides, and this example should very clearly demonstrate that there is no value whatsoever to always ship the newest package. I am suggesting to by policy aim for shipping the newest *working* package.
Again, I don't remember repeatedly reverting cmd2, that sounds truly bad, but I ended up making comments in SPEC files in sense "Do not upgrade until you are certain you are not breaking python-foo!". Just above the Version: line. Perhaps, that could help.
Working needs to be more important than "latest". I don't say "latest" isn't what we should strive for, but if "latest" breaks, "outdated but working" should be fine, while the regression is being resolved.
I completely agree.
lets put the policy in some shared etherpad and I'm happy to edit or improve it further and hopefully we can come up something that everyone can tolerate and support.
https://en.opensuse.org/openSUSE:Packaging_Python is a wiki. It has Discussion page. Or we have this email list. Let's not make the third avenue for discussion.
your proposal for me was trying to control "inflow". I would prefer to make "egress" easier.
I think we have to do both. Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Oh, to be young, and to feel love’s keen sting. -- Albus Dumbledore