Hi Dimitri,
On Wed, Mar 17, 2021 at 05:50:45PM +0000, Dimitri John Ledkov wrote:
> My preference would be to open up some refs of git-ubuntu repositories to
> uploaders to be read&write.
>
> Such that one could created dgit like uploads and push the commit id, as a
> ref, into the git-ubuntu repository directly. Aka
> refs/heads/uploads/commit-hash as a branch.
>
> Then upon import git-ubuntu could look up the Dgit header from the dsc, and
> check if it knows about refs/heads/uploads/Dgit-header-from and reuse that
> as part of the archive-matching set of branches.
This sounds very much like the "upload tag" hack we have going at the
moment, except that we'd adjust Launchpad to allow any uploader to push
them. The way the hack works today, we don't need a Dgit or equivalent
header because the package version string is suitable as a unique
identifier. So the current hack just looks for
refs/tags/upload/<version>, where <version> is escaped according to
dep14.
To do this indefinitely as a permanent solution, how would cleanup work?
Do you expect refs/heads/uploads/* to grow forever? What about for
pushed refs that git-ubuntu doesn't use, such as when the ref doesn't
match the upload, or if an upload was rejected?
Since this is so close to what we're doing already, I can tell you about
a couple of practical issues with it:
1. We'd need ACL control so that any uploader can push the appropriate
ref before uploading. Launchpad doesn't support an ACL type that stands
for "anyone who can upload this package" today, though that is something
that was considered in the ACL spec such that it could be added later.
I'd really like to avoid rich history preservation becoming a "core devs
only" thing; it should be available to anyone who can upload a package,
given that we have a rich and structured ACL mechanism for package
uploads already that is extensively used.
2. If using the existing ACL mechanism, the git-ubuntu importer would
have to maintain individual ACLs as state in every single importer
repository. This is possible but seems somewhat painful to me; the less
arbitrary state to maintain that can fall out of sync, the better. For
example, the Launchpad API isn't transactional, so we could end up
creating a repository and then losing connectivity, leaving the ACL not
updated. Ideally we'd be able to define some kind of "umbrella default
ACL" for a set of repositories such as those owned by the importer user.
This would need a further Launchpad feature addition before it could be
implemented.
Because of the above two points, it seems an easier path to me to follow
my proposed spec instead, since that doesn't require any change to
Launchpad. It does have some caveats as Colin rightly points out, but I
don't think they'll be a problem in practice, and in the long term I'd
like something better anyway, as I describe in my other reply.
> Separately, I also want team uploads to be open to coredevs in the
> git-ubuntu repositories, i.e. such that there is no need to create
> ~ubuntu-core-dev/ubuntu/+source/$package repositories and instead the main
> git-ubuntu repository has refs/heads/teams/ubuntu-core-dev/* namespace
> available for ubuntu-core-devs to push using per-ref ACLs in Launchpad.
I'm aware this is a separate outstanding feature request. In the
interest of making progress though, I'd prefer to get the rich history
adoption implemented first, and defer this for a future conversation.
One step at a time :)
Robie
