Hi, On 11/20/20 8:41 AM, Matěj Cepl wrote:
Dirk Müller píše v Pá 20. 11. 2020 v 11:22 +0100:
sometimes having them out of date is a feature (when the newer version breaks everything else). But that should be a minority.
Certainly, but as you said, these should be minority (I have just downgraded python-Pygments).
"We want to maintain it" is a very vague term.. is that more than the "the initial submitter wants to maintain it"? if so, what is it?
See below, its updates are monitored and the package should be updated as soon as possible (with stress on the word “possible”).
Whats a "business reason" for a community project?
I haven’t meant business reasons with the bottom line calculated, just to make submitter stop and think, whether he has really good reasons why to push the package to d:l:p. Do we really need python-buttplug in d:l:p, shouldn't it be better to have it some special project supporting exotic hardware? Is this really important to have it as a part of the Python ecosystem (perhaps yes, we have other Python bindings for other C libraries in d:l:p as well)? Perhaps, but all what I ask is that the submitter stops for a minute and thinks about it (and writes his reasons down, so we can follow his logic).
d:l:p shouldn't be just dumpster where people throw anything they can come up with.
Huh? Why? I get the idea, you want people to help contributing also in other areas, but imho thats why we had all the splitting of dlp into subprojects (with the corresponding pain for people that just want to use a set of working and updated packages on older distros)
And yet, we still have over 2000 packages in d:l:p (and 500 of them needs update).
But this problem is not solved by making up some rules that make it harder for people to contribute and ask for a "business reason" in an open source project that is community driven. "business reasons" apply to SLE not to openSUSE. The way to fix the "it doesn't build" or "no one cares and it's way old" problem is to have a policy to evict packages that fall into those categories, define the policy and automate it. Don't create a policy that makes it harder for people to contribute, that's counter productive to what we are trying to achieve. We want to attract contributors not scare them away. Simple things like "When a package fails to build the original contributor or maintainer on record will be notified. If the package build is not fixed after $SUITABLE_GRACE_PERIOD the package will be removed from d:l:p" "The goal of the d:l:p project is to stay reasonably close to upstream where we define "reasonably close" as a version spread of no more than $SUITABLE_VERSION_DIFFERENCE". If a package falls outside this reasonably close condition the original contributor or maintainer on record will be notified. If the package is not updated after $SUITABLE_GRACE_PERIOD the package will be removed from d:l:p" There, simple, can be fully automated and tells people that when they submit a package they have a responsibility. Later, Robert
Thats the same reason for every of those python-packages, right? lets assume I want to have certbot. I can totally install that from pip, so why is it packaged in openSUSE?
a) certbot has C modules, doesn't it? Those are always a bitch to package, so having it done well in OpenSUSE makes a lot of sense. b) how many people have OpenSUSE/SLE on their websites and they want to use Letsencrypt for their certificates versus how many people use OpenSUSE to create packages for Fedora/RHEL? c) thinking about these things could stop you long enough to recognize, that these packages don’t belong to d:l:p, but to the system:packagemanager project.
I'm not against defining a policy for inclusion, but we need to chew a bit more on the rules for that.
That’s why this is RFC. I mean it, I really want to get a feedback.
There are just a few packages that are incredibly painful to maintain, as they are breaking frequently when its dependencies are updated. maybe we should try to do something about them first (e.g. Twisted is one that came accross).
And these should unfortunately certainly be part of our packages which we support, because they are foundation of so many other packages, and exactly because they are difficult to maintain. And yes, I would love to have some volunteer dedicating his/her time to actually really understand well Twisted and all problems related to its packaging. Even if we separate all python*twisted* packages to separate subproject (which may be a good idea), we certainly want to monitor it and keep it supported.
Best,
Matěj
_______________________________________________ openSUSE Python mailing list -- python@lists.opensuse.org To unsubscribe, email python-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/python@lists.opensuse.org
-- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Engineer LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo