Hey! On 05/01/2023 23:15, Levente Polyak wrote:
# Introduction
Behold, ~~winter~~ Git is coming. We've been working on and off to get Git packaging sources ready for a while now. Today I'd like to outline the final proposal regarding the action plan, workflow, tooling and also the reason for a couple of decisions. Consider this as a late xmas gift to our distro 🎁😻
# Git repo layout
Lets get technical. The Git repo layout is related to RFC-14 (Merge package repositories) and most of its aspects were discussed during that proposal. However, let's summarize what that actually means for the packaging repositories and how all this looks like.
Every `pkgbase` will have its own dedicated repository that is stored in a single combined GitLab group called `packages` (e.g. https://gitlab.archlinux.org/archlinux/packaging/packages/foo). This allows us to have a well structured and simple layout, which provides the grounds for a per `pkgbase` issue board on GitLab (note: dealing with the issue boards is not part of the migration). Package maintainers will receive write access to the entire GitLab group.
Whenever we completely remove a `pkgbase` from our distro, we will archive the corresponding GitLab repository instead of deleting it. Being able to physically delete the GitLab repository would effectively circumvent force-push and tag protection rules. On top, preserving an auditable history of former packaging sources is actually a good thing.
I'm looking into the Archweb changes for Git packaging support, at least linking to the urls should be easier. But what do we do with kde-unstable, gnome-unstable? I believe that kde-unstable is now a branch next of trunk? Or a separate branch? [1] I'm actually not 100% sure how in Git packaging we handle [testing]/[community] now. As far as I can see it will be a linear history. So I commit something to [community-testing], we tag it. I won't be able to update [community] unless I bump both. Which honestly makes me wonder if we should ideally just use branches in our Git packaging repo for community, community-testing. [1] https://github.com/archlinux/archweb/issues/438