debcheckout -a behavior in Ubuntu?

[Sebastien Bacher]

Hey Steve,

Le 08/06/2023 à 22:10, Steve Langasek a écrit :
> Now the reason I think this needs discussion before I just run off and
> implement it is that I know some teams use ubuntu branches on
> salsa.debian.org today for their work.  But those repositories would be
> unsuitable for the above workflow, because the ubuntu branch on salsa
> doesn't know about Launchpad ~ubuntu-dev ACLs.

The issue isn't specific to salsa and ~ubuntu-dev though, we have 
packages maintained on launchpad but owned by teams which don't include 
~ubuntu-dev (I've often hit that problem trying to fix installer bugs) 
or in github, and in reverse we have Ubuntu uploaders who do have access 
to the salsa branches.

The question is rather 'has the person doing the checkout write access 
to the target repository'

> Do folks who use non-Launchpad repositories as the primary vehicle for their
> packaging work mind if 'debcheckout -a' stops pointing at those
> repositories?

I've an issue with that yes. For me as a package maintainer the ideal 
outcome for the cases where the uploader doesn't have write access to 
the Vcs would be to receive a merge request targeting the Vcs where the 
package is maintained. That's less work for the contributor (it gives 
them a chance to base the changes on the current state of the package 
vcs which might be different from the archive one, it might even 
potentially already include a fix for their problem) and less work for 
the maintainer (no need to rebase, possibility to merge from the webUI 
directly, ...).

Ideally we would guide them in doing the right thing (get an account if 
needed/push to personal space/mp).

For practical reasons it might be that the only reasonable action we can 
do in a consistant way from the debcheckout is to clone the git-ubuntu 
vcs but if go that way I would like for the tools to start by displaying 
a warning that the package is as actually maintained at 
<packagaging_vcs> and that it is recommended/suggested to try to submit 
the fix there even if the tool is about to give a checkout from an 
import instead.

Cheers,
Sébastien