Hello Simon, On Sat, 11 May 2024 at 11:51, Simon Josefsson <[email protected]> wrote: > Following up on the namespace question separately. To clarify: I'm not > proposing any change. I'm mostly trying to learn and understand why > some decisions were made and if the rationale still apply.
No worries, I think there's definitely room for improvement. I've been having discussions like this with the other curl maintainers but we haven't managed to find a good alternative for the issue yet. If you're going to attend DebConf, I'd love to chat about this with you (I have seen your emails on other threads and it looks like we are aligned on how we view the issue). > Samuel Henrique <[email protected]> writes: > > > Downsides of keeping the packaging under debian/: > > * Lack of the salsa's view of current opened MRs, as seen on > > https://salsa.debian.org/groups/pkg-security-team/-/merge_requests. This > > is > > the biggest downside in my opinion. > > Couldn't this easily be solved by tagging merge requests for > pkg-security-related packages with a tag, and search for that? Assuming > all pkg-security-team packages were to be moved to /debian/ (for sake of > discussing this aspect). I'm not familiar enough with GitLab workflows > to tell if using Assignee, Reviewer, Label, Environment or some other > tag though.... then you could go to this page, using label CI as an > example but CI would be replaced with PKG-SECURITY or similar: > > https://salsa.debian.org/groups/debian/-/merge_requests?scope=all&state=opened&label_name[]=CI That would work, yes, but I don't think there's a straightforward way to automate this. It's an interesting idea nonetheless... > > * Team contributors who have received permissions to push to all team-owned > > repos (before becoming DDs) will still not be able to push to the packages > > under debian/. This is not a huge issue because they can still open MRs, > > but > > the process to contribute becomes a bit more cumbersome. > > Is there any documented policy for /debian/ packages including group > membership policy? Maybe lack of documented policy for /debian/ is the > biggest problem here though, it isn't even possible to evaluate if the > policies are compatible. Not that I'm aware, what's done in practice is that all DDs get permission to push to the debian namespace. The way we handle the concept of teams on debian is not very well defined, for good or for bad. We miss a few things to get an ideal process, but one that often gets to my mind is the ability for multiple teams to own the same package. For example, a security-related package written in python should be set up so that both the security-tools and the python team are able to push to git (and to upload) as a team upload. If we go further, we can also say that any DD is allowed to push and upload, while still keeping a team under its maintenance umbrella (the people from the team would be the ones receiving bug reports, watching MRs, etc...). Cheers, -- Samuel Henrique <samueloph>
