![](https://seccdn.libravatar.org/avatar/a4139df10120ce151e457fd1faff018d.jpg?s=120&d=mm&r=g)
On 11/21/20 1:56 AM, Matěj Cepl wrote:
Dan Čermák píše v Pá 20. 11. 2020 v 10:21 +0100:
I am against such a measure, as this is very much subjective and will result in one of the following:
a) the devel project maintainer wants to encourage collaboration, so nothing really changes for them, except that they now have to read business reasons as well (and the submitter has to come up with one).
I didn’t want to change anything for them, just to make them think whether d:l:p is really the place where they want to submit their package, and whether they should submit it into OpenSUSE at all.
One of openSUSE's fundamental strengths has always been that we welcome any contribution or package that they believe will be useful for someone in the community
b) the devel project maintainer does not want to have an overloaded project, so they either would reject such a package anyway, or they make the submitter the maintainer. Also in this case, I fail to see how a business reason helps.
Well, to the best of my understanding, I am closest to being the maintainer of d:l:p, but the problem is that with over 2000 packages in the project, it is really hard to do decisions without some rules about it. Which is what we are talking about right now.
And, forget the word “business”, that was unfortunate, I don’t care about money and sense, only about making the packager to think, as said above.
Imho the best solution would be: if you submit a package, then you have to maintain it. If you fail to do so, then it gets dropped. Don't add any additional (arbitrary) conditions. We already have wildly different and mostly unwritten rules for submissions to devel projects, we don't need more of that, rather less.
With the number of packages we have in d:l:p, I believe the community effort with monitoring scripts is the only way how to make at least some sense in the effort. Yes, we can effectively split whole project into little subfiefdoms and assign group of packages to each maintainer, but I think that the collective maintenance is way more powerful and more sustainable (especially considering having many volunteer packagers, who cannot be expected to be as reliable as full-time professionals due to The Real Life™ making troubles for them).
The reality is most openSUSE packages (especially once your away from the core) are maintained by single people who cares about a certain few things, sometimes they no longer have time and we need to find a new maintainer or drop the package
Also, I want to be able to make large-scale changes without struggling in discussions with individual submaintainer. We are currently working on removal of python-nose from OpenSUSE, and whatever else may come up in future (e.g., I have my eyes set on eliminating python-mock as a third party package as well). See https://trello.com/b/WsskhdXA/opensuse-python for current TODO-list.
Needing to discuss large scale changes is a part of working in the openSUSE community, that is why we have this list and the factory list. Although rather then discussing it with each maintainer 1-1 a better approach would be to write a proposal to this list about dropping python-nose and if you get a general consensus here you can just give any maintainers a link to the thread and be done. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B