On Tue, 27 Feb 2024, Thomas Goirand wrote:
On 2/27/24 09:05, Andreas Tille wrote:
Hi,
I became more deeply involved into DPT since 2022 as a consequence of
the suggestion for transfering several Debian Med/Science packages to
DPMT[1][2]. I happily followed this suggestion and moved >30 packages
from the Blends teams to DPT. I was happy with this move since it makes
sense.
Recently we received lots of testing removal warnings in those Blends
teams due to RC bugs caused by Cython 3.0 and Python3.12 migrations. So
I did what I usually do in those teams: I dedicated quite some time in
team wide bug hunting. That way I squashed about 50 bugs on packages
where I was not in Uploaders. When doing so I usually run
routine-update on the package which basically streamlines packaging to
latest standards including calling Janitor tools which are so far
accepted inside DPT.
I probably should have reviewed the DPT policy on Maintainership[3] more
carefully. In other teams, it's common for the Maintainer to be set to
the team, so I assumed it was just an oversight when I made this
change[4] when touching the package to fix RC bug #1058177. However, I
I was pointed immediately about the fact that I was mistaken according
to the current DPT policy. I apologize for this. However, the wording
of the comment on my commit was discouraging, especially considering I
was a volunteer who had fixed a critical bug. Because of this, I
decided to focus my efforts on fixing other critical bugs for the
moment. If the comment had started with a 'Thanks for fixing the
critical bug, but...' I likely would have corrected my mistake quickly.
The lack of respect from my teammate simply made me prioritize my time
on other issues that are more visible to our users. I wonder whether I
should propose another change to the policy about maintaining a kind and
polite language inside the team - but that's a different thing.
While I applied the patch for another RC bug (#1063443) after >2 weeks
which triggered a RC bug in reportbug I remembered the "keep the
maintainer" policy. But I kept on doing Janitor like changes since
finally the package is maintained in a team where Janitor is accepted.
When doing so I failed the phrase "please contact the Maintainer for the
green light." I apoligize for this again. The response was another
volunteer-demotivating private mail (thus no quote) which also was
lacking the "Thanks for fixing"-phrase and degrading my changes as
"frivolous".
So far what happened (seen from my possibly biased perspective).
Why do I like to change the policy?
The current wording provides some means to stop volunteer team members
helping out moving forward to speed up migrations and fix Debian wide
dependencies. It hides team maintained packages from a common BTS
view. When pointing my browser to
https://bugs.debian.org/team+pyt...@tracker.debian.org
I currently see 1339 open bugs (calculated by [UDD1]). This hides
another 309 [UDD2] bugs (>18% of team bugs) from our sight. To work
around this flaw I used an UDD query to find relevant Python3.12 bugs.
When I think twice about the wording
Team in Uploaders is a weak statement of collaboration.[3]
I personally consider it a statement of *no* collaboration (which fits
the wording of the responses I've got).
How can a team member for instance find another RC bug #1009424? Just
from reading the bug report it is pretty easy to fix but does not
feature any response in BTS. I came across this while looking into
Cython 3.0 bugs. The same source package (basemap) that had the open
Cython bug (#1056789, tagged patch since 2023-12-09) is featuring RC bug
(#1009424) that stayed unattended for 22 months? We all know volunteers
have limited time and I do not want to blame anybody in the team to not
care promptly about RC bugs. But what else is the sense of a packaging
team than stepping in situations for long standing RC bugs and RC bugs
tagged patch?
This kind of situation wouldn't occur in teams where collaboration is
strong and communication is effective. My motivation to address these
long-ignored critical bugs diminishes when the maintainer opts for
"weak" cooperation and lacks respectful communication with potential
helpers. I see no difference to simply do a NMU.
I've checked the current situation who is actually using the DPT team as
Uploaders[UDD3]. 66 of the 73 maintainers have less than 5 packages
some of these "Maintainers" are other teams and lots of the persons
listed as Maintainer are known to be MIA. This means the packages are
de-facto not maintained which is most probably an unwanted effect of the
current policy. I know other maintainers from other teams to be fine
with stronger team understanding.
Since I consider the current situation as demotivating for newcomers
as well as long standing contributors I would like to suggest to drop
this "weak statement of collaboration" option from policy. I've attached
an according patch to the 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
