Hi,
Louis-Philippe (just quoting below in case you might have missed it) is
repeating the importance that anyone who thinks my suggestion (MR[1]) is
a bad idea make themselves heard. I'm hereby adding those maintainers
who have more than 5 packages that are affected and did not yet raised
their opinion in To: field.
udd=> SELECT * FROM (select maintainer, count(*) from sources where uploaders
like '%team+pyt...@tracker.debian.org%' and release = 'sid' group by maintainer
order by maintainer) tmp WHERE count > 5;
maintainer |
count
-------------------------------------------------------------------------+-------
Debian PaN Maintainers <debian-pan-maintain...@alioth-lists.debian.net> | 7
Jeroen Ploemen <j...@debian.org> | 16
Piotr Ożarowski <pi...@debian.org> | 23
Sandro Tosi <mo...@debian.org> | 82
Scott Kitterman <sc...@kitterman.com> | 7
Vincent Bernat <ber...@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+pyt...@tracker.debian.org
> > I currently see 1339 open bugs (calculated by [UDD1]). This hides
> > another 309 [UDD2] bugs (>18% of team bugs) from our sight. To work
> > around this flaw I used an UDD query to find relevant Python3.12 bugs.
> >
> > When I think twice about the wording
> > Team in Uploaders is a weak statement of collaboration.[3]
> > I personally consider it a statement of *no* collaboration (which fits
> > the wording of the responses I've got).
> >
> > How can a team member for instance find another RC bug #1009424? Just
> > from reading the bug report it is pretty easy to fix but does not
> > feature any response in BTS. I came across this while looking into
> > Cython 3.0 bugs. The same source package (basemap) that had the open
> > Cython bug (#1056789, tagged patch since 2023-12-09) is featuring RC bug
> > (#1009424) that stayed unattended for 22 months? We all know volunteers
> > have limited time and I do not want to blame anybody in the team to not
> > care promptly about RC bugs. But what else is the sense of a packaging
> > team than stepping in situations for long standing RC bugs and RC bugs
> > tagged patch?
> >
> > This kind of situation wouldn't occur in teams where collaboration is
> > strong and communication is effective. My motivation to address these
> > long-ignored critical bugs diminishes when the maintainer opts for
> > "weak" cooperation and lacks respectful communication with potential
> > helpers. I see no difference to simply do a NMU.
> >
> > I've checked the current situation who is actually using the DPT team as
> > Uploaders[UDD3]. 66 of the 73 maintainers have less than 5 packages
> > some of these "Maintainers" are other teams and lots of the persons
> > listed as Maintainer are known to be MIA. This means the packages are
> > de-facto not maintained which is most probably an unwanted effect of the
> > current policy. I know other maintainers from other teams to be fine
> > with stronger team understanding.
> >
> > Since I consider the current situation as demotivating for newcomers
> > as well as long standing contributors I would like to suggest to drop
> > this "weak statement of collaboration" option from policy. I've attached
> > an according patch to the team policy[5]. I'm fine with creating a MR
> > to be discussed rather in Salsa than this 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
> ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org
> ⠈⠳⣄
>
>
--
http://fam-tille.de
