Thank you very much for pushing forward a modern VCS based development workflow for Ubuntu!
I very much like the suggested changes.
You mentioned the systemd package above and I’ve worked heavily on that one, so I have a few thoughts on some of the use cases (non-blocking):
- So far we used a shared git history with Debian’s corresponding Salsa repository and used the Debian maintainer’s tags to merge in new version into Ubuntu. Switching that to
git-ubuntuwe’d need to rebase onto the correspondingpkg/import/DEBIAN_VERSIONtags instead, which will consist of mostly synthesized commits… Oftentimes, additional context is given inside the commit message by the Debian maintainer, which might (or might not) be relevant for us. This information would be lost… or rather we’d need to keep a separate Salsa git history to check the relevant commits. - We’re making heavy use of git-buildpackage, e.g.
gbp pq. Some gbp commands can create additional branches, which are mostly local (so not a problem for this spec) and IIUC should not clash with the git-ubuntu namespaces. But it’s something to keep in mind when designing git-ubuntu, to avoid future conflicts between the two tools. - For bigger changes in systemd we used to create feature branches (e.g. enabling systemd-oomd, dropping i386 binaries, …), which we shared between co-maintainers inside our packaging repository. Such branches might not be ready for “staging”. So I think the idea would be to keep those in our personal Launchpad git namespace and creating merge-proposals against the staging branch. But being in the personal namespace would not allow a co-maintainer to push to my WIP branch. This is something we need to be aware of, it might need additional coordination between co-maintainers. But is probably easy to work around.
- I wonder if we could have some automation or tooling support to adopt the
Vcs-Git/Browserfields indebian/controland keep them consistent accross all packages, so that Ubuntu developers can always rely on that information. Right now it’s all over the place. And once we have a common structure for staging branches, it would be good to have that consistently represented in´d/control. Maybe even (automatically?) adding aXS-Vcs-Git-Ubuntufield in there.
Overall, I think having a common, modern workflow (and git repository location!) across all Ubuntu packages is of much higher priority than the few quirks/adoptions in workflow for existing packaging repos (and their maintainers).