Re: pkg-security-team vs debian namespace
Hello Simon,
On Sat, 11 May 2024 at 11:51, Simon Josefsson <simon@josefsson.org> 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 <samueloph@debian.org> 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>
Reply to: