Re: Debian Math Team
Hi Andrius,
Am Wed, Nov 03, 2021 at 01:26:34PM +0200 schrieb Andrius Merkys:
> > No notes, Andreas came up with this idea in debconf, you could find it on videos.debian.net.
> > But anyways, I have the following point to make:
> >
> > 1. Separate team will help keep track of math-specific software, making it easy for
> > interested folks to work on them. Currently there is no specific team, and packages
> > are scattered across several teams which is (in my eyes) a bit haphazard
>
> I find it hard to believe that all (most?) of math software in Debian will
> be brought under this team.
First let those maintainers move their packages to that team who like it.
Once this has proven to work nicely others will follow.
> Then there is the categorization problem: How
> would we define what is math software? What would be done with
> interdisciplinary software?
Blends categorisation is *not* exclusive. One package can be in two or
more Blends (and we have lots of examples for this).
> For example, I maintain two packages, spglib and
> voronota, which deal with crystallography (chemistry?), but employ heavy
> math. Should I put them in debichem or debian-math?
Leaving it where it is would be a first approach.
> I believe the
> classification problem cannot be solved in general way, leading to looking
> for more "pragmatic" classification.
I consider it pragmatic to simply not change anything that works for
you. Nobody will force you to move your packages.
> > 2. debian-math meta-package (with a separate team) -- this will help researchers to get
> > math related software and tooling in one go (exactly like the debian-med metapackage)
>
> I would extend Stuart's argument [4] by saying that meta-packages should be
> independent from teams. As said, I find it hard to believe that all math
> software will end up in debian-math.
I try to reword what I thought I would have explained several times (in
this thread and always when similar discussion was done): Metapackages
are *designed* to be independent from teams. The idea was to build
sensible sets of user oriented packages and users usually do not ask who
is maintaining a package (as long as it is maintained at all). The
impossibility to put all packages under one team actually created the
need to find other ways to build those sets of packages.
Well, it turns out that maintainers of somehow related software find
together in one team to enhance cooperation and team maintenance. But
this has nothing to do with the metapackage approach per se.
> > 3. Easier to find and contribute for people -- I am sure there are a lot of people on this list,
> > and even DDs who are interested in math, having such a team helps them approach and contribute well.
>
> I am still not entirely sure this will improve the bus factor. Nevertheless
> please add me to debian-math.
We can never be sure - but I'm personally extremely optimistic
considering the amount of positive responses which I'd consider
overwhelming compared to similar attempts I've seen in the past.
> > 4. Better maintainance - Lots of math softwares which are still lying un-updated, or broken in some ways.
> > So it helps improve the overall quality
>
> This greatly depends on the enthusiasm on the members of the new team (as
> everywhere in Debian).
This is correct. However, the existence of a team is lowering the
barrier to touch those packages. I have quite some experience with
this.
> > 5. We have debichem team for chemistry packages, astro team for astronomy ones, and now even a new robotics team
> > We had a new AI team made a few months back. These would also come under science earlier, so if we could
> > make teams for specific domains, *and* they are doing well, why not do so for math?
> > I mean this comes as a very natural choice to me, considering other blends.
>
> Indeed, precedents for debian-math exist. I do not want to block launching
> debian-math, I am just questioning whether fragmentation by domain will
> result in significant increase of net attention for packages.
Only time can prove whether your doubts are right or wrong.
> For debian-ai, I see a clear need. Packaging AI software for Debian has its
> own specific implications, and its coordination is important.
ACK.
> > I'm sorry, but I have to admit this argument of yours is sloppy, Andrius.
> > By this logic, we could push entire debian-med python packages into python-team,
> > java packages into java-team and so on... >
> > You also mentioned debian-med above, so if you think everything would be per-language
> > organised, why do you think separate teams (like -med, or -astro) should even exist?
>
> Sure, feel free to disagree. I however cannot solve the package
> categorization even for myself - almost every time I package stuff I have to
> deliberate on where to push it. I see per-language teams employing
> semi-automated means to update packages/fix common issues, therefore I
> believe my packages would stay in good shape there even without my input.
If you see this kind of advantage for your package by all means use
these advantages.
> > The whole point of blends is to help people with "specific" needs, right.
> > and such teams help organize that in a reliable way.
>
> In real life I personally do not meet Debian/Ubuntu users who know what a
> "blend" or "team" in Debian is. Most users I meet use apt to search for
> particular packages they need, that's all.
So it is our task to run around and tell users. I'm doing so for many
years[5]. You should point users to relevant tasks pages. Why do you
think I started writing that code (luckily I've got help by several
others) and was keen on adding things like citations etc.? It is to
make users aware that there is extra value.
Debian has no advertising department as other distributions. So it is
part of our job to explain users the advantages we have. IMHO some
dedicated team can do this better - thus I applause the Debian Math
team creation.
> If not found, they turn to snap
> or conda or just .deb lying around on the Web. Of course this is just my
> experience.
I think you are describing the "typical user these days". But users
might grow up when educated. So lets educate them. Always when I told
them about the Blends idea users liked it. They liked it even more if
the software ended up as a package in the tasks list (sometimes very
quickly).
> > And Fwiw, people do
> > ask sometimes about software in debian-med (check element), people do file bug reports there, et. al.
> > Many upstreams are tied to -med team, and that could've never happened without domain-specific knowledge.
>
> These are all great achievements of debian-med and other teams. I am not
> trying to null them, sorry it looks like that.
At least I did not misunderstood you that way. I just want to stress
that I expect that a Debian Math team can do similar positive things
than other teams ... and they can do this better if not hidden inside
Debian Science IMHO.
> > The number of pure math software in R package team is in no way overflowing, so I really think this should
> > be manageable. The probability of it having a bit-rot will be less -- atleast not high with me, Andreas, Doug et. al.
> > being around.
>
> I am really impressed by the work you all do. I have no doubt teams having
> you all will take good care of their packages. Thus if you are fine with
> further subdivisions of debian-science, I think I should not have any
> concerns either.
I was one of the initiators of Debian Science and I was suggesting right
from the beginning that this project should help subdivisions to grow.
Beeing a physicist by profession I should start a Debian Physics myself -
but well, one pet project is enough for me. ;-)
> > Should you want more explanation, do let me know and I'll be happy to discuss.
>
> Sure. Thanks for finding time to discuss it with me.
BTW, I consider discussing your doubts very important and I'm happy you
raised these. This gives better options to explain main ideas. BTW, even
the Blends doc says[6]:
While there are Debian Pure Blends that care for certain sciences
(Debian Med deals in a main part with Biology, DebiChem for Chemistry
and Debian GIS for geography) not all sciences are covered by a specific
Blend. The main reason is that at the moment not enough people support
such an effort for every science. The temporary solution was to build a
general Debian Science Blend that makes use of the work of other Blends
in case it exists.
Looking at that page I see its again outdated (Debian Astro is missing and
Ezgo is dead) and should be overworked. Its a good sign that nobody is
reading those docs and thus its not very motivating to keep it updated.
Kind regards
Andreas.
> > [1]: http://blends.debian.net/liststats/
> > [2]: http://blends.debian.net/liststats/uploaders_r-pkg.png
> > [3]: http://blends.debian.net/liststats/commitstat_pkg-r.png
>
> [4] https://lists.debian.org/debian-science/2021/11/msg00016.html
[5] https://people.debian.org/~tille/talks/
[6] https://blends.debian.org/blends/ch04.html#debian-science
--
http://fam-tille.de
Reply to: