Hi Steve,
Thanks for raising this.
I have no strong opinion on the behaviour for debcheckout you suggest.
From my perpective though, I think it would be useful if "git ubuntu
clone" were to read the Vcs-Git field and add a sensible remote for it.
Currently, even if the primary Vcs for a package in Ubuntu is maintained
in some other git repository, git-ubuntu is still relevant, because the
Ubuntu archive can diverge with a direct dput by an Ubuntu uploader. For
example, there might be a security update or a +1 maintenance person
who, through an upload, causes it to diverge. That person may not
necessarliy have permission to push to the preferred git repository, and
even if they did, they may not necessarily do so.
So it's really useful to have both the git-ubuntu repository and the
preferred git repository in the same local clone, as two separate
remotes. This allows for easy reconciliation between the two to bring
them back into sync, with things like "git diff", "git cherry-pick",
splitting commits with "git rebase" and so forth.
Therefore, whatever tool I use to make a local repository available for
a given package, I'd like for it to ensure that both the git-ubuntu and
the preferred repository (if one exists) are available as remotes.
Since "git ubuntu clone" also does a little bit of extra setup (eg.
another remote that corresponds to your own Launchpad namespace,
different default url and pushUrl configurations to try to do the right
thing with authentication, etc), I would find it preferable to let "git
ubuntu clone" continue to do that setup and have it add (eg) Salsa as an
additional remote.
There's no reason this can't be done in addition to the debcheckout
Ubuntu delta you suggest. But it might be worth thinking about what
workflow to recommend to Ubuntu developers in general - since
debcheckout as you suggest won't (I think?) solve the reconciliation use
case.
Robie
On Thu, Jun 08, 2023 at 01:10:43PM -0700, Steve Langasek wrote:
> Hi all,
>
> For those unfamiliar, 'debcheckout' is a tool in devscripts which is meant
> to automate the traversal of Vcs-* metadata for Debian packages to let
> developers check out the correct VCS repository for a package.
>
> The 'debcheckout -a' option maps the Vcs-* fields to authenticated URLs for
> known code hosting services, so that if you have commit access to the
> repository, your checkout will be set up such that a push works out of the
> box.
>
> This is a useful tool in principle, and historically where packages were
> maintained in Ubuntu we have taken care to populate Vcs-* fields in
> debian/control to point to the right place.
>
> The problem, from my perspective, is that I can't just trust 'debcheckout
> -a' to do the right thing for me as an Ubuntu developer. I always have to
> run 'apt-cache showsrc' first to check whether Vcs-* is pointing to a
> suitable repo, to know whether I want to run 'debcheckout -a' or 'git-ubuntu
> clone'.
>
> I would like to fix this. I believe the desirable properties are:
>
> - if I am running 'debcheckout -a' for a package that I have upload rights
> on, I should get a checkout that I can push from, and the next Ubuntu
> developer to do 'debcheckout -a' should see my changes, whether or not I
> upload them to the archive
> - if I do not have upload rights, running 'debcheckout -a' should give me a
> checkout that shares commit history with the above, so that I can raise
> sensible MPs
>
> With the work on git-ubuntu support for staging branches happening this
> cycle, git-ubuntu will soon satisfy this for the majority of packages in the
> archive (but not yet). So I think the implementation we want - at the end
> of this cycle - would be:
>
> - if there is a Vcs-* field pointing to a repository in Launchpad, use that
> - otherwise, call git-ubuntu clone
> - if git-ubuntu clone fails (because the package is missing from the
> importer), fall back to apt-get source
>
> 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.
>
> Do folks who use non-Launchpad repositories as the primary vehicle for their
> packaging work mind if 'debcheckout -a' stops pointing at those
> repositories? Should we add a new option to debcheckout ('--debian'?
> '--upstream'?) to unconditionally follow the fields in debian/control?
>
> Now, another place where the above implementation will give wrong results
> today is that there are various Ubuntu-specific Vcs-* fields pointing at
> launchpad branches that have effectively been abandoned and have not been
> used for any recent uploads (stretching back for years). This is a problem
> that can fix itself over time if more people are using debcheckout, as the
> wrong metadata gets fixed
