Re: Suggesting change in DPT Policy

[Andreas Tille]

Hi Julian,

Am Sat, Mar 09, 2024 at 09:21:40PM + schrieb Julian Gilbey:
> Following on from some earlier discussions, I've been thinking about
> the relationship between the DPT (presumably a group of developers who
> work together) and salsa (could there be packages in the
> python-team/packages area which are not team maintained?).  I reread
> much of the policy at
> https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
> and discovered something quite strange.  The introduction begins:
> 
> ---
> [Old version stripped]
> ---
> 
> If the DPT is a team (a group of maintainers/developers/helpful
> others), what does "The DPT is hosted at salsa" mean - how can a
> "team" be hosted?  (And in the first paragraph, "maintained by a team"
> seems a little strange too.)
> 
> Perhaps something like the following would be better (shifting the
> focus from the tools to the people), and would also separate concerns
> more clearly:

I like this shift.

> ---
> Introduction:
> 
> The Debian Python Team (DPT) is a group of maintainers who are jointly
> responsible for a large number of Python packages in Debian.  They
> package and support available Python modules and applications that may
> be useful.
> 
> By using a central location on salsa.debian.org, the Debian GitLab
> instance, for these team-maintained packages, the DPT are able to
> improve responsiveness, integration, and standardization.
> ---

I think it makes sense if you create some MR for the suggested change.

> Then the details of how to mark a package as being team-maintained can
> be left to the Maintainership section.
> 
> We could then include a statement along the lines of the following
> (though I'm not sure where would be best):
> 
> ---
> Python module packages which are not team-maintained by the DPT can
> also be stored in the python-team/packages namespace on salsa in order
> to benefit from the integration and standardization tools such as
> Janitor.  Manual changes to these packages by someone other than the
> package's maintainer should be proposed via salsa merge requests or
> comments in the BTS (or using NMUs if appropriate) as for any other
> individually-maintained package.
> ---

I see the advantage of having all Python packages in a common name space
on Salsa.  However, I fail to see the advantage of individually
maintained packages in Debian in general.  The discussion here did not
really contained arguments convincing me about the need for individual
maintainership.  Well, for sure we have maintainers of very high
competence for specific packages and it is good to consult these before
doing some upload.

The suggsted solution was to add some debian/README.to_be_decided_ext.
I confirm that bumping to a new upstream version might be harmful in
certain cases and there are packages where this should not be done
without confirmation of one of the persons specified in the Uploaders
field.  To my experience these packages are an exception - most packages
that where lagging behind upstream are harmless.

In general I would consider it sensible that *any* team member has
permission to

  1. Add autopkgtest
  2. Fix bugs (no matter about severity)
  3. Fix lintian issues
  4. Upload Janitor changes

by doing

  dch --team

marked cangelog entry.  We have made good experiences with this (not
even written) policy in Debian Med.  Well, in real practice it does not
happen *that* frequently that maintainers have so much time and energy
to crawl the package pool seeking for chances of enhancements (even if I
wished this would be the case).  Thus I suggest to lower the barrier to
do so to a sensible minimum.  Adding some
debian/README.to_be_decided_ext (debian/README.source which is
established and documented) mentioning potential pitfalls should be
sufficient to warn a team member driven by good intentions (and I assume
this is the case for any team member).
 
> It would be good to say something about Uploaders in the
> Maintainership section.  Perhaps something like this:
> 
> ---
> A package maintained within the team must have the name of the team in
> the Maintainer field:
> 
> Maintainer: Debian Python Team 
> 
> This enables the team to have an overview of its packages on the
> DDPO_website.
> 
> If a particular developer wishes to take primary responsibility for a
> package, they should put their name in the Uploaders field.  [*** What
> does this mean though?  Maybe something like: In this case, any DPT
> member is still welcome to make changes to the package, though it is
> polite to contact the developer(s) named in the Uploaders field
> first. ***]

To my experience an Uploader does not respond to say some RC bug due to
time constraints.  Asking and waiting for a time constrained person
might be just another ping that drains time from this person.  For sure
the some imagined bug report in question might just be overlooked and
such a ping might trigger immediate responce.  On the other hand I
experienced 

Re: Suggesting change in DPT Policy

[Julian Gilbey]

On Sat, Mar 09, 2024 at 06:46:52PM +0100, Anton Gladky wrote:
> Same for me. Thanks for proposal. +1
> Anton
> Am Sa., 9. März 2024 um 17:51 Uhr schrieb Nilesh Patra :
> 
>   I am late to the party but I agree with the policy change.

Following on from some earlier discussions, I've been thinking about
the relationship between the DPT (presumably a group of developers who
work together) and salsa (could there be packages in the
python-team/packages area which are not team maintained?).  I reread
much of the policy at
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst
and discovered something quite strange.  The introduction begins:

---
Introduction:

The Debian Python Team (DPT) aims to improve the Python packages
situation in Debian, by packaging available modules and applications
that may be useful and providing a central location for packages
maintained by a team, hence improving responsiveness, integration, and
standardization.

The DPT is hosted at salsa.debian.org, the Debian GitLab
installation. We currently have a Git repository and a mailing list
whose email address can be used in the Maintainer or Uploaders fields
on co-maintained packages.
---

If the DPT is a team (a group of maintainers/developers/helpful
others), what does "The DPT is hosted at salsa" mean - how can a
"team" be hosted?  (And in the first paragraph, "maintained by a team"
seems a little strange too.)

Perhaps something like the following would be better (shifting the
focus from the tools to the people), and would also separate concerns
more clearly:

---
Introduction:

The Debian Python Team (DPT) is a group of maintainers who are jointly
responsible for a large number of Python packages in Debian.  They
package and support available Python modules and applications that may
be useful.

By using a central location on salsa.debian.org, the Debian GitLab
instance, for these team-maintained packages, the DPT are able to
improve responsiveness, integration, and standardization.
---

Then the details of how to mark a package as being team-maintained can
be left to the Maintainership section.

We could then include a statement along the lines of the following
(though I'm not sure where would be best):

---
Python module packages which are not team-maintained by the DPT can
also be stored in the python-team/packages namespace on salsa in order
to benefit from the integration and standardization tools such as
Janitor.  Manual changes to these packages by someone other than the
package's maintainer should be proposed via salsa merge requests or
comments in the BTS (or using NMUs if appropriate) as for any other
individually-maintained package.
---

It would be good to say something about Uploaders in the
Maintainership section.  Perhaps something like this:

---
A package maintained within the team must have the name of the team in
the Maintainer field:

Maintainer: Debian Python Team 

This enables the team to have an overview of its packages on the
DDPO_website.

If a particular developer wishes to take primary responsibility for a
package, they should put their name in the Uploaders field.  [*** What
does this mean though?  Maybe something like: In this case, any DPT
member is still welcome to make changes to the package, though it is
polite to contact the developer(s) named in the Uploaders field
first. ***]

If there are complications in the packaging of the module, for
example, if certain modules are interdependent and need to be updated
together, this should be documented in debian/README.source [*** or
somewhere else ***]
---

Best wishes,

   Julian

Re: Suggesting change in DPT Policy

[Anton Gladky]

Same for me. Thanks for proposal. +1

Anton


Am Sa., 9. März 2024 um 17:51 Uhr schrieb Nilesh Patra :

> I am late to the party but I agree with the policy change.
>
> Best,
> Nilesh
>

Re: Suggesting change in DPT Policy

[Nilesh Patra]

On 2024-02-27 03:05, Andreas Tille wrote:
>  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 

Re: Suggesting change in DPT policy

[Christian Kastner]

On 2024-03-03 17:32, Thomas Goirand wrote:
> On 3/3/24 00:37, Christian Kastner wrote:
>> For
>> example, I also often skip tests -- it's just that I do it under
>> conditions that I'm happy to defend (cause isolated, reported upstream,
>> etc.), but others may not be aware of that.
> 
> There are many cases where skipping tests is ok. As you wrote, when
> reported upstream, and when the thing that's broken is the test itself
> (but the functionality is not broken).
> 
> The best practice is to document somewhere in the package (in d/rules?)
> why it's been disabled. I have to admit I often don't do that extra
> documentation work myself though (though mostly on packages I maintain
> alone, for OpenStack for example).

I agree and have no issue with this. On the contrary, I consider this
proper. I do it myself all the time. I've also temporarily disabled doc
builds (for some transition). But I make note of these things in d/rules
(or wherever it makes sense), and/or file bugs, etc.

In the case I'm talking about, this was more of just disabling large
parts (or maybe it was all, I don't remember) of tests with no attempt
at even looking what the problem was.

I should have framed my complaints better. I don't have any issue at all
with workarounds or pragmatism when they're implemented somewhat
carefully and/or reasonably, like the test-skip-handling you describe above.

Best,
Christian

Re: Suggesting change in DPT policy

[Scott Kitterman]

On March 3, 2024 6:12:09 AM UTC, Andreas Tille  wrote:
>Hi Christian,
>
>Am Sat, Mar 02, 2024 at 11:48:57PM +0100 schrieb Christian Kastner:
>> On 2024-03-02 23:11, Andreas Tille wrote:
>> > I'm curious why you believe I didn't care. I likely would have reverted
>> > my change if I didn't have more urgent matters to attend to.
>> > Re-uploading a package just to revert the Maintainer and Uploader is
>> > lower on my priority list than fixing other RC bugs.
>> 
>> To add another perspective: what if reverting is not about "fixing" the
>> package again, but a courtesy or sign of respect towards the person that
>> was upset by this action. Wouldn't that change the priority entirely?
>
>Thanks for pointing this out.  I agree I failed here.  I hope to not
>fail the same way in future again since in this very case I can't fix
>this any more.
> 
>The lesson I hopefully learned now is that this kind of failures seems
>to put other arguments I gave for a policy change in the shadow at least
>for those team members I would love to reach for a constructive
>discussion.

Thanks both for your response and for Christian for doing a much better job 
than I managed trying to communicate this.

Scott K

Re: Suggesting change in DPT policy

[Thomas Goirand]

On 3/3/24 00:37, Christian Kastner wrote:

For
example, I also often skip tests -- it's just that I do it under
conditions that I'm happy to defend (cause isolated, reported upstream,
etc.), but others may not be aware of that.


There are many cases where skipping tests is ok. As you wrote, when 
reported upstream, and when the thing that's broken is the test itself 
(but the functionality is not broken).


The best practice is to document somewhere in the package (in d/rules?) 
why it's been disabled. I have to admit I often don't do that extra 
documentation work myself though (though mostly on packages I maintain 
alone, for OpenStack for example).


Unfortunately, when dealing with a large amount of packages, at some 
point, one may be tired and skip some of the documentation/reporting 
upstream work, because there's so much to do... I have to admit that 
sometimes, I just do the quick fix by myself in debian/ptaches, and 
don't have enough energy to report or fix upstream, thinking that 
upstream will hit the (python 3.x for example) bug themselves, and fix 
anyways. :/


Cheers,

Thomas Goirand (zigo)

Re: Suggesting change in DPT policy

[Thomas Goirand]

On 3/2/24 23:09, Christian Kastner wrote:

Not going to name names, but I've seen this with packages I've worked
on: I put a lot of effort into cleaning things up, making things robust,
getting docs to build, tests to pass, collaborating with upstream,
fixing reverse dependencies, and then someone spends a few minutes to
upload a new version with total disregard for what the other
maintainer(s) were doing.

Things like "oh, documentation doesn't build anymore, I'll just disable
it", rather than fixing it. Or "oh, these tests don't pass anymore, I'll
just disable them", rather than looking into the regression. "Oh, my
upload triggered a transition, I'm no longer interested in this".

(This are all things that have happened to me.)

All that stuff is then left for others to clean up. And if one is
unlucky enough, this doesn't just cause work for the package, but for
all reverse dependencies.


I've seen careless uploads and mistakes too (and done my part of bad 
uploads a few times as well). There's one thing that can save us all 
from this: a lot of autopkgtest in every package, and uploading packages 
with a lot of reverse dependencies to Experimental first, then fixing 
the excuse page before an upload to unstable.


I did this for flask 2.2 and werkzeug, and saw Carsten Schoenert doing 
the same with flask 3. It's a proven safe workflow. For this, you don't 
really need to know the said transitioning package. I very much hope we 
all move into this direction, even if that means more work and follow-up 
with reverse dependency maintainers.


Cheers,

Thomas Goirand (zigo)

Re: Suggesting change in DPT policy

[Thomas Goirand]

On 3/2/24 21:29, Andreas Tille wrote:

sphinxtesters (0.2.3-4) unstable; urgency=medium

   * Revert attempt by a rogue developer to hijack this package

  -- Sandro Tosi   Sun, 14 Jan 2024 01:25:23 -0500

I wonder how the attribute 'rogue' is supported by the discussion above,
nor where the intention to hijack the package is inferred from.


On 3/2/24 21:29, Andreas Tille wrote:
> In my view, this crosses the line

It does cross the line.

On 3/2/24 21:29, Andreas Tille wrote:
> and I am grateful to have been part of teams where such
> incidents were not tolerated.

IMO, this shouldn't be tolerated in this team either. Even if Sandro is 
doing awesome work in the team.


I'm btw hereby sending warm thanks to Sandro for his huge work that I 
very much respect, despite all of this thread and other events. I 
remember the huge amount of uploads when we removed Python 2 from 
Debian, tirelessly doing things on the correct order, in a technically 
near perfect way, when I didn't dare to touch this puzzle ...


But it's not an excuse to create a toxic atmosphere. This has been 
hashed multiple times in many areas in Debian: doing a lot of (good) 
packaging work doesn't grant anyone the right to disrespect others.


On 3/2/24 22:11, Scott Kitterman wrote:
> I understand your argument to be:
>
> I did not follow the team policy and didn't care about the other
> people involved to rectify the error.  They were upset about this, so
> clearly this mess is all their fault.  We should change the rules so
> that I won't have been wrong.
>
> I absolutely do not know how to respond to that level of entitlement.
> Hopefully I have misunderstood what you are trying to communicate?

I strongly do not agree with the above. You wrote it as if what 
triggered Sandro was Andreas not willing to "rectify the error". That's 
not what's happened: Sandro was harsh with Andreas to begin with, and 
that is the reason Andreas wasn't motivated to "fix" what he saw as 
cosmetic metadata in d/control for a weird policy of packages "half 
belonging to the team", rather than an important bugfix.


The way you wrote it, it feels like you're only blaming Andreas for what 
he did: I wouldn't do that, but that is ok, it's your opinion. But it 
feels you're saying his bad behavior is an excuse for changing the 
policy, and that, I do not agree, this isn't what's happening.


We should change the policy, but that's not so that Andreas "won't have 
been wrong". It is because at least 3 persons (including myself and 
Andreas) in this thread missed the point we're willing to remove. It is 
because having a package "half in the team" doesn't make sense. And it 
is because of many other points we already discussed in this thread. I 
don't understand why are you making such a shortcut, when you already 
agreed to these other points.


I'm sure you also notice part of this thread is also about Sandro's 
communication style. My view (which I believe is shared by others) is 
that Andreas is a nice person that deserves respect. It's unfortunate 
that the sphinxtesters uploads were the tiger of this policy change, 
though we need to take a step back, and understand the policy was bad 
anyways.


So indeed, we have read the same things, but have very different 
perspectives. None of them are completely wrong, we simply have very 
different feelings. And despite all of this, it's a good thing you also 
agree to get rid of this part of this policy.


Cheers,

Thomas Goirand (zigo)

Re: Suggesting change in DPT policy

[Alexandre Detiste]

+1 for this policy change too,

I went through the same hurdles & thinking progress, but it's much fresher
in py head because I m only contributing to DPT since 1/1/2024, doing
exactly what I said I would do on my membership application mail.

Before this talk happened I would not have recommended anybody to join the
team.

I m glad it is being resolved.

Greetings

Le dim. 3 mars 2024, 00:30, Emmanuel Arias  a écrit :

> +1 for this DPT policy change.
>
> When I started to contribute I received these kind of comments that made
> me think if I could really start contributing to Debian. As time went by,
> I learned to read first who is the maintainer of the package before read
> the bug reported, no matter if the package is (apparently) under the DPT
> umbrella.
> --
> cheers,
> Emmanuel Arias

Re: Suggesting change in DPT policy

[Andreas Tille]

Hi Christian,

Am Sat, Mar 02, 2024 at 11:48:57PM +0100 schrieb Christian Kastner:
> On 2024-03-02 23:11, Andreas Tille wrote:
> > I'm curious why you believe I didn't care. I likely would have reverted
> > my change if I didn't have more urgent matters to attend to.
> > Re-uploading a package just to revert the Maintainer and Uploader is
> > lower on my priority list than fixing other RC bugs.
> 
> To add another perspective: what if reverting is not about "fixing" the
> package again, but a courtesy or sign of respect towards the person that
> was upset by this action. Wouldn't that change the priority entirely?

Thanks for pointing this out.  I agree I failed here.  I hope to not
fail the same way in future again since in this very case I can't fix
this any more.
 
The lesson I hopefully learned now is that this kind of failures seems
to put other arguments I gave for a policy change in the shadow at least
for those team members I would love to reach for a constructive
discussion.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Re: Suggesting change in DPT policy

[Christian Kastner]

On 2024-03-02 23:09, Christian Kastner wrote:
> I think moving DPT to Maintainers is a good idea.

Additionally, I agree that having DPT in Uploaders is pointless, and
welcome the prposed policy change.

> I think removing Uploaders is a terrible one.

Apologies, I retract this part as it was not suggested. I misunderstood
the diff.

Best,
Christian

Re: Suggesting change in DPT policy

[Christian Kastner]

Hi Stefano,

I need to retract my previous mail. Ironically, it was based on a
careless misread of the proposed policy change diff.

On 2024-03-03 00:07, Stefano Rivera wrote:
> Now that we have Salsa with Merge Requests, it's hard for me to see much
> benefit from having packages in the team with the weak team membership
> (uploader).

I fully support removing weak team membership. I have always considered
having DPT in Uploaders to be pointless.

What I misunderstood in the diff was that the proposed policy change of
"anyone can commit" to effectively mean that Uploaders is not relevant
anymore, but that was not what was proposed.

> I don't think any of the things you describe there are acceptable for
> team maintenance.
> 
> Disabling tests or docs may be necessary in the short term. Or if they
> will never be able to work again. But I don't think those are OK to do,
> upload and walk away.
> 
> If the tests are broken and you can't figure it out, you talk to the
> people who know the package better.
> 
> We could spell these things out more clearly in the team rules.
> We can also push back on team members who behave like this. Repeatedly
> doing the things you describe, when asked not to, should lead to being
> kicked out of the team.

I like that suggestion a lot!

And, to be more constructive this time, I want to make it clear that
contributions are always truly welcome, that's why it's under DPT.

And while diligence (or lack thereof) can be criticized, I'm aware that
often, contributors are unaware that what they are doing is wrong. For
example, I also often skip tests -- it's just that I do it under
conditions that I'm happy to defend (cause isolated, reported upstream,
etc.), but others may not be aware of that.

Spelling this out more clearly would improve this.

> Picking up a bug and realising you are in over year head is something
> that will happen to new contributors to Debian. Having a team there to
> help out when someone does make a mess like that is useful.
> 
> A few lines in a README.source about what makes a package complex is
> probably also useful to your collaborators (although, yes, of course
> writing this is work).

I'd like that. But to be effective, it must really be in-grained that
for anything DPT, one should check README.source first.

This may come naturally to many of us, but it's certainly not universal.

>> I see Uploaders as a signal of "these are the regular maintainers, I
>> should check with these people before doing any *major* changes". And I
>> argue that this is reasonable.
> 
> I'd say it's best practice to do that whenever a package has people who
> seem to be caring about it.

Agreed.

> That's not the case for many packages in the team. Even ones listed with
> the team in Uploaders and a human as Maintainer.

Also agreed. But in that case, this inter-personal conflict usually does
not arise, for lack persons.

Best,
Christian

Re: Suggesting change in DPT policy

[Emmanuel Arias]

On Tue, Feb 27, 2024 at 09:05:44AM +0100, 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 

Re: Suggesting change in DPT policy

[Stefano Rivera]

Hi Christian (2024.03.02_22:09:29_+)
> Some packages are complex, some packages have lots of reverse
> dependencies. Where these two circles overlap, a careless "drive-by"
> maintainer can do a lot of harm.

Maybe we should look at ways we can improve this situation, without
having to have packages under the team umbrella that aren't really team
maintained.

Now that we have Salsa with Merge Requests, it's hard for me to see much
benefit from having packages in the team with the weak team membership
(uploader).

As a team member all I can do to contribute to such packages is commit
to git. If I'm not sure my changes will be approved, I'd rather file a
merge request. At that point, it may as well not be a team package.
I filed merge requests to improve a weak team package, a couple of
months ago. They never got reviewed. Is this still a team package?
Yes I was able to do emergency uploads of it too, but I could also do
that via NMU.

> Things like "oh, documentation doesn't build anymore, I'll just disable
> it", rather than fixing it. Or "oh, these tests don't pass anymore, I'll
> just disable them", rather than looking into the regression. "Oh, my
> upload triggered a transition, I'm no longer interested in this".
> 
> (This are all things that have happened to me.)
> 
> All that stuff is then left for others to clean up. And if one is
> unlucky enough, this doesn't just cause work for the package, but for
> all reverse dependencies.

I don't think any of the things you describe there are acceptable for
team maintenance.

Disabling tests or docs may be necessary in the short term. Or if they
will never be able to work again. But I don't think those are OK to do,
upload and walk away.

If the tests are broken and you can't figure it out, you talk to the
people who know the package better.

We could spell these things out more clearly in the team rules.
We can also push back on team members who behave like this. Repeatedly
doing the things you describe, when asked not to, should lead to being
kicked out of the team.

Picking up a bug and realising you are in over year head is something
that will happen to new contributors to Debian. Having a team there to
help out when someone does make a mess like that is useful.

A few lines in a README.source about what makes a package complex is
probably also useful to your collaborators (although, yes, of course
writing this is work).

> I see Uploaders as a signal of "these are the regular maintainers, I
> should check with these people before doing any *major* changes". And I
> argue that this is reasonable.

I'd say it's best practice to do that whenever a package has people who
seem to be caring about it.

That's not the case for many packages in the team. Even ones listed with
the team in Uploaders and a human as Maintainer.

Stefano

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

Re: Suggesting change in DPT policy

[Christian Kastner]

Hi again,

On 2024-03-02 23:11, Andreas Tille wrote:
> I'm curious why you believe I didn't care. I likely would have reverted
> my change if I didn't have more urgent matters to attend to.
> Re-uploading a package just to revert the Maintainer and Uploader is
> lower on my priority list than fixing other RC bugs.

To add another perspective: what if reverting is not about "fixing" the
package again, but a courtesy or sign of respect towards the person that
was upset by this action. Wouldn't that change the priority entirely?

> What exactly is the "mess" in this story.  Probably not swapping
> Maintainer+Uploader since I several times confirmed that it is my fault
> and immediately said I'm sorry about this.
>From past interactions, I honestly believe you are. But let me point out
that interaction-wise, saying you're sorry and showing you're sorry are
two different things. And having upset someone, not performing that one
requested gesture that would heal the situation is going to cause friction.

Best,
Christian

Re: Suggesting change in DPT policy

[Christian Kastner]

Hi Andreas,

On 2024-02-27 09:05, Andreas Tille wrote:
> 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 think moving DPT to Maintainers is a good idea.

I think removing Uploaders is a terrible one.

Some packages are complex, some packages have lots of reverse
dependencies. Where these two circles overlap, a careless "drive-by"
maintainer can do a lot of harm.

Not going to name names, but I've seen this with packages I've worked
on: I put a lot of effort into cleaning things up, making things robust,
getting docs to build, tests to pass, collaborating with upstream,
fixing reverse dependencies, and then someone spends a few minutes to
upload a new version with total disregard for what the other
maintainer(s) were doing.

Things like "oh, documentation doesn't build anymore, I'll just disable
it", rather than fixing it. Or "oh, these tests don't pass anymore, I'll
just disable them", rather than looking into the regression. "Oh, my
upload triggered a transition, I'm no longer interested in this".

(This are all things that have happened to me.)

All that stuff is then left for others to clean up. And if one is
unlucky enough, this doesn't just cause work for the package, but for
all reverse dependencies.

So while I absolutely condemn the conduct that you describe, I do also
have to condemn this careless drive-by work, because it is also
extremely demotivating.

I see Uploaders as a signal of "these are the regular maintainers, I
should check with these people before doing any *major* changes". And I
argue that this is reasonable.

Best,
Christian

Re: Suggesting change in DPT policy

[Andreas Tille]

Am Sat, Mar 02, 2024 at 09:11:52PM + schrieb Scott Kitterman:
> 
> It's possible I am misunderstanding you here (languages are hard even when 
> they are your first), but if I am not, I think you are not really seeing 
> things from the correct perspective.

I'm probably biased since involved into this and I'm interested into
other perspectives.

> Here's my summary of what I understand your argument to be:
> 
> I did not follow the team policy and didn't care about the other people 
> involved to rectify the error.

I'm curious why you believe I didn't care. I likely would have reverted
my change if I didn't have more urgent matters to attend to.
Re-uploading a package just to revert the Maintainer and Uploader is
lower on my priority list than fixing other RC bugs. I've mentioned
multiple times that different wording might have elevated the priority.
I'm not sure how to express this more clearly, sorry.

> They were upset about this, so clearly this mess is all their fault.

What exactly is the "mess" in this story.  Probably not swapping
Maintainer+Uploader since I several times confirmed that it is my fault
and immediately said I'm sorry about this.

>  We should change the rules so that I won't have been wrong.

Again no.  My proposal to change policy was after a second upload of
mine connected to

  pysimplesoap (1.16.2-6) unstable; urgency=3Dmedium

I asked the maintainer to post his response to a public mailing list but
he refused.  *Then* I proposed a change to the policy since I see
problems in it.  If we had only the first story I would have done
nothing (except reverting the change the maintainer considered wrong
once I might have time for it.)
 
> I absolutely do not know how to respond to that level of entitlement.  
> Hopefully I have misunderstood what you are trying to communicate?

I was told that I should not expect any thanks for fixing a bug and I
tried to explain this is not the case.  Now I am being accused of having
a sense of entitlement.  I'm starting to have severe doubt to make
my point clear enough.  My gut feeling tells me that it is time to lean
back and observe this thread passively instead of putting even more
fuel into it.

Kind regards
Andreas.


-- 
http://fam-tille.de

Re: Suggesting change in DPT policy

[Scott Kitterman]

On March 2, 2024 8:29:47 PM UTC, Andreas Tille  wrote:
>Hi Jeroen,
>
>Am Thu, Feb 29, 2024 at 08:48:33PM +0100 schrieb Jeroen Ploemen:
>> ...
>
>Julian had sensibly commented on this and had added interesting
>questions I'm keen on hearing your answers.
>
>> As for the inclusion of codes of conduct or similar wording,
>> documenting common sense just feels unnecessary. While being on the
>> receiving end of a compliment for bug-squashing work is certainly
>> nice, the lack thereof isn't a measure of disrespect.
>
>Julien also commented on this.  Despite I never thought to spent so much
>time on the bug that triggered the discussion I consider it important
>enough to clarify some misunderstandings which obviously were caused by
>the mails I wrote about this.
>
>As a non-native speaker, I am actively working on improving my
>communication skills. I would appreciate it if you could point out which
>part of my messages led you to believe that I felt disrespected. My
>intention was simply to provide some insight into why the task someone
>scheduled for me was not high on my priority list during my spare time.
>
>To summarize the visible facts:
>
> 2023-12-12 serious bug #1058177 was filed, solution for this kind of
>bugs is simple for maintainers comfortable with Python 3.12
>
> 2023-12-22 closed with changelog
>[ Andreas Tille ]
>* Set DPT maintainer
>* Replace SafeConfigParser deprecated in Python3.12
>  Closes: #1058177
>* Transparently skip test_bad_pagebuilder instead of ignoring test suite
>  errors
>
>  --> I confirm "Set DPT mainter" was in conflict with DPT policy since
>  I just forgot about that very detail and considered it some
>  unintended oversight.  I will not do this again as long as this
>  policy is not changed
>
> Response in Salsa comment[1]
>
> Sandro Tosi: @tille please explain why you think this is appropriate
>
> Andreas Tille: In all teams I know policy says the team address should be put
>   as Maintainer. After checking DPT policy again again I realise it gives both
>   options with different meanings. Sorry about that and feel free to revert.
>
> Sandro Tosi: @tille you made the mistake, so you do the reverting and the
>   uploading to rectify it.
>
>
>Comment: That seems fair.  If my real-life boss had asked, I would have
>done it, considering he pays me for it.  Fortunately, my day job boss
>knows how to motivate me better.  I wouldn't had brought this up on my
>own behalf.  I just went into more detail to explain why I did not fixed
>my mistake immediately.  As a volunteer, I have the freedom to choose
>which tasks to prioritize.  A little kindness in communication can
>significantly impact my priorities.  I wasn't expecting a "thank you for
>fixing the bug," but I believe it's unrealistic for Sandro to expect me
>to follow such commands as a volunteer.  (Fun fact:  I was throwing the
>last two paragraphs into a LLM and besides fixing my paragraph several
>changes where suggested to Sandro's quote.)
>
>
>sphinxtesters (0.2.3-4) unstable; urgency=medium
>
>  * Revert attempt by a rogue developer to hijack this package
>
> -- Sandro Tosi   Sun, 14 Jan 2024 01:25:23 -0500
>
>
>I wonder how the attribute 'rogue' is supported by the discussion above,
>nor where the intention to hijack the package is inferred from.
>
>
>sphinxtesters (0.2.3-5) unstable; urgency=medium
>
>  * orphan
>
> -- Sandro Tosi   Thu, 29 Feb 2024 01:55:25 -0500
>
>
>I admit the last upload makes the initial request to revert the
>Maintainer change questionable.  I also confirm that I have experienced
>worse things before than giving me the attribute "rogue" or blaming
>me about bad intentions.  Fine for me I developed some thick skin
>meanwhile.
>
>> I cannot recall
>> any discussion on the team's IRC channel or mailing list crossing
>> that line.
>
>If you cannot recall anything that crossed the line I intended to draw
>explicitly in our policy through my MR[2], I am curious to know where,
>in your opinion, this falls in relation to our goal of 'striving to
>create a kind and inviting atmosphere among team members.'  If it would
>be only about me, I would simply move on (which I did until there was
>another point of friction with no public traces).  But it does concern
>fostering a welcoming team environment. In my view, this crosses the
>line, and I am grateful to have been part of teams where such incidents
>were not tolerated.
>
>Kind regards
>Andreas.
>
>[1] 
>https://salsa.debian.org/python-team/packages/sphinxtesters/-/commit/d8b1083db26c753c8a76dd91b7e91f3ef98c0515#note_450676
>[2] 
>https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/21
>

It's possible I am misunderstanding you here (languages are hard even when they 
are your first), but if I am not, I think you are not really seeing things from 
the correct perspective.  Here's my summary of what I understand your argument 
to be:

I did not follow the team policy and 

Re: Suggesting change in DPT policy

[Andreas Tille]

Hi Jeroen,

Am Thu, Feb 29, 2024 at 08:48:33PM +0100 schrieb Jeroen Ploemen:
> ...

Julian had sensibly commented on this and had added interesting
questions I'm keen on hearing your answers.

> As for the inclusion of codes of conduct or similar wording,
> documenting common sense just feels unnecessary. While being on the
> receiving end of a compliment for bug-squashing work is certainly
> nice, the lack thereof isn't a measure of disrespect.

Julien also commented on this.  Despite I never thought to spent so much
time on the bug that triggered the discussion I consider it important
enough to clarify some misunderstandings which obviously were caused by
the mails I wrote about this.

As a non-native speaker, I am actively working on improving my
communication skills. I would appreciate it if you could point out which
part of my messages led you to believe that I felt disrespected. My
intention was simply to provide some insight into why the task someone
scheduled for me was not high on my priority list during my spare time.

To summarize the visible facts:

 2023-12-12 serious bug #1058177 was filed, solution for this kind of
bugs is simple for maintainers comfortable with Python 3.12

 2023-12-22 closed with changelog
[ Andreas Tille ]
* Set DPT maintainer
* Replace SafeConfigParser deprecated in Python3.12
  Closes: #1058177
* Transparently skip test_bad_pagebuilder instead of ignoring test suite
  errors

  --> I confirm "Set DPT mainter" was in conflict with DPT policy since
  I just forgot about that very detail and considered it some
  unintended oversight.  I will not do this again as long as this
  policy is not changed

 Response in Salsa comment[1]

 Sandro Tosi: @tille please explain why you think this is appropriate

 Andreas Tille: In all teams I know policy says the team address should be put
   as Maintainer. After checking DPT policy again again I realise it gives both
   options with different meanings. Sorry about that and feel free to revert.

 Sandro Tosi: @tille you made the mistake, so you do the reverting and the
   uploading to rectify it.


Comment: That seems fair.  If my real-life boss had asked, I would have
done it, considering he pays me for it.  Fortunately, my day job boss
knows how to motivate me better.  I wouldn't had brought this up on my
own behalf.  I just went into more detail to explain why I did not fixed
my mistake immediately.  As a volunteer, I have the freedom to choose
which tasks to prioritize.  A little kindness in communication can
significantly impact my priorities.  I wasn't expecting a "thank you for
fixing the bug," but I believe it's unrealistic for Sandro to expect me
to follow such commands as a volunteer.  (Fun fact:  I was throwing the
last two paragraphs into a LLM and besides fixing my paragraph several
changes where suggested to Sandro's quote.)


sphinxtesters (0.2.3-4) unstable; urgency=medium

  * Revert attempt by a rogue developer to hijack this package

 -- Sandro Tosi   Sun, 14 Jan 2024 01:25:23 -0500


I wonder how the attribute 'rogue' is supported by the discussion above,
nor where the intention to hijack the package is inferred from.


sphinxtesters (0.2.3-5) unstable; urgency=medium

  * orphan

 -- Sandro Tosi   Thu, 29 Feb 2024 01:55:25 -0500


I admit the last upload makes the initial request to revert the
Maintainer change questionable.  I also confirm that I have experienced
worse things before than giving me the attribute "rogue" or blaming
me about bad intentions.  Fine for me I developed some thick skin
meanwhile.

> I cannot recall
> any discussion on the team's IRC channel or mailing list crossing
> that line.

If you cannot recall anything that crossed the line I intended to draw
explicitly in our policy through my MR[2], I am curious to know where,
in your opinion, this falls in relation to our goal of 'striving to
create a kind and inviting atmosphere among team members.'  If it would
be only about me, I would simply move on (which I did until there was
another point of friction with no public traces).  But it does concern
fostering a welcoming team environment. In my view, this crosses the
line, and I am grateful to have been part of teams where such incidents
were not tolerated.

Kind regards
Andreas.

[1] 
https://salsa.debian.org/python-team/packages/sphinxtesters/-/commit/d8b1083db26c753c8a76dd91b7e91f3ef98c0515#note_450676
[2] 
https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/21

Re: Suggesting change in DPT policy

[Jeroen Ploemen]

On Fri, 1 Mar 2024 07:21:57 +
Julian Gilbey  wrote:

> These are really interesting points.  Under the proposed system, I
> presume that one could leave "privately maintained" packages within
> the python-team area of salsa and still benefit from these automatic
> changes without giving automatic permission to other developers to
> make manual changes.  Being part of the team is a relationship
> between developers; it surely doesn't say anything about a specific
> package's maintenance, just as one can ask questions on
> debian-devel without saying "anyone can do anything to my packages
> without asking me".

As far as I can tell, the proposed change aims to remove that kind of
flexibility: any package that currently lists the team as an uploader
would have to pick between "team as maintainer" or "out" to be in
compliance.

> > That said, I'm very careful not to spend more time on volunteer
> > efforts than I can afford to, and not looking to offload the full
> > maintenance of any of my packages. Upstream involvement often
> > gives me advance knowledge of upcoming releases, their
> > compatibility issues and other quirks, which in turn helps avoid
> > problems on the Debian end. I do not share the optimism that
> > documenting such details somewhere in individual packages - as
> > suggested elsewhere in this thread - would be effective to avoid
> > trouble; more so considering that the inability to stick to a
> > single, concise, and rather clear team policy is ultimately what
> > triggered this whole discussion in the first place.  
> 
> I don't think it's a binary choice: "offload the full maintenance"
> of a package versus "keep the full maintenance".  As far as I
> understand it, a package maintained by the team will typically have
> a main person who does the day-to-day work on it (few people have
> the time to start doing serious work on lots of other packages),
> but anyone on the team could work on it.  In the cases mentioned,
> there are RC bugs in packages which have not been addressed in a
> timely fashion and are holding up transitions or similar.  In some
> of "my" packages, other developers on the team have uploaded more
> regular updates (thanks!). In most cases, updates are routine and
> I'm very appreciative of it.

I should probably have phrased that a bit differently than 'offload'.
My packages simply never have RC bugs open for a long time and under
normal circumstances don't require any team attention/intervention.
Which is exactly why I prefer the "talk to me before making major
changes" approach the current policy provides.

Whatever extra time I have beyond that needed for my own packages
mostly goes towards sponsorship, in part because that makes people
feel their work is appreciated and encourages further contributions.

> While documenting quirks might not fully avoid trouble, it's much
> better than not documenting them.  After all, this is detailed
> knowledge of a package or collection of packages that has been
> gained over time, and in addition to helping anyone stepping in to
> do a team upload, documenting it will help whoever ends up taking
> over the package one day (as well as helping the maintainer
> themselves!).
> 
> The question for your quirky packages then becomes: what does the
> current team maintenance position offer that having the package
> solely maintained by yourself would not provide?  I can see very
> little; anyone wanting to help with a package outside of the team
> can still offer to do an NMU (and push their changes to salsa).

Working directly in git is simply more convenient, lowers the bar for
contributing, and subjects any contributions to the scrutiny of the CI
pipeline. In addition, having team members familiar with python
packages involved lowers risk vs. a drive-by NMU, no matter how well
intended.


pgpd0kYFIliI4.pgp
Description: OpenPGP digital signature

Re: Suggesting change in DPT policy

[Julian Gilbey]

Hi Jeroen,

On Thu, Feb 29, 2024 at 08:48:33PM +0100, Jeroen Ploemen wrote:
> On Tue, 27 Feb 2024 18:32:54 +
> Scott Kitterman  wrote:
> 
> > 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.
> 
> For me, the weaker collaboration option that the DPT provides is key
> to putting my packages under a team umbrella.
> 
> As I find myself completely AFK for up to a month at a time for both
> work and private reasons, having a knowledgeable bunch of developers
> around with full access to my packages (VCS and CI included) is a
> definite plus, if only out of a strong sense of responsibility. The
> same goes for benefiting from the shared knowledge of the team,
> including routine fixes and similar minor changes being rolled out
> across all packages in the team.

These are really interesting points.  Under the proposed system, I
presume that one could leave "privately maintained" packages within
the python-team area of salsa and still benefit from these automatic
changes without giving automatic permission to other developers to
make manual changes.  Being part of the team is a relationship between
developers; it surely doesn't say anything about a specific package's
maintenance, just as one can ask questions on debian-devel without
saying "anyone can do anything to my packages without asking me".

> That said, I'm very careful not to spend more time on volunteer
> efforts than I can afford to, and not looking to offload the full
> maintenance of any of my packages. Upstream involvement often gives
> me advance knowledge of upcoming releases, their compatibility issues
> and other quirks, which in turn helps avoid problems on the Debian
> end. I do not share the optimism that documenting such details
> somewhere in individual packages - as suggested elsewhere in this
> thread - would be effective to avoid trouble; more so considering
> that the inability to stick to a single, concise, and rather clear
> team policy is ultimately what triggered this whole discussion in the
> first place.

I don't think it's a binary choice: "offload the full maintenance" of
a package versus "keep the full maintenance".  As far as I understand
it, a package maintained by the team will typically have a main person
who does the day-to-day work on it (few people have the time to start
doing serious work on lots of other packages), but anyone on the team
could work on it.  In the cases mentioned, there are RC bugs in
packages which have not been addressed in a timely fashion and are
holding up transitions or similar.  In some of "my" packages, other
developers on the team have uploaded more regular updates (thanks!).
In most cases, updates are routine and I'm very appreciative of it.

While documenting quirks might not fully avoid trouble, it's much
better than not documenting them.  After all, this is detailed
knowledge of a package or collection of packages that has been gained
over time, and in addition to helping anyone stepping in to do a team
upload, documenting it will help whoever ends up taking over the
package one day (as well as helping the maintainer themselves!).

The question for your quirky packages then becomes: what does the
current team maintenance position offer that having the package solely
maintained by yourself would not provide?  I can see very little;
anyone wanting to help with a package outside of the team can still
offer to do an NMU (and push their changes to salsa).

> As for the inclusion of codes of conduct or similar wording,
> documenting common sense just feels unnecessary. While being on the
> receiving end of a compliment for bug-squashing work is certainly
> nice, the lack thereof isn't a measure of disrespect. I cannot recall
> any discussion on the team's IRC channel or mailing list crossing
> that line.

As far as I understand, this thread was started not because Andreas
did not receive a compliment, but because he received quite unpleasant
emails "telling him off" for doing it.  These were not public
communications, so you would not have seen them.  I don't think anyone
is suggesting that every team upload requires a compliment (though
such things are, of course, nice and appreciated!).

Best wishes,

   Julian

Re: Suggesting change in DPT policy

[Jeroen Ploemen]

On Tue, 27 Feb 2024 18:32:54 +
Scott Kitterman  wrote:

> 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.

For me, the weaker collaboration option that the DPT provides is key
to putting my packages under a team umbrella.

As I find myself completely AFK for up to a month at a time for both
work and private reasons, having a knowledgeable bunch of developers
around with full access to my packages (VCS and CI included) is a
definite plus, if only out of a strong sense of responsibility. The
same goes for benefiting from the shared knowledge of the team,
including routine fixes and similar minor changes being rolled out
across all packages in the team.

That said, I'm very careful not to spend more time on volunteer
efforts than I can afford to, and not looking to offload the full
maintenance of any of my packages. Upstream involvement often gives
me advance knowledge of upcoming releases, their compatibility issues
and other quirks, which in turn helps avoid problems on the Debian
end. I do not share the optimism that documenting such details
somewhere in individual packages - as suggested elsewhere in this
thread - would be effective to avoid trouble; more so considering
that the inability to stick to a single, concise, and rather clear
team policy is ultimately what triggered this whole discussion in the
first place.

As for the inclusion of codes of conduct or similar wording,
documenting common sense just feels unnecessary. While being on the
receiving end of a compliment for bug-squashing work is certainly
nice, the lack thereof isn't a measure of disrespect. I cannot recall
any discussion on the team's IRC channel or mailing list crossing
that line.


pgpye0JS70SkC.pgp
Description: OpenPGP digital signature

Re: Suggesting change in DPT policy

[Thomas Goirand]

On 2/28/24 12:44, Scott Kitterman wrote:

Everyone in Debian is already bound by the code of conduct already, so it seems 
redundant to add it here again.


I agree.

Thomas

Re: Maintaining packages with complex relationships (Was: Suggesting change in DPT policy)

[Timo Röhling]

Hi,

* Andreas Tille  [2024-02-28 11:51]:

I think it could be useful for the routine-update command to stop 
when such file is hit, in order to raise the importance that the 
package has quirks, and should not be casually updated without 
involved scrutiny.  I wonder whether this can be generalized, 
like if d/README.source file is present?  (Although the latter 
use is codified[2] and I'm not confident it is 100% suitable for 
such purpose: I see many such files on my radar which do not 
necessarily hint for quirks.)



I like all your suggestions.  When reading Timo's suggestion about
debian/README.DPT I also thought about rather using the more generic
debian/README.source.  In any case I agree that routine-update should
respect such debian/README.* (except debian/README.Debian which is
user oriented).


I also thought of README.source at first, and I remained on the 
fence until Étienne brought up the potential use for routine-update, 
which makes me think that a dedicated "quirks" file makes more 
sense. I'm not too attached to the .DPT suffix though, maybe 
something like README.team or even README.quirks signals the 
intention behind the file even better. I'll leave the bikeshedding 
to interested readers for now. :)



Cheers
Timo


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


signature.asc
Description: PGP signature

Re: Suggesting change in DPT policy

[Andreas Tille]

Hi Scott,

Am Wed, Feb 28, 2024 at 09:19:29AM -0500 schrieb Scott Kitterman:
> Looking at your list, I note that it includes team members that have been 
> very 
> active in team wide work, not just on their own packages.

I'm fully aware of this.

> I think it would be 
> contrary to the spirit of Debian and working together if we changed the rules 
> and they felt they had to leave the team.

It is not my intention to move anybody out of the team but find
some consensus that other teams in Debian agreed upon as well.

Kind regards
Andreas.

-- 
http://fam-tille.de

Re: Suggesting change in DPT policy

[Andreas Tille]

Hi Scott,

Am Wed, Feb 28, 2024 at 11:44:07AM + schrieb Scott Kitterman:
> 
> This makes more sense to me.  It is completely understandable that how things 
> are communicated affects how people feel about them.  This is a difficult 
> thing to get right.  I have experienced similar demotivating conversations in 
> Debian myself.

Seems everybody who has contributed to Debian some time was facing this.
 
> Everyone in Debian is already bound by the code of conduct already, so it 
> seems redundant to add it here again.  While I agree with the principle you 
> are trying to address, I think this change unnecessarily clutters the DPT 
> document and we should not make it.

I have no really strong opinion about this.  I had the cluttering point
in mind when I moved this paragraph right to the end.  I agree that it
is redundant to some extend.  Sometimes saying things repeatedly does
not harm but I would not strongly insist on this change.

Kind regards
   Andreas.

-- 
http://fam-tille.de

Re: Suggesting change in DPT policy

[Scott Kitterman]

On Wednesday, February 28, 2024 3:21:12 AM EST Andreas Tille wrote:
> Hi,
> 
> Louis-Philippe (just quoting below in case you might have missed it) is
> repeating the importance that anyone who thinks my suggestion (MR[1]) is
> a bad idea make themselves heard.  I'm hereby adding those maintainers
> who have more than 5 packages that are affected and did not yet raised
> their opinion in To: field.
> 
> udd=> SELECT * FROM (select maintainer, count(*) from sources where
> uploaders like '%team+pyt...@tracker.debian.org%' and release = 'sid' group
> by maintainer order by maintainer) tmp WHERE count > 5; maintainer 
>   | count
> -+-
> -- Debian PaN Maintainers
>  | 7
> Jeroen Ploemen |16
> Piotr Ożarowski   |23
> Sandro Tosi   |82 
> Scott Kitterman | 7 
> Vincent Bernat  |15
> (6 rows)
> 
> Debian PaN is another team which might need extra discussion but I think
> the intention is clear and Scott has raised his opinion before[2].
> 
> 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/msg00060.html

I used to use this a lot more than I do now.  Currently I only use it for 
packages where I'm also the or a upstream developer, so it generally makes 
more sense to do non-packaging changes there.  This did cause me to go back 
and check and I found one I had missed when I was changing this previously.  
I've just uploaded vrfydmn with DPT as maintainer.

Looking at your list, I note that it includes team members that have been very 
active in team wide work, not just on their own packages.  I think it would be 
contrary to the spirit of Debian and working together if we changed the rules 
and they felt they had to leave the team.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: Suggesting change in DPT policy

[Scott Kitterman]

On February 28, 2024 9:54:55 AM UTC, Thomas Goirand  wrote:
>On 2/28/24 00:54, Scott Kitterman wrote:
>> 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.
>
>The way you're wording it, it feels like we on purpose didn't follow what was 
>written in the policy. That's not the case.
>
>The point you're missing here, is that this policy is not obvious at all, and 
>it's easy to either not understand it, or not know about it.

That seems rather tangential to the question at hand.  In the cases you cited 
the people in question both knew about and understood the policy.  I agree that 
I am not really following your logic.  Andreas' explanation makes more sense to 
me, but it's neither here nor there as you don't need to convince me.

My only concern is that we not cause people to leave the team over this change. 
 I'm personally ambivalent about it.

Scott K

Re: Suggesting change in DPT policy

[Scott Kitterman]

On February 28, 2024 7:08:14 AM UTC, Andreas Tille  wrote:
>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:

This makes more sense to me.  It is completely understandable that how things 
are communicated affects how people feel about them.  This is a difficult thing 
to get right.  I have experienced similar demotivating conversations in Debian 
myself.

Everyone in Debian is already bound by the code of conduct already, so it seems 
redundant to add it here again.  While I agree with the principle you are 
trying to address, I think this change unnecessarily clutters the DPT document 
and we should not make it.

Scott K

Maintaining packages with complex relationships (Was: Suggesting change in DPT policy)

[Andreas Tille]

Hi Étienne,

Am Wed, Feb 28, 2024 at 09:37:59AM +0100 schrieb Étienne Mollier:
> > > 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.
> 
> Policy changes aside,
(Thus changed subject. ;-) )

> I think it could be useful for the
> routine-update command to stop when such file is hit, in order
> to raise the importance that the package has quirks, and should
> not be casually updated without involved scrutiny.  I wonder
> whether this can be generalized, like if d/README.source file is
> present?  (Although the latter use is codified[2] and I'm not
> confident it is 100% suitable for such purpose: I see many such
> files on my radar which do not necessarily hint for quirks.)
> 
> Of course this could be overred with a --readme-reviewed flag
> once ready to finalize the package with automation for instance.

I like all your suggestions.  When reading Timo's suggestion about
debian/README.DPT I also thought about rather using the more generic
debian/README.source.  In any case I agree that routine-update should
respect such debian/README.* (except debian/README.Debian which is
user oriented).

I admit I like this kind of constructive discussion.

Kind regards
   Andreas.
 
> > [1] 
> > https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/20
> [2]: 
> https://www.debian.org/doc/debian-policy/ch-source.html#source-package-handling-debian-readme-source

-- 
http://fam-tille.de

Re: Suggesting change in DPT policy

[Julian Gilbey]

On Tue, Feb 27, 2024 at 09:05:44AM +0100, Andreas Tille wrote:
> Hi,
> 
> [...]

+1 from me, too.  I had completely forgotten this paragraph in the
Python policy and it doesn't make that much sense.  I personally
generally do send an email to anyone in the "Maintainers" field or the
last uploader just as a matter of courtesy before working on
something, and then wait for a day before doing anything; for all I
know, they may already be working on a patch, especially if it's a
very new bug.  But if the model of team maintainership is made much
stronger and clearer, though I would still encourage sending an email
to the "main maintainer" for anything non-trivial, even if just to let
them know the situation.

In response to other comments, I suggest that those maintainers who do
not wish other team members to help work on their packages under this
new approach should just remove DPT from the Maintainer and Uploader
fields, and regard any offers of help as an NMU or merge request.

One tweak to Andreas's patch:

> diff --git a/policy.rst b/policy.rst
> index 27bf6f3..7185d6d 100644
> --- a/policy.rst
> +++ b/policy.rst
> @@ -48,20 +48,14 @@ Maintainership
>  ==
>  
>  A package maintained within the team should have the name of the team either

this should be:

- A package maintained within the team should have the name of the team either
+ A package maintained within the team should have the name of the team

> -in the ``Maintainer`` field or in the ``Uploaders`` field.
> +in the ``Maintainer``.

Best wishes,

   Julian

Re: Suggesting change in DPT policy

[Thomas Goirand]

On 2/28/24 09:21, Andreas Tille wrote:

Hi,

Louis-Philippe (just quoting below in case you might have missed it) is
repeating the importance that anyone who thinks my suggestion (MR[1]) is
a bad idea make themselves heard.  I'm hereby adding those maintainers
who have more than 5 packages that are affected and did not yet raised
their opinion in To: field.

udd=> SELECT * FROM (select maintainer, count(*) from sources where uploaders like 
'%team+pyt...@tracker.debian.org%' and release = 'sid' group by maintainer order by 
maintainer) tmp WHERE count > 5;
maintainer| 
count
-+---
  Debian PaN Maintainers  | 
7
  Jeroen Ploemen |
16
  Piotr Ożarowski  |23
  Sandro Tosi   |
82
  Scott Kitterman| 
7
  Vincent Bernat   |
15
(6 rows)


Note that it's been the case at least for Vincent, in at least a few 
instances, that the tooling (py2dsp you wrote?) made him wrongly put the 
team as uploader. There's porbably other cases as well.


Cheers,

Thomas Goirand (zigo)

Re: Suggesting change in DPT policy

[Thomas Goirand]

On 2/28/24 00:54, Scott Kitterman wrote:

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.


The way you're wording it, it feels like we on purpose didn't follow 
what was written in the policy. That's not the case.


The point you're missing here, is that this policy is not obvious at 
all, and it's easy to either not understand it, or not know about it.


Cheers,

Thomas Goirand (zigo)

Re: Suggesting change in DPT policy

[Agathe Porte]

Hi,

2024-02-27 09:06 CET, Andreas Tille:
> 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 also have been bitten by this recently. I assumed that the package was
DPT maintained because it was in the DPT namespace on Salsa.
But it was not. And I got a message after my upload.

If the package was outside of DPT, I would have created a bug instead
for the maintainer to handle. I do not understand the point of
Uploader: DPT compared to individually maintained packages.

So, +1 for this.

Re: Suggesting change in DPT policy

[Vincent Bernat]

Hello,

I support this change too. I am myself set to maintainer of packages 
just because whatever tool we used at the time to generate debian/ 
directory for a package did that.


On 2024-02-28 09:21, Andreas Tille wrote:

Hi,

Louis-Philippe (just quoting below in case you might have missed it) is
repeating the importance that anyone who thinks my suggestion (MR[1]) is
a bad idea make themselves heard.  I'm hereby adding those maintainers
who have more than 5 packages that are affected and did not yet raised
their opinion in To: field.

udd=> SELECT * FROM (select maintainer, count(*) from sources where uploaders like 
'%team+pyt...@tracker.debian.org%' and release = 'sid' group by maintainer order by 
maintainer) tmp WHERE count > 5;
maintainer| 
count
-+---
  Debian PaN Maintainers  | 
7
  Jeroen Ploemen |
16
  Piotr Ożarowski  |23
  Sandro Tosi   |
82
  Scott Kitterman| 
7
  Vincent Bernat   |
15
(6 rows)

Debian PaN is another team which might need extra discussion but I think
the intention is clear and Scott has raised his opinion before[2].

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/msg00060.html

Am Tue, Feb 27, 2024 at 03:36:24PM -0500 schrieb 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 

Re: Suggesting change in DPT policy

[Étienne Mollier]

Hi all,

Andreas Tille, on 2024-02-28:
> 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.

Thanks Timo for raising this point, it is important indeed.

> > 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.

Policy changes aside, I think it could be useful for the
routine-update command to stop when such file is hit, in order
to raise the importance that the package has quirks, and should
not be casually updated without involved scrutiny.  I wonder
whether this can be generalized, like if d/README.source file is
present?  (Although the latter use is codified[2] and I'm not
confident it is 100% suitable for such purpose: I see many such
files on my radar which do not necessarily hint for quirks.)

Of course this could be overred with a --readme-reviewed flag
once ready to finalize the package with automation for instance.

> [1] 
> https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/20
[2]: 
https://www.debian.org/doc/debian-policy/ch-source.html#source-package-handling-debian-readme-source

Have a nice day,  :)
-- 
  .''`.  Étienne Mollier 
 : :' :  pgp: 8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
 `. `'   sent from /dev/pts/1, please excuse my verbosity
   `-on air: Dream the Electric Sleep - Utopic


signature.asc
Description: PGP signature

Re: Suggesting change in DPT policy

[Andreas Tille]

Hi,

Louis-Philippe (just quoting below in case you might have missed it) is
repeating the importance that anyone who thinks my suggestion (MR[1]) is
a bad idea make themselves heard.  I'm hereby adding those maintainers
who have more than 5 packages that are affected and did not yet raised
their opinion in To: field.

udd=> SELECT * FROM (select maintainer, count(*) from sources where uploaders 
like '%team+pyt...@tracker.debian.org%' and release = 'sid' group by maintainer 
order by maintainer) tmp WHERE count > 5;
   maintainer| 
count 
-+---
 Debian PaN Maintainers  | 7
 Jeroen Ploemen |16
 Piotr Ożarowski  |23
 Sandro Tosi   |82
 Scott Kitterman| 7
 Vincent Bernat   |15
(6 rows)

Debian PaN is another team which might need extra discussion but I think
the intention is clear and Scott has raised his opinion before[2].

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/msg00060.html

Am Tue, Feb 27, 2024 at 03:36:24PM -0500 schrieb 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 

Re: Suggesting change in DPT policy

[Andreas Tille]

Am Tue, Feb 27, 2024 at 04:25:49PM + schrieb 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.

Good point.  I've filed

  #1064952 pypi2deb: Please set DPT as Maintainer and the ID of the person 
calling py2dsp as uploader

with a patch that works for me in one test example.

The interesting thing is that a tool targeting at streamlining the work
of DPT is not team maintained itself.  It is maintained by those two
maintainers who obviously see some value in the weak cooperation option

udd=> SELECT * FROM (select maintainer, count(*) from sources where uploaders 
like '%team+pyt...@tracker.debian.org%' and release = 'sid' group by maintainer 
order by maintainer) tmp WHERE count > 20;
 maintainer  | count 
-+---
 Piotr Ożarowski  |23
 Sandro Tosi   |82
(2 rows)

which might influence their decision of the design of the tool.

Kind regards
Andreas.


[1] https://bugs.debian.org/1064952

-- 
http://fam-tille.de

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

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: 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