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_acce…
[3] https://build.opensuse.org/package/show/openSUSE:Factory/hugo
