On February 27, 2024 2:27:35 PM UTC, Scott Talbert <s...@techie.net> wrote: >On Tue, 27 Feb 2024, Thomas Goirand wrote: > >> On 2/27/24 09:05, Andreas Tille wrote: >>> Hi, >>> >>> I became more deeply involved into DPT since 2022 as a consequence of >>> the suggestion for transfering several Debian Med/Science packages to >>> DPMT[1][2]. I happily followed this suggestion and moved >30 packages >>> from the Blends teams to DPT. I was happy with this move since it makes >>> sense. >>> >>> Recently we received lots of testing removal warnings in those Blends >>> teams due to RC bugs caused by Cython 3.0 and Python3.12 migrations. So >>> I did what I usually do in those teams: I dedicated quite some time in >>> team wide bug hunting. That way I squashed about 50 bugs on packages >>> where I was not in Uploaders. When doing so I usually run >>> routine-update on the package which basically streamlines packaging to >>> latest standards including calling Janitor tools which are so far >>> accepted inside DPT. >>> >>> I probably should have reviewed the DPT policy on Maintainership[3] more >>> carefully. In other teams, it's common for the Maintainer to be set to >>> the team, so I assumed it was just an oversight when I made this >>> change[4] when touching the package to fix RC bug #1058177. However, I >>> I was pointed immediately about the fact that I was mistaken according >>> to the current DPT policy. I apologize for this. However, the wording >>> of the comment on my commit was discouraging, especially considering I >>> was a volunteer who had fixed a critical bug. Because of this, I >>> decided to focus my efforts on fixing other critical bugs for the >>> moment. If the comment had started with a 'Thanks for fixing the >>> critical bug, but...' I likely would have corrected my mistake quickly. >>> The lack of respect from my teammate simply made me prioritize my time >>> on other issues that are more visible to our users. I wonder whether I >>> should propose another change to the policy about maintaining a kind and >>> polite language inside the team - but that's a different thing. >>> >>> While I applied the patch for another RC bug (#1063443) after >2 weeks >>> which triggered a RC bug in reportbug I remembered the "keep the >>> maintainer" policy. But I kept on doing Janitor like changes since >>> finally the package is maintained in a team where Janitor is accepted. >>> When doing so I failed the phrase "please contact the Maintainer for the >>> green light." I apoligize for this again. The response was another >>> volunteer-demotivating private mail (thus no quote) which also was >>> lacking the "Thanks for fixing"-phrase and degrading my changes as >>> "frivolous". >>> >>> So far what happened (seen from my possibly biased perspective). >>> >>> Why do I like to change the policy? >>> >>> The current wording provides some means to stop volunteer team members >>> helping out moving forward to speed up migrations and fix Debian wide >>> dependencies. It hides team maintained packages from a common BTS >>> view. When pointing my browser to >>> https://bugs.debian.org/team+pyt...@tracker.debian.org >>> I currently see 1339 open bugs (calculated by [UDD1]). This hides >>> another 309 [UDD2] bugs (>18% of team bugs) from our sight. To work >>> around this flaw I used an UDD query to find relevant Python3.12 bugs. >>> >>> When I think twice about the wording >>> Team in Uploaders is a weak statement of collaboration.[3] >>> I personally consider it a statement of *no* collaboration (which fits >>> the wording of the responses I've got). >>> >>> How can a team member for instance find another RC bug #1009424? Just >>> from reading the bug report it is pretty easy to fix but does not >>> feature any response in BTS. I came across this while looking into >>> Cython 3.0 bugs. The same source package (basemap) that had the open >>> Cython bug (#1056789, tagged patch since 2023-12-09) is featuring RC bug >>> (#1009424) that stayed unattended for 22 months? We all know volunteers >>> have limited time and I do not want to blame anybody in the team to not >>> care promptly about RC bugs. But what else is the sense of a packaging >>> team than stepping in situations for long standing RC bugs and RC bugs >>> tagged patch? >>> >>> This kind of situation wouldn't occur in teams where collaboration is >>> strong and communication is effective. My motivation to address these >>> long-ignored critical bugs diminishes when the maintainer opts for >>> "weak" cooperation and lacks respectful communication with potential >>> helpers. I see no difference to simply do a NMU. >>> >>> I've checked the current situation who is actually using the DPT team as >>> Uploaders[UDD3]. 66 of the 73 maintainers have less than 5 packages >>> some of these "Maintainers" are other teams and lots of the persons >>> listed as Maintainer are known to be MIA. This means the packages are >>> de-facto not maintained which is most probably an unwanted effect of the >>> current policy. I know other maintainers from other teams to be fine >>> with stronger team understanding. >>> >>> Since I consider the current situation as demotivating for newcomers >>> as well as long standing contributors I would like to suggest to drop >>> this "weak statement of collaboration" option from policy. I've attached >>> an according patch to the team policy[5]. I'm fine with creating a MR >>> to be discussed rather in Salsa than this mailing list - whatever seems >>> worthwhile to you. >>> >>> Kind regards >>> Andreas. >> >> Hi Andreas, >> >> I had similar experience, and the same kind of demotivating response from >> the same person. So I'm not surprised. >> >> It's been a long long time that I would have like this DPT policy to go >> away, but didn't dare to raise the topic. Though indeed, I don't think it's >> reasonable to have a package in the team, but with strong ownership. I >> believe that we should either have a package in the team, or not. Period. >> >> If someone isn't happy about this policy change, it's ok to move the package >> way from the team, if having team-mate working on "your" package isn't ok >> (of course, we would all prefer this doesn't happen, and that we work >> collaboratively). This would make things a way clearer. >> >> So I'm 100% with you for the removal of this policy. >> >> To everyone else in the team: please also state your opinion, so we can make >> a collective decision. > >I agree with both of you. I think packages should be team maintained or not >at all. No middle area.
While I do take advantage of this for a few packages, I don't personally care much either way. I suspect that packages will be removed from team maintenance as a result though and I think that's a bad idea. I'd prefer the current approach over people removing packages from the team, so I think it's important that anyone who feels strongly enough about this to do so, speak up. Scott K
