[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: