Hello Simon, I've just realized I forgot to reply to this, sorry about that.
On Sat, 16 Dec 2023 at 11:04, Simon Josefsson <[email protected]> wrote: > I help maintain a couple of security-related packages in the pkg-auth- > maintainers, pkg-sssd, pkg-xmpp-devel, oath-toolkit-help groups; gsasl, > libntlm, globalplatform, uid/pam/socket/nss/priv-wrapper, shishi, gss, > oath-toolkit, and maybe some more. Having all these different > maintainer groups doesn't seem to serve a lot of purpose these days, > and I discovered your pkg-security team which has a reasonable wiki > page [1] with thoughts around collaborative maintainance. > > Are you open to adding (some of) these packages to the group? If so I > would like to join as maintainer of this group and move the packages > (as time permit) here. Yes. > Do you have strong opinions to maintain packages in the salsa "debian" > or "pkg-security-team" group? Is there anything important that is > achieved by having debian packages in different groups on salsa? The > only thing I can think of is to restrict write access through > permission settings, but I wonder how much good that actually achieves. > I don't know if there has been any historical problems with people > doing bad things to salsa "/debian/" projects? That would be a mostly > social issue anyway. > > I've been recommending the "debian" group for some new packages like > lib25519, librandombytes, libcpucycles, libmceliece etc, which may also > belong in this group. > > So if you don't strongly disagree, I would prefer to move the packages > I mentioned above to the Debian-wide Salsa "debian" group but still use > a 'Maintainers: pkg-security-tools' field to indicate collaborative > group maintanenace and use this mailing list for bug reports etc. If I > move packages on Salsa now, I would prefer to move to a group/URL that > is more likely to be stable for the next 10-20 years, like /debian/, to > avoid having to move them again in the future. > > Of course, I'm willing to reconsider if there are some strong reasons > that I'm missing. I just don't see how /debian/ vs /pkg-security- > tools/ on Salsa would make a huge difference. I don't think we currently have any package from the team maintained under the "debian" salsa org, I also don't have an opinion strong enough against it. If the package is security-related, better to have it in the team under debian/ on salsa than nothing. Me, sergiodj and charles have done something similar for the curl package: we set a team as the maintainer and kept the packaging in debian/ (with a d/README.debian explaining our policy). Now, for the team's packages, there's no clear better option in my opinion, and I think this is still an unsolved issue in Debian's workflows: Downside of keeping the packaging under pkg-security-team: * It makes it harder for other DDs to push commits and do uploads, as they have to be added to the salsa group [0]. 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. * 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. I have added you to the team on salsa, in any case. [0] Being able to automatically add all DDs to certain salsa groups could solve this issue, but I haven't looked into what's needed for that to happen. Regards, -- Samuel Henrique <samueloph>
