Re: Request to join as new member
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 <simon@josefsson.org> 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>
Reply to: