Re: Suggesting change in DPT policy

[Andreas Tille]

Hi Timo,

Am Tue, Feb 27, 2024 at 04:08:51PM +0100 schrieb Timo Röhling:
> I guess the motivation behind the weak collaboration model is that some
> packages have hidden "gotchas", which a casual team uploader might not know.
> For instance, pygit2 is one of multiple libgit2 language bindings which all
> need to be upgraded in lock-step when a new upstream version is released.

You are making an important point here.
 
> Instead of restricting collaboration, we could let policy encourage
> maintainers to state such constraints in debian/README.DPT and ask team
> members to check that file before they team-upload.

I think this is a very good idea.  In case MR[1] will be accepted this
should be added to the policy as well.  I'm not sure whether the
"Maintainership" paragraph is the best place to add this.  I wonder if
you (or someone with the same doubts) might want to suggest another MR
to add this debian/README.DPT feature.

Kind regards
Andreas.


[1] 
https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/20

-- 
http://fam-tille.de

Re: Suggesting change in DPT policy

[Andreas Tille]

Hi Scott,

Am Tue, Feb 27, 2024 at 11:54:01PM + schrieb Scott Kitterman:
> It's self-induced.  I mean if it's demotivating to have people point out that 
> you didn't follow the policy, then you can solve that all by yourself by 
> following the policy.  If I take your argument to its logical conclusion, all 
> of Debian's rules can be demotivating when people ignore them, so we should 
> get rid of them all so your feelings are safe.

I agree that it was my mistake to not follow team policy.  I should not
have done this and I apologized for this.  I should have written this
e-mail first to change a policy that does not fit my experiences in
other teams as well as what obviously several contributors consider
inappropriate.  To solve this I started this discussion and meanwhile
created a MR[1].

The demotivating part was the wording to point me to the policy.  I
addressed this with the words "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." in my initial mail[2].

To make sure this will really clear I added the proposed change in a
second MR[3] containing the following diff:


--- a/policy.rst
+++ b/policy.rst
@@ -169,6 +169,16 @@ To be merged, a policy update needs the approval of at 
least one team
 administrator.
 
 
+Code of Conduct
+===
+  
+The Debian Python team members agree to the
+`Debian Code of Conduct `
+and strive to create a kind and inviting atmosphere among team members.
+We are welcoming newcomers and will be open to questions to get them
+starting.
+
+


Kind regards
Andreas.

[1] 
https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/20
[2] https://lists.debian.org/debian-python/2024/02/msg00052.html
[3] 
https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/21

-- 
http://fam-tille.de

Re: Suggesting change in DPT policy

[Stefano Rivera]

Hi Andreas (2024.02.27_08:05:44_+)
> 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.

Thank you for doing this work. I've come across a number of DPT bugs
where you've been leading the charge on Python 3.12 support (and related
things, like Cython 3).

I'd like the Python Team to be a team that fosters this kind of
collaboration. Being supported, rather than demotivated by the response
you get from the team is important.

We've been talking about changing the maintainership rules for years,
for all the reasons you raise. They are unexpected and hurt new (and
old) contributors.

What other people are hinting at is that there are one or two package
maintainers in the team who feel strongly about needing this level of
control for their packages. The team only gets to have their packages in
the git repo, in exchange for allowing them this control. We'd probably
lose their packages if we change the rule.

How bad would that be? Now that everyone uses git, probably not so bad.
Back in the day, if the package wasn't in our svn it probably wasn't in
VCS at all.

So, +1 from me.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Re: Suggesting change in DPT policy

[Scott Kitterman]

On February 27, 2024 11:42:33 PM UTC, Thomas Goirand  wrote:
>On 2/27/24 19:32, Scott Kitterman wrote:
>> I suspect that packages will be removed from team maintenance as a result 
>> though and I think that's a bad idea.
>
>If a package isn't in the team, any DD can ask for permission from the 
>maintainer before an upload. So, what's the difference, with a package that is 
>"is in the Python team", but nobody from the team can upload without prior 
>approval from the current maintainer? It simply doesn't make sense.
>
>So at the end, if packages get "removed from the team", it's a good thing: it 
>clarifies the situation.
>
>Andreas has been the biggest uploader of packages for many years (by the 
>number of upload per year), and working a lot on Python stuff. It feels wrong 
>we both fell in the "upload not granted: you should have read the team's 
>policy better" mistake, and I do not wish others also receive this kind of 
>demotivating message anymore.
>

It's self-induced.  I mean if it's demotivating to have people point out that 
you didn't follow the policy, then you can solve that all by yourself by 
following the policy.  If I take your argument to its logical conclusion, all 
of Debian's rules can be demotivating when people ignore them, so we should get 
rid of them all so your feelings are safe.

Scott K

Re: Suggesting change in DPT policy

[Thomas Goirand]

On 2/27/24 19:32, Scott Kitterman wrote:

I suspect that packages will be removed from team maintenance as a result 
though and I think that's a bad idea.


If a package isn't in the team, any DD can ask for permission from the 
maintainer before an upload. So, what's the difference, with a package 
that is "is in the Python team", but nobody from the team can upload 
without prior approval from the current maintainer? It simply doesn't 
make sense.


So at the end, if packages get "removed from the team", it's a good 
thing: it clarifies the situation.


Andreas has been the biggest uploader of packages for many years (by the 
number of upload per year), and working a lot on Python stuff. It feels 
wrong we both fell in the "upload not granted: you should have read the 
team's policy better" mistake, and I do not wish others also receive 
this kind of demotivating message anymore.


Cheers,

Thomas Goirand (zigo)

Re: Suggesting change in DPT policy

[Louis-Philippe Véronneau]

On 2024-02-27 03: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 

Re: Suggesting change in DPT policy

[Arto Jantunen]

Andreas Tille  writes:
> 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.

I support this change to the team policy.

-- 
Arto Jantunen

Membership request

[Nicolas Couture]

Good day,

As I met "pollo" this morning on OFTC after inquiring about helping out
with the adoption of virtualenvwrapper or researching more into the state
of packaging pyenv in Debian, he suggested a good starting point would be
to read  https://deb.li/PyPolicy which I had not until now and then join
the team to help out on any team-maintained packages.

I understand the gist of it but I'm starting to think that "pollo" might
actually be a chicken, because he's excellent at laying out eggs-amples of
policy, but when it comes to packaging, he believes in free-range.

On with the serious phase of this request:

*Why you want to join the team:*


   - Help maintain specific packages though my interest might be broader
   than that and I'm willing to help out on team-maintained packages to become
   familiar with the workflows
   - Salsa login: ncouture
   - I have read and accept
   
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst


Best regards,

Nicolas Couture
Open Source Enthusiast

Re: Suggesting change in DPT policy

[Scott Kitterman]

On February 27, 2024 2:27:35 PM UTC, Scott Talbert  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 

Re: dh_python3: file in /usr/lib/python3.12/dist-packages ?

[Stefano Rivera]

Hi Carles (2024.02.26_00:00:48_+)
> The first one includes, in top_level.txt:
> debian
> ping3
> 
> And the second one:
> build
> debian
> ping3
> 
> Where "ping3" is the expected module. "debian" is there because of the
> debian/ directory (I'm super sure, and AFAIK should not be there!) and
> "build" is there on the second time since, I guess, it exists at that
> time.
> 
> So, even in the package in testing, it contains "debian" which is wrong:

Yeah, that's wrong. We tried to stop this from happening a while ago,
but it doesn't appear to be working, here.
https://github.com/pypa/setuptools/pull/4001

I think you've hit the NOTE in
https://setuptools.pypa.io/en/latest/userguide/package_discovery.html#finding-simple-packages
If you (or ideally upstream) set "namespaces = false"
I think it'll behave correctly.

BTW, I see this package has patches-applied in git, so gbp can't work
with them. The team policy is to store patches-unapplied.  You can work
on the patches with git via gbp-pq.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

Re: Suggesting change in DPT policy

[weepingclown]

While perfectly understanding the weak collaboration model reasoning, I've 
still always found DPT as uploader and not maintainer rather absurd TBH. The 
current go to tool (as I understand it) for python packaging, py2dsp, also 
creates an initial packaging with team in uploaders section and the person as 
maintainer; something that I find even more absurd. Not only would I welcome 
this suggested change, I also think it is better if py2dsp default to starting 
with DPT as maintainers.

Best,
Ananthu

Re: Suggesting change in DPT policy

[Martin]

On 2024-02-27 15:15, Thomas Goirand wrote:
> 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.

I'm in favour of that change, too, but I can live with the current state
as well. All my packages are team owned, and I'm mere uploader, anyway.

Cheers

Re: Suggesting change in DPT policy

[Timo Röhling]

Hi,

* Andreas Tille  [2024-02-27 09:05]:
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.

+1 from me.

I guess the motivation behind the weak collaboration model is that 
some packages have hidden "gotchas", which a casual team uploader 
might not know. For instance, pygit2 is one of multiple libgit2 
language bindings which all need to be upgraded in lock-step when a 
new upstream version is released.


Instead of restricting collaboration, we could let policy encourage 
maintainers to state such constraints in debian/README.DPT and ask 
team members to check that file before they team-upload.



Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

+1 (Re: Suggesting change in DPT policy)

[Jochen Sprickerhof]

* Thomas Goirand  [2024-02-27 15:15]:

So I'm 100% with you for the removal of this policy.


+1 to everything.

Cheers Jochen


signature.asc
Description: PGP signature

Re: Suggesting change in DPT policy

[Scott Talbert]

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 

Re: Suggesting change in DPT policy

[Thomas Goirand]

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

Suggesting change in DPT policy

[Andreas Tille]

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