Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
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
Reply to: