On Mon Aug 21, 2023 at 1:01 PM CEST, Dominik George wrote:
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.
There are many reasons why the situation in openSUSE is different than in Debian (I don’t want to get into details, because it would be long), so your habits and behaviour learned there doesn’t transfer well to here. And I have absolutely nothing against Debian (I used it for many years, and I have stoped only when I was employed in a Linux company), but the situation is very different.
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
It is slightly less complicated than that. We have 2237 packages just in d:l:p (plus hundreds of packages in subprojects of d:l:p). Even though a group of SUSE employees are working on them, it is just too much and we try continually to pass packages to better hands, when we find them. Also, given this number, we can effectively work only with pure Python problems, and we don’t have much time and mental capacity to be knowedgeable enough in some more specialised areas. So, for example, even though there are some Python packages in the Gnome/Glib universe, I have tried very hard to push all Gnome/Glib related packages to the Gnome development team. The same goes to Python packages connecting to some specialized hardware, or for example, do you know that both Breezy (originally Bazaar) and Mercurial are written in Python? Or python-kubernetes. All this has been moved elsewhere (we used to have many MORE packages in d:l:p, this is after substantial trimming down). Not only we are overloaded with our packages, but also I really cannot do the justice to the maintenance of packages which all about something else than just Python (see examples above). So, when I see a package which looks it would fit better into the Education project, I suggested to be moved there. Of course, if it is a general package, it can go to d:l:p, but I tried. Best, Matěj -- https://matej.ceplovi.cz/blog/, @mcepl@floss.social GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 No matter what happens in the kitchen, never apologize. -- Julia Child