Re: Request to join Debian Python team
Hi DPT, Sorry for bothering. I’m writing this to kindly remind this request. And please let me know if there is anything to fix. Regards, Xuanteng > On Mar 5, 2024, at 16:25, Xuanteng Huang wrote: > > Hi all, > > I’m a newcomer to Debian community and interested in participating in Debian > package maintainances. > I’m willing to maintain jupyter-cache[1], the execution cache system of > Jupyter Notebook under DPT, as other jupyer related package do. > > My Salsa login is xuantengh [2] and I’ve read the DPT policy [3] and accept > it. > > Best, > Xuanteng Huang > > [1] https://github.com/executablebooks/jupyter-cache > [2] https://salsa.debian.org/xuantengh > [3] > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst >
Request to join Debian Python team
Hi Team, I am interested in joining the team, because, actually I am working in adopting some python apps [1][2][3] My Salsa login is epsilon[4]. Thanks! Regards [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065239 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065241 [3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065237 [4]: https://salsa.debian.org/epsilon -- Daniel Echeverri Debian Developer Linux user: #477840 GPG Fingerprint: D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB
Re: Suggesting change in DPT Policy
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+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 situat
Re: Suggesting change in DPT Policy
Same for me. Thanks for proposal. +1 Anton Am Sa., 9. März 2024 um 17:51 Uhr schrieb Nilesh Patra : > I am late to the party but I agree with the policy change. > > Best, > Nilesh >
Re: Suggesting change in DPT Policy
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 : > > 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 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
