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
