On 2/27/24 09:05, Andreas Tille wrote:
Hi,
I became more deeply involved into DPT since 2022 as a consequence of
the suggestion for transfering several Debian Med/Science packages to
DPMT[1][2]. I happily followed this suggestion and moved >30 packages
from the Blends teams to DPT. I was happy with this move since it makes
sense.
Recently we received lots of testing removal warnings in those Blends
teams due to RC bugs caused by Cython 3.0 and Python3.12 migrations. So
I did what I usually do in those teams: I dedicated quite some time in
team wide bug hunting. That way I squashed about 50 bugs on packages
where I was not in Uploaders. When doing so I usually run
routine-update on the package which basically streamlines packaging to
latest standards including calling Janitor tools which are so far
accepted inside DPT.
I probably should have reviewed the DPT policy on Maintainership[3] more
carefully. In other teams, it's common for the Maintainer to be set to
the team, so I assumed it was just an oversight when I made this
change[4] when touching the package to fix RC bug #1058177. However, I
I was pointed immediately about the fact that I was mistaken according
to the current DPT policy. I apologize for this. However, the wording
of the comment on my commit was discouraging, especially considering I
was a volunteer who had fixed a critical bug. Because of this, I
decided to focus my efforts on fixing other critical bugs for the
moment. If the comment had started with a 'Thanks for fixing the
critical bug, but...' I likely would have corrected my mistake quickly.
The lack of respect from my teammate simply made me prioritize my time
on other issues that are more visible to our users. I wonder whether I
should propose another change to the policy about maintaining a kind and
polite language inside the team - but that's a different thing.
While I applied the patch for another RC bug (#1063443) after >2 weeks
which triggered a RC bug in reportbug I remembered the "keep the
maintainer" policy. But I kept on doing Janitor like changes since
finally the package is maintained in a team where Janitor is accepted.
When doing so I failed the phrase "please contact the Maintainer for the
green light." I apoligize for this again. The response was another
volunteer-demotivating private mail (thus no quote) which also was
lacking the "Thanks for fixing"-phrase and degrading my changes as
"frivolous".
So far what happened (seen from my possibly biased perspective).
Why do I like to change the policy?
The current wording provides some means to stop volunteer team members
helping out moving forward to speed up migrations and fix Debian wide
dependencies. It hides team maintained packages from a common BTS
view. When pointing my browser to
https://bugs.debian.org/team+python@tracker.debian.org
I currently see 1339 open bugs (calculated by [UDD1]). This hides
another 309 [UDD2] bugs (>18% of team bugs) from our sight. To work
around this flaw I used an UDD query to find relevant Python3.12 bugs.
When I think twice about the wording
Team in Uploaders is a weak statement of collaboration.[3]
I personally consider it a statement of *no* collaboration (which fits
the wording of the responses I've got).
How can a team member for instance find another RC bug #1009424? Just
from reading the bug report it is pretty easy to fix but does not
feature any response in BTS. I came across this while looking into
Cython 3.0 bugs. The same source package (basemap) that had the open
Cython bug (#1056789, tagged patch since 2023-12-09) is featuring RC bug
(#1009424) that stayed unattended for 22 months? We all know volunteers
have limited time and I do not want to blame anybody in the team to not
care promptly about RC bugs. But what else is the sense of a packaging
team than stepping in situations for long standing RC bugs and RC bugs
tagged patch?
This kind of situation wouldn't occur in teams where collaboration is
strong and communication is effective. My motivation to address these
long-ignored critical bugs diminishes when the maintainer opts for
"weak" cooperation and lacks respectful communication with potential
helpers. I see no difference to simply do a NMU.
I've checked the current situation who is actually using the DPT team as
Uploaders[UDD3]. 66 of the 73 maintainers have less than 5 packages
some of these "Maintainers" are other teams and lots of the persons
listed as Maintainer are known to be MIA. This means the packages are
de-facto not maintained which is most probably an unwanted effect of the
current policy. I know other maintainers from other teams to be fine
with stronger team understanding.
Since I consider the current situation as demotivating for newcomers
as well as long standing contributors I would like to suggest to drop
this "weak statement of collaboration" option from policy. I've attached
an according patch to the team policy[5]. I'm fine with creating a MR
to be discussed rather in Salsa than this mailing list - whatever seems
worthwhile to you.
Kind regards
Andreas.
Hi Andreas,
I had similar experience, and the same kind of demotivating response from the same person. So I'm not surprised.
It's been a long long time that I would have like this DPT policy to go away, but didn't dare to raise the topic. Though indeed, I don't think it's reasonable to have a package in the team, but with strong ownership. I believe that we should either have a package in the team, or not. Period.
If someone isn't happy about this policy change, it's ok to move the package way from the team, if having team-mate working on "your" package isn't ok (of course, we would all prefer this doesn't happen, and that we work collaboratively). This would make things a way clearer.
So I'm 100% with you for the removal of this policy.
To everyone else in the team: please also state your opinion, so we can make a collective decision.
Since I consider the current situation as demotivating for+1 from me.
newcomers as well as long standing contributors I would like to
suggest to drop this "weak statement of collaboration" option from
policy.
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.
On Tue, 27 Feb 2024, Thomas Goirand wrote:have a package in the team, or not. Period.
On 2/27/24 09:05, Andreas Tille wrote:
Hi,
I became more deeply involved into DPT since 2022 as a consequence of
the suggestion for transfering several Debian Med/Science packages to
DPMT[1][2]. I happily followed this suggestion and moved >30 packages
from the Blends teams to DPT. I was happy with this move since it makes >>> sense.
Recently we received lots of testing removal warnings in those Blends
teams due to RC bugs caused by Cython 3.0 and Python3.12 migrations. So >>> I did what I usually do in those teams: I dedicated quite some time in
team wide bug hunting. That way I squashed about 50 bugs on packages
where I was not in Uploaders. When doing so I usually run
routine-update on the package which basically streamlines packaging to
latest standards including calling Janitor tools which are so far
accepted inside DPT.
I probably should have reviewed the DPT policy on Maintainership[3] more >>> carefully. In other teams, it's common for the Maintainer to be set to
the team, so I assumed it was just an oversight when I made this
change[4] when touching the package to fix RC bug #1058177. However, I
I was pointed immediately about the fact that I was mistaken according
to the current DPT policy. I apologize for this. However, the wording
of the comment on my commit was discouraging, especially considering I
was a volunteer who had fixed a critical bug. Because of this, I
decided to focus my efforts on fixing other critical bugs for the
moment. If the comment had started with a 'Thanks for fixing the
critical bug, but...' I likely would have corrected my mistake quickly.
The lack of respect from my teammate simply made me prioritize my time
on other issues that are more visible to our users. I wonder whether I
should propose another change to the policy about maintaining a kind and >>> polite language inside the team - but that's a different thing.
While I applied the patch for another RC bug (#1063443) after >2 weeks
which triggered a RC bug in reportbug I remembered the "keep the
maintainer" policy. But I kept on doing Janitor like changes since
finally the package is maintained in a team where Janitor is accepted.
When doing so I failed the phrase "please contact the Maintainer for the >>> green light." I apoligize for this again. The response was another
volunteer-demotivating private mail (thus no quote) which also was
lacking the "Thanks for fixing"-phrase and degrading my changes as
"frivolous".
So far what happened (seen from my possibly biased perspective).
Why do I like to change the policy?
The current wording provides some means to stop volunteer team members
helping out moving forward to speed up migrations and fix Debian wide
dependencies. It hides team maintained packages from a common BTS
view. When pointing my browser to
https://bugs.debian.org/team+python@tracker.debian.org
I currently see 1339 open bugs (calculated by [UDD1]). This hides
another 309 [UDD2] bugs (>18% of team bugs) from our sight. To work
around this flaw I used an UDD query to find relevant Python3.12 bugs.
When I think twice about the wording
Team in Uploaders is a weak statement of collaboration.[3]
I personally consider it a statement of *no* collaboration (which fits
the wording of the responses I've got).
How can a team member for instance find another RC bug #1009424? Just
from reading the bug report it is pretty easy to fix but does not
feature any response in BTS. I came across this while looking into
Cython 3.0 bugs. The same source package (basemap) that had the open
Cython bug (#1056789, tagged patch since 2023-12-09) is featuring RC bug >>> (#1009424) that stayed unattended for 22 months? We all know volunteers >>> have limited time and I do not want to blame anybody in the team to not
care promptly about RC bugs. But what else is the sense of a packaging
team than stepping in situations for long standing RC bugs and RC bugs
tagged patch?
This kind of situation wouldn't occur in teams where collaboration is
strong and communication is effective. My motivation to address these
long-ignored critical bugs diminishes when the maintainer opts for
"weak" cooperation and lacks respectful communication with potential
helpers. I see no difference to simply do a NMU.
I've checked the current situation who is actually using the DPT team as >>> Uploaders[UDD3]. 66 of the 73 maintainers have less than 5 packages
some of these "Maintainers" are other teams and lots of the persons
listed as Maintainer are known to be MIA. This means the packages are
de-facto not maintained which is most probably an unwanted effect of the >>> current policy. I know other maintainers from other teams to be fine
with stronger team understanding.
Since I consider the current situation as demotivating for newcomers
as well as long standing contributors I would like to suggest to drop
this "weak statement of collaboration" option from policy. I've attached >>> an according patch to the team policy[5]. I'm fine with creating a MR
to be discussed rather in Salsa than this mailing list - whatever seems
worthwhile to you.
Kind regards
Andreas.
Hi Andreas,
I had similar experience, and the same kind of demotivating response from the same person. So I'm not surprised.
It's been a long long time that I would have like this DPT policy to go away, but didn't dare to raise the topic. Though indeed, I don't think it's reasonable to have a package in the team, but with strong ownership. I believe that we should either
make things a way clearer.
If someone isn't happy about this policy change, it's ok to move the package way from the team, if having team-mate working on "your" package isn't ok (of course, we would all prefer this doesn't happen, and that we work collaboratively). This would
So I'm 100% with you for the removal of this policy.
To everyone else in the team: please also state your opinion, so we can make a collective decision.
I agree with both of you. I think packages should be team maintained or not at all. No middle area.
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.
Hi,
I became more deeply involved into DPT since 2022 as a consequence of
the suggestion for transfering several Debian Med/Science packages to DPMT[1][2]. I happily followed this suggestion and moved >30 packages
from the Blends teams to DPT. I was happy with this move since it makes sense.
Recently we received lots of testing removal warnings in those Blends
teams due to RC bugs caused by Cython 3.0 and Python3.12 migrations. So
I did what I usually do in those teams: I dedicated quite some time in
team wide bug hunting. That way I squashed about 50 bugs on packages
where I was not in Uploaders. When doing so I usually run
routine-update on the package which basically streamlines packaging to
latest standards including calling Janitor tools which are so far
accepted inside DPT.
I probably should have reviewed the DPT policy on Maintainership[3] more carefully. In other teams, it's common for the Maintainer to be set to
the team, so I assumed it was just an oversight when I made this
change[4] when touching the package to fix RC bug #1058177. However, I
I was pointed immediately about the fact that I was mistaken according
to the current DPT policy. I apologize for this. However, the wording
of the comment on my commit was discouraging, especially considering I
was a volunteer who had fixed a critical bug. Because of this, I
decided to focus my efforts on fixing other critical bugs for the
moment. If the comment had started with a 'Thanks for fixing the
critical bug, but...' I likely would have corrected my mistake quickly.
The lack of respect from my teammate simply made me prioritize my time
on other issues that are more visible to our users. I wonder whether I should propose another change to the policy about maintaining a kind and polite language inside the team - but that's a different thing.
While I applied the patch for another RC bug (#1063443) after >2 weeks
which triggered a RC bug in reportbug I remembered the "keep the
maintainer" policy. But I kept on doing Janitor like changes since
finally the package is maintained in a team where Janitor is accepted.
When doing so I failed the phrase "please contact the Maintainer for the green light." I apoligize for this again. The response was another volunteer-demotivating private mail (thus no quote) which also was
lacking the "Thanks for fixing"-phrase and degrading my changes as "frivolous".
So far what happened (seen from my possibly biased perspective).
Why do I like to change the policy?
The current wording provides some means to stop volunteer team members helping out moving forward to speed up migrations and fix Debian wide dependencies. It hides team maintained packages from a common BTS
view. When pointing my browser to
https://bugs.debian.org/team+python@tracker.debian.org
I currently see 1339 open bugs (calculated by [UDD1]). This hides
another 309 [UDD2] bugs (>18% of team bugs) from our sight. To work
around this flaw I used an UDD query to find relevant Python3.12 bugs.
When I think twice about the wording
Team in Uploaders is a weak statement of collaboration.[3]
I personally consider it a statement of *no* collaboration (which fits
the wording of the responses I've got).
How can a team member for instance find another RC bug #1009424? Just
from reading the bug report it is pretty easy to fix but does not
feature any response in BTS. I came across this while looking into
Cython 3.0 bugs. The same source package (basemap) that had the open
Cython bug (#1056789, tagged patch since 2023-12-09) is featuring RC bug (#1009424) that stayed unattended for 22 months? We all know volunteers
have limited time and I do not want to blame anybody in the team to not
care promptly about RC bugs. But what else is the sense of a packaging
team than stepping in situations for long standing RC bugs and RC bugs
tagged patch?
This kind of situation wouldn't occur in teams where collaboration is
strong and communication is effective. My motivation to address these long-ignored critical bugs diminishes when the maintainer opts for
"weak" cooperation and lacks respectful communication with potential
helpers. I see no difference to simply do a NMU.
I've checked the current situation who is actually using the DPT team as Uploaders[UDD3]. 66 of the 73 maintainers have less than 5 packages
some of these "Maintainers" are other teams and lots of the persons
listed as Maintainer are known to be MIA. This means the packages are de-facto not maintained which is most probably an unwanted effect of the current policy. I know other maintainers from other teams to be fine
with stronger team understanding.
Since I consider the current situation as demotivating for newcomers
as well as long standing contributors I would like to suggest to drop
this "weak statement of collaboration" option from policy. I've attached
an according patch to the team policy[5]. I'm fine with creating a MR
to be discussed rather in Salsa than this mailing list - whatever seems worthwhile to you.
maintainer? It simply doesn't make sense.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
So at the end, if packages get "removed from the team", it's a good thing: it clarifies the situation.do not wish others also receive this kind of demotivating message anymore.
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
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.
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 canbe demotivating when people ignore them, so we should get rid of them all so your feelings are safe.
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.
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 initialpackaging 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.
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+python@tracker.debian.org
I currently see 1339 open bugs (calculated by [UDD1]). This hides
another 309 [UDD2] bugs (>18% of team bugs) from our sight. To work
around this flaw I used an UDD query to find relevant Python3.12 bugs.
When I think twice about the wording
Team in Uploaders is a weak statement of collaboration.[3]
I personally consider it a statement of *no* collaboration (which fits
the wording of the responses I've got).
How can a team member for instance find another RC bug #1009424? Just
from reading the bug report it is pretty easy to fix but does not
feature any response in BTS. I came across this while looking into
Cython 3.0 bugs. The same source package (basemap) that had the open Cython bug (#1056789, tagged patch since 2023-12-09) is featuring RC bug (#1009424) that stayed unattended for 22 months? We all know volunteers have limited time and I do not want to blame anybody in the team to not care promptly about RC bugs. But what else is the sense of a packaging team than stepping in situations for long standing RC bugs and RC bugs tagged patch?
This kind of situation wouldn't occur in teams where collaboration is strong and communication is effective. My motivation to address these long-ignored critical bugs diminishes when the maintainer opts for
"weak" cooperation and lacks respectful communication with potential helpers. I see no difference to simply do a NMU.
I've checked the current situation who is actually using the DPT team as Uploaders[UDD3]. 66 of the 73 maintainers have less than 5 packages
some of these "Maintainers" are other teams and lots of the persons
listed as Maintainer are known to be MIA. This means the packages are de-facto not maintained which is most probably an unwanted effect of the current policy. I know other maintainers from other teams to be fine
with stronger team understanding.
Since I consider the current situation as demotivating for newcomers
as well as long standing contributors I would like to suggest to drop
this "weak statement of collaboration" option from policy. I've attached an according patch to the team policy[5]. I'm fine with creating a MR
to be discussed rather in Salsa than this mailing list - whatever seems worthwhile to you.
I too, support this change.
As Scott said, I want to reiterate that I think it's important that anyone who thinks this is a bad idea to make themselves heard.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ pollo@debian.org / veronneau.org
⠈⠳⣄
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.
[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
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.
(Thus changed subject. ;-) )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
Hi,
[...]
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
-in the ``Maintainer`` field or in the ``Uploaders`` field.
+in the ``Maintainer``.
be demotivating when people ignore them, so we should get rid of them all so your feelings are safe.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
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.
Am Tue, Feb 27, 2024 at 11:54:01PM +0000 schrieb Scott Kitterman:be demotivating when people ignore them, so we should get rid of them all so your feelings are safe.
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
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:
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+python@tracker.debian.org%' and release = 'sid' group by maintainer order by maintainer) tmp WHERE count > 5; maintainer
| count -------------------------------------------------------------------------+- ------ Debian PaN Maintainers <debian-pan-maintainers@alioth-lists.debian.net> | 7
Jeroen Ploemen <jcfp@debian.org> | 16
Piotr Ożarowski <piotr@debian.org> | 23
Sandro Tosi <morph@debian.org> | 82
Scott Kitterman <scott@kitterman.com> | 7
Vincent Bernat <bernat@debian.org> | 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
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 notmake it.
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.
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).
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.
To everyone else in the team: please also state your opinion, so we can
make a collective decision.
On Tue, 27 Feb 2024 18:32:54 +0000
Scott Kitterman <debian@kitterman.com> 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.
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.
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 sinceI 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 <morph@debian.org> 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 <morph@debian.org> 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 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?
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.
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 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.
Hi,
I became more deeply involved into DPT since 2022 as a consequence of
the suggestion for transfering several Debian Med/Science packages to DPMT[1][2]. I happily followed this suggestion and moved >30 packages
from the Blends teams to DPT. I was happy with this move since it makes sense.
Recently we received lots of testing removal warnings in those Blends
teams due to RC bugs caused by Cython 3.0 and Python3.12 migrations. So
I did what I usually do in those teams: I dedicated quite some time in
team wide bug hunting. That way I squashed about 50 bugs on packages
where I was not in Uploaders. When doing so I usually run
routine-update on the package which basically streamlines packaging to
latest standards including calling Janitor tools which are so far
accepted inside DPT.
I probably should have reviewed the DPT policy on Maintainership[3] more carefully. In other teams, it's common for the Maintainer to be set to
the team, so I assumed it was just an oversight when I made this
change[4] when touching the package to fix RC bug #1058177. However, I
I was pointed immediately about the fact that I was mistaken according
to the current DPT policy. I apologize for this. However, the wording
of the comment on my commit was discouraging, especially considering I
was a volunteer who had fixed a critical bug. Because of this, I
decided to focus my efforts on fixing other critical bugs for the
moment. If the comment had started with a 'Thanks for fixing the
critical bug, but...' I likely would have corrected my mistake quickly.
The lack of respect from my teammate simply made me prioritize my time
on other issues that are more visible to our users. I wonder whether I should propose another change to the policy about maintaining a kind and polite language inside the team - but that's a different thing.
While I applied the patch for another RC bug (#1063443) after >2 weeks
which triggered a RC bug in reportbug I remembered the "keep the
maintainer" policy. But I kept on doing Janitor like changes since
finally the package is maintained in a team where Janitor is accepted.
When doing so I failed the phrase "please contact the Maintainer for the green light." I apoligize for this again. The response was another volunteer-demotivating private mail (thus no quote) which also was
lacking the "Thanks for fixing"-phrase and degrading my changes as "frivolous".
So far what happened (seen from my possibly biased perspective).
Why do I like to change the policy?
The current wording provides some means to stop volunteer team members helping out moving forward to speed up migrations and fix Debian wide dependencies. It hides team maintained packages from a common BTS
view. When pointing my browser to
https://bugs.debian.org/team+python@tracker.debian.org
I currently see 1339 open bugs (calculated by [UDD1]). This hides
another 309 [UDD2] bugs (>18% of team bugs) from our sight. To work
around this flaw I used an UDD query to find relevant Python3.12 bugs.
When I think twice about the wording
Team in Uploaders is a weak statement of collaboration.[3]
I personally consider it a statement of *no* collaboration (which fits
the wording of the responses I've got).
How can a team member for instance find another RC bug #1009424? Just
from reading the bug report it is pretty easy to fix but does not
feature any response in BTS. I came across this while looking into
Cython 3.0 bugs. The same source package (basemap) that had the open
Cython bug (#1056789, tagged patch since 2023-12-09) is featuring RC bug (#1009424) that stayed unattended for 22 months? We all know volunteers
have limited time and I do not want to blame anybody in the team to not
care promptly about RC bugs. But what else is the sense of a packaging
team than stepping in situations for long standing RC bugs and RC bugs
tagged patch?
This kind of situation wouldn't occur in teams where collaboration is
strong and communication is effective. My motivation to address these long-ignored critical bugs diminishes when the maintainer opts for
"weak" cooperation and lacks respectful communication with potential
helpers. I see no difference to simply do a NMU.
I've checked the current situation who is actually using the DPT team as Uploaders[UDD3]. 66 of the 73 maintainers have less than 5 packages
some of these "Maintainers" are other teams and lots of the persons
listed as Maintainer are known to be MIA. This means the packages are de-facto not maintained which is most probably an unwanted effect of the current policy. I know other maintainers from other teams to be fine
with stronger team understanding.
Since I consider the current situation as demotivating for newcomers
as well as long standing contributors I would like to suggest to drop
this "weak statement of collaboration" option from policy. I've attached
an according patch to the team policy[5]. I'm fine with creating a MR
to be discussed rather in Salsa than this mailing list - whatever seems worthwhile to you.
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?
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.
I became more deeply involved into DPT since 2022 as a consequence of
the suggestion for transfering several Debian Med/Science packages to
DPMT[1][2]. I happily followed this suggestion and moved >30 packages
from the Blends teams to DPT. I was happy with this move since it makes
sense.
Recently we received lots of testing removal warnings in those Blends
teams due to RC bugs caused by Cython 3.0 and Python3.12 migrations. So
I did what I usually do in those teams: I dedicated quite some time in
team wide bug hunting. That way I squashed about 50 bugs on packages
where I was not in Uploaders. When doing so I usually run
routine-update on the package which basically streamlines packaging to
latest standards including calling Janitor tools which are so far
accepted inside DPT.
I probably should have reviewed the DPT policy on Maintainership[3] more
carefully. In other teams, it's common for the Maintainer to be set to
the team, so I assumed it was just an oversight when I made this
change[4] when touching the package to fix RC bug #1058177. However, I
I was pointed immediately about the fact that I was mistaken according
to the current DPT policy. I apologize for this. However, the wording
of the comment on my commit was discouraging, especially considering I
was a volunteer who had fixed a critical bug. Because of this, I
decided to focus my efforts on fixing other critical bugs for the
moment. If the comment had started with a 'Thanks for fixing the
critical bug, but...' I likely would have corrected my mistake quickly.
The lack of respect from my teammate simply made me prioritize my time
on other issues that are more visible to our users. I wonder whether I
should propose another change to the policy about maintaining a kind and
polite language inside the team - but that's a different thing.
While I applied the patch for another RC bug (#1063443) after >2 weeks
which triggered a RC bug in reportbug I remembered the "keep the
maintainer" policy. But I kept on doing Janitor like changes since
finally the package is maintained in a team where Janitor is accepted.
When doing so I failed the phrase "please contact the Maintainer for the
green light." I apoligize for this again. The response was another
volunteer-demotivating private mail (thus no quote) which also was
lacking the "Thanks for fixing"-phrase and degrading my changes as
"frivolous".
So far what happened (seen from my possibly biased perspective).
Why do I like to change the policy?
The current wording provides some means to stop volunteer team members
helping out moving forward to speed up migrations and fix Debian wide
dependencies. It hides team maintained packages from a common BTS
view. When pointing my browser to
https://bugs.debian.org/team+python@tracker.debian.org
I currently see 1339 open bugs (calculated by [UDD1]). This hides
another 309 [UDD2] bugs (>18% of team bugs) from our sight. To work
around this flaw I used an UDD query to find relevant Python3.12 bugs.
When I think twice about the wording
Team in Uploaders is a weak statement of collaboration.[3]
I personally consider it a statement of *no* collaboration (which fits
the wording of the responses I've got).
How can a team member for instance find another RC bug #1009424? Just
from reading the bug report it is pretty easy to fix but does not
feature any response in BTS. I came across this while looking into
Cython 3.0 bugs. The same source package (basemap) that had the open
Cython bug (#1056789, tagged patch since 2023-12-09) is featuring RC bug
(#1009424) that stayed unattended for 22 months? We all know volunteers
have limited time and I do not want to blame anybody in the team to not
care promptly about RC bugs. But what else is the sense of a packaging
team than stepping in situations for long standing RC bugs and RC bugs
tagged patch?
This kind of situation wouldn't occur in teams where collaboration is
strong and communication is effective. My motivation to address these
long-ignored critical bugs diminishes when the maintainer opts for
"weak" cooperation and lacks respectful communication with potential
helpers. I see no difference to simply do a NMU.
I've checked the current situation who is actually using the DPT team as
Uploaders[UDD3]. 66 of the 73 maintainers have less than 5 packages
some of these "Maintainers" are other teams and lots of the persons
listed as Maintainer are known to be MIA. This means the packages are
de-facto not maintained which is most probably an unwanted effect of the
current policy. I know other maintainers from other teams to be fine
with stronger team understanding.
Since I consider the current situation as demotivating for newcomers
as well as long standing contributors I would like to suggest to drop
this "weak statement of collaboration" option from policy. I've attached
an according patch to the team policy[5]. I'm fine with creating a MR
to be discussed rather in Salsa than this mailing list - whatever seems
worthwhile to you.
I am late to the party but I agree with the policy change.
Best,
Nilesh
Same for me. Thanks for proposal. +1
Anton
Am Sa., 9. Mrz 2024 um 17:51Uhr schrieb Nilesh Patra <nilesh@debian.org>:
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:
---
[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:
---
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 <team+python@tracker.debian.org>
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 ***]
---
From my (probably biased) perspective MR "Drop option of weakcollaboration and permit DPT team as Maintainer only"[3] which is discussed
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 109:02:44 |
| Calls: | 6,700 |
| Files: | 12,232 |
| Messages: | 5,348,484 |