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

Groups > linux.debian.maint.python > #15495 > unrolled thread

Suggesting change in DPT policy

Back to article view | Back to linux.debian.maint.python

Contents

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

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

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

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 │
⠈⠳⣄⠀⠀⠀⠀   ╰────────────────────────────────────────────────────╯

[toc] | [prev] | [next] | [standalone]

#15499

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

[toc] | [prev] | [next] | [standalone]

#15500

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#15510

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

[toc] | [prev] | [next] | [standalone]

#15504

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

[toc] | [prev] | [next] | [standalone]

#15505

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

[toc] | [prev] | [next] | [standalone]

#15511

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

[toc] | [prev] | [next] | [standalone]

#15519

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#15521

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

[toc] | [prev] | [next] | [standalone]

#15507

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

[toc] | [prev] | [next] | [standalone]

#15513

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.

[toc] | [prev] | [next] | [standalone]

#15514

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

[toc] | [prev] | [next] | [standalone]

#15529

[Multipart message — attachments visible in raw view] — view raw

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/

[toc] | [prev] | [next] | [standalone]

#15538

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

[toc] | [prev] | [next] | [standalone]

#15540

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#15542

[Multipart message — attachments visible in raw view] — view raw

+1 for this policy change too,

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

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

I m glad it is being resolved.

Greetings

Le dim. 3 mars 2024, 00:30, Emmanuel Arias <eamanu@yaerobi.com> a écrit :

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

[toc] | [prev] | [next] | [standalone]

#15551

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#15552

[Multipart message — attachments visible in raw view] — view raw

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
>

[toc] | [prev] | [next] | [standalone]

#15553

On Sat, Mar 09, 2024 at 06:46:52PM +0100, Anton Gladky wrote:
> Same for me. Thanks for proposal. +1
> Anton
> Am Sa., 9. März 2024 um 17:51 Uhr schrieb Nilesh Patra <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 jointly
responsible for a large number of Python packages in Debian.  They
package and support available Python modules and applications that may
be useful.

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

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

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

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

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

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

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

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

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

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

Best wishes,

   Julian

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.maint.python

csiph-web