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: 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: 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: 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: 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: 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: 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: 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
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: 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: 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
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
