Hi,
On 2024-06-13 13:13:33, Pierre-Elliott Bécue wrote:
Andrey Rakhmatullin <w...@debian.org> wrote on 13/06/2024 at 12:48:36+0200:
I'm always hesitant to look at Python module RFSes because on one hand I
would like all of them to be in the team but on the other hand I'm not
sure if it makes sense to write "please move this to DPT" or "please
consider moving this to DPT", especially for people who are first time
packages without a team membership.
Perhaps we should discuss this and find a single recommended practice for
such packages.
I really think we should encourage newcomers to apply joining the team
and put their packages there.
What we could do if the idea of giving broad commit rights to newcomers
poses issues is to create a specific namespace in python-team for
newcomers. (then we'd need to have some migration plan and then oh dear)
I agree with both of you that it would be good to encourage new
contributors to put their Python packages in the Python team namespace.
If one does not want to grant push rights to all team repositories to
newcomers, an alternative to a separate namespace would be that a
sponsor (who is a member of the Python group on salsa) creates a
repository in the Python team namespace (after approval by the sponsored
person), moves the repository contents to the created repository and
grants the right to push to this repository to the sponsored person.
During that phase, new contributors can only submit changes to other
repositories in the team namespace by other means, e. g. by submitting
merge requests (although MRs are not ideal for all cases, e. g. updating
packages to new upstream versions). After a couple of good contributions
access to all team repositories could be granted if there is interest in
broader team contributions (rather than focusing on one's own packages).
This sketched procedure is e. g. followed by the security tools
packaging team (see e. g. Samuel Henrique's explanation on [0]). It does
not involve an additional migration step but adopting this by the Python
team probably requires rethinking the team policy acceptance workflow.
Best regards,
Peter
[0] https://lists.debian.org/debian-security-tools/2021/10/msg00003.html
