Dirk Müller píše v Út 01. 12. 2020 v 13:52 +0100:
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”).
and that is not always the case. I would argue in some cases the "lets get rid of nose and drop unittest2" changes that ended up creating hundreds of downstream patches everywhere, some of them never going upstream or are submitted upstream but failing there (or having patch conflicts meanwhile) did not *improve* quality either.
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).
For me quality is: "it works and is secure". There are soft quality factors, like "is recent, is performant", but those are a clear 2nd factor over "it works" and "is secure".
Is it so surprising idea that most commits upstream are meant to improve that software? Is it so surprising to expect that the easiest way (in large numbers, I have neither time nor will to do per-package research) to get the best and greatest is to make sure we have the latest?
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. My actual goal, which you apparently don’t share, but it doesn’t make it less relevant, is to keep Factory updated and not ignore the fact that quarter of our packages in the supposedly latest 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.
Also, IMHO openSUSE is not really "large" by any means. I'd say it is by far the smallest of the popular distros, so instead of coming up with policies on our own we maybe should also learn about how others that are larger are managing that (I haven't really educated myself on that either, so I can't point it out directly, sorry).
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. 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. Let me present some numbers: * Debian unstable https://repology.org/repository/debian_unstable * Fedora Rawhide https://repology.org/repository/fedora_rawhide * OpenSUSE Tumbleweed https://repology.org/repository/opensuse_tumbleweed Ignoring small difference in distributions (yes, we have QA, Fedora effectively doesn’t, I am not sure about the current situation in Debian) and ignoring unknown methodology of indicating “outdated” packages (and just by brief looks at their graphs, I am not full of confidence in it), I see that * Debian has 33,015 packages in total, 6,879 of them outdated, which is 20.84 %. * Fedora has 22,489 packages, 4,349 of them outdated, which is 19.34 % * We have the smallest number of packages, 14,152, but 3,052 of them are outdated, which is the highest share, 21.57 %. * Situation in d:l:p is even worse, 538 out of 2,027 packages (i.e., 26.54 %) need update. And that’s probably the best situation from all d:l:p projects (I see some life in d:l:p:numeric, but otherwise it is really silent there).
In my observation, the python packaging has also always done things in a way that make things extremly painful. or in another way of stating it, it sometimes appeared like you intentionally want to hit all the obstacles on the way.
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.
As far as I remember in this mailthread, noone was against a policy of dropping unmaintained(unmaintainable) stuff. Lets just work on a refresher on the original policy draft proposal addressing also the feedback you got.
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. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 There is no reason to suppose that most human beings are engaged in maximizing anything unless it be unhappiness, and even this with incomplete success. -- Ronald Coase Introduction to “The Firm, the Market, and the Law”