• Suggesting change in DPT policy

    From Andreas Tille@21:1/5 to All on Tue Feb 27 09:10:01 2024
    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.


    [1] https://lists.debian.org/debian-python/2021/12/msg00051.html
    [2] https://lists.debian.org/debian-python/2021/12/msg00051.html
    [3] https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#maintainership
    [4] https://salsa.debian.org/python-team/packages/sphinxtesters/-/commit/d8b1083db26c753c8a76dd91b7e91f3ef98c0515
    [5] https://salsa.debian.org/python-team/tools/python-modules


    PGPASSWORD="udd-mirror" psql --port=5432 --host=udd-mirror.debian.net --username=udd-mirror udd -c \

    [UDD1] select count(*) from bugs b inner join (select distinct source, maintainer FROM sources WHERE maintainer_email = 'team+python@tracker.debian.org') s ON s.source=b.source where status not in ('done');
    [UDD2] select count(*) from bugs b inner join (select distinct source, uploaders FROM sources WHERE uploaders like '%team+python@tracker.debian.org%') s ON s.source=b.source where status not in ('done');
    [UDD3] select maintainer, count(*) from sources where uploaders like '%team+python@tracker.debian.org%' and release = 'sid' group by maintainer order by maintainer;

    --
    http://fam-tille.de

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

    Maintainer: Debian Python Team <team+python@tracker.debian.org>

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

    -* Team in ``Maintainers`` is a strong statement that fully collaborative
    - maintenance is preferred. Anyone can commit to the Git repository and upload - as needed. A courtesy email to ``Uploaders`` can be nice but not required.
    -
    -* Team in ``Uploaders`` is a weak statement of collaboration. Help in
    - maintaining the package is appreciated, commits to the Git repository are
    - freely welcomed, but before uploading, please contact the ``Maintainer`` for - the green light.
    +Anyone can commit to the Git repository and upload
    +as needed.

    Team members who have broad interest should subscribe t
  • From Scott Talbert@21:1/5 to Thomas Goirand on Tue Feb 27 15:30:02 2024
    On Tue, 27 Feb 2024, Thomas Goirand wrote:

    On 2/27/24 09:05, Andreas Tille wrote:
    Hi,

    I became more deeply involved into DPT since 2022 as a consequence of
    the suggestion for transfering several Debian Med/Science packages to
    DPMT[1][2]. I happily followed this suggestion and moved >30 packages
    from the Blends teams to DPT. I was happy with this move since it makes
    sense.

    Recently we received lots of testing removal warnings in those Blends
    teams due to RC bugs caused by Cython 3.0 and Python3.12 migrations. So
    I did what I usually do in those teams: I dedicated quite some time in
    team wide bug hunting. That way I squashed about 50 bugs on packages
    where I was not in Uploaders. When doing so I usually run
    routine-update on the package which basically streamlines packaging to
    latest standards including calling Janitor tools which are so far
    accepted inside DPT.

    I probably should have reviewed the DPT policy on Maintainership[3] more
    carefully. In other teams, it's common for the Maintainer to be set to
    the team, so I assumed it was just an oversight when I made this
    change[4] when touching the package to fix RC bug #1058177. However, I
    I was pointed immediately about the fact that I was mistaken according
    to the current DPT policy. I apologize for this. However, the wording
    of the comment on my commit was discouraging, especially considering I
    was a volunteer who had fixed a critical bug. Because of this, I
    decided to focus my efforts on fixing other critical bugs for the
    moment. If the comment had started with a 'Thanks for fixing the
    critical bug, but...' I likely would have corrected my mistake quickly.
    The lack of respect from my teammate simply made me prioritize my time
    on other issues that are more visible to our users. I wonder whether I
    should propose another change to the policy about maintaining a kind and
    polite language inside the team - but that's a different thing.

    While I applied the patch for another RC bug (#1063443) after >2 weeks
    which triggered a RC bug in reportbug I remembered the "keep the
    maintainer" policy. But I kept on doing Janitor like changes since
    finally the package is maintained in a team where Janitor is accepted.
    When doing so I failed the phrase "please contact the Maintainer for the
    green light." I apoligize for this again. The response was another
    volunteer-demotivating private mail (thus no quote) which also was
    lacking the "Thanks for fixing"-phrase and degrading my changes as
    "frivolous".

    So far what happened (seen from my possibly biased perspective).

    Why do I like to change the policy?

    The current wording provides some means to stop volunteer team members
    helping out moving forward to speed up migrations and fix Debian wide
    dependencies. It hides team maintained packages from a common BTS
    view. When pointing my browser to
    https://bugs.debian.org/team+python@tracker.debian.org
    I currently see 1339 open bugs (calculated by [UDD1]). This hides
    another 309 [UDD2] bugs (>18% of team bugs) from our sight. To work
    around this flaw I used an UDD query to find relevant Python3.12 bugs.

    When I think twice about the wording
    Team in Uploaders is a weak statement of collaboration.[3]
    I personally consider it a statement of *no* collaboration (which fits
    the wording of the responses I've got).

    How can a team member for instance find another RC bug #1009424? Just
    from reading the bug report it is pretty easy to fix but does not
    feature any response in BTS. I came across this while looking into
    Cython 3.0 bugs. The same source package (basemap) that had the open
    Cython bug (#1056789, tagged patch since 2023-12-09) is featuring RC bug
    (#1009424) that stayed unattended for 22 months? We all know volunteers
    have limited time and I do not want to blame anybody in the team to not
    care promptly about RC bugs. But what else is the sense of a packaging
    team than stepping in situations for long standing RC bugs and RC bugs
    tagged patch?

    This kind of situation wouldn't occur in teams where collaboration is
    strong and communication is effective. My motivation to address these
    long-ignored critical bugs diminishes when the maintainer opts for
    "weak" cooperation and lacks respectful communication with potential
    helpers. I see no difference to simply do a NMU.

    I've checked the current situation who is actually using the DPT team as
    Uploaders[UDD3]. 66 of the 73 maintainers have less than 5 packages
    some of these "Maintainers" are other teams and lots of the persons
    listed as Maintainer are known to be MIA. This means the packages are
    de-facto not maintained which is most probably an unwanted effect of the
    current policy. I know other maintainers from other teams to be fine
    with stronger team understanding.

    Since I consider the current situation as demotivating for newcomers
    as well as long standing contributors I would like to suggest to drop
    this "weak statement of collaboration" option from policy. I've attached
    an according patch to the team policy[5]. I'm fine with creating a MR
    to be discussed rather in Salsa than this mailing list - whatever seems
    worthwhile to you.

    Kind regards
    Andreas.

    Hi Andreas,

    I had similar experience, and the same kind of demotivating response from the same person. So I'm not surprised.

    It's been a long long time that I would have like this DPT policy to go away, but didn't dare to raise the topic. Though indeed, I don't think it's reasonable to have a package in the team, but with strong ownership. I believe that we should either have a package in the team, or not. Period.

    If someone isn't happy about this policy change, it's ok to move the package way from the team, if having team-mate working on "your" package isn't ok (of course, we would all prefer this doesn't happen, and that we work collaboratively). This would make things a way clearer.

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

    To everyone else in the team: please also state your opinion, so we can make a collective decision.

    I agree with both of you. I think packages should be team maintained or
    not at all. No middle area.

    Regards,
    Scott

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Timo =?utf-8?Q?R=C3=B6hling?=@21:1/5 to All on Tue Feb 27 16:10:02 2024
    Hi,

    * Andreas Tille <andreas@an3as.eu> [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 │
    ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯

    -----BEGIN PGP SIGNATURE-----

    iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmXd+wAACgkQ+C8H+466 LVlY6gwA6mEGEicOOryBd+xQVsviveQbCinw/Sk06kM5GtUjIWvK+vOlYlWj2F6V 9CtCIPl9duaI0i10oiJzPbmO/AmvppW+epTfTFoROBCRa6mWB8XARg+HoAEzXo0e fiXs2J0jFYdjhr5V0TiRh3o6cHArCUpj0QGFXx1GJ9lyTzGs1Dzx2AEsrrAeCwHv 1cIYgfUNOk/vJg+B3XYO0g22vgGeg19hmS5xvSItWjSXY5ZiEDxWnxHOsc6uRmKA LaWLTg3+k8R3IzkNcd0PjcinibAjxlPxN7Nnjq617WJiT/V6lxl9FgCAyoVoyMqh 98dpSfGaDZP1zTsBdRrj7rdb/pyU2TVP3NqE1mJYK3l
  • From Martin@21:1/5 to Thomas Goirand on Tue Feb 27 16:40:03 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From weepingclown@21:1/5 to All on Tue Feb 27 17:30:01 2024
    ------WBCFREU813RPFSLZ9G5XCVPU3PIM8C
    Content-Type: text/plain;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    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
    ------WBCFREU813RPFSLZ9G5XCVPU3PIM8C
    Content-Type: text/html;
    charset=utf-8
    Content-Transfer-Encoding: quoted-printable

    <!DOCTYPE html><html><body><div dir="auto">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.<br><br>Best,<br>Ananthu</div></body></html> ------WBCFREU813RPFSLZ9G5XCVPU3PIM8C--

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Kitterman@21:1/5 to Scott Talbert on Tue Feb 27 19:40:02 2024
    On February 27, 2024 2:27:35 PM UTC, Scott Talbert <swt@techie.net> wrote:
    On Tue, 27 Feb 2024, Thomas Goirand wrote:

    On 2/27/24 09:05, Andreas Tille wrote:
    Hi,

    I became more deeply involved into DPT since 2022 as a consequence of
    the suggestion for transfering several Debian Med/Science packages to
    DPMT[1][2]. I happily followed this suggestion and moved >30 packages
    from the Blends teams to DPT. I was happy with this move since it makes >>> sense.

    Recently we received lots of testing removal warnings in those Blends
    teams due to RC bugs caused by Cython 3.0 and Python3.12 migrations. So >>> I did what I usually do in those teams: I dedicated quite some time in
    team wide bug hunting. That way I squashed about 50 bugs on packages
    where I was not in Uploaders. When doing so I usually run
    routine-update on the package which basically streamlines packaging to
    latest standards including calling Janitor tools which are so far
    accepted inside DPT.

    I probably should have reviewed the DPT policy on Maintainership[3] more >>> carefully. In other teams, it's common for the Maintainer to be set to
    the team, so I assumed it was just an oversight when I made this
    change[4] when touching the package to fix RC bug #1058177. However, I
    I was pointed immediately about the fact that I was mistaken according
    to the current DPT policy. I apologize for this. However, the wording
    of the comment on my commit was discouraging, especially considering I
    was a volunteer who had fixed a critical bug. Because of this, I
    decided to focus my efforts on fixing other critical bugs for the
    moment. If the comment had started with a 'Thanks for fixing the
    critical bug, but...' I likely would have corrected my mistake quickly.
    The lack of respect from my teammate simply made me prioritize my time
    on other issues that are more visible to our users. I wonder whether I
    should propose another change to the policy about maintaining a kind and >>> polite language inside the team - but that's a different thing.

    While I applied the patch for another RC bug (#1063443) after >2 weeks
    which triggered a RC bug in reportbug I remembered the "keep the
    maintainer" policy. But I kept on doing Janitor like changes since
    finally the package is maintained in a team where Janitor is accepted.
    When doing so I failed the phrase "please contact the Maintainer for the >>> green light." I apoligize for this again. The response was another
    volunteer-demotivating private mail (thus no quote) which also was
    lacking the "Thanks for fixing"-phrase and degrading my changes as
    "frivolous".

    So far what happened (seen from my possibly biased perspective).

    Why do I like to change the policy?

    The current wording provides some means to stop volunteer team members
    helping out moving forward to speed up migrations and fix Debian wide
    dependencies. It hides team maintained packages from a common BTS
    view. When pointing my browser to
    https://bugs.debian.org/team+python@tracker.debian.org
    I currently see 1339 open bugs (calculated by [UDD1]). This hides
    another 309 [UDD2] bugs (>18% of team bugs) from our sight. To work
    around this flaw I used an UDD query to find relevant Python3.12 bugs.

    When I think twice about the wording
    Team in Uploaders is a weak statement of collaboration.[3]
    I personally consider it a statement of *no* collaboration (which fits
    the wording of the responses I've got).

    How can a team member for instance find another RC bug #1009424? Just
    from reading the bug report it is pretty easy to fix but does not
    feature any response in BTS. I came across this while looking into
    Cython 3.0 bugs. The same source package (basemap) that had the open
    Cython bug (#1056789, tagged patch since 2023-12-09) is featuring RC bug >>> (#1009424) that stayed unattended for 22 months? We all know volunteers >>> have limited time and I do not want to blame anybody in the team to not
    care promptly about RC bugs. But what else is the sense of a packaging
    team than stepping in situations for long standing RC bugs and RC bugs
    tagged patch?

    This kind of situation wouldn't occur in teams where collaboration is
    strong and communication is effective. My motivation to address these
    long-ignored critical bugs diminishes when the maintainer opts for
    "weak" cooperation and lacks respectful communication with potential
    helpers. I see no difference to simply do a NMU.

    I've checked the current situation who is actually using the DPT team as >>> Uploaders[UDD3]. 66 of the 73 maintainers have less than 5 packages
    some of these "Maintainers" are other teams and lots of the persons
    listed as Maintainer are known to be MIA. This means the packages are
    de-facto not maintained which is most probably an unwanted effect of the >>> current policy. I know other maintainers from other teams to be fine
    with stronger team understanding.

    Since I consider the current situation as demotivating for newcomers
    as well as long standing contributors I would like to suggest to drop
    this "weak statement of collaboration" option from policy. I've attached >>> an according patch to the team policy[5]. I'm fine with creating a MR
    to be discussed rather in Salsa than this mailing list - whatever seems
    worthwhile to you.

    Kind regards
    Andreas.

    Hi Andreas,

    I had similar experience, and the same kind of demotivating response from the same person. So I'm not surprised.

    It's been a long long time that I would have like this DPT policy to go away, but didn't dare to raise the topic. Though indeed, I don't think it's reasonable to have a package in the team, but with strong ownership. I believe that we should either
    have a package in the team, or not. Period.

    If someone isn't happy about this policy change, it's ok to move the package way from the team, if having team-mate working on "your" package isn't ok (of course, we would all prefer this doesn't happen, and that we work collaboratively). This would
    make things a way clearer.

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

    To everyone else in the team: please also state your opinion, so we can make a collective decision.

    I agree with both of you. I think packages should be team maintained or not at all. No middle area.

    While I do take advantage of this for a few packages, I don't personally care much either way. I suspect that packages will be removed from team maintenance as a result though and I think that's a bad idea.

    I'd prefer the current approach over people removing packages from the team, so I think it's important that anyone who feels strongly enough about this to do so, speak up.

    Scott K

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Arto Jantunen@21:1/5 to Andreas Tille on Tue Feb 27 21:30:01 2024
    Andreas Tille <andreas@an3as.eu> 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?Q?Louis-Philippe_V=C3=A9ron@21:1/5 to Andreas Tille on Tue Feb 27 21:40:02 2024
    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
    ⠈⠳⣄

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Kitterman@21:1/5 to Thomas Goirand on Wed Feb 28 01:00:01 2024
    On February 27, 2024 11:42:33 PM UTC, Thomas Goirand <zigo@debian.org> 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefano Rivera@21:1/5 to All on Wed Feb 28 03:00:01 2024
    Hi Andreas (2024.02.27_08:05:44_+0000)
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Tille@21:1/5 to All on Wed Feb 28 08:10:01 2024
    Hi Scott,

    Am Tue, Feb 27, 2024 at 11:54:01PM +0000 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 <https://www.debian.org/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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Tille@21:1/5 to All on Wed Feb 28 08:20:01 2024
    Hi Timo,

    Am Tue, Feb 27, 2024 at 04:08:51PM +0100 schrieb Timo Rhling:
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Tille@21:1/5 to All on Wed Feb 28 09:10:02 2024
    Am Tue, Feb 27, 2024 at 04:25:49PM +0000 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+python@tracker.debian.org%' and release = 'sid' group by maintainer order by maintainer) tmp WHERE count > 20;
    maintainer | count -------------------------------------+-------
    Piotr Ożarowski <piotr@debian.org> | 23
    Sandro Tosi <morph@debian.org> | 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Tille@21:1/5 to All on Wed Feb 28 09:30:01 2024
    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

    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+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
    ⠈⠳⣄



    --
    http://fam-tille.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?utf-8?Q?=C3=89tienne?= Mollier@21:1/5 to All on Wed Feb 28 09:40:02 2024
    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 <emollier@debian.org>
    : :' : 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

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEj5GyJ8fW8rGUjII2eTz2fo8NEdoFAmXe8OYACgkQeTz2fo8N EdoJ0hAAhOSS1tYjis8TxI2Y46zU0WD+1urZCm68BEf52rW9zgChh0SIVPCNtjb5 0fTZKn2miqs5kqHRYMhYh0ue3+k/a0pvYhdpChFhsuxxxDBYXtESobsgOHNmH9Q6 gBi0Zu6QJ4z20YLKNnp9A+PiJMRskm8TCneXmdLaiLRLzQ5GpQWmiYSqcjA9V4ag 9hF2//KeiTzKLW5O8NoSpOO4sMwyplnCYQg7pcqA+Yd4kMbCBKVe3cUr2IOJl3o1 gpJopLhCqzaMLK0gSl5OPg5BjJBg8Roc1/EsdY+Pu+MO/j4OlhZgWEVY2FcfBNrr T3fm06m9PIN7DSaSO9RmREPpEMWnUwi29wKIbBhyZ1QEFjyHo/i/N51brBv2qBAd pgNUo6rEx4aoxQxDIcofoLGE/5bAR8Ei/1vRF57vk2E0cuITWVLWnsNIfaKb1luh mSBpVIxFQeCH2wtMOjldKShgTgOnaWnnaMCBpXRR/6ae4zXPgI5e4Pn9BoRUKgPW KUvhgfsjTKUiWNe64jhEdPDDWaF2tPjAueZb1S9thic1jiCDnqsQMb5jCQCO4y/9 uCDzeR+cyZLAQCxKdoqDaiFcZJqe3gjgET6kFE2Q8VRt1Oe0j4FtqAdTfNxJWyyT IeAfe/9zg/DTFFGteJ/rZYvHL1b2T2VC
  • From Agathe Porte@21:1/5 to All on Wed Feb 28 10:30:01 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Tille@21:1/5 to All on Wed Feb 28 12:00:01 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Julian Gilbey@21:1/5 to Andreas Tille on Wed Feb 28 11:50:02 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Kitterman@21:1/5 to Thomas Goirand on Wed Feb 28 13:00:02 2024
    On February 28, 2024 9:54:55 AM UTC, Thomas Goirand <thomas@goirand.fr> 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Kitterman@21:1/5 to Andreas Tille on Wed Feb 28 12:50:03 2024
    On February 28, 2024 7:08:14 AM UTC, Andreas Tille <andreas@an3as.eu> wrote: >Hi Scott,

    Am Tue, Feb 27, 2024 at 11:54:01PM +0000 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Kitterman@21:1/5 to All on Wed Feb 28 09:19:29 2024
    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+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

    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
    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEE53Kb/76FQA/u7iOxeNfe+5rVmvEFAmXfQPEACgkQeNfe+5rV mvFq8A//SI7/CbWqKW1dE1Mbq+0cKKxg7VVhXigyrt49z8DuadCuPajY7lVWBWCo 8P2dbKrUWN47JPFXZSOvwffcUCPI9sQVR7LdaJ7ALt4Ojs0TydPfWee37qa2G2aI Ms9NOyGvXgzh+gZ31t0+5a6DaYvq1J5PaU/RmTFD1rN+aldR1/WjVcH28XIPMzjX +MkA7EDdS07O9zOQNA6exon9OuAFfeBqRK5S7QJa8EaCjrAzol8m97a1tz5tHPxR wO0SClaqksL0r+mPHGL4cOqDplpF4JOiw4BeWiEXRh+ecUGh/qdPbemFYM9KNobs S5bQ8nmVXbabg6bKwmuZm83RJtZe+BSLQp3GF8PWZXpCgQycq9jbytOq3MB8YRhI N5KeYu0NEgIWryxtQCC5WjuHpu4zYHRalq4xn+rGdWZDtFiA+xwra0cdkq5V1Jxm U3ZdntkVkATONM11IpPywsoQ3gn9l4dQ+ZSTV9f5QXWv0xuesyJG6yldzTsOqWG/ ZmQbVY7x5dLWgIqBFdFqz0kKUFCVAecHqJV/6Vhc2biHiK13cON/CE78kLP/6FOZ Eq/Fz6P+J6TFNBqhHI7FeWNVsdYVND9bNQ2eNzE15uoERXo9rSf8FGw1WCx/AWvA GNYypDFDmhTdCWZpluQr4F1Ot0jVUa5BnvRItM9wVcfas37uSkk=
    =dOSM
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Tille@21:1/5 to All on Wed Feb 28 15:40:01 2024
    Hi Scott,

    Am Wed, Feb 28, 2024 at 11:44:07AM +0000 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Tille@21:1/5 to All on Wed Feb 28 15:50:02 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Timo =?utf-8?Q?R=C3=B6hling?=@21:1/5 to All on Wed Feb 28 16:50:01 2024
    Hi,

    * Andreas Tille <andreas@an3as.eu> [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 │
    ⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯

    -----BEGIN PGP SIGNATURE-----

    iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmXfVekACgkQ+C8H+466 LVkYoAwA7Jp8UUjWUdpShWxhUP2FNU8TOive2LoAdp2/2iFEFmbctW/gt5vrHoNK d4jlNnVl22ZrhlerIxzlPemG+ARTJAAmJnuimcMXEJ5alOpfnXq8cXx1yjUb+fKe FTZdwFo4EBrKFBytXBWl5dMyogsxsCA237vAlBLrRpXq3N8urbpHGpJGWDpowG0M udFClxmcq/HHDhmMa0muFQvRfg+RCeIDmvhCzcQlU51qmRYVgm5tXDFb6aOHxhwd rdPhRxJg7bAAzVu4CIgmwIJZOBbtvkYBD1a8ZujWcupPjePn5l+A5EiI8Sgc9XGY 5pDlOzJI96IFv+Lb8zWWjmCO8XO11xzP6niMfHeAohg
  • From Jeroen Ploemen@21:1/5 to Scott Kitterman on Thu Feb 29 20:50:01 2024
    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.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEEd8lhnEnWos3N8v+qQoMEoXSNzHoFAmXg35EACgkQQoMEoXSN zHq5NBAAnbuufYLb+Krx2eEq3KqFLLh1jav2Y/LR8WD4dO5L/aQewXjrBenWeA6K lUAi6NSuV0Rn2o33T51d0bd8ef+anJk+6hXifHNWbpxSDnHO7JpBVJfGw/Es7dLj Cgw28S7f7gHnbaQrW+RiqXR2zCVelE4luP3WMdUD7Aas2P9fn5U7OHblh7EQfvr9 5dbkMykdgyxZNOp9VnsuHbMYH5F4P4ARPpiGHbEf8mBlZqAo+gr3pf6DRfoPaeVY iquImlaFG2EA6auEzaDlbneBkV5FjJP4FKD2YfiwaJRALI5WQvK3WIAnma5CLvYn u4p3Y09uzMPOar4/ii/V3jNRjVEKV7TiVmEUiL9YyOwxHHnfzQ7eV+nrdqVkjUU3 IBlzf9WoJieZstgJigjpNCACRNhbvMWe9PBu4EhUKk29zIEJuV2S41WtMoD3MZhJ Q3SQ+Xdzc6VdZ4ij9Tmpf9T6oM28ue4+pobageNDOulymJxmYrNQDTs1I4C46HYC 4DTqIOGsC2yy323v3b1MOwjYgp9n0w1d9wNCRrd+p6TikvSU5u26aksnoiDUFz87 pBKot5tGxghtaBX2s6z/6buDBgMIhRtqA8pSpbre3O7opv8qOneQz52ddZcfMQr9 rLzR0V0r96C8HW6g7PxQ/lBx4CeMrY/kSzi8Ia5/kt0ZhCKAkrQ=
    =Gnw5
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Salvo Tomaselli@21:1/5 to Debian Python on Fri Mar 1 01:12:52 2024
    Copy: zigo@debian.org (Thomas Goirand)

    In data marted 27 febbraio 2024 15:15:30 CET, Thomas Goirand ha scritto:

    To everyone else in the team: please also state your opinion, so we can
    make a collective decision.

    +1 from me


    --
    Salvo Tomaselli

    "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
    -- Galileo Galilei

    https://ltworf.codeberg.page/
    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCAAdFiEEQnSLnnbYmXmeH74Us6fPDIAYhs8FAmXhHYQACgkQs6fPDIAY hs+djQ/+LpH1mgNYClDy3VqQj8bsA0NO483LN0SP4ub0V3Sifino2C81F7WBL3vB d4OaA8myWAsMCXXySvfRjdjlZPBwnpnq3C2BewR5fXMEQ9b72Bicflghh/XmNL4q +tdYMmiopOR03HGl5HXAOSXHgk5teTveh7RRv8f7XRwKBAPeYDn1HcT39XQTxvdt iLkMn/ISP/SGEmjDBQUjuGLA+8GUVv1tgchXTCGNYe8J/vDS/3XUbyb5Ie3KtCF1 xon3l+o6C4/XYmAsqaJsAolJwkpqBszzob1p7hSZq13W4CD5AYGxH2R4gVqR0+9K rPNDiklHRd4C/poykRbT7SbLfBvA7BW6ZzfHvT63kfqdgoD1Z/9G0qusuMkeo8tP p8Lq7NEXkjCp5YuppEA66BrsJjT11QjrorQzgtOKldhEp/O3R0CC3GHLFncKjtKt M2IPKumXPCqQD3KeHUKfbtD/NhbyWSzVNQAZINxFJBUPrSFuZ64VaOEcrxC2LY2v PEyNZpqwy62+LB0EhKxRKbIa8aOMpXLDb2uPT9s8sjsj2Ztlqu12GxSQQvc/KXsj EEx58i687AKWDAcEzd8sfOWBgtNAjF+LTr/12hcCAt3FtSN6/8B7NZRB2Nzf5liQ sJUnvWaxvr2i0/VKCIQOA0I6v
  • From Julian Gilbey@21:1/5 to Jeroen Ploemen on Fri Mar 1 08:30:02 2024
    Hi Jeroen,

    On Thu, Feb 29, 2024 at 08:48:33PM +0100, Jeroen Ploemen wrote:
    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.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeroen Ploemen@21:1/5 to Julian Gilbey on Fri Mar 1 13:10:01 2024
    On Fri, 1 Mar 2024 07:21:57 +0000
    Julian Gilbey <julian@d-and-j.net> 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.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEEd8lhnEnWos3N8v+qQoMEoXSNzHoFAmXhxTIACgkQQoMEoXSN zHoDrRAAx6f2F2FqZWLKy4cld7GrcYHnNr2doF8Jbz2oCE5HUoQ1SGa71rgc5m4O ue5TWn17Y0t4q5XRp8C4c4mcj/nBRcm+GBMuxKDtqo2wFobRaP7Q+c8btiSdnS8o xHsWB2Oqd46cIxJcgeZGVFIZOJlIa5JkSmH9TtN1MHtDEFWTv4NRB1Iv5td0rGF+ +Us4IB/wKUHKijineY6Bu9zBOsJQ29VfuSJPmspjH5B01XCikqQ0CRnAC1o877qa zXR8kd94eUCf+W0J0kTYDaW+vdV5PNSvZojgnkqT5gz6fkL45CnYLxvyy2r99al/ tXO8vY7a2TmbSJSmWFBEykgVsvKiyE8JN1J8WD4ZXgyJY34UPAF1g1qApk5xeviW bOXWISFnHzZ4iTSiX6h9pJQ+F6Z1HwKnunWgmmC7RDqLXyoA5sH6tfyrJ14NIhEl OhzeSl/uGqc3u9NwR0wCyffWXbWu+GFbJtEtVSSjIhTj86IsVRG88uKpJ/vvCuoS F77B0CpMPvMSrSOdGbNIjIq4hdjCfUO21Z09lrpwFkM2VLwuoyR5Pv3Qo9B0l+vX ONm8+p2sNJs1nEXK7NjeHTKdy3M3Cb0lkqb+ZC2jTQOHKtcX4X8alhjm5A5s6JoZ 3+9XOiMyX451zsDLBGsEj5GHycSmBNfrsS1vTXFGn9wq1WcST3k=
    =FglU
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Tille@21:1/5 to All on Sat Mar 2 21:40:02 2024
    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 <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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Kitterman@21:1/5 to Andreas Tille on Sat Mar 2 22:20:01 2024
    On March 2, 2024 8:29:47 PM UTC, Andreas Tille <tille@debian.org> 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 <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?

    Scott K

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Tille@21:1/5 to and immediately on Sat Mar 2 23:20:01 2024
    Am Sat, Mar 02, 2024 at 09:11:52PM +0000 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Stefano Rivera@21:1/5 to All on Sun Mar 3 00:10:01 2024
    Hi Christian (2024.03.02_22:09:29_+0000)
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Emmanuel Arias@21:1/5 to Andreas Tille on Sun Mar 3 00:40:02 2024
    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+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.


    +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

    ⢀⣴⠾⠻⢶⣦⠀
    ⣾⠁⢠⠒⠀⣿⡁ eamanu@debian.org
    ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: 13796755BBC72BB8ABE2AEB5 FA9DEC5DE11C63F1
    ⠈⠳⣄

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEE3lnVbvHK7ir4q61+p3sXeEcY/EFAmXjtlQACgkQ+p3sXeEc Y/H3JRAAhDIxG1x4WdsNyssZ4oRL9WEXw4HugxPBh4qjX3wJPO8xYjEXJZd3+KyO iRhFsAT4vJuuDDyjiSIYV+IhKQ27hYJ8G+NXegu34G4+uP3HEIuJTrg/OWaU8T55 DoqWUli5y/y8shTwSm9zJaAkhLXkuP3/9bPS8nT3ZfFK4RmyU/dOIjfpL0URxXFM MR0OWCP/UvnqjItg53nf7+lVOn7CSw01GhlrQEgH2ZBl1LDf6LW5JDpEsl8giu7Z rUzR11sq9q6wRj/aCwaLY/SHRR1adPK0++WF4jRSqKrFQanAUkQzl37cZOkQ03Ir ZRqBctHH9qnt38K1qw+de+rJgYo6QB82+MY4hfPS0ik5yJDWjd5Vm1N155DIeIwV hMuyk4rxOjNWBPT9qTuB40AQVMzkhppi1bo4GDoUibhR+mbKRX1jgv+7Y+HbXREw hT1NTJOUiWuLGa1FAxOOcSmgXdUsj+0wheKovZ+FJJBQAK8kdvJKokIurDkKpujI TGCzc0IU/6jN9+xoLblSqef8gT5Wc5H60UR5nSlCXPUYZBJjTH2NivbohTcZtTV5 pTg15wQwrfASX2wiv+H2svLwSvnqtvYql/CuJCbWnEM4pjhH/iN2ef5661Wqor/e Ns1nudZQBmcArzg3ie1vmKBFSQx5v9XgjGo7zogKid83bEs
  • From Andreas Tille@21:1/5 to All on Sun Mar 3 07:20:01 2024
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Scott Kitterman@21:1/5 to Andreas Tille on Sun Mar 3 18:20:01 2024
    On March 3, 2024 6:12:09 AM UTC, Andreas Tille <andreas@an3as.eu> 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nilesh Patra@21:1/5 to Andreas Tille on Sat Mar 9 18:00:01 2024
    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+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

    -----BEGIN PGP SIGNATURE-----

    iHUEABYIAB0WIQSglbZu4JAkvuai8HIqJ5BL1yQ+2gUCZeyTVQAKCRAqJ5BL1yQ+ 2m+nAP9jqWY741/pienK5QDaU+t5NMI7qRaTH5iIDKkGKC2LsQD7BhW+309ej2kO nco0xqhsE4lM7VNf8BlxL4cn+1Lk0wc=
    =MXF/
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Anton Gladky@21:1/5 to All on Sat Mar 9 18:50:01 2024
    Same for me. Thanks for proposal. +1

    Anton


    Am Sa., 9. März 2024 um 17:51 Uhr schrieb Nilesh Patra <nilesh@debian.org>:

    I am late to the party but I agree with the policy change.

    Best,
    Nilesh


    <div dir="ltr"><div dir="ltr">Same for me. Thanks for proposal. +1<br clear="all"><div><br><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Anton</div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="
    gmail_attr">Am Sa., 9. März 2024 um 17:51 Uhr schrieb Nilesh Patra &lt;<a href="mailto:nilesh@debian.org">nilesh@debian.org</a>&gt;:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-
    left:1ex">
    I am late to the party but I agree with the policy change.<br>

    Best,<br>
    Nilesh<br>
    </blockquote></div></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Julian Gilbey@21:1/5 to Anton Gladky on Sat Mar 9 22:30:01 2024
    On Sat, Mar 09, 2024 at 06:46:52PM +0100, Anton Gladky wrote:
    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:

    ---
    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
  • From Andreas Tille@21:1/5 to All on Tue Mar 19 08:40:02 2024
    Hi Julian,

    Am Sat, Mar 09, 2024 at 09:21:40PM +0000 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 <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. ***]

    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 that it just involves another waiting period and is slowing
    down the process of getting things fixed. There are chances that the
    slice of spare time of the other contributor is running out before the
    Uploader might have time to respond. Thus IMHO we should not express
    the need for contacting another team member explicitly and rather
    trust common sense and some debian/README.* .

    To the contrary: If a team member intends to care for some specific
    package in the long run, the ID should be simply added to the Uploaders
    field. Its a list and I'd prefer if we would have more than one
    elements in this list for every important package. For sure it makes
    sense to inform other Uploaders once someone might add the own ID.
    Finally we are talking about good communication practices between
    contributors.

    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 ***]
    ---

    I think if we draft some MR about this document we should probably
    start by suggesting debian/README.source.


    Finally I'm wondering what the decision making process about team policy
    might be. OK, we have some MRs. Do we need some confirmation comments? Currently there are 9 MRs[1] some created 5 years ago with latest
    changes two years ago[2] (the update 2 years ago was a question why this
    is still open).

    From my (probably biased) perspective MR "Drop option of weak
    collaboration and permit DPT team as Maintainer only"[3] which is discussed
    in this thread received

    1. Lots of positive responses
    2. a) Some doubts by Scott
    b) No response from Pjotr
    (Scott and Pjotr are listed as project members in
    python-team/tools/python-modules so have commit permissions)
    3. Some kind of "silent disagreement" by Sandro
    4. LGTM after some enhancements by Eberhard

    How do we proceed from here now?

    Kind regards
    Andreas.

    [1] https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests [2] https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/7
    [3] https://salsa.debian.org/python-team/tools/python-modules/-/merge_requests/20
    [4] https://salsa.debian.org/python-team/tools/python-modules/-/project_members

    --
    http://fam-tille.de

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)