Path: csiph.com!fu-berlin.de!bofh.it!news.nic.it!robomod From: Scott Talbert Newsgroups: linux.debian.maint.python Subject: Re: Suggesting change in DPT policy Date: Tue, 27 Feb 2024 15:30:02 +0100 Message-ID: References: X-Mailbox-Line: From debian-python-request@lists.debian.org Tue Feb 27 14:28:01 2024 Old-Return-Path: X-Amavis-Spam-Status: No, score=-2.11 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FOURLA=0.1, LDO_WHITELIST=-5, META_ATTENDEES_DBSPAM1=5, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no X-Policyd-Weight: using cached result; rate: -4.6 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Mailing-List: archive/latest/21474 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/e12c01-e27d-1e2-daf-3eef9a8bcbf6@techie.net Approved: robomod@news.nic.it Lines: 124 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Cc: Debian Python X-Original-Date: Tue, 27 Feb 2024 09:27:35 -0500 (EST) X-Original-Message-ID: X-Original-References: <80455cbe-cc13-4240-8517-f9ba0512c32e@debian.org> Xref: csiph.com linux.debian.maint.python:15496 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+python@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. Regards, Scott