Re: Debian Math Team
Thanks, I could make some transfers. Cheers, Jerome On 05/02/2022 13:35, Tobias Hansen wrote: On 2/5/22 12:12, Jerome BENOIT wrote: I plan to transfer sooner or later the following packages from science-team to math-team: 4ti2 primesieve bliss blitz++ e-antic nauty mpfrc++ normaliz primesieve singular sympow mpfi can anyone grant me the necessary permissions to do so in due time ? Thanks a lot in advance, Jerome Hi Jerome, ok I changed your permissions. Best, Tobias -- Jerome BENOIT, Ph.D. | jgmbenoit-at+rezozer*dot_net https://www.rezozer.net/ OpenPGP_signature Description: OpenPGP digital signature
Re: Debian Math Team
Am Sat, Feb 05, 2022 at 01:12:34PM +0100 schrieb Jerome BENOIT: > I plan to transfer sooner or later the following packages from science-team > to math-team: > > 4ti2 > primesieve > bliss > blitz++ > e-antic > nauty > mpfrc++ > normaliz > primesieve > singular > sympow > mpfi > > can anyone grant me the necessary permissions to do so in due time ? I made you owner in Debian Science which should enable you transfering any package. Hope this helps Andreas. PS: Please avoid pinging Nilesh until / including next weekend. Thank you. -- http://fam-tille.de
Re: Debian Math Team
On 2/5/22 12:12, Jerome BENOIT wrote: > > > I plan to transfer sooner or later the following packages from science-team > to math-team: > > 4ti2 > primesieve > bliss > blitz++ > e-antic > nauty > mpfrc++ > normaliz > primesieve > singular > sympow > mpfi > > can anyone grant me the necessary permissions to do so in due time ? > > Thanks a lot in advance, > Jerome > > > Hi Jerome, ok I changed your permissions. Best, Tobias
Re: Debian Math Team
Hello, On 07/11/2021 12:56, Torrance, Douglas wrote: On Mon 01 Nov 2021 10:28:55 AM EDT, Andreas Tille wrote: How to move a package: In Salsa: Settings -> General -> Advanced [Expand] -> Transfer project This redirects users who are using the old URL. For sure you need the according permissions in both teams (not sure whether maintainer is sufficient or whether you need owner). Maintainer must not be sufficient, as this option doesn't appear to me for debian-science packages. Would anyone be able to either grant me owner permissions, or alternatively transfer the following from debian-science to debian-math? cohomcalg coinor-csdp fflas-ffpack frobby geneagrapher gfan givaro linbox macaulay2 macaulay2-jupyter-kernel mathic mathicgb memtailor mpsolve qepcad saclib topcom Thanks! Doug I plan to transfer sooner or later the following packages from science-team to math-team: 4ti2 primesieve bliss blitz++ e-antic nauty mpfrc++ normaliz primesieve singular sympow mpfi can anyone grant me the necessary permissions to do so in due time ? Thanks a lot in advance, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Re: Debian Math Team
On 2021-12-06 16:04, Drew Parsons wrote: On 2021-10-29 19:31, Torrance, Douglas wrote: During the Debian Science BoF at this year's DebConf, there was some discussion of creating a team devoted to packaging mathematical software. This seemed like a pretty good idea, so I figured that I'd go ahead and start working on getting it set up. I've already created a Salsa group and a team on the Debian Package Tracker Here are a couple of worthy candidates for the Debian Math Team, RFA and RTP: ^^^ RFP I mean. This email is the request for someone to package python-facile :) (based on its usefulness indicated at https://stackoverflow.com/questions/43995862/python-multivariate-non-linear-solver-with-constraints ) - facile - functional constraint library - is looking for adoption, https://tracker.debian.org/pkg/facile - python-facile (python interface to facile) could be useful to package, more flexible than scipy.optimize https://github.com/xoolive/facile
Re: Debian Math Team
On 2021-10-29 19:31, Torrance, Douglas wrote: During the Debian Science BoF at this year's DebConf, there was some discussion of creating a team devoted to packaging mathematical software. This seemed like a pretty good idea, so I figured that I'd go ahead and start working on getting it set up. I've already created a Salsa group and a team on the Debian Package Tracker Here are a couple of worthy candidates for the Debian Math Team, RFA and RTP: - facile - functional constraint library - is looking for adoption, https://tracker.debian.org/pkg/facile - python-facile (python interface to facile) could be useful to package, more flexible than scipy.optimize https://github.com/xoolive/facile Drew
Re: Debian Math Team
On 4 December 2021 5:43:35 pm IST, Tobias Hansen wrote: >On 11/3/21 4:08 PM, Andreas Tille wrote: >> Am Wed, Nov 03, 2021 at 04:55:54PM +0100 schrieb Julien Puydt: >>> Hi, >>> >>> Le lundi 01 novembre 2021 à 15:28 +0100, Andreas Tille a écrit : How to move a package: In Salsa: Settings -> General -> Advanced [Expand] -> Transfer project This redirects users who are using the old URL. For sure you need the according permissions in both teams (not sure whether maintainer is sufficient or whether you need owner). >>> Hmmm... I just tried with flint, and I can go to settings, expand >>> "Advanced"... and the choices are "Housekeeping", "Export project" and >>> "Change path". >>> >>> Perhaps I lack some credentials? >> Seems you need to be "Owner" to remove a repository somewhere ... and now >> you are. >> Please try again. > >Hi Andreas, > >could you also make me owner please? I am planning to move sagemath related >packages to the maths team one by one whenever I do the next upload, in order >for the Vcs fields to stay correct. > >Best wishes, > >Tobias > Bumped to owner. Regards, Nilesh
Re: Debian Math Team
On 11/3/21 4:08 PM, Andreas Tille wrote: > Am Wed, Nov 03, 2021 at 04:55:54PM +0100 schrieb Julien Puydt: >> Hi, >> >> Le lundi 01 novembre 2021 à 15:28 +0100, Andreas Tille a écrit : >>> How to move a package: >>> >>> In Salsa: >>> >>> Settings >>> -> General >>> -> Advanced [Expand] >>> -> Transfer project >>> >>> This redirects users who are using the old URL. For sure you need >>> the according permissions in both teams (not sure whether maintainer >>> is sufficient or whether you need owner). >>> >> Hmmm... I just tried with flint, and I can go to settings, expand >> "Advanced"... and the choices are "Housekeeping", "Export project" and >> "Change path". >> >> Perhaps I lack some credentials? > Seems you need to be "Owner" to remove a repository somewhere ... and now you > are. > Please try again. Hi Andreas, could you also make me owner please? I am planning to move sagemath related packages to the maths team one by one whenever I do the next upload, in order for the Vcs fields to stay correct. Best wishes, Tobias
Re: Debian Math Team
Hi Nilesh, On 2021-11-04 13:13, Nilesh Patra wrote: > On Thu, Nov 04, 2021 at 11:48:45AM +0200, Andrius Merkys wrote: >> Maybe separate mailing lists could be enough? In the end >> upstreams mostly work on one-two source packages, and even if they >> become DMs they do not get push/upload permissions for all source >> packages of a team, do they? > > I think this point is not exactly a discussion for the mathematics team, but > pretty much several other teams (i.e separate lists, etc) > Since this looks (to me) very generic and not very specific, maybe you'd > want to ask -devel for more opinions, but :) I agree, this is a topic for a separate discussion :) >>> since R packages are extremely uniform and >>> usually come with test suites that can be re-used which to some extend >>> is taking over the role of an expert knowing the software. There are >>> also not really any specific decisions to make about the packaging since >>> everything is really straightforward. >>> >>> This is absolutely different to software written in Python, Java or >>> anything else. >> >> I disagree. I find at least JavaScript and Perl packages quite uniform, >> and I have an impression that at least > > I cannot say about perl, but your argument is certainly invalid for > javascript team. > My journey to contributing in debian started with JS team, and I've been > involved there > ever since (few years by now), and no, they are _not_ uniform. > Several packages need much more work than the defaults and maintaining JS is > also more work > for more techinal reasons (like embedding node modules for instance) > > Several packages come with typescript defs, and you need to take care of them. > They come with varieties of build systems - webpack, rollup, grunt then > terser, uglifyjs for > minifying and what not. > In majority of the JS packages I've touched (several dozens by now) I almost > always had > to do something more than just running some scripts and I can attest to that. Interestingly, my experience is different. Most of JS packages I deal with are rather uniform, but maybe it is just luck. > A couple of years back, there was no pkg-js-tools (sort of a debhelper sort > of tool for JS team) and > the work was even more. Yadd later wrote this nice tool that automates a > number of tasks, and maybe that > gives you an impression that stuff is unform - sure, it has improved a lot, > but you cannot compare it with > R packages. You can maintain R packages without knowing the build system very > well, but not JS. Maybe it is just pkg-js-tools, yes. When I came to JS packaging, pkg-js-tools were already there, so I have no experience with the situation before that. Nevertheless, thanks to pkg-js-tools, JS packages look quite uniform to me now :) Apart from that, maintainers of the JS team do great deal of (seemingly semi-automated) improvements on team-maintained packages. Thus I am happy about my JS packages in JS team as they are taken care of even without my attention. > In case of R packages, dh-R takes care of literally everything. Ofcourse > there are exceptions, > but they are very rare. A template legit works just okay, always. OK, good to know. Best, Andrius
Re: What should be moved to math-team (Re: Debian Math Team
On 2021-11-09 16:20, Nilesh Patra wrote: Makes sense to me. Maybe, it is also a fine idea to move packages which are important in the science team, but are unmaintained. Ofcourse, only if some volunteer is willing to take care of it. Makes sense to move meschach to the Maths team. Technically it's a linear algebra package which could be (and has been) used by science applications, but it's long since superseded by other libraries (BLAS and others), so useful more as a mathematical (or historical) curiosity at this point. Still used by neuron though. Drew
Re: What should be moved to math-team (Re: Debian Math Team
On Mon, Nov 08, 2021 at 10:54:35AM -0500, M. Zhou wrote: > Hi, > > At this point I have some doubt on "what should be moved to > math team." The borderline and the expected outcome are > not discussed in some specific cases. > > In my understanding, domain-specific mathematical applications, > such as theorem prover, would be a good fit for the new team. > And this is not likely of interest by a larger range of audience. > > However, as we know, mathematics is the underlying core of > many engineering and science fields. The critical mathematical > libraries such as BLAS and LAPACK should have the attention > to the whole science team, instead of limited attention of > a small team. > > In brief, my personal opinion is: packages that are too important > and generic should be kept in science team as they may affect > any sub-area of science; packages are less likely used in > other sub-areas of science can be moved to smaller but dedicated > teams for better care. > > The borderline should depend on the influence of a package, > and its expected usage. Makes sense to me. Maybe, it is also a fine idea to move packages which are important in the science team, but are unmaintained. Ofcourse, only if some volunteer is willing to take care of it. Nilesh
What should be moved to math-team (Re: Debian Math Team
Hi, At this point I have some doubt on "what should be moved to math team." The borderline and the expected outcome are not discussed in some specific cases. In my understanding, domain-specific mathematical applications, such as theorem prover, would be a good fit for the new team. And this is not likely of interest by a larger range of audience. However, as we know, mathematics is the underlying core of many engineering and science fields. The critical mathematical libraries such as BLAS and LAPACK should have the attention to the whole science team, instead of limited attention of a small team. In brief, my personal opinion is: packages that are too important and generic should be kept in science team as they may affect any sub-area of science; packages are less likely used in other sub-areas of science can be moved to smaller but dedicated teams for better care. The borderline should depend on the influence of a package, and its expected usage. On Sun, 2021-11-07 at 11:56 +, Torrance, Douglas wrote: > > Would anyone be able to either grant me owner > permissions, or alternatively transfer the following from debian- > science to > debian-math? > > [...] > fflas-ffpack This just reminds me of BLAS and LAPACK.
Re: Debian Math Team
Hi Ole, On Tue, 2021-11-02 at 08:04 +0100, Ole Streicher wrote: > Instead, I would suggest to keep (and improve) the Science Team > policy, > and then to have a *tiny* Math team policy, which could just be a > 5..10-liner, like > > > We inherit the Science Team policy, except: > > * The maintainer field should be set to > > "Debian Math Team ". > > * The VCS location is in the Salsa namespace > > https://salsa.debian.org/math-team/ I suggest the same. In practice the deep learning team directly adopted science team policy, and ML-Policy is added on top of it to address domain-specific issues. Maybe I should find some time to write down the policy ... explicitly.
Re: Debian Math Team
Hi Anton, My first impression is the same -- that may increase fragmentation. But in fact, as long as the main contributors on these packages are happy, why should we stop them :-) Debian contributors are already scarce. If a new team help a group of maintainers retain their enthusiasm, it will be good. I think I have done something similar -- I splitted the deep learning stuff from the science team umbrella into a dedicated team. In this way people who have a specific interest will have a better place to collaborate. Besides, deep learning team inherited the science team policy, and ML-Policy handles some new problems. Overall a new team should be good. As long as the maintainer permission is given to every contributor. Or, it is suggested to directly assign the maintainer access to the whole science team. On Sat, 2021-10-30 at 01:55 +0200, Anton Gladky wrote: > Hi Doug, > > well, I think that it just increases a fragmentation. But it is up to > you. > > Best regards > > Anton > > Am Fr., 29. Okt. 2021 um 22:04 Uhr schrieb Torrance, Douglas > : > > > > During the Debian Science BoF at this year's DebConf, there was > > some > > discussion of creating a team devoted to packaging mathematical > > software. > > > > This seemed like a pretty good idea, so I figured that I'd go ahead > > and > > start working on getting it set up. I've already created a Salsa > > group [1] > > and a team on the Debian Package Tracker [2]. If you're interested > > in > > joining, then you should be able to sign up at these links. > > > > I figured next would be applying for a mailing list, putting > > together a team policy, etc. Any thoughts? > > > > Doug > > > > [1] https://salsa.debian.org/math-team > > [2] https://tracker.debian.org/teams/math/ >
Re: Blends framework for Debian Math (Was: Science Subgroups [was Re: Debian Math Team])
Le jeudi 04 novembre 2021 à 10:31 +0100, Andreas Tille a écrit : > Am Wed, Nov 03, 2021 at 03:41:43PM +0530 schrieb Nilesh Patra: > > > > > We should remember that having blends packages, blends web pages > > > and > > > informative wiki pages are completely independent of having a > > > defined team with > > > separate VCS and mailing list. All that needs is one or more > > > people to curate > > > them. > > > > That's correct. I talked with Andreas yesterday on the debian-med > > bi-weekly call, and > > tasks for math packages should be done soonish :) > > I've pushed the code for the metapackages to > > https://salsa.debian.org/blends-team/math/ > > and made > > Doug Torrance > Julien Puydt > Timo Röhling > > members of the Blends team to enable currating these files (which > should be **really** done before announcing anything since its just a > copy of the two tasks from debian-science and does not make any sense > in this form.) > > I've also did the necessary steps to create the web sentinel which > you > can see here: > > https://blends.debian.org/math/tasks/ > > Said members should probably feed some content into > > > https://salsa.debian.org/blends-team/website/-/tree/master/www/math > > before anything is announced and links will be set. > > Hope this helps Thanks for everything! I'll not be very active right in the near future : I'm both busy for paid work, and on the Debian side I'm taking more things on my shoulders in the Debian OCaml Team. In fact, it's mathematics software which I'll probably want to move in the Math Team at some point, but for now a language-specific team is more appropriate. The thread "Multiple teams maintaining one package (proposal)" on debian-devel will have a direct impact on this. Cheers, J.Puydt
Re: Debian Math Team
On Sun 07 Nov 2021 08:39:22 AM EST, Andreas Tille wrote: Am Sun, Nov 07, 2021 at 11:56:11AM + schrieb Torrance, Douglas: On Mon 01 Nov 2021 10:28:55 AM EDT, Andreas Tille wrote: Would anyone be able to either grant me owner permissions, or alternatively transfer the following from debian-science to debian-math? You are owner now. Thanks, Andreas! signature.asc Description: PGP signature
Re: Blends framework for Debian Math (Was: Science Subgroups [was Re: Debian Math Team])
Hi Gard, Am Sun, Nov 07, 2021 at 04:38:09PM +0100 schrieb Gard Spreemann: > > >> Aha! Thanks for teaching me. I'll fix these things. > >> > >> Where are these task files documented, by the way? > > > >https://blends.debian.org/blends/ch06.html > > > > You could hopefully find the Blends doc easily when going to > > > >https://blends.debian.org > > > > --> if not please let me know how to enhance the pointers to > > the docs. > > I could not find the documentation for fields like "Task" and > "Description", but that could just be me. May be also this chapter is worth reading: https://blends.debian.org/blends/apb.html It at least documents "Description" - but you are right "Task" is not covered by the documentation. I'd recommend to simply check the examples of Debian Science and see where it shows up on the Web Sentinel. > > ;-) > > I've made a new merge request with the packages I added before now split > out into separate task files. I landed on keeping the whole MSC2020 code > + name, even though it's quite verbose. Maybe we'll change that later. I repeat what I commented on your MR here: I merged this MR. However, for my taste the task names are a bit long. If you consider that these tasks will be turned into binary packages named math-your-very-long-names this is somehow inconvenient for users. If I were you I would try to find shorter names. BTW, you have push permissions and can push directly. Kind regards Andreas. -- http://fam-tille.de
Re: Blends framework for Debian Math (Was: Science Subgroups [was Re: Debian Math Team])
Andreas Tille writes: > Hi Gard, > > Am Fri, Nov 05, 2021 at 01:51:14PM +0100 schrieb Gard Spreemann: >> >> > All 'X-*' fields in tasks files are pure comments for editors of the >> > tasks files and are technically ignored (as well as in d/control files). >> >> Aha! Thanks for teaching me. I'll fix these things. >> >> Where are these task files documented, by the way? > >https://blends.debian.org/blends/ch06.html > > You could hopefully find the Blends doc easily when going to > >https://blends.debian.org > > --> if not please let me know how to enhance the pointers to > the docs. I could not find the documentation for fields like "Task" and "Description", but that could just be me. >> Just so I can avoid >> doing more things wrong when I got about fixing. > > ;-) I've made a new merge request with the packages I added before now split out into separate task files. I landed on keeping the whole MSC2020 code + name, even though it's quite verbose. Maybe we'll change that later. Best, Gard signature.asc Description: PGP signature
Re: Debian Math Team
Hi Doug, Am Sun, Nov 07, 2021 at 11:56:11AM + schrieb Torrance, Douglas: > On Mon 01 Nov 2021 10:28:55 AM EDT, Andreas Tille wrote: > > Maintainer must not be sufficient, as this option doesn't appear to me > for debian-science packages. Yes, I think you need to be owner to delete a repository and transfering is finally a deletion at the original place. > Would anyone be able to either grant me owner > permissions, or alternatively transfer the following from debian-science to > debian-math? You are owner now. > cohomcalg > coinor-csdp > fflas-ffpack > frobby > geneagrapher > gfan > givaro > linbox > macaulay2 > macaulay2-jupyter-kernel > mathic > mathicgb > memtailor > mpsolve > qepcad > saclib > topcom > > Thanks! > Doug Thanks a lot for working on this Andreas. -- http://fam-tille.de
Re: Debian Math Team
On Mon 01 Nov 2021 10:28:55 AM EDT, Andreas Tille wrote: How to move a package: In Salsa: Settings -> General -> Advanced [Expand] -> Transfer project This redirects users who are using the old URL. For sure you need the according permissions in both teams (not sure whether maintainer is sufficient or whether you need owner). Maintainer must not be sufficient, as this option doesn't appear to me for debian-science packages. Would anyone be able to either grant me owner permissions, or alternatively transfer the following from debian-science to debian-math? cohomcalg coinor-csdp fflas-ffpack frobby geneagrapher gfan givaro linbox macaulay2 macaulay2-jupyter-kernel mathic mathicgb memtailor mpsolve qepcad saclib topcom Thanks! Doug signature.asc Description: PGP signature
Re: Blends framework for Debian Math (Was: Science Subgroups [was Re: Debian Math Team])
Hi Gard, Am Fri, Nov 05, 2021 at 01:51:14PM +0100 schrieb Gard Spreemann: > > > All 'X-*' fields in tasks files are pure comments for editors of the > > tasks files and are technically ignored (as well as in d/control files). > > Aha! Thanks for teaching me. I'll fix these things. > > Where are these task files documented, by the way? https://blends.debian.org/blends/ch06.html You could hopefully find the Blends doc easily when going to https://blends.debian.org --> if not please let me know how to enhance the pointers to the docs. > Just so I can avoid > doing more things wrong when I got about fixing. ;-) Kind regards Andreas. -- http://fam-tille.de
Re: Debian Math Team
On 2021-11-05 14:44, Andrius Merkys wrote: Hi Ole, On 2021-11-03 13:52, Ole Streicher wrote: ... Why can't a Python math package be maintained by both the Python and the math team? Maintainer: Debian Math Team <...> Uploaders: Debian Python Team <...>, me This would set a primary team (and the place in the Salsa directory structure), but also allow the Python team to exercise required changes as team upload. ... This suggestion gives some feed for thought. I think it should be proposed on debian-devel first to see if it is possible to adjust policies, scripts and salsa permissions accordingly. Allowing for secondary teams would certainly ameliorate a lot of the concerns about team fragmentation. Drew
Re: Debian Math Team
Hi Ole, On 2021-11-03 13:52, Ole Streicher wrote: > Andrius Merkys writes: >> problem: How would we define what is math software? What would be done >> with interdisciplinary software? 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? I >> believe the classification problem cannot be solved in general way, >> leading to looking for more "pragmatic" classification. > > I sometimes have this problem for Debian Astro packages, and then I > decide on whether the package is (intended to be) useful outside of > astronomy. Sometimes this is difficult; f.e. I just uploaded > "mpl-animators" which does animations with matplotlib, but this depends > on astropy for many functions which hints me that the authors focus on > astronomy (and not general) usage. This might be a candidate for objective criterion, yes. >>> By this logic, we could push entire debian-med python packages into >>> python-team, java packages into java-team and so on... > > I really think this is a bit problematic; IMO the problem here is mainly > that we imply disjunct teams. > > Why can't a Python math package be maintained by both the Python and the > math team? > > Maintainer: Debian Math Team <...> > Uploaders: Debian Python Team <...>, me > > This would set a primary team (and the place in the Salsa directory > structure), but also allow the Python team to exercise required changes > as team upload. > > Probably policies and scripts should be adjusted to make use of > this. And "somehow" the Salsa permissions should match this. This suggestion gives some feed for thought. I think it should be proposed on debian-devel first to see if it is possible to adjust policies, scripts and salsa permissions accordingly. I am replying to this message instead of yours from Fri, 05 Nov 2021 14:14:35 +0100 just to cite your whole proposal. Best, Andrius
Re: Debian Math Team
Andrius Merkys writes: > On 2021-11-03 17:55, Andreas Tille wrote: >> Blends categorisation is *not* exclusive. One package can be in two or >> more Blends (and we have lots of examples for this). > > ACK. However, team categorization is exclusive. In principle, we could put "secondary" teams into the uploaders field, which could allow them to do team uploads as well. Best Ole
Re: Blends framework for Debian Math (Was: Science Subgroups [was Re: Debian Math Team])
Andreas Tille writes: > Am Fri, Nov 05, 2021 at 10:22:32AM +0100 schrieb Gard Spreemann: >> >> I will try to categorize the few packages I maintain myself, and issue a >> merge request so that there are examples for people to go by. > > I merged your commits but the proper way to go would to create say two > new tasks files either named with the cryptical names (like 55n31 and > 65k10 ... which would end up in metapackages math-55n31 and math-65k10 > respectively) or somehow speaking names like persistent-homology and > numerical-optimization (or something better!) Than you add your > binary packages to those tasks files. > > All 'X-*' fields in tasks files are pure comments for editors of the > tasks files and are technically ignored (as well as in d/control files). Aha! Thanks for teaching me. I'll fix these things. Where are these task files documented, by the way? Just so I can avoid doing more things wrong when I got about fixing. Best, Gard signature.asc Description: PGP signature
Re: Debian Math Team
Hi Andrius, Am Fri, Nov 05, 2021 at 01:56:56PM +0200 schrieb Andrius Merkys: > > Blends categorisation is *not* exclusive. One package can be in two or > > more Blends (and we have lots of examples for this). > > ACK. However, team categorization is exclusive. If you call organisation of team maintained packacges a categorisation than yes, it is exclusive. I personally would not use the term categorisation here. > > 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. > > From my experience users usually know which packages they want to > install. The fact that a certain piece of software is not packaged for > Debian rarely instigates them to search for Debian-provided > alternatives. Thus they turn to snap/conda/deb-from-web. Task pages are > really nice and they help a lot when one looks for Debian-provided > package for a task they want to achieve. But from my experience users > most of the time know exactly (= software name) what they want. I've seen users who tried hard to install some software manually who did not even checked the Debian package pool and thus did not found what was just an `apt install` away. I admit that's not the usual case but most users I asked whether they like the software they need as a package confirmed this. > > 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. > > I do not think that anything in debian-science is hidden :) In the sense of "hard to find" inside the to less specific tasks the packages are not so prominently presented. Hidden is surely the wrong word. > > 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. > > Thanks for providing this historical background to me. It helps me > understand the further fragmentation of debian-science has been foreseen > at its creation. I however see some disadvantages of such fragmentation > (and seemingly I am not alone), but surely I do not want to block the > progress. Maybe just instigate a discussion about how certain aspects > could be done even better. As always. ;-) 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
Re: Debian Math Team
ell, 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. Right. >>> 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. OK. >>> 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. >From my experience users usually know which packages they want to install. The fact that a certain piece of software is not packaged for Debian rarely instigates them to search for Debian-provided alternatives. Thus they turn to snap/conda/deb-from-web. Task pages are really nice and they help a lot when one looks for Debian-provided package for a task they want to achieve. But from my experience users most of the time know exactly (= software name) what they want. But I am afraid I am derailing the main conversation. I acknowledge the great work you do with maintaining tasks. They surely deserve more attention from the general users, though. > 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. I hope so. >> 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). ACK. >>> 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. I do not think that anything in debian-science is hidden :) >>> 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 init
Re: Blends framework for Debian Math (Was: Science Subgroups [was Re: Debian Math Team])
Am Fri, Nov 05, 2021 at 10:22:32AM +0100 schrieb Gard Spreemann: > > I will try to categorize the few packages I maintain myself, and issue a > merge request so that there are examples for people to go by. I merged your commits but the proper way to go would to create say two new tasks files either named with the cryptical names (like 55n31 and 65k10 ... which would end up in metapackages math-55n31 and math-65k10 respectively) or somehow speaking names like persistent-homology and numerical-optimization (or something better!) Than you add your binary packages to those tasks files. All 'X-*' fields in tasks files are pure comments for editors of the tasks files and are technically ignored (as well as in d/control files). Kind regards Andreas. -- http://fam-tille.de
Re: Blends framework for Debian Math (Was: Science Subgroups [was Re: Debian Math Team])
Torrance, Douglas writes: > On Thu 04 Nov 2021 12:06:47 PM EDT, Andreas Tille wrote: >>> All mathematics >>> packages? How do the categories work, and what conditions warrant a new >>> category? >> >> You need to ask the mathematicians what might be sensible tasks. >> The tasks mathematics and mathematics-dev are definitely non-sense >> but it was the easiest way for me to kickstart something. > > One possible source of task categories is to use the American Mathematical > Society's Mathematics Subject Classification [1]. This is already used to > classify academic papers, and the problem of classifying mathematics > software is certainly similar. > > Doug > > [1] https://mathscinet.ams.org/mathscinet/msc/msc2020.html I think that's a really good idea! That classification – while seemingly complicated to outsiders – is probably quite well-known to anyone interested in the mathematics Debian tasks in the first place. I will try to categorize the few packages I maintain myself, and issue a merge request so that there are examples for people to go by. Best, Gard signature.asc Description: PGP signature
Re: Blends framework for Debian Math (Was: Science Subgroups [was Re: Debian Math Team])
Andreas Tille writes: > Hi Gard, > > Am Thu, Nov 04, 2021 at 11:02:49AM +0100 schrieb Gard Spreemann: >> > I've pushed the code for the metapackages to >> > >> > https://salsa.debian.org/blends-team/math/ >> > >> > and made >> > >> > Doug Torrance >> > Julien Puydt >> > Timo Röhling >> > >> > members of the Blends team to enable currating these files (which should >> > be **really** done before announcing anything since its just a copy of the >> > two tasks from debian-science and does not make any sense in this form.) >> >> Stupid questions: What packages should go into the task? > > That's not a stupid question but the key question! > >> All mathematics >> packages? How do the categories work, and what conditions warrant a new >> category? > > You need to ask the mathematicians what might be sensible tasks. The reason I said the question was stupid is that I am in fact one of the mathematicians ;-) > The tasks mathematics and mathematics-dev are definitely non-sense > but it was the easiest way for me to kickstart something. > > Please keep in mind that tasks should be user oriented and should fit > the work ... the tasks! ... users are doing. Its extremely important to > understand that one package can be in *several* tasks. See, I didn't even know this last part. Thanks for the pointers! > So you can start with your own work, what you need and find a good > field / category for your own work and put all these into a task. Makes sense. Best, Gard signature.asc Description: PGP signature
Re: Debian Math Team
On 4 November 2021 9:32:08 pm IST, Andreas Tille wrote: >Hi, > >Am Thu, Nov 04, 2021 at 04:43:12PM +0530 schrieb Nilesh Patra: >> > I disagree. I find at least JavaScript and Perl packages quite uniform, >> > and I have an impression that at least >> >> I cannot say about perl, > >I absolutely agree about Perl team and as I said we left some Perl >libraries to that team and I would not mind if some Perl team member >asks for moving everything to them. For historic reasons we just >have some software written in Perl in Debian Med team. > >To come back to Debian Science: My gut feeling is that there are so >many packages of very different fields in very different state that it >is very hard to care for them all. My gut feeling is that some Debian >Math team can have a better overview and the quality of math related >packages can be enhanced. If some of these can be moved into good hands >of a language team - why not? Ofcourse, I never said we should not. But what I meant to say is that standards/ease of packaging are not same across teams and certain stuff is best if maintained in the language team. JS is a good example, same goes for say, golang (we very recently moved a lib there if you remember). But certain packages, which are very specifically either scientific or bioinformatics, I prefer our blends for these. One of the canonical reasons being that it'd be easier to track them for me. I absolutely don't mind someone taking them over, either. Nilesh
Re: Blends framework for Debian Math (Was: Science Subgroups [was Re: Debian Math Team])
On Thu 04 Nov 2021 12:06:47 PM EDT, Andreas Tille wrote: >> All mathematics >> packages? How do the categories work, and what conditions warrant a new >> category? > > You need to ask the mathematicians what might be sensible tasks. > The tasks mathematics and mathematics-dev are definitely non-sense > but it was the easiest way for me to kickstart something. One possible source of task categories is to use the American Mathematical Society's Mathematics Subject Classification [1]. This is already used to classify academic papers, and the problem of classifying mathematics software is certainly similar. Doug [1] https://mathscinet.ams.org/mathscinet/msc/msc2020.html
Re: Blends framework for Debian Math (Was: Science Subgroups [was Re: Debian Math Team])
Hi Gard, Am Thu, Nov 04, 2021 at 11:02:49AM +0100 schrieb Gard Spreemann: > > I've pushed the code for the metapackages to > > > > https://salsa.debian.org/blends-team/math/ > > > > and made > > > > Doug Torrance > > Julien Puydt > > Timo Röhling > > > > members of the Blends team to enable currating these files (which should > > be **really** done before announcing anything since its just a copy of the > > two tasks from debian-science and does not make any sense in this form.) > > Stupid questions: What packages should go into the task? That's not a stupid question but the key question! > All mathematics > packages? How do the categories work, and what conditions warrant a new > category? You need to ask the mathematicians what might be sensible tasks. The tasks mathematics and mathematics-dev are definitely non-sense but it was the easiest way for me to kickstart something. Please keep in mind that tasks should be user oriented and should fit the work ... the tasks! ... users are doing. Its extremely important to understand that one package can be in *several* tasks. So you can start with your own work, what you need and find a good field / category for your own work and put all these into a task. Kind regards Andreas. -- http://fam-tille.de
Re: Debian Math Team
Hi, Am Thu, Nov 04, 2021 at 04:43:12PM +0530 schrieb Nilesh Patra: > > I disagree. I find at least JavaScript and Perl packages quite uniform, > > and I have an impression that at least > > I cannot say about perl, I absolutely agree about Perl team and as I said we left some Perl libraries to that team and I would not mind if some Perl team member asks for moving everything to them. For historic reasons we just have some software written in Perl in Debian Med team. To come back to Debian Science: My gut feeling is that there are so many packages of very different fields in very different state that it is very hard to care for them all. My gut feeling is that some Debian Math team can have a better overview and the quality of math related packages can be enhanced. If some of these can be moved into good hands of a language team - why not? Kind regards Andreas. -- http://fam-tille.de
Re: Blends framework for Debian Math (Was: Science Subgroups [was Re: Debian Math Team])
Am Thu, Nov 04, 2021 at 04:48:25PM +0530 schrieb Nilesh Patra: > > I've pushed the code for the metapackages to > > > > https://salsa.debian.org/blends-team/math/ > > Many thanks! You are welcome. > > [...] > > members of the Blends team to enable currating these files (which should > > be **really** done before announcing anything since its just a copy of the > > two tasks from debian-science and does not make any sense in this form.) > > Looks like I was already a member -- can you bump my access to that of a > maintainer? That'd ease my work there I took the freedom to bump it to owner. > > I've also did the necessary steps to create the web sentinel which you > > can see here: > > > > https://blends.debian.org/math/tasks/ > > > > Said members should probably feed some content into > > > > https://salsa.debian.org/blends-team/website/-/tree/master/www/math > > > > before anything is announced and links will be set. > > > > Hope this helps > > Awesome, thanks! It will become awesome once the tasks are properly curated. ;-) Kind regards Andreas. -- http://fam-tille.de
Re: Blends framework for Debian Math (Was: Science Subgroups [was Re: Debian Math Team])
On Thu, Nov 04, 2021 at 10:31:13AM +0100, Andreas Tille wrote: > Am Wed, Nov 03, 2021 at 03:41:43PM +0530 schrieb Nilesh Patra: > > > > > We should remember that having blends packages, blends web pages and > > > informative wiki pages are completely independent of having a defined > > > team with > > > separate VCS and mailing list. All that needs is one or more people to > > > curate > > > them. > > > > That's correct. I talked with Andreas yesterday on the debian-med bi-weekly > > call, and > > tasks for math packages should be done soonish :) > > I've pushed the code for the metapackages to > > https://salsa.debian.org/blends-team/math/ Many thanks! > and made > > [...] > members of the Blends team to enable currating these files (which should > be **really** done before announcing anything since its just a copy of the > two tasks from debian-science and does not make any sense in this form.) Looks like I was already a member -- can you bump my access to that of a maintainer? That'd ease my work there > I've also did the necessary steps to create the web sentinel which you > can see here: > > https://blends.debian.org/math/tasks/ > > Said members should probably feed some content into > > https://salsa.debian.org/blends-team/website/-/tree/master/www/math > > before anything is announced and links will be set. > > Hope this helps Awesome, thanks! Nilesh signature.asc Description: PGP signature
Re: Debian Math Team
Hi Andrius, On Thu, Nov 04, 2021 at 11:48:45AM +0200, Andrius Merkys wrote: > Maybe separate mailing lists could be enough? In the end > upstreams mostly work on one-two source packages, and even if they > become DMs they do not get push/upload permissions for all source > packages of a team, do they? I think this point is not exactly a discussion for the mathematics team, but pretty much several other teams (i.e separate lists, etc) Since this looks (to me) very generic and not very specific, maybe you'd want to ask -devel for more opinions, but :) > > since R packages are extremely uniform and > > usually come with test suites that can be re-used which to some extend > > is taking over the role of an expert knowing the software. There are > > also not really any specific decisions to make about the packaging since > > everything is really straightforward. > > > > This is absolutely different to software written in Python, Java or > > anything else. > > I disagree. I find at least JavaScript and Perl packages quite uniform, > and I have an impression that at least I cannot say about perl, but your argument is certainly invalid for javascript team. My journey to contributing in debian started with JS team, and I've been involved there ever since (few years by now), and no, they are _not_ uniform. Several packages need much more work than the defaults and maintaining JS is also more work for more techinal reasons (like embedding node modules for instance) Several packages come with typescript defs, and you need to take care of them. They come with varieties of build systems - webpack, rollup, grunt then terser, uglifyjs for minifying and what not. In majority of the JS packages I've touched (several dozens by now) I almost always had to do something more than just running some scripts and I can attest to that. A couple of years back, there was no pkg-js-tools (sort of a debhelper sort of tool for JS team) and the work was even more. Yadd later wrote this nice tool that automates a number of tasks, and maybe that gives you an impression that stuff is unform - sure, it has improved a lot, but you cannot compare it with R packages. You can maintain R packages without knowing the build system very well, but not JS. In case of R packages, dh-R takes care of literally everything. Ofcourse there are exceptions, but they are very rare. A template legit works just okay, always. Nilesh signature.asc Description: PGP signature
Re: Blends framework for Debian Math (Was: Science Subgroups [was Re: Debian Math Team])
Andreas Tille writes: > Am Wed, Nov 03, 2021 at 03:41:43PM +0530 schrieb Nilesh Patra: >> >> > We should remember that having blends packages, blends web pages and >> > informative wiki pages are completely independent of having a defined team >> > with >> > separate VCS and mailing list. All that needs is one or more people to >> > curate >> > them. >> >> That's correct. I talked with Andreas yesterday on the debian-med bi-weekly >> call, and >> tasks for math packages should be done soonish :) > > I've pushed the code for the metapackages to > > https://salsa.debian.org/blends-team/math/ > > and made > > Doug Torrance > Julien Puydt > Timo Röhling > > members of the Blends team to enable currating these files (which should > be **really** done before announcing anything since its just a copy of the > two tasks from debian-science and does not make any sense in this form.) Stupid questions: What packages should go into the task? All mathematics packages? How do the categories work, and what conditions warrant a new category? -- Gard signature.asc Description: PGP signature
Re: Debian Math Team
Hi Andreas, Thanks for finding time to reply to my worries. On 2021-11-01 16:19, Andreas Tille wrote: > 1. Another "one-man" team > I think Ole gave a good answer here: Its not about creating a > one-man team but rather attract more people to the team - from > inside and outside Debian. For those who have any doubt that this > can work: There are 23 people who confirmed, that they became > DDs *because* Debian Med exists[4]. Debian Med is now nearly > 20 years old. I would love if Debian Math would beat Debian Med > in attracting new developers. (Andrius, you even belong to this > set. ;-) ) It is true that I am among these 23 :) My reason for being in the list is mostly pragmatical: it was Debian Med people who signed my key and advocated me to become a DD, and for this I am very grateful. I believe being very open and very friendly to newcomers is one of the strongest sides of Debian Med. > Those 20 years when the Debian Med project have teached me that > it is very important to advertise the fact to the world that Debian > is targeting specific fields of science and IMHO mathematics is > a) well worth to be advertised > b) has lots of technically competent people beeing potential DDs > > 2. Further fragmentation of debian-science > I do not think that another Blend will lead to fragmentation of > Debian Science. Sure, some mathematics related packages will be > moved sooner or later but I personally can not see in how far > this might weaken Debian Science. I personally see also additional > contributors for Debian Science once more mathematicans might > join Debian (as I'm very positive about). > > Am Sat, Oct 30, 2021 at 06:18:28PM +0530 schrieb Nilesh Patra: >> Hi Andrius, >> >> Thanks for replying. See below :- >> >> On Sat, Oct 30, 2021 at 10:33:02AM +0300, Andrius Merkys wrote: I am skipping most of your replies to Nilesh's response to my mail. I ACK the skipped parts. >>> Furthermore, from my experience one does not need domain >>> knowledge to successfully package and maintain packages in Debian. >>> What makes more sense to me, is organizing packages into teams based on >>> programming languages and build/test systems, as such teams indeed >>> possess specific knowledge. I think most of the mails asking for help in >>> debian-med concern language and build system problems, not >>> domain-specific issues. >> >> 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... > > While this would work in principle the point of creating a Blend is to > attract experts who know the algorithm and internals of a certain > software to craft sensible packages and enable thorough testing. This > is usually not simply a programming language issue. In Debian Med we > have several upstreams maintaining their software as Debian packages > (after sufficient teaching of the packaging process and for sure > sponsored by a DD). IMHO exactly this is the strength of the Blends > concept to pair experts of the software with packaging experts. Even > better if this can be completed to involve users into that effort which > does not (yet) work as good as expected (but this has IMHO more external > reasons which we can hardly solve). I see your point. However I am not entirely convinced that teams are essential here. Maybe separate mailing lists could be enough? In the end upstreams mostly work on one-two source packages, and even if they become DMs they do not get push/upload permissions for all source packages of a team, do they? Domain-specific mailing lists could indeed be a go-to place for newcomers, those in need of help with packaging and sponsoring and so on. >>> I am worried reading about R packages being moved from debian-r to new >>> debian-math. I am afraid doing so might negatively impact their quality. >> >> You are right in your worries, but I have some statistics to present here. >> See here[1] or more specifically, look here[2,3] > > I'm not worried about moving R packages to some other Blend. It has > turned out to be a good idea to move all R packages from Debian Science, > Debian Med Debichem and possibly others into one language specific team. > However, this had happened since R packages are extremely uniform and > usually come with test suites that can be re-used which to some extend > is taking over the role of an expert knowing the software. There are > also not really any specific decisions to make about the packaging since > everything is really straightforward. > > This is absolutely different to software written in Python, Java or > anything else. I disagree. I find at least JavaScript and Perl packages quite uniform, and I have an impression that at least Perl packages outside the Debian Perl Team are generally in
Blends framework for Debian Math (Was: Science Subgroups [was Re: Debian Math Team])
Am Wed, Nov 03, 2021 at 03:41:43PM +0530 schrieb Nilesh Patra: > > > We should remember that having blends packages, blends web pages and > > informative wiki pages are completely independent of having a defined team > > with > > separate VCS and mailing list. All that needs is one or more people to > > curate > > them. > > That's correct. I talked with Andreas yesterday on the debian-med bi-weekly > call, and > tasks for math packages should be done soonish :) I've pushed the code for the metapackages to https://salsa.debian.org/blends-team/math/ and made Doug Torrance Julien Puydt Timo Röhling members of the Blends team to enable currating these files (which should be **really** done before announcing anything since its just a copy of the two tasks from debian-science and does not make any sense in this form.) I've also did the necessary steps to create the web sentinel which you can see here: https://blends.debian.org/math/tasks/ Said members should probably feed some content into https://salsa.debian.org/blends-team/website/-/tree/master/www/math before anything is announced and links will be set. Hope this helps Andreas. -- http://fam-tille.de
Re: Debian Math Team
Dear Anton, Am Wed, Nov 03, 2021 at 09:09:15PM +0100 schrieb Anton Gladky: > I think we all have a very limited free time to work on Debian. > At least it is my situation. > > ... > > I will probably need to request membership in other teams due to > some QA or release-transition work, but I can fully understand you doubt and please let me use this chance to explicitly thank you for all your work in Debian Science. I'm pretty convinced that Debian Science would be in a worse shape without all your work. Thanks a lot for this! Regarding Debian Math I personally hope that moving mathematics packages from Debian Science repository to Debian Math repository which also means that these packages are taken from your todo list since I fully trust the members of the Debian Math team to take over the role to care for all packages under this scope. Kind regards Andreas. -- http://fam-tille.de
Re: Debian Math Team
I think we all have a very limited free time to work on Debian. At least it is my situation. Newcomers are looking for reviewers/uploaders, trying to reach a relatively large audience in d/science, sometimes for a very long time without success. How will it work in a smaller team? Doing some large transitions (vtk, boost, etc.) I am always very glad seeing package maintained in a d/science because it is very easy to make a tiny uploads, reaching the result very fast without filing bugs, NMUs etc. All these official bureaucratic procedures take a lot of time and at the end slow down the process. Why do we want to get a one-more team with own policy, necessity to be a member of it doing such uploads etc. It makes things harder! I have unsubscribed myself from most of the mailing lists (even from debian-devel, sorry), leaving only important ones for me to save some more time for QA-work, reviewing/sponsoring/uploading packages, fixing bugs, setting CI-pipelines for salsa-repos etc. Why do we want to spread an energy/time writing new policy, moving packages etc? My strong opinion is that new barriers (blends/teams/salsa-groups whatever) will unlikely improve the total quality and amount of Debian packages. For me it just means that I will probably need to file more NMUs, asking other people for reviews etc... It is a pain and a waste of time. Sorry. I will probably need to request membership in other teams due to some QA or release-transition work, but Regards Anton
Re: Debian Math Team
Hi, Le mercredi 03 novembre 2021 à 17:08 +0100, Andreas Tille a écrit : > Am Wed, Nov 03, 2021 at 04:55:54PM +0100 schrieb Julien Puydt: > > Perhaps I lack some credentials? > > Seems you need to be "Owner" to remove a repository somewhere ... and > now you are. > Please try again. Perfect! Thanks! J.Puydt
Re: Debian Math Team
Am Wed, Nov 03, 2021 at 04:55:54PM +0100 schrieb Julien Puydt: > Hi, > > Le lundi 01 novembre 2021 à 15:28 +0100, Andreas Tille a écrit : > > > > How to move a package: > > > > In Salsa: > > > > Settings > > -> General > > -> Advanced [Expand] > > -> Transfer project > > > > This redirects users who are using the old URL. For sure you need > > the according permissions in both teams (not sure whether maintainer > > is sufficient or whether you need owner). > > > > Hmmm... I just tried with flint, and I can go to settings, expand > "Advanced"... and the choices are "Housekeeping", "Export project" and > "Change path". > > Perhaps I lack some credentials? Seems you need to be "Owner" to remove a repository somewhere ... and now you are. Please try again. Kind regards Andreas. -- http://fam-tille.de
Re: Science Subgroups [was Re: Debian Math Team]
Hi, Am Wed, Nov 03, 2021 at 03:41:43PM +0530 schrieb Nilesh Patra: > I could agree that there will initially be a few people looking after, but I > do expect > this team to grow, like several other teams in Debian have too. Maybe Andreas > could give > better pointers here. Since my name was mentioned here: I hope I gave sufficient pointers in this discussion. ;-) > I think this is repeating the same argument made above again, that we've > fewer people, > I'd simply say that many active people in other blends projects (like -med, > -science et. al.) are also > involved here, and there are good chances that it grows with time. > I can very well understand your fears that some of our packages undergo > bitrot, but then I've two thinsg to point at. Always if I meet Matthias Klose I expects me to care for better quality of Debian Science packages. I usually defend this "generic" blaming of Debian Science in general but yes, he has a point. Since Debian Science maintains a lot of packages and also quite complex ones there is always a number of packages that has issues. "Outsiders" of the Debian Science team have a different view on this as we who know these issues. So my hope is that a Debian Math team will not raise that signal for people like Matthias and others. > First, its not like the science team has all packages in excellent condition > - from my experience of contributing in the science > team for around two years, I've found several packages lying around, broken. > It's not an opinion, its a fact UDD and bug tracker > show proofs. I'm not pointing fingers at anyone here, please assume my best > of intentions here. > Second, having a separate team with dedicated set of people working on it can > make the condition better. In the best case, > we will see nice QA, in the worst case, I don't expect stuff to change > drastically. I fully agree. > Again, please consider good intention here. This is by our code of conduct. ;-) > > We should remember that having blends packages, blends web pages and > > informative wiki pages are completely independent of having a defined team > > with > > separate VCS and mailing list. All that needs is one or more people to > > curate > > them. > > That's correct. I talked with Andreas yesterday on the debian-med bi-weekly > call, and > tasks for math packages should be done soonish :) I just wanted to work on it right now ... but now I had to answer mails first! ;-) Kind regards Andreas. -- http://fam-tille.de
Re: Debian Math Team
Hi, Le lundi 01 novembre 2021 à 15:28 +0100, Andreas Tille a écrit : > > How to move a package: > > In Salsa: > > Settings > -> General > -> Advanced [Expand] > -> Transfer project > > This redirects users who are using the old URL. For sure you need > the according permissions in both teams (not sure whether maintainer > is sufficient or whether you need owner). > Hmmm... I just tried with flint, and I can go to settings, expand "Advanced"... and the choices are "Housekeeping", "Export project" and "Change path". Perhaps I lack some credentials? Cheers, J.Puydt
Re: Debian Math Team
eams (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
Re: Debian Math Team
Andrius Merkys writes: > problem: How would we define what is math software? What would be done > with interdisciplinary software? 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? I > believe the classification problem cannot be solved in general way, > leading to looking for more "pragmatic" classification. I sometimes have this problem for Debian Astro packages, and then I decide on whether the package is (intended to be) useful outside of astronomy. Sometimes this is difficult; f.e. I just uploaded "mpl-animators" which does animations with matplotlib, but this depends on astropy for many functions which hints me that the authors focus on astronomy (and not general) usage. >> By this logic, we could push entire debian-med python packages into >> python-team, java packages into java-team and so on... I really think this is a bit problematic; IMO the problem here is mainly that we imply disjunct teams. Why can't a Python math package be maintained by both the Python and the math team? Maintainer: Debian Math Team <...> Uploaders: Debian Python Team <...>, me This would set a primary team (and the place in the Salsa directory structure), but also allow the Python team to exercise required changes as team upload. Probably policies and scripts should be adjusted to make use of this. And "somehow" the Salsa permissions should match this. Best Ole
Re: Debian Math Team
Hi Nilesh, On 2021-10-30 15:48, Nilesh Patra wrote: Thanks for replying. See below :- Thanks for answering my concerns, and sorry for the long silence. On Sat, Oct 30, 2021 at 10:33:02AM +0300, Andrius Merkys wrote: I agree with Anton here. I do not see how further fragmentation of debian-science could benefit it. I missed the BoF, but maybe there are notes reflecting this decision? 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. Then there is the categorization problem: How would we define what is math software? What would be done with interdisciplinary software? 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? I believe the classification problem cannot be solved in general way, leading to looking for more "pragmatic" classification. 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. 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. 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). 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. For debian-ai, I see a clear need. Packaging AI software for Debian has its own specific implications, and its coordination is important. Separate team and separate mailing list will have less members than debian-science. Well, every other team has started exactly the same way in Debian (i.e. less members) -- it would grow with time, I don't think it'll be stalled for ever. I could _somehat_ agree with the mailing list thingy, maybe we can keep using this list for discussions. Furthermore, from my experience one does not need domain knowledge to successfully package and maintain packages in Debian. What makes more sense to me, is organizing packages into teams based on programming languages and build/test systems, as such teams indeed possess specific knowledge. I think most of the mails asking for help in debian-med concern language and build system problems, not domain-specific issues. 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. 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. If not found, they turn to snap or conda or just .deb lying around on the Web. Of course this is just my experience. And Fwiw, people do ask sometimes about
Re: Science Subgroups [was Re: Debian Math Team]
Hi, Le mercredi 03 novembre 2021 à 15:41 +0530, Nilesh Patra a écrit : > > On Wed, Nov 03, 2021 at 08:38:10PM +1100, Stuart Prescott wrote: > > Separate teams are optimised for the "main" maintainer of a handful > > of > > packages who doesn't routinely work on any other packages; they are > > optimised > > _against_ bugsquashers, generalists or people trying to land big > > projects > > across large sets of packages. > > I'm not sure how that's true, would you mind explaining a bit? I wanted sagemath in Debian. So I started packaging things left and right, and because of that, I'm now a DD with my hands in the Debian Python Team, the Debian JavaScript Team and the Debian Science Team. And I need to be in those teams to do anything useful. If there had already been a Debian Math Team at that time, I would have needed to join too -- one more team! And I think that's Stuart's point : someone who is either a bug-hunter (yes, some like it) or who is aiming at a large target (dropping Python 2, packaging a beast) will need to be part of all teams involved, and having too many of them is adding to the chore. I'm not sure that's a strong issue, though. Cheers, J.Puydt
Re: Science Subgroups [was Re: Debian Math Team]
Nilesh Patra writes: > On Wed, Nov 03, 2021 at 08:38:10PM +1100, Stuart Prescott wrote: > >> However, the disadvantages of separate teams are >> >> - differing conventions in each team around VCS layout, interactions etc > > We adopt the policy of the science team, so the VCS layout will essentially > be the same. So this will not have any delta with what science team is doing > currently. I must say I fail to see how this isn't an argument for lumping the two teams together (or, as I suggested in my other message, lump all the "computation-scientifically" oriented teams into one; I'd wager the domain-specific expertise often varies just as much within one of the current teams as it does across them). Again, I have no strong opinions against the forming of the math team, certainly not when wearing my mathematician's (dunce) hat, but it seems to me that several of the arguments for doing so boil down to "things won't be worse, and they might be better", with some additional work needed to align conventions in order to ensure that things in fact will not be worse. Best, Gard signature.asc Description: PGP signature
Re: Science Subgroups [was Re: Debian Math Team]
Hi Stuart, Thanks for replying, see below:- On Wed, Nov 03, 2021 at 08:38:10PM +1100, Stuart Prescott wrote: I'll start from here, > However, the disadvantages of separate teams are > > - differing conventions in each team around VCS layout, interactions etc We adopt the policy of the science team, so the VCS layout will essentially be the same. So this will not have any delta with what science team is doing currently. > - niceties around team upload vs NMU reduces the number of people who feel > able to help with the packages I already added several active and interested DDs to the salsa group already, and added you just now. I also have owner permissions in other teams, and from time to time me and others keep looking at pending requests so I expect it to be a low friction process here. > - fewer people looking at packages across the inevitably-smaller teams That's a valid point, but I think we need to see the other side of the story here as well. There are a few people who are really interested in maintaining math software, and having a separate team makes our work easier in seeking for those packages and fixing, rather than say, searching for math software in a huge pile, right. I could agree that there will initially be a few people looking after, but I do expect this team to grow, like several other teams in Debian have too. Maybe Andreas could give better pointers here. > Separate teams are optimised for the "main" maintainer of a handful of > packages who doesn't routinely work on any other packages; they are optimised > _against_ bugsquashers, generalists or people trying to land big projects > across large sets of packages. I'm not sure how that's true, would you mind explaining a bit? > Collectively, we need to make big changes on a regular basis (GCC bumps, > large > transitions, Python 2 removal, ...) and for each of them we need people to be > able to work on lots of packages with minimal friction. In the recent Python > 2 > removal work, for instance, it was easy for me to work on debian-science > packages as I've been a team member since the dawn of time. Working with > packages in the smaller teams was *much* more work involving additional git > dances, MRs or BTS round-trips. Okay, I see. But since we adopt essentially the same policy, and the same layout, it'd be painless for most folks to do any changes here, with minimal efforts. > There were also fewer people looking at those > packages and it was more likely that there was lots of outstanding QA work, > unpackaged upstream versions and packages effectively maintained by NMU. I think this is repeating the same argument made above again, that we've fewer people, I'd simply say that many active people in other blends projects (like -med, -science et. al.) are also involved here, and there are good chances that it grows with time. I can very well understand your fears that some of our packages undergo bitrot, but then I've two thinsg to point at. First, its not like the science team has all packages in excellent condition - from my experience of contributing in the science team for around two years, I've found several packages lying around, broken. It's not an opinion, its a fact UDD and bug tracker show proofs. I'm not pointing fingers at anyone here, please assume my best of intentions here. Second, having a separate team with dedicated set of people working on it can make the condition better. In the best case, we will see nice QA, in the worst case, I don't expect stuff to change drastically. Again, please consider good intention here. > We should remember that having blends packages, blends web pages and > informative wiki pages are completely independent of having a defined team > with > separate VCS and mailing list. All that needs is one or more people to curate > them. That's correct. I talked with Andreas yesterday on the debian-med bi-weekly call, and tasks for math packages should be done soonish :) Let me know if you need more explanation and/or discussion, and I'll be more than happy to do so. With best regards, Nilesh signature.asc Description: PGP signature
Re: Science Subgroups [was Re: Debian Math Team]
Hi folks From this discussion it seems that the main advantages of separate teams are - bespoke views of packages via tracker/dppo/udd - mailing lists where the signal:noise is higher (if you're lucky) However, the disadvantages of separate teams are - differing conventions in each team around VCS layout, interactions etc - niceties around team upload vs NMU reduces the number of people who feel able to help with the packages - fewer people looking at packages across the inevitably-smaller teams Separate teams are optimised for the "main" maintainer of a handful of packages who doesn't routinely work on any other packages; they are optimised _against_ bugsquashers, generalists or people trying to land big projects across large sets of packages. These are some of the biggest annoyances of package maintenance in Debian and are what make it very hard to produce a good quality distribution. Collectively, we need to make big changes on a regular basis (GCC bumps, large transitions, Python 2 removal, ...) and for each of them we need people to be able to work on lots of packages with minimal friction. In the recent Python 2 removal work, for instance, it was easy for me to work on debian-science packages as I've been a team member since the dawn of time. Working with packages in the smaller teams was *much* more work involving additional git dances, MRs or BTS round-trips. There were also fewer people looking at those packages and it was more likely that there was lots of outstanding QA work, unpackaged upstream versions and packages effectively maintained by NMU. We should remember that having blends packages, blends web pages and informative wiki pages are completely independent of having a defined team with separate VCS and mailing list. All that needs is one or more people to curate them. On Tuesday, 2 November 2021 20:55:47 AEDT Timo Röhling wrote: [...] > As one of the "instigators" of the new Debian Robotics Team, I like > this idea very much and we will adopt it, too. That's excellent news :) > Jochen and I also discussed that we would like to consider the > Robotics Team more of a subgroup of the Science Team rather than a > completely independent team. I think that's an excellent idea! > Maybe this concept might also work for the Math Team and other > science-related groups? Yes please! I believe that we should think of this as good practice for maintenance of scientific software in Debian and that we should encourage all the other science-related teams to do this. Scientific software in Debian has a bit of a reputation problem that stems from many different causes that include upstream motivations, the vagaries of research funding, non-expert development work… but also because we are spread too thinly in Debian maintenance and many of our teams are nothing more than a VCS namespace and not actual teams. Making subgroups with a common way of working (i.e. policy) and having more permissive salsa configurations could help us a lot. cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: Debian Math Team
On Tue 02 Nov 2021 04:08:32 AM EDT, Nilesh Patra wrote: On Mon, Nov 01, 2021 at 08:57:21PM +, Torrance, Douglas wrote: On Mon 01 Nov 2021 04:35:36 PM EDT, Nilesh Patra wrote: > On Mon, Nov 01, 2021 at 09:20:18PM +0100, Julien Puydt wrote: > > H... for each package, the Maintainer field in d/control should > > probably be changed to -- "Debian Math Team > > > > The much better option would be to use instead. > So as to avoid large volumes of processing emails onto the main mailing list. > > Both golang and python teams use something similar, > "" and "" respectively. I agree. I went ahead and started a draft of a team policy including this as the Maintainer address [1]. It's just a fork of the Debian Science policy and still needs a lot of work. The source is at [2]. Please feel free to suggest/make changes! I also created a wiki page here[3] Feel free to edit this as needed. I somewhat agree with Ole on the policy thingy, maybe this is just extra work. So for now, on the wiki I simply stated that we adopt the policy of science team. This seems like a good! I went ahead and un-published the policy draft that was briefly at [1]. I also added a link to the list of all teams at [4]. Doug [1] https://math-team.pages.debian.net/policy/ [2] https://salsa.debian.org/math-team/policy [3]: https://wiki.debian.org/DebianMath [4] https://wiki.debian.org/Teams signature.asc Description: PGP signature
Re: Debian Math Team
Am Tue, Nov 02, 2021 at 08:04:40AM +0100 schrieb Ole Streicher: > I'd really disagree here. We should avoid a fragmentation of the policy > without a really good reason. This makes it difficult for people to step > in, as they have to learn all the small differences in the team > policy. And it is hard to find them in the full text. I agree that it would be great to settle with some common policy and a minimum set of necessary deviations like Salsa repository and Maintainer field and whatever. Unfortunately I'm not sure that Debian Science policy is written in a way that this is easily possible. So we should probably work on this (and than adapt not only Debian Mathematics policy but also Debian Med and others). > Instead, I would suggest to keep (and improve) the Science Team policy, > and then to have a *tiny* Math team policy, which could just be a > 5..10-liner, like > > | We inherit the Science Team policy, except: > | * The maintainer field should be set to > | "Debian Math Team ". > | * The VCS location is in the Salsa namespace > | https://salsa.debian.org/math-team/ > > Having many nearly-identical policies for relatively small teams > otherwise creates problems in consistency, and I am afraid that useful > changes are not always "upstreamed" to the science umbrella otherwise. > > I would also suggest (also for the science team policy) that a package > under team maintainance *must* be git version controlled and under the > team's namespace. I'm a fan of clearly outspoken must. :-) I'm guilty for a couple of "team-hijacks" in the past and besides one single case where an outsider told me that I'm not permitted to do this (which is technically correct) this was good for the packages and for the users of the packages. > I would (again, also for science team) not put the metapackages into the > policy, as the policy should remain rather stable, but the metapackages > are ongoing work. Amen. ;-) Kind regards Andreas. -- http://fam-tille.de
Science Subgroups [was Re: Debian Math Team]
* Ole Streicher [2021-11-02 08:04]: Instead, I would suggest to keep (and improve) the Science Team policy, and then to have a *tiny* Math team policy, which could just be a 5..10-liner, like | We inherit the Science Team policy, except: | * The maintainer field should be set to | "Debian Math Team ". | * The VCS location is in the Salsa namespace | https://salsa.debian.org/math-team/ As one of the "instigators" of the new Debian Robotics Team, I like this idea very much and we will adopt it, too. Jochen and I also discussed that we would like to consider the Robotics Team more of a subgroup of the Science Team rather than a completely independent team. Like the Math Team, we are mostly looking to improve the outside visibility of our field and attract more collaboration. (Personally, I also like the convenience of the dedicated package overviews on the PTS and DDPO pages). This means we will allow Team Uploads from Science Team members (and I'll add the Science Team as member to our Salsa namespace to reflect that); of course, we encourage regular contributors to directly join our team, so we have a better idea who is interested in the continued work on robotics-related packages. Maybe this concept might also work for the Math Team and other science-related groups? Cheers Timo -- ⢀⣴⠾⠻⢶⣦⠀ ╭╮ ⣾⠁⢠⠒⠀⣿⡁ │ Timo Röhling │ ⢿⡄⠘⠷⠚⠋⠀ │ 9B03 EBB9 8300 DF97 C2B1 23BF CC8C 6BDD 1403 F4CA │ ⠈⠳⣄ ╰╯ signature.asc Description: PGP signature
Re: Debian Math Team
On Mon, Nov 01, 2021 at 08:57:21PM +, Torrance, Douglas wrote: > On Mon 01 Nov 2021 04:35:36 PM EDT, Nilesh Patra wrote: > > On Mon, Nov 01, 2021 at 09:20:18PM +0100, Julien Puydt wrote: > > > H... for each package, the Maintainer field in d/control should > > > probably be changed to -- "Debian Math Team > > > > > > The much better option would be to use > > instead. > > So as to avoid large volumes of processing emails onto the main mailing > > list. > > > > Both golang and python teams use something similar, > > "" and "" > > respectively. > > I agree. I went ahead and started a draft of a team policy including this as > the > Maintainer address [1]. It's just a fork of the Debian Science policy and > still needs a lot > of work. The source is at [2]. Please feel free to suggest/make changes! I also created a wiki page here[3] Feel free to edit this as needed. I somewhat agree with Ole on the policy thingy, maybe this is just extra work. So for now, on the wiki I simply stated that we adopt the policy of science team. > [1] https://math-team.pages.debian.net/policy/ > [2] https://salsa.debian.org/math-team/policy [3]: https://wiki.debian.org/DebianMath Nilesh signature.asc Description: PGP signature
Re: Debian Math Team
"Torrance, Douglas" writes: > I went ahead and started a draft of a team policy including this as > the Maintainer address [1]. It's just a fork of the Debian Science > policy and still needs a lot of work. The source is at [2]. Please > feel free to suggest/make changes! I'd really disagree here. We should avoid a fragmentation of the policy without a really good reason. This makes it difficult for people to step in, as they have to learn all the small differences in the team policy. And it is hard to find them in the full text. Instead, I would suggest to keep (and improve) the Science Team policy, and then to have a *tiny* Math team policy, which could just be a 5..10-liner, like | We inherit the Science Team policy, except: | * The maintainer field should be set to | "Debian Math Team ". | * The VCS location is in the Salsa namespace | https://salsa.debian.org/math-team/ Having many nearly-identical policies for relatively small teams otherwise creates problems in consistency, and I am afraid that useful changes are not always "upstreamed" to the science umbrella otherwise. I would also suggest (also for the science team policy) that a package under team maintainance *must* be git version controlled and under the team's namespace. I would (again, also for science team) not put the metapackages into the policy, as the policy should remain rather stable, but the metapackages are ongoing work. Cheers Ole
Re: Debian Math Team
On Mon 01 Nov 2021 04:35:36 PM EDT, Nilesh Patra wrote: On Mon, Nov 01, 2021 at 09:20:18PM +0100, Julien Puydt wrote: H... for each package, the Maintainer field in d/control should probably be changed to -- "Debian Math Team The much better option would be to use instead. So as to avoid large volumes of processing emails onto the main mailing list. Both golang and python teams use something similar, "" and "" respectively. I agree. I went ahead and started a draft of a team policy including this as the Maintainer address [1]. It's just a fork of the Debian Science policy and still needs a lot of work. The source is at [2]. Please feel free to suggest/make changes! [Probably the mailing-list should exist first] See bug#998244 and consider replying to it please, so as to raise interest in creation of this mailing list. Yes, please do! :) Doug [1] https://math-team.pages.debian.net/policy/ [2] https://salsa.debian.org/math-team/policy signature.asc Description: PGP signature
Re: Debian Math Team
On Mon, Nov 01, 2021 at 09:20:18PM +0100, Julien Puydt wrote: > Le lundi 01 novembre 2021 à 15:28 +0100, Andreas Tille a écrit : > > Hi Julien, > > > > Am Sun, Oct 31, 2021 at 04:15:28PM +0100 schrieb Julien Puydt: > > > For all packages in the debian science team, I'm ok with them > > > moving to > > > the new team. [I have no clue how to move them] > > > > How to move a package: > > > > In Salsa: > > > > Settings > > -> General > > -> Advanced [Expand] > > -> Transfer project > > > > This redirects users who are using the old URL. For sure you need > > the > > according permissions in both teams (not sure whether maintainer is > > sufficient or whether you need owner). > > > > > > H... for each package, the Maintainer field in d/control should > probably be changed to -- "Debian Math Team > instead. So as to avoid large volumes of processing emails onto the main mailing list. Both golang and python teams use something similar, "" and "" respectively. > [Probably the mailing-list should > exist first] See bug#998244 and consider replying to it please, so as to raise interest in creation of this mailing list. Thanks, Nilesh signature.asc Description: PGP signature
Re: Debian Math Team
Le lundi 01 novembre 2021 à 15:28 +0100, Andreas Tille a écrit : > Hi Julien, > > Am Sun, Oct 31, 2021 at 04:15:28PM +0100 schrieb Julien Puydt: > > For all packages in the debian science team, I'm ok with them > > moving to > > the new team. [I have no clue how to move them] > > How to move a package: > > In Salsa: > > Settings > -> General > -> Advanced [Expand] > -> Transfer project > > This redirects users who are using the old URL. For sure you need > the > according permissions in both teams (not sure whether maintainer is > sufficient or whether you need owner). > > H... for each package, the Maintainer field in d/control should probably be changed to -- "Debian Math Team
Re: Bug#998244: lists.debian.org: request for debian-math mailing list (was: Re: Debian Math Team)
Hi, I am interested in the creation of this list. The Debian Math Team is being created now; https://salsa.debian.org/math-team was created last week, it currently has 11 members. The need for this group (and list) has been discussed in the thread starting at https://lists.debian.org/msgid-search/87wnlvn3fg@piedmont.edu ; people expressed interest there. Thanks, Bye, Joost
Re: Debian Math Team
On Sun 31 Oct 2021 03:49:56 PM EDT, Nilesh Patra wrote: @Doug, do you intend asking out for a mailing list? Done! See https://bugs.debian.org/998244 signature.asc Description: PGP signature
Re: Debian Math Team
Hi Tobias, On Mon, Nov 01, 2021 at 09:52:19AM +, Tobias Hansen wrote: > On 10/31/21 7:49 PM, Nilesh Patra wrote: > > On Sun, Oct 31, 2021 at 04:15:28PM +0100, Julien Puydt wrote: > >> Perhaps the debian sagemath team should be merged in the math team? > > Yep, that was the plan. Hope sagemath folks agree there. > Hi, > > yeah, why not. In the best case it leads to more people helping to keep > sagemath updated. In the worst case, nothing much changes. Makes sense, do consider moving it whenever you see it as appropriate Nilesh signature.asc Description: PGP signature
Re: Debian Math Team
On Mon, Nov 01, 2021 at 03:44:32PM +0100, Joost van Baal-Ilić wrote: > I've just clicked > https://salsa.debian.org/groups/math-team/-/group_members/request_access and > got "Your request for access has been queued for review." Could you grant me > (user joostvb) access? Added you, Andreas Tille and Mo Zhou to the team. Thanks! > In the past I've maintained the mathatical package mcl, > I am interesting in contributing there soonish again. And I happen to be a > mathematician :) Awesome! Nilesh signature.asc Description: PGP signature
Re: Debian Math Team
Hi Doug, On Fri, Oct 29, 2021 at 05:31:20PM +, Torrance, Douglas wrote: > During the Debian Science BoF at this year's DebConf, there was some > discussion of creating a team devoted to packaging mathematical software. > > This seemed like a pretty good idea, so I figured that I'd go ahead and > start working on getting it set up. I've already created a Salsa group [1] > and a team on the Debian Package Tracker [2]. If you're interested in > joining, then you should be able to sign up at these links. > > I figured next would be applying for a mailing list, putting together a team > policy, etc. Any thoughts? > > Doug > > [1] https://salsa.debian.org/math-team > [2] https://tracker.debian.org/teams/math/ I've just clicked https://salsa.debian.org/groups/math-team/-/group_members/request_access and got "Your request for access has been queued for review." Could you grant me (user joostvb) access? In the past I've maintained the mathatical package mcl, I am interesting in contributing there soonish again. And I happen to be a mathematician :) Thanks, Bye, Joost PS: please post here once you've asked for mailing list creation, IIRC listmasters need public stated support by multiple people before list gets created.
Re: Debian Math Team
Hi Julien, Am Sun, Oct 31, 2021 at 04:15:28PM +0100 schrieb Julien Puydt: > But about moving things, my feelings are mixed. Indeed, this very week, > I joined the OCaml Team and packaged src:elpi there -- which is > mathematics software. But since it's written in OCaml, I feel it's > better to keep it in the language-specific team. >From time to time it makes sense to join a certain language team and leave some packages of a Blend there. For instance the Debian Med team has a couple of Perl packages maintained by the Perl team. That's fine and is a case by case decision what might make the most sense. I think also the Ruby team asked for taking over the bioruby package. The point of a Blend is to inform users about the available software inside Debian of a certain field. The Vcs location is not really an information that is very important for the user. Debian Med is pointing to several packages maintained by Debichem, Debian Science or also packages maintained by language teams. >From a developer point of view it comes handy to use a common Salsa team - but that's by no means "mandatory" and sensible exceptions should be made. > For all packages in the debian science team, I'm ok with them moving to > the new team. [I have no clue how to move them] How to move a package: In Salsa: Settings -> General -> Advanced [Expand] -> Transfer project This redirects users who are using the old URL. For sure you need the according permissions in both teams (not sure whether maintainer is sufficient or whether you need owner). > Perhaps the debian sagemath team should be merged in the math team? >From my naive perspective this makes perfectly sense and I would recommend this. Kind regards Andreas. -- http://fam-tille.de
Re: Debian Math Team
Hi Doug and other Debian Science team members, at first thanks a lot for the step you did. I think it is a move into the right direction. As far as I've read the worries about this step here in the thread these seem to be: 1. Another "one-man" team I think Ole gave a good answer here: Its not about creating a one-man team but rather attract more people to the team - from inside and outside Debian. For those who have any doubt that this can work: There are 23 people who confirmed, that they became DDs *because* Debian Med exists[4]. Debian Med is now nearly 20 years old. I would love if Debian Math would beat Debian Med in attracting new developers. (Andrius, you even belong to this set. ;-) ) Those 20 years when the Debian Med project have teached me that it is very important to advertise the fact to the world that Debian is targeting specific fields of science and IMHO mathematics is a) well worth to be advertised b) has lots of technically competent people beeing potential DDs 2. Further fragmentation of debian-science I do not think that another Blend will lead to fragmentation of Debian Science. Sure, some mathematics related packages will be moved sooner or later but I personally can not see in how far this might weaken Debian Science. I personally see also additional contributors for Debian Science once more mathematicans might join Debian (as I'm very positive about). Am Sat, Oct 30, 2021 at 06:18:28PM +0530 schrieb Nilesh Patra: > Hi Andrius, > > Thanks for replying. See below :- > > On Sat, Oct 30, 2021 at 10:33:02AM +0300, Andrius Merkys wrote: > > Hi, > > > > On 2021-10-29 20:31, Torrance, Douglas wrote: > > > During the Debian Science BoF at this year's DebConf, there was some > > > discussion of creating a team devoted to packaging mathematical software. > > > > I agree with Anton here. I do not see how further fragmentation of > > debian-science could benefit it. I missed the BoF, but maybe there are > > notes reflecting this decision? > > 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 +1 > 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 definitely see the need for improvement in the very generic tasks of Debian Science since science-mathematics (and science-mathematics-dev) are not really what users will be happy about. Doug, I'll happily give you a kick-start to create a sensible blends framework which enables more fine grained tasks (and by doing so a more fine QA toolset). > 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. ... which was my point 1. ;-) > 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 I can confirm Nilesh is extremely good in dealing with those! (Thanks Nilesh for all the QA work you are doing in Debian Med!) > 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. Absolutely! > > Separate team and separate mailing list will have less members than > > debian-science. > > Well, every other team has started exactly the same way in Debian (i.e. less > members) -- it would > grow with time, I don't think it'll be stalled for ever. > I could _somehat_ agree with the mailing list thingy, maybe we can > keep using this list for discussions. The start is definitely the hardest time and needs a lot of patience. I would encourage Doug to ask for list creation and I would lurk on this list. > > Furthermore, from my experience one does not need domain > > knowledge to successfully package and maintain packages in Debian. > > What makes more sense to me, is organizing packages into teams based on > > programming languages and build/test systems, as such teams indeed > > possess specific knowledge. I think most of the mails asking for help in > > debian-med concern language and build system problems, not > > domain-specific issues. > > I'm sorry, but I have to admit this
Re: Debian Math Team
On 10/31/21 7:49 PM, Nilesh Patra wrote: > On Sun, Oct 31, 2021 at 04:15:28PM +0100, Julien Puydt wrote: >> Perhaps the debian sagemath team should be merged in the math team? > Yep, that was the plan. Hope sagemath folks agree there. > > Nilesh Hi, yeah, why not. In the best case it leads to more people helping to keep sagemath updated. In the worst case, nothing much changes. Best, Tobias
Re: Debian Math Team
On Sun, Oct 31, 2021 at 04:15:28PM +0100, Julien Puydt wrote: > Hi, > Count me in on this team (on salsa & mailing-list). Added to salsa. @Doug, do you intend asking out for a mailing list? > But about moving things, my feelings are mixed. Indeed, this very week, > I joined the OCaml Team and packaged src:elpi there -- which is > mathematics software. But since it's written in OCaml, I feel it's > better to keep it in the language-specific team. Sure. > For all packages in the debian science team, I'm ok with them moving to > the new team. [I have no clue how to move them] I fiddled a bit, and figured out the way. Settings > General > Advanced > Transfer Now transfer it to the namespace you want. I just did it for python-pulp from science -> math (my package) > Perhaps the debian sagemath team should be merged in the math team? Yep, that was the plan. Hope sagemath folks agree there. Nilesh signature.asc Description: PGP signature
Re: [Debian-science-sagemath] Debian Math Team
I suppose there are a number of SageMath packages that can and should be moved to the new team, especially ones shared between it and, say, Macaulay2. Dima On Sun, 31 Oct 2021, 15:41 Julien Puydt, wrote: > Hi, > > Le vendredi 29 octobre 2021 à 17:31 +, Torrance, Douglas a écrit : > > During the Debian Science BoF at this year's DebConf, there was some > > discussion of creating a team devoted to packaging mathematical > > software. > > > > This seemed like a pretty good idea, so I figured that I'd go ahead > > and > > start working on getting it set up. I've already created a Salsa > > group [1] > > and a team on the Debian Package Tracker [2]. If you're interested > > in > > joining, then you should be able to sign up at these links. > > > > I figured next would be applying for a mailing list, putting together > > a team policy, etc. Any thoughts? > > > > [1] https://salsa.debian.org/math-team > > [2] https://tracker.debian.org/teams/math/ > > > Count me in on this team (on salsa & mailing-list). > > But about moving things, my feelings are mixed. Indeed, this very week, > I joined the OCaml Team and packaged src:elpi there -- which is > mathematics software. But since it's written in OCaml, I feel it's > better to keep it in the language-specific team. > > For all packages in the debian science team, I'm ok with them moving to > the new team. [I have no clue how to move them] > > Perhaps the debian sagemath team should be merged in the math team? > > Cheers, > > J.Puydt > > ___ > Debian-science-sagemath mailing list > debian-science-sagem...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-sagemath >
Re: Debian Math Team
Hi, Le vendredi 29 octobre 2021 à 17:31 +, Torrance, Douglas a écrit : > During the Debian Science BoF at this year's DebConf, there was some > discussion of creating a team devoted to packaging mathematical > software. > > This seemed like a pretty good idea, so I figured that I'd go ahead > and > start working on getting it set up. I've already created a Salsa > group [1] > and a team on the Debian Package Tracker [2]. If you're interested > in > joining, then you should be able to sign up at these links. > > I figured next would be applying for a mailing list, putting together > a team policy, etc. Any thoughts? > > [1] https://salsa.debian.org/math-team > [2] https://tracker.debian.org/teams/math/ Count me in on this team (on salsa & mailing-list). But about moving things, my feelings are mixed. Indeed, this very week, I joined the OCaml Team and packaged src:elpi there -- which is mathematics software. But since it's written in OCaml, I feel it's better to keep it in the language-specific team. For all packages in the debian science team, I'm ok with them moving to the new team. [I have no clue how to move them] Perhaps the debian sagemath team should be merged in the math team? Cheers, J.Puydt
Re: Debian Math Team
On Sun, 31 Oct 2021 at 16:18, Jerome BENOIT wrote: > Hello, > > please add me to the math team as well: > > calculus > Done. > I will migrate my math packages on the the go. > Sure! Nilesh
Re: Debian Math Team
Hello, please add me to the math team as well: calculus I will migrate my math packages on the the go. On 30/10/2021 22:28, Nilesh Patra wrote: On Sat, Oct 30, 2021 at 05:05:32PM +0200, Gard Spreemann wrote: Hi, That being said, my opinion on the matter is not a strong one, and if a math team is indeed formed, please do add me to it (Salsa user "gspr"). Done, thanks! I currently maintain the following math packages: gudhi, hera, lbfgsb, phat, python-pot, ripser. Do consider moving $things there. Regards, Nilesh Cheers, Jerome -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Re: Debian Math Team
On Sat, Oct 30, 2021 at 05:05:32PM +0200, Gard Spreemann wrote: Hi, > That being said, my opinion on the matter is not a strong > one, and if a math team is indeed formed, please do add me to it (Salsa > user "gspr"). Done, thanks! > I currently maintain the following math packages: gudhi, hera, lbfgsb, > phat, python-pot, ripser. Do consider moving $things there. Regards, Nilesh signature.asc Description: PGP signature
Re: Debian Math Team
Torrance, Douglas writes: > During the Debian Science BoF at this year's DebConf, there was some > discussion of creating a team devoted to packaging mathematical software. > > This seemed like a pretty good idea, so I figured that I'd go ahead and > start working on getting it set up. I've already created a Salsa group [1] > and a team on the Debian Package Tracker [2]. If you're interested in > joining, then you should be able to sign up at these links. > > I figured next would be applying for a mailing list, putting together a team > policy, etc. Any thoughts? Hi Douglas, Nice initiative! I do think I agree with the comments made by others about fragmentation thoguh; to me it would probably even make sense to have the science, med, AI, and math teams all together in one big lump (the "computational software" team?), rather than adding yet another separate one. That being said, my opinion on the matter is not a strong one, and if a math team is indeed formed, please do add me to it (Salsa user "gspr"). I currently maintain the following math packages: gudhi, hera, lbfgsb, phat, python-pot, ripser. Best, Gard signature.asc Description: PGP signature
Re: Debian Math Team
Hi On Sat, Oct 30, 2021 at 11:26:32AM +0200, Ole Streicher wrote: > Anton Gladky writes: > > well, I think that it just increases a fragmentation. > > Based on my own experience with debian-astro, I don't see this as a > problem: If there is enough enhusiasm, an own blend gives much more > possibilities and a more fine-grained structure for packaging, and a > higher visibility. And it gives people a higher motivation to > contribute. > > I still think that "debian-science" is a kind-of umbrella blend, which > is the parent of other science blends (like d-astro), but also the > default for packages that don't have another specific blend. > > For the team policy, I would recommend to inherit the science team > policy. Full ACK, thanks for sharing. > BTW; It tried to join the salsa group but couldn't. Could someone add me > please? Added, thanks :) Nilesh signature.asc Description: PGP signature
Re: Debian Math Team
Hi, On Sat, Oct 30, 2021 at 02:52:25PM +0300, Andrius Merkys wrote: > On 2021-10-30 14:45, Anton Gladky wrote: >>From my point of view, we have enough really useful work in Debian which >> needs to be done (fixing bugs, adding autopkgtests, setting-up >> CI-pipelines etc.) >> instead of moving packages between teams. ... and setting up a separate team could ease-off looking at those issues, and fixing them quicky, making better quality math software for end users. While otherwise I'd be looking up for specific packages in a huge pile.. > Couldn't agree more. Uploader agreement to moving is a must, IMO. Ofcourse, no-one is doing a hostile takeover here. Nilesh signature.asc Description: PGP signature
Re: Debian Math Team
Hi Andrius, Thanks for replying. See below :- On Sat, Oct 30, 2021 at 10:33:02AM +0300, Andrius Merkys wrote: > Hi, > > On 2021-10-29 20:31, Torrance, Douglas wrote: > > During the Debian Science BoF at this year's DebConf, there was some > > discussion of creating a team devoted to packaging mathematical software. > > I agree with Anton here. I do not see how further fragmentation of > debian-science could benefit it. I missed the BoF, but maybe there are > notes reflecting this decision? 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 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) 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. 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 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. > Separate team and separate mailing list will have less members than > debian-science. Well, every other team has started exactly the same way in Debian (i.e. less members) -- it would grow with time, I don't think it'll be stalled for ever. I could _somehat_ agree with the mailing list thingy, maybe we can keep using this list for discussions. > Furthermore, from my experience one does not need domain > knowledge to successfully package and maintain packages in Debian. > What makes more sense to me, is organizing packages into teams based on > programming languages and build/test systems, as such teams indeed > possess specific knowledge. I think most of the mails asking for help in > debian-med concern language and build system problems, not > domain-specific issues. 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? The whole point of blends is to help people with "specific" needs, right. and such teams help organize that in a reliable way. 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. > I am worried reading about R packages being moved from debian-r to new > debian-math. I am afraid doing so might negatively impact their quality. You are right in your worries, but I have some statistics to present here. See here[1] or more specifically, look here[2,3] You would notice that in recent times, the most active people there (Andreas, myself, Steffen, Dylan etc) are also the members of debian-med and also the members of debian-science. And if we have a math team, I'm sure atleasts some of these people would be involved there. 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. However if you very strongly feel about it, we could leave the R packages where they are and continue maintaining them under R package umbrella. Should you want more explanation, do let me know and I'll be happy to discuss. [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 Nilesh signature.asc Description: PGP signature
Re: Debian Math Team
Hi all, I found this quote of myself from 2007: > Last year, I was thinking about starting something like « Debian > Biology », and Andreas Tille suggested me to join the Debian-Med project > instead. I think that I would hardly have acheived anyhing if I had not > listened to his advice. https://lists.debian.org/debian-blends/2007/02/msg00014.html Have a nice week-end ! Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Debian Math Team
While I agree, this may also be good thing. There will be more Sprints (I hope) with then more people that are brought to our community at large. And Debian so far does very well in keeping all those fragments together. Best, Steffen On 30.10.21 01:55, Anton Gladky wrote: Hi Doug, well, I think that it just increases a fragmentation. But it is up to you. Best regards Anton Am Fr., 29. Okt. 2021 um 22:04 Uhr schrieb Torrance, Douglas : During the Debian Science BoF at this year's DebConf, there was some discussion of creating a team devoted to packaging mathematical software. This seemed like a pretty good idea, so I figured that I'd go ahead and start working on getting it set up. I've already created a Salsa group [1] and a team on the Debian Package Tracker [2]. If you're interested in joining, then you should be able to sign up at these links. I figured next would be applying for a mailing list, putting together a team policy, etc. Any thoughts? Doug [1] https://salsa.debian.org/math-team [2] https://tracker.debian.org/teams/math/
Re: Debian Math Team
On 2021-10-30 14:45, Anton Gladky wrote: > I do not see any benefits from creating a one-more team. It decreases > definitely bus-factor of the package, will unlikely increase their quality > and for end-users it is mostly not visible, in what team it is maintained. > > Sure, feel free to create it, if you want, but please do not move any existing > packages from any team to a new one without prior confirmation of all > uploaders. > >>From my point of view, we have enough really useful work in Debian which > needs to be done (fixing bugs, adding autopkgtests, setting-up > CI-pipelines etc.) > instead of moving packages between teams. Couldn't agree more. Uploader agreement to moving is a must, IMO. Best, Andrius
Re: Debian Math Team
I do not see any benefits from creating a one-more team. It decreases definitely bus-factor of the package, will unlikely increase their quality and for end-users it is mostly not visible, in what team it is maintained. Sure, feel free to create it, if you want, but please do not move any existing packages from any team to a new one without prior confirmation of all uploaders. >From my point of view, we have enough really useful work in Debian which needs to be done (fixing bugs, adding autopkgtests, setting-up CI-pipelines etc.) instead of moving packages between teams. Cheers Anton
Re: Debian Math Team
Anton Gladky writes: > well, I think that it just increases a fragmentation. Based on my own experience with debian-astro, I don't see this as a problem: If there is enough enhusiasm, an own blend gives much more possibilities and a more fine-grained structure for packaging, and a higher visibility. And it gives people a higher motivation to contribute. I still think that "debian-science" is a kind-of umbrella blend, which is the parent of other science blends (like d-astro), but also the default for packages that don't have another specific blend. For the team policy, I would recommend to inherit the science team policy. BTW; It tried to join the salsa group but couldn't. Could someone add me please? Cheers Ole
Re: Debian Math Team
Hi, On 2021-10-29 20:31, Torrance, Douglas wrote: > During the Debian Science BoF at this year's DebConf, there was some > discussion of creating a team devoted to packaging mathematical software. I agree with Anton here. I do not see how further fragmentation of debian-science could benefit it. I missed the BoF, but maybe there are notes reflecting this decision? Separate team and separate mailing list will have less members than debian-science. Furthermore, from my experience one does not need domain knowledge to successfully package and maintain packages in Debian. What makes more sense to me, is organizing packages into teams based on programming languages and build/test systems, as such teams indeed possess specific knowledge. I think most of the mails asking for help in debian-med concern language and build system problems, not domain-specific issues. Thus I am very comfortable keeping my math packages in per-language teams knowing that these teams will take good care of them if needed. I am worried reading about R packages being moved from debian-r to new debian-math. I am afraid doing so might negatively impact their quality. Best, Andrius
Re: Debian Math Team
On Sat, 30 Oct, 2021, 12:27 pm Ben Tris, wrote: > Just want to notice > > Debian Science > https://blends.debian.org/science/tasks/mathematics > https://blends.debian.org/science/tasks/mathematics-dev > Debian edu > https://blends.debian.org/edu/tasks/mathematics > > Debian packages has a mathematics category > https://www.gezapig.nl/Software/Special/Debian_Categories.html > Made a mathematics category based on debian category and some maintainer > groups. > https://www.gezapig.nl/Software/Category/Mathematics2021.html Thanks a lot for this! This would help us to decide on the packages to move/take-over into math team. Nilesh
Re: Debian Math Team
Just want to notice Debian Science https://blends.debian.org/science/tasks/mathematics https://blends.debian.org/science/tasks/mathematics-dev Debian edu https://blends.debian.org/edu/tasks/mathematics Debian packages has a mathematics category https://www.gezapig.nl/Software/Special/Debian_Categories.html Made a mathematics category based on debian category and some maintainer groups. https://www.gezapig.nl/Software/Category/Mathematics2021.html > Op 29-10-2021 19:31 schreef Torrance, Douglas : > > > During the Debian Science BoF at this year's DebConf, there was some > discussion of creating a team devoted to packaging mathematical software. > > This seemed like a pretty good idea, so I figured that I'd go ahead and > start working on getting it set up. I've already created a Salsa group [1] > and a team on the Debian Package Tracker [2]. If you're interested in > joining, then you should be able to sign up at these links. > > I figured next would be applying for a mailing list, putting together a team > policy, etc. Any thoughts? > > Doug > > [1] https://salsa.debian.org/math-team > [2] https://tracker.debian.org/teams/math/
Re: Debian Math Team
Hi Doug, well, I think that it just increases a fragmentation. But it is up to you. Best regards Anton Am Fr., 29. Okt. 2021 um 22:04 Uhr schrieb Torrance, Douglas : > > During the Debian Science BoF at this year's DebConf, there was some > discussion of creating a team devoted to packaging mathematical software. > > This seemed like a pretty good idea, so I figured that I'd go ahead and > start working on getting it set up. I've already created a Salsa group [1] > and a team on the Debian Package Tracker [2]. If you're interested in > joining, then you should be able to sign up at these links. > > I figured next would be applying for a mailing list, putting together a team > policy, etc. Any thoughts? > > Doug > > [1] https://salsa.debian.org/math-team > [2] https://tracker.debian.org/teams/math/
Re: Debian Math Team
Hi Doug, Thanks for doing this! On Fri, Oct 29, 2021 at 05:31:20PM +, Torrance, Douglas wrote: > During the Debian Science BoF at this year's DebConf, there was some > discussion of creating a team devoted to packaging mathematical software. > > This seemed like a pretty good idea, so I figured that I'd go ahead and > start working on getting it set up. I've already created a Salsa group [1] > and a team on the Debian Package Tracker [2]. > If you're interested in > joining, then you should be able to sign up at these links. I requested access on salsa, please consider adding me with access level >= maintainer and signed up at the tracker too. > I figured next would be applying for a mailing list, putting together a team > policy, etc. Any thoughts? As discussed privately as well, I think these are the tasks: == Main tasks == * Creating a debian-m...@lists.debian.org mailing list * If possible, ask for an alioth mailing list for tracking packaging changes * Setting up a wiki page about the team, pointing to various links (mailing list, salsa, policy et. al.) * Moving math related packages from science -> math team on salsa and on tracker + We need to make a list here. Some math packages in science team, some in R team + Sagemath has a separate mailing list, and it might make sence to merge them * Setting up a policy -- which we could largely inherit from the science-team one * Updating and uploading math-team packages * Seek more volunteers :) == Additional tasks for blends == * Creating a debian-math metapackage * Add math to blends team and track the qa stuff @Andreas (in CC), can you help setting up the latter part? If someone has more suggestions, and would like helping, please let us know. Kind Regards, Nilesh signature.asc Description: PGP signature
Debian Math Team
During the Debian Science BoF at this year's DebConf, there was some discussion of creating a team devoted to packaging mathematical software. This seemed like a pretty good idea, so I figured that I'd go ahead and start working on getting it set up. I've already created a Salsa group [1] and a team on the Debian Package Tracker [2]. If you're interested in joining, then you should be able to sign up at these links. I figured next would be applying for a mailing list, putting together a team policy, etc. Any thoughts? Doug [1] https://salsa.debian.org/math-team [2] https://tracker.debian.org/teams/math/ signature.asc Description: PGP signature
