![](https://seccdn.libravatar.org/avatar/a4139df10120ce151e457fd1faff018d.jpg?s=120&d=mm&r=g)
On 11/20/20 10:35 PM, Matěj Cepl wrote:
Simon Lees píše v Pá 20. 11. 2020 v 18:45 +1030:
I strongly disagree with most of this, firstly if i'm writing a script and have a missing dep, i'd much rather push it to tumbleweed then deal with pip I want to zypper dup/up not try and think of what I need to update with pip.
I have absolutely no intent to stop submission of new packages. Just update two packages already in d:l:p (or any other of the checked projects, it may be as simple as just bumping the version number, rebuilding the package, and submitting to OBS), and you are very welcome to update new one.
The message I just really want to send is that having package in d:l:p is not costless. The cost is small, but with 2007 packages in it (with over 500 in need of update), the bottom line is very much non-zero.
I don't actually see a problem with 500 packages needing an update, at least if those packages are working for people. My other point is that the people who submit the packages and want to maintain them should be paying that cost for the most part not you.
Secondly in openSUSE we always encourage people to do and only say no to a contribution if we have very good reason to, we also don't expect anyone to do work for us. With that in mind id suggest a policy more along these lines which is what happens elsewhere.
Perhaps the solution would be just send some packages to some other repos, which would remain unmaintained by the community (i.e., if you care about them enough to maintain them, be my guest, or actually the guest of OBS).
So, for example, all those COPR packages belong to system:packagemanager, after all they have really not much to do with the Python ecosystem anyway.
Yeah in some cases that would make sense, I already maintain the bindings for efl in the enlightenment repo because it makes more sense.
Also, I would have no problems with (non-monitored) d:l:p:PyPI project with automatically (or otherwise) generated mirror of PyPI.
If someone adds a new package they get added as the maintainer in obs (For now lets just talk about non core things that aren't in SLE).
That’s absolutely perfect, but let them do it outside of d:l:p (or other monitored projects).
Please no, then we will just end up with d:l:p and d:l:p:nonmonitored and that would just be a world of confusion. d:l:p:core with just the packages we care about for SLE could be less confusing but not nearly as good as my suggestions down further.
What goes alongside that is no one expects you or anyone else to keep packages that you don't want to maintain up to date which means there is only a small amount of work per package in the unusual case where we need to modify some macro etc even then generally such a change can be done in a way where not every package needs to be done at once.
We have scripts which follow these repositories https://gitlab.com/mcepl/suse_cron_scripts/-/blob/master/scripts/environment... and generate the weekly email to this list. It would be very difficult to separate unmaintained packages in these projects from those we wish to update.
This is not true, obs makes it very easy to get the package maintainer `osc maintainer python-PyPDF2` for example, (using the -e flag will even provide an email address). It would be easy for you to treat packages that have a maintainer separately you could also get the script to email me when the packages I maintain explicitly are out of date (that would be really useful). [A side note is I should maintain several more python packages then I do I don't know where my rights went]. Another way would be to define "Core" and "Non Core" packages a basic definition could be any python package that uses SLE as its origin in Leap. For 15.1 that list was here https://build.opensuse.org/package/view_file/openSUSE:Leap:15.1:Update/00Met... so again easy for your script to deal with (I'm not sure where it went in 15.2). It would be reasonable to state that SUSE is committed to keeping core packages up to date, but not non core packages. Maybe it could also be reasonable to require "Non core" packages to have a maintainer listed, but that might also depend on how many of the non core packages the non SUSE project maintainers are looking after. I also generally agree with Robert, we shouldn't be making the process harder, if i'm in the middle of something the last thing I want to do is stop and update 2 random packages I don't care about (i'm more then happy to update the ones I do care about). The result of making things harder (even by a bit) is that people will just end up leaving packages in there home project and duplicating each others effort which is exactly what we as a project want to avoid. -- 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