Re: Suggesting change in DPT policy
On February 27, 2024 2:27:35 PM UTC, Scott Talbert <swt@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+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.
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
Reply to: