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


--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel

Reply via email to