Heisan, this topic came up during my submission of python-mmllib to the Python devel project [1]. But, in fact, it seems to be a quite general discussion, so I am raising it here to get a general picture. As a side note, my current endeavour is exploring the maintenance, especially team maintenance and mentoring approaches, of packages in openSUSE, in comparison to how it is handled in Debian. I am a Debian Developer and therefore quite used to the workflows and basic approaches over there. The general question I'd like to discuss is where libraries for development in various languages should be maintained. There are development teams for all major languages, and these seem, to some extent, to maintain development libraries as well. Then, looking at MMLlib as an example, this package can be seen in two ways: * it is a library that can be used for various kinds of programs written in Python, among which are games, educational toys, and multimedia applications * it is not _really_ generic, as it is somewhat specialized in not only, but probably mostly the fields mentioned above So, in *theory*, MMLlib is a generic library that can be used by whoever thinks they need it in their program, but in practice, it will be mostly useful for the mentioned fields. Matej therefore proposed it be moved to another team, with the Education devel project in mind (because education is the field where I, also being the upstream maintainer, developed it). I, i ncontrast, are still in favour of having all sorts of Python libraries maintained in a language team. Let me summarize what I think are the arguments for the two approaches: a) Maintaining all development libraries in a single language project - high maintenance load for a single team - large collection of packages in a single, probably not too well namespaced bunch + simplified auto-maintenance and batch changes + better control over adherence to library packaging guidelines b) Maintaining specialised libraries in topical projects - less control over adherence to library packaging guidelines - not clear which topic fits the best (see example above) sometimes + less maintenance burden for a single team Closely related to this question is the question whether development libraries should go into the distribution at all. More recently, I found the stance of the Go language team on that [2]. In conclusion, this is "we do not want a large collection of development packages in the distribution, only those needed to build and run leaf binaries". Taht implies that developers who use openSUSE for their work are told to use non-openSUSE sources instead, and install development libraries from the repositories provided by their language ecosystem, and that we make a clear distinction: * packages in openSUSE are for end users * developers use their language ecosystem tools Generally, I am in favour of providing all tools, including libraries, for everyone in a distribution, but that's a very "Debian" view of things. In practice, it shows that for Python development, virtual environments managed with poetry or whtever, and installing packages from PyPI, is far better suited. So I am somewhat moving into that direction. But then again, I find it questionnable that the Go language team should be responsible for maintaining any binary leaf packages. Why is teh Go devel project responsible for maintaining, say, hugo [3], and not a devel project tailored at website topics? All in all, I think my favourite pattern would be somethign like this: * maintain binary leaf packages in a topical team * maintain libraries in a language team, independent of topic * do not accept libraries that are not dependencies of leaf packages I am aware that there is no "one size fits all" solution, but hopefully, others can contribute valuable views on that topic ☺. Ha det bra, Nik [1] https://build.opensuse.org/request/show/1103110?notification_id=42200225 [2] https://en.opensuse.org/openSUSE:Packaging_Go#Not_all_packages_will_be_accep... [3] https://build.opensuse.org/package/show/openSUSE:Factory/hugo