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
signature.asc
Description: PGP signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
