Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.maint.python > #15502

Re: Suggesting change in DPT policy

From Scott Kitterman <debian@kitterman.com>
Newsgroups linux.debian.maint.python
Subject Re: Suggesting change in DPT policy
Date 2024-02-27 19:40 +0100
Message-ID <IcawW-d2gs-3@gated-at.bofh.it> (permalink)
References <Ic0Hf-cWrX-1@gated-at.bofh.it> <Ic6D0-cZX8-11@gated-at.bofh.it> <Ic6D0-cZX8-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Back to linux.debian.maint.python | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Suggesting change in DPT policy Andreas Tille <andreas@an3as.eu> - 2024-02-27 09:10 +0100
  Re: Suggesting change in DPT policy Scott Talbert <swt@techie.net> - 2024-02-27 15:30 +0100
    Re: Suggesting change in DPT policy Scott Kitterman <debian@kitterman.com> - 2024-02-27 19:40 +0100
      Re: Suggesting change in DPT policy Scott Kitterman <debian@kitterman.com> - 2024-02-28 01:00 +0100
        Re: Suggesting change in DPT policy Andreas Tille <andreas@an3as.eu> - 2024-02-28 08:10 +0100
          Re: Suggesting change in DPT policy Scott Kitterman <debian@kitterman.com> - 2024-02-28 12:50 +0100
            Re: Suggesting change in DPT policy Andreas Tille <andreas@an3as.eu> - 2024-02-28 15:40 +0100
        Re: Suggesting change in DPT policy Scott Kitterman <debian@kitterman.com> - 2024-02-28 13:00 +0100
      Re: Suggesting change in DPT policy Jeroen Ploemen <jcfp@debian.org> - 2024-02-29 20:50 +0100
        Re: Suggesting change in DPT policy Julian Gilbey <julian@d-and-j.net> - 2024-03-01 08:30 +0100
          Re: Suggesting change in DPT policy Jeroen Ploemen <jcfp@debian.org> - 2024-03-01 13:10 +0100
            Re: Suggesting change in DPT policy Andreas Tille <tille@debian.org> - 2024-03-02 21:40 +0100
              Re: Suggesting change in DPT policy Scott Kitterman <debian@kitterman.com> - 2024-03-02 22:20 +0100
                Re: Suggesting change in DPT policy Andreas Tille <andreas@an3as.eu> - 2024-03-02 23:20 +0100
                Re: Suggesting change in DPT policy Andreas Tille <andreas@an3as.eu> - 2024-03-03 07:20 +0100
                Re: Suggesting change in DPT policy Scott Kitterman <debian@kitterman.com> - 2024-03-03 18:20 +0100
  +1 (Re: Suggesting change in DPT policy) Jochen Sprickerhof <jspricke@debian.org> - 2024-02-27 15:40 +0100
  Re: Suggesting change in DPT policy Timo Röhling <roehling@debian.org> - 2024-02-27 16:10 +0100
    Re: Suggesting change in DPT policy Andreas Tille <andreas@an3as.eu> - 2024-02-28 08:20 +0100
      Re: Suggesting change in DPT policy Étienne Mollier <emollier@debian.org> - 2024-02-28 09:40 +0100
        Maintaining packages with complex relationships (Was: Suggesting  change in DPT policy) Andreas Tille <andreas@an3as.eu> - 2024-02-28 12:00 +0100
          Re: Maintaining packages with complex relationships (Was: Suggesting  change in DPT policy) Timo Röhling <roehling@debian.org> - 2024-02-28 16:50 +0100
  Re: Suggesting change in DPT policy Martin <debacle@debian.org> - 2024-02-27 16:40 +0100
  Re: Suggesting change in DPT policy weepingclown <weepingclown@disroot.org> - 2024-02-27 17:30 +0100
    Re: Suggesting change in DPT policy Andreas Tille <andreas@an3as.eu> - 2024-02-28 09:10 +0100
  Re: Suggesting change in DPT policy Arto Jantunen <viiru@debian.org> - 2024-02-27 21:30 +0100
  Re: Suggesting change in DPT policy Louis-Philippe Véronneau <pollo@debian.org> - 2024-02-27 21:40 +0100
    Re: Suggesting change in DPT policy Andreas Tille <andreas@an3as.eu> - 2024-02-28 09:30 +0100
      Re: Suggesting change in DPT policy Scott Kitterman <debian@kitterman.com> - 2024-02-28 15:30 +0100
        Re: Suggesting change in DPT policy Andreas Tille <andreas@an3as.eu> - 2024-02-28 15:50 +0100
  Re: Suggesting change in DPT policy Stefano Rivera <stefanor@debian.org> - 2024-02-28 03:00 +0100
  Re: Suggesting change in DPT policy Agathe Porte <gagath@debian.org> - 2024-02-28 10:30 +0100
  Re: Suggesting change in DPT policy Julian Gilbey <julian@d-and-j.net> - 2024-02-28 11:50 +0100
  Re: Suggesting change in DPT policy Salvo Tomaselli <tiposchi@tiscali.it> - 2024-03-01 01:20 +0100
  Re: Suggesting change in DPT policy Stefano Rivera <stefanor@debian.org> - 2024-03-03 00:10 +0100
  Re: Suggesting change in DPT policy Emmanuel Arias <eamanu@yaerobi.com> - 2024-03-03 00:40 +0100
    Re: Suggesting change in DPT policy Alexandre Detiste <alexandre.detiste@gmail.com> - 2024-03-03 16:20 +0100
  Re: Suggesting change in DPT Policy Nilesh Patra <nilesh@debian.org> - 2024-03-09 18:00 +0100
    Re: Suggesting change in DPT Policy Anton Gladky <gladk@debian.org> - 2024-03-09 18:50 +0100
      Re: Suggesting change in DPT Policy Julian Gilbey <julian@d-and-j.net> - 2024-03-09 22:30 +0100
        Re: Suggesting change in DPT Policy Andreas Tille <andreas@an3as.eu> - 2024-03-19 08:40 +0100

csiph-web