So, this is much harder than the dh discussion. Here, we're not trying to come to a consensus on policy changes. And here, the level of agreement is not as high. I'd like to start by thanking the Salsa admins for running a great service and for answering some naive questions I had while putting this mail together. First, I guess I should see if we're in the same place on what we're trying to accomplish. Based on what I've seen, I think we can come up with recommendations that are entirely optional. One purpose these can serve is to guide people who are starting a new package and simply want to follow something they know a bunch of other people are doing. In some cases we can make conditional recommendations about best practice. Fore example, in round one we seem to have agreed that leaving merge requests enabled while entirely ignoring them with no one set to receive notifications is a definite worst practice. Judging consensus on optional recommendations is harder than judging consensus in the dh discussion. For example "Hey, I do not want to do that," may not even be an argument against a recommendation. Similarly, "There are circumstances where that would be wrong," may be an argument for documenting the circumstances or may even be an argument for no change. I can really use your help here. If you're providing feedback please make it clear whether you're arguing to refine/constrain the recommendation, just providing context, or arguing that I'm misreading what we as a community want to do. And as always, it's more helpful if you explain why. Deferred for Round 3 ==================== In this message I'm trying to focus on when we should use salsa.debian.org and where we should put stuff on that server. I'm hoping to cover git branch format, upstream tarballs, pristine-tar, and upstream integrity in round 3. General Recommendation ====================== This recommendation is intended for people who are simply looking for an approach that will work well with approaches others are using. If you are packaging something in a large team, follow their existing practices. If you are setting up a new team, see the recommendation for teams. If you have your own ideas about what you'd like to do and choose to disregard this recommendation, that is also fine. If you do not already know the answer you want, this recommendation is for you. If you are a Debian Developer packaging a package for inclusion in Debian, you should store your packaging information in one repository per package on salsa.debian.org in the debian group. That is you should create a repository under https://salsa.debian.org/debian . You should make sure that at least one person sets their notification level to 'watch' rather than global. This way you will receive notifications of merge requests and changes. Hopefully you will choose to monitor merge requests for your repository. If not, turn off merge requests. If you are not a Debian Developer, you cannot directly create a repository in the debian group. If you're willing to wait for a Debian Developer to create a repository for you and grant you access, that may make things simpler longer-term. If that wait would be long enough to frustrate you or demotivate you, you should [do what? Create a repo in their personal namespace on salsa?] By creating a repository in the debian group, you grant access to all developers. That way people performing NMUs can directly commit their changes. It will also make it easier if you later orphan the package to preserve version control history. The Salsa CA pipeline is recommended. Notes and Limitations --------------------- The debian group is great for relatively unrelated packages. It may not be appropriate for a large number of related packages (especially when maintained by a team) for these reasons: * It is hard to examine the group of related packages without also seeing other unrelated packages * You cannot subscribe to watch a group of related packages with one click * Access to people who are not Debian Developers needs to be granted on a per-repository basis in the debian group Some teams with a large number of packages have adopted a monolithic format where a single repository contains information for many packages. It is not the intent of this recommendation to judge that approach either positively or negatively; this recommendation is targeted at a very different audience. This recommendation is not appropriate in cases when Debian Developers should not have push access to the repository. For example if you are mirroring the repository from another service and do not want changes pushed to this replica, using the debian group is inappropriate. Discussion Comments ------------------- This is my notes for the debian-devel discussion. I'm not sure how much of any of the text here will survive into something that lasts, but the "discussion comments" subsections are explicitly intended only for this discussion. Obviously, I need input on what we should recommend for non-DDs who are packaging. We can create repos in the debian group for them, but what's the best practice if you don't want to wait that long? I realize that not everyone wants all developers to have push access to their packages. If you have a firm idea about that, then this recommendation is not for you. I also realize that by starting by recommending the debian group I'm recommending a more permissive maintainership model closer to low threshhold NMU than only NMU my packages after explicit confirmation. I think that the dh discussion supports the conclusion that we are OK with that as a project *as a recommendation*. If a maintainer doesn't like that level of openness, that's fine. My take though is that when recommending what to do to people who do not have preconceived ideas, more open policies like the debian group and low threshhold NMUs are in alignment with the project. I realize that a number of people choose not to use Salsa. Reasons have included: * Wanting to do packaging development in the upstream repository * Wanting to use a platform less under the control of a small number of administrators than Salsa * Not using Git My take is that those people can ignore this recommendation. My big question here is whether there is consensus behind this being the default recommendation if you don't have something else you want to do. Packages not on Salsa ===================== Some people choose not to host their packages on Salsa for a variety of reasons. Examples include wanting to host Debian packaging in the same repository as upstream development when the Debian and upstream maintainers are related. Even if you do not host your packaging work on Salsa you should: * Host your packaging work in Git. * Use a public repository where in-progress and ongoing work are available to the public. Do not just push when you release. * Set the vcs-git and vcs-browser fields in debian/control to point to your repository. You are encouraged to mirror your repository to Salsa so that people can find more of the Debian packaging in one place. Non-Free Services ----------------- It is important to many members of our community that they be able to do work within Debian without using non-free software or web services that depend on non-free software. Github is a common example of a web service that uses non-free software. Clearly community members can use the BTS, make NMUs and interact with mailing lists. However, not being able to interact with packaging Git repos can significantly reduce developer's effectiveness. Evaluate the impact on our community before using a non-free service like Github for Debian packaging. Would your needs be met by mirroring from free services to non-free services? Using non-free services for Debian packaging is not recommended but is permitted. Some have suggested that we forbid the use of non-free services for Debian packaging. First, we'd rather public git repositories be available than for example have people claim they are not using VCS at all. Secondly, we don't even have a mechanism to codify such a policy, nor is it clear that it would be desirable to have formal policy for what tools people use prior to upload. If the use of a non-free service is preventing an active member of our community from contributing to a team, the team should work to find a solution so that member can contribute effectively. Discussion Comments ------------------- The biggest question here is whether we have consensus that people should be using Git. I've seen two arguments against: 1) Simon pointed out that especially for upstreams with large files Git may not be a fit. However, I think that even in these cases the Debian packaging can be in Git. (Also, git-lfs may be appropriate in some cases) 2) Upstreams that use some other VCS than Git. I need more input here. Would we prefer that people have Debian only packaging repos? Would we prefer that they use athe other VCS? Do we not have enough consensus to have a recommendation in this case. The second issue where we've had some significant discussion is around non-free services. I'd appreciate feedback on whether I've gotten that right. Recommendation for Teams ======================== The debian group on Salsa may not be the best choice for teams maintaining a large number of packages. The team packages will be mixed together with other packages and that may be confusing. Often, a team will want their own group to segregate their packages. In this case the team should create a team group on Salsa and store their packages there. This will make looking at changes to these packages, merge requests for the set of packages, and CI information easier. It is not possible to grant the debian group access to all packages in a group at once. However, if a team wishes, they may grant push access to the debian group on a package-by-package basis. Best practice is for multiple people to have owner privileges on the team. If the team owner leaves Debian, having a second team owner will make managing the team easier. Similarly if an account is locked for security reasons, having a second owner will make the transition smoother. Account Transitions =================== This isn't so much a case where we have a recommendation as where it seems like we need to do more work. There are some awkward issues around Salsa accounts: * When you retire from Debian or are removed, your salsa account becomes inaccessible. That means you no longer have access to teams and repos that you are granted access to. * Granting access to repositories in personal namespace becomes problematic. You will typically no longer be able to push to repositories in your personal namespace. * If you are the only active team owner for a team, gaining access to the team will require administrator action and will be relatively slow. * You will need to regain access to any repositories that you should have access to. Depending on why an account is locked, the above may be strongly desired or deeply frustrating. There's been enough discussion of this issue that it seems like someone should take on the task of trying to figure out what we as a project want. Solutions might include: * Procedures that get followed when accounts are closed. We probably don't want more effort added to the tasks of NM front desk, MIA or DAM. But if additional volunteers stepped forward who wanted to help with these transitions, it might make sense to approach things that way. * Changing how Salsa and Debian LDAP interact. This would involve figuring out what we want and working with the Salsa admins and DSA. Closing Thoughts ================ A couple of issues have been brought up where people objected to the project recommending Salsa. I've considered the following issues: * Some have objected that Salsa is not sufficiently free. My understanding of the argument is that Salsa is running a community edition of Gitlab that is generally free, but contains non-DFSG free components that we would strip/do strip from the package. * Others have objected that we don't run the Gitlab package on Salsa. I'll note that many core services do not run packaged code. * Some have objected to recommending Salsa without improving the account transition experience. I've considered these issues, and my reading of the discussion is that the community is aware of them, but they do not rise to a level where they would challenge recommending Salsa. If you'd like to work on Salsa, including helping Salsa be more free, reach out to the Salsa admins and see if they can use your help. --Sam
Attachment:
signature.asc
Description: PGP signature