![](https://seccdn.libravatar.org/avatar/c13f6726c52ab070fa80fa59a08f5c7c.jpg?s=120&d=mm&r=g)
Am Donnerstag, 3. Dezember 2020, 21:33:11 CET schrieb Matěj Cepl: Hi Matej,
fundamentally, you're saying "outdated" == "low quality". Just to be clear. No, I am not saying that. To rewrite your statement, I would say more like “many outdated packages” == “low quality of maintenance” (or to paraphrase even more, “we took more than we can chew on”).
yes, I agree, updating python packages by itself is not hard, and I'm doing that regularly. I see two major timesinks: * finding the changelog. often this is not in the tarball itself, so it requires searching where the F this particular piece of software publishes its changelog to add it to changes. I spent more than 80% of the time on this * rebasing off-upstream patches. This is mostly like those "general cleanups" patches, like unittest2 removals that did not go upstream or the like. everything else, is probably like 2-3 minutes of work per package. Not that I'm saying I am happy to do 500+ package updates a week, but I am happy to do the ones that I care about once a week or so, especially if there are no off- upstream patches added.
As far as I know, ALL those patches went upstream and many were accepted with gratitude (of course, many projects are dead or a maintainer is lazy, but at least the patch is known and public in such situations). We got couple of “Lovely, so at least SUSE is not only living from our work but sometimes also contributing upstream” as well. Hopefully with continuing updates back from upstream, we will be removing those patches from our packages (as it happened in many situations).
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. This is very frustrating. I think being able to drop those patches and accelerating the work on getting it upstream would be a solution. Its not the one you prefer, but that leads to updating packages become slow and more painful, not so much more a side job. 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. 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". There was one package (python-cmd2 iirc) that had only one (!) dependency. This one depencency was requiring a specific old version. Yet, I think 6 or 7 times the python team updated cmd2 to the latest release, breaking every time the single depending pacakge. every time I went in, reverted to the old version, and less than two days later someone came in, without checking the changes file, and updated the package again to the latest version, which again broke everything. 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. 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.
Is it so surprising idea that most commits upstream are meant to improve that software?
I have no issue whatsoever for anyone doing stuff upstream. what I have an issue with is aptches that did not *go* upstream (e.g. got merged in $main/ $master of some future release) being added to packages, because they just add drag.
So how about we draft a policy around the actual goals rather than having a unrelated discussion ("you can only add a package if you have a business reason"). Thank you for keeping the discussion on topic and avoiding personal attacks.
Sorry, I hope you didn't mean this ironically. I'm not trying to attack you personally in any way. I see you have found a problem, and it is worth tackling and I'm happy to help. 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.
and most raw edge distribution are outdated. That was the goal I started this thread with. You may not like this goal, you may think that you have better metric for the quality of our Python packages, but it doesn’t give you the right to refuse it as ignorable.
I do like to have tumbleweed always up to date. I am regularly working towards that goal (not only with python packages). however I *strongly* prefer working software over newest software.
I have no idea about Debian (and related distros), but from my (very) past experience they don’t care much, and some parts of their waste repository are not very well maintained. Also, their solution to most of problems is to have endless number of people on the job. I don’t have exact numbers, but combining Debian, Ubuntu, Mint, and other derived distros, they have substantial share of all Linux users and thus also developers.
its a spectrum. Debian is very much more on the spectrum towards "stable" and tumbleweed is very much towards the spectrum to "latest". all I'm saying we can take one step back from the rightmost corner of the spectrum of "latest" and still not devalue the goal of a rolling release distro.
From my personal experience with Fedora (I was working at Red Hat for eleven years), their solution is simple: exactly what I was suggesting. Keeping the number of packages low, keeps the situation somehow stable.
I am also not against dropping packages that break often, noone uses, noone maintains. Thats totally fine. I just don't want to make this by making initial contribution difficult. initial contribution needs to be easy. if contributions slow down, or a package goes problematic and noone steps up, I'm with you we should drop it. Thats all I'm trying ot say.
* We have the smallest number of packages, 14,152, but 3,052 of them are outdated, which is the highest share, 21.57 %.
yes. I'm aware of that. "latest" is not necessarily the most important dimension. it is not unimportant at all. if you have a range of 1 to 10, where 1 is "stable working" and "10" is latest, I'm saying we should aim for 8 or 9. Thats all I'm trying to say.
From my experience packaging both on Debian and Fedora, Python packaging in OpenSUSE is by far the easiest and our macros are actually helpful. Without them (and some of our ultra-dedicated maintainers … hi, Markéta! hi, John!, hi, Benjamin!) we would be completely lost.
I am very regularly comparing the work done in fedora with the opensuse packages, because I can often find fixes there and I see the part of the benefit of working in the open that we can collaborate, even if we work on different distros. I don't disagree that the ppython packaging has made things easier and more standardized. thats great. I am not at all saying we should stop that. on the other hand, the macros are also adding a lot of secret sauce that is often not easy to understand.
Well, the container has two ends: one where the new packages flow in, and the other where unmaintained packages are kicked out of repo. It is by far easier to stop inflow of suspicious packages, then to indicate and eliminate them on the outflow. Control of inflow was what I was trying to achieve.
Right, my point is that contributions should be encouraged, and unmaintained stuff should be discouraged. your proposal for me was trying to control "inflow". I would prefer to make "egress" easier. Greetings, Dirk