Re: Suggesting change in DPT policy
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
Re: Suggesting change in DPT policy
On 2024-03-02 23:09, Christian Kastner wrote: > I think moving DPT to Maintainers is a good idea. Additionally, I agree that having DPT in Uploaders is pointless, and welcome the prposed policy change. > I think removing Uploaders is a terrible one. Apologies, I retract this part as it was not suggested. I misunderstood the diff. Best, Christian
Re: Suggesting change in DPT policy
Hi Stefano, I need to retract my previous mail. Ironically, it was based on a careless misread of the proposed policy change diff. On 2024-03-03 00:07, Stefano Rivera wrote: > 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). I fully support removing weak team membership. I have always considered having DPT in Uploaders to be pointless. What I misunderstood in the diff was that the proposed policy change of "anyone can commit" to effectively mean that Uploaders is not relevant anymore, but that was not what was proposed. > 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. I like that suggestion a lot! And, to be more constructive this time, I want to make it clear that contributions are always truly welcome, that's why it's under DPT. And while diligence (or lack thereof) can be criticized, I'm aware that often, contributors are unaware that what they are doing is wrong. For example, I also often skip tests -- it's just that I do it under conditions that I'm happy to defend (cause isolated, reported upstream, etc.), but others may not be aware of that. Spelling this out more clearly would improve this. > 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'd like that. But to be effective, it must really be in-grained that for anything DPT, one should check README.source first. This may come naturally to many of us, but it's certainly not universal. >> 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. Agreed. > That's not the case for many packages in the team. Even ones listed with > the team in Uploaders and a human as Maintainer. Also agreed. But in that case, this inter-personal conflict usually does not arise, for lack persons. Best, Christian
Re: Suggesting change in DPT policy
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+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
Re: Please delete two empty salsa repositories
Hi Julian (2024.03.02_20:52:04_+) > Please could someone with the required permissions delete the > following two empty salsa repositories Deleted. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Re: Suggesting change in DPT policy
Hi Christian (2024.03.02_22:09:29_+) > 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
Re: Suggesting change in DPT policy
Hi again, 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? > 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. >From past interactions, I honestly believe you are. But let me point out that interaction-wise, saying you're sorry and showing you're sorry are two different things. And having upset someone, not performing that one requested gesture that would heal the situation is going to cause friction. Best, Christian
Re: Suggesting change in DPT policy
Hi Andreas, On 2024-02-27 09:05, Andreas Tille wrote: > 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 think moving DPT to Maintainers is a good idea. I think removing Uploaders is a terrible one. 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. Not going to name names, but I've seen this with packages I've worked on: I put a lot of effort into cleaning things up, making things robust, getting docs to build, tests to pass, collaborating with upstream, fixing reverse dependencies, and then someone spends a few minutes to upload a new version with total disregard for what the other maintainer(s) were doing. 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. So while I absolutely condemn the conduct that you describe, I do also have to condemn this careless drive-by work, because it is also extremely demotivating. 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. Best, Christian
Re: Bug#1065042: O: mpl-sphinx-theme -- documentation for the mpl-sphinx-theme Python library
Am Thu, Feb 29, 2024 at 02:06:25PM -0800 schrieb Vagrant Cascadian: > On 2024-02-29, Sandro Tosi wrote: > > I intend to orphan the mpl-sphinx-theme package. > > > > The package description is: > > This is the official Sphinx theme for Matplotlib documentation. It > > extends the > > pydata-sphinx-theme project, but adds custom styling and a navigation bar. > > . > > This package provides documentation for mpl-sphinx-theme > > It looks like you attempted to orphan it, but switched the Maintainer to > the python team rather than the Debian QA team ... It seems Sandro is trying to get rid of several of his packages. There are quite some Orphan bugs done by him in the last couple of days. > Was your intention to orphan it, or just leave it up to the python team? My gut feeling is that someone from the Python team would take over these packages. I will bounce the orphan messages from BTS to debian-python list to keep people informed about these packages. Kind regards Andreas. -- http://fam-tille.de
Re: Suggesting change in DPT policy
Am Sat, Mar 02, 2024 at 09:11:52PM + 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
Re: Suggesting change in DPT policy
On March 2, 2024 8:29:47 PM UTC, Andreas Tille 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 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 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
Please delete two empty salsa repositories
Hello, Please could someone with the required permissions delete the following two empty salsa repositories; due to an upstream reorganisation of the package, they will no longer be needed, and will instead be part of the rapidfuzz package: https://salsa.debian.org/python-team/packages/jarowinkler https://salsa.debian.org/python-team/packages/rapidfuzz-capi Thanks, Julian
Re: Suggesting change in DPT policy
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 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 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
