Hi! Thanks for the comments. Responding inline to the questions you raised:
> Then it makes no effort to define communication channels. Before making some > time consuming change, it's usually better to just ask if that's a good idea .. > Then the document should enforce a particular commit style. I've seen several > people who do a bunch of unrelated changes in a single commit. The idea in DEP-18 is to define a few key principles that enable collaboration. There is no need to publish recommendations on communicating channels or git commit message styles. We have maintainer guides, team-specific guides and a lot of other documentation for that kind of stuff. Also, for a DEP to recommend something it should already be popular and widely supported by maintainers, hence the five principles it now has. > > Run Salsa CI at least once before every upload to ensure minimal level of > > quality > > Can you tell me how to do a CI for python3-motor, given that it's a client for > a proprietary database? > > Testing GUI packages, or fonts packages, or clients is generally very > difficult > if not impossible. What's the plan in those cases? Salsa CI mimics what the official Debian QA systems do. You don't need to write tests specific for Salsa CI. In the case of python3-motor, just improve on the autopkgtests it has, and both Salsa CI and Debian CI will run them. Salsa CI just brings the benefit that you can more easily catch regressions in packaging or new upstream versions _before_ uploading to Debian, thus protecting the quality of the packages in official repositories. > > While collaboration can happen based purely on developers submitting patch > > files as email attachments directly to each other, to mailing lists or in > > bug > > reports, it does not scale well. > > It scales better than having to open salsa, find out the git:// url, add a new > remote in the local git, diff the patch locally, then of course I can't just > merge the patch locally because salsa doesn't know about that, so I have to go > again on salsa and click to merge. You can find the git url in the package debian/control Vcs-* fields. No matter what way you do a patch, you need to download the sources in some way. Doing a git clone isn't really extra work. I am not sure I followed your description, but if you merge something locally and push to Salsa, it will automatically detect that a commit in a Merge Request landed on the target branch and mark the Merge Request merged on git push. > All of this with salsa being not fast nor responsive by any definition of > those > terms. I agree that Salsa is sometimes a bit sluggish (https://salsa.debian.org/salsa/support/-/issues/395), but I hope we can do something to improve it and it is now a permanent reason to not use Salsa. > > Allow changes to be reviewed before uploads to Debian > > I guess this means that we should have some mandatory waiting time from the > last commit to the upload. How long would this time be? Would it apply even if > we're talking about fixing a libc upload that will break any system where it > gets installed? I will try to reword "5. Allow changes to be reviewed before uploads to Debian" to be explicit about not prescribing anything too specific. It is up to each team and maintainer to decide what and when to ask for reviews. The main point in DEP-18 is that when you use salsa.debian.org, the code is published as source first, tested with Salsa CI and potentially reviewed instead of just being uploaded directly without any room for collaboration. - Otto
