Bug#1018336: Is it OK to switch Uploader and Maintainer in deap [Was: Suggesting change in DPT policy]
Hi Miriam, Am Thu, Mar 14, 2024 at 08:33:13PM +0100 schrieb Miriam Ruiz: > I am totally okay with team maintenance. Lots of thanks!!! Updated to latest upstream which fixes the bug. Thanks a lot for your quick response Andreas. -- http://fam-tille.de
Bug#1018336: Is it OK to switch Uploader and Maintainer in deap [Was: Suggesting change in DPT policy]
I am totally okay with team maintenance. Lots of thanks!!! Hugs, Miry El jue, 14 mar 2024 a las 19:18, Andreas Tille () escribió: > > Hi Miriam, > > gentle ping about this. I remember for cycle and pcalendar you was fine > with team maintenance. So I assume in this case you are as well. If > we do not hear from you in the next two weeks we will assume agreement. > > Kind regards >Andreas. > > - Weitergeleitete Nachricht von Andreas Tille - > > Date: Tue, 27 Feb 2024 14:48:21 +0100 > From: Andreas Tille > To: Miriam Ruiz > Subject: Is it OK to switch Uploader and Maintainer in deap [Was: Suggesting > change in DPT policy] > > Hi Miriam, > > as you can read below I doubt that the situation in several packages is > the interpretation of "weak" team maintenance if the Maintainer field is > set to a person. In the case of your package deap I would guess you > are OK if I would swap these fields in a potential upload of the new > upstream version (which might potentially fix >#1018336 deap: build-depends on python3-nose or uses it for autopkgtest > ) > Would you mind if I would do so? > > Kind regards > Andreas. > > - Weitergeleitete Nachricht von Andreas Tille - > > Date: Tue, 27 Feb 2024 09:05:44 +0100 > From: Andreas Tille > To: Debian Python > Subject: Suggesting change in DPT policy > > 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
Bug#1018336: Is it OK to switch Uploader and Maintainer in deap [Was: Suggesting change in DPT policy]
Hi Miriam, gentle ping about this. I remember for cycle and pcalendar you was fine with team maintenance. So I assume in this case you are as well. If we do not hear from you in the next two weeks we will assume agreement. Kind regards Andreas. - Weitergeleitete Nachricht von Andreas Tille - Date: Tue, 27 Feb 2024 14:48:21 +0100 From: Andreas Tille To: Miriam Ruiz Subject: Is it OK to switch Uploader and Maintainer in deap [Was: Suggesting change in DPT policy] Hi Miriam, as you can read below I doubt that the situation in several packages is the interpretation of "weak" team maintenance if the Maintainer field is set to a person. In the case of your package deap I would guess you are OK if I would swap these fields in a potential upload of the new upstream version (which might potentially fix #1018336 deap: build-depends on python3-nose or uses it for autopkgtest ) Would you mind if I would do so? Kind regards Andreas. - Weitergeleitete Nachricht von Andreas Tille - Date: Tue, 27 Feb 2024 09:05:44 +0100 From: Andreas Tille To: Debian Python Subject: Suggesting change in DPT policy 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
