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
