The Debian GNOME Team has moved most of its packaging repositories to https://salsa.debian.org/gnome-team/ . Salsa is a new git hosting service powered by GitLab and hosted by Debian. Salsa supports forking and merge proposals similar to GitHub. Previously, the Debian GNOME team used svn repositories on Alioth. (There are still about 15 repositories that weren’t successfully converted to git and so are still managed in svn for now.)
The Ubuntu Desktop Team has long used bzr for its repositories (although the team has some git repos too).
The Debian GNOME team has approximately 270 repositories for packages in Debian Unstable. By my count, approximately 60 of those (22%) have Ubuntu diffs currently which means they need to be manually merged and maintained for Ubuntu.
I propose that we start using branches (named ubuntu/bionic) in Salsa for those Ubuntu managed packages instead of the bzr repositories (except for the packages that haven’t been migrated to Salsa yet).
The Debian wiki has more information about the Salsa workflow used by the Debian GNOME Team. See the Salsa docs for how to register for a Salsa account.
Yeah, this is totally a good idea IMO. In my experience these repositories are nice to work with. Good job . One great thing is that they have full upstream + Debian history, which is really handy if you need to do any forensics (e.g. git blame works as you’d hope).
I think it might be worth talking about where we put the repositories. I’d been assuming that we’d host them on Launchpad, but here you were thinking of salsa.d.o. If we use the ~ubuntu-desktop team on LP then the ACLs are already all set up, and any Ubuntu developer who can upload can also push. I think it’d be a bit of a barrier to ask people to register on salsa and join the team there, and possibly not even desirable to have people not interested in Debian able to push fixes. AFAICS the main benefit you’d get by being on salsa is not having to have two remotes configured.
The team as a whole is new to git packaging, and so it might be a good idea to run some tutorial sessions for those that might find that useful, probably in addition to documenting common tasks like importing “NMUs” and managing patches etc. (We have an upcoming internal sprint in March - I could do something there for Canoncial people if there was some interest.)
Thanks for following that work and keeping us updated. I agree with Iain that it would be nicer to not request Ubuntu contributors to have to create an account on salsa.d.o but rely on the Ubuntu infrastructure and teams instead.
Some random thoughts on the topic:
mid-LTS-cycle might not be the right time to look at changing our workflow for one most of the team is not familiar with. That sounds like an un-necessary distraction at the moment.
Ubuntu is trying to standardize on a common workflow around ubuntu-git, how does that compare to what you suggest using there? Whare are the pro & con of each solution ?
we should have those tutorial sessions, get the team familiar with the topic and probably experiment with some sources before taking a decision
I vote -1 for any kind of official change at the moment since the focus should be on LTS work and there no real reason our current infrastructure & workflow should be causing us any issue in the near futur.
Your summary also doesn’t seem to contain much “why” we should switch and why that option is the best one. Debian is doing that, and it “includes a github-like interface” seems to be the summary. How is their github-like interface better than what we would get on launchpad or github itself? How does the new workflow compared to what we have currently or what other Ubuntu&Debian team are doing? What would be the wins fo us?
Didier said he would investigate the ubuntu-git workflow post ff and I think we need a better understanding of the different options and their value/pro/con before considering a switch.
Please note that git-ubuntu currently has somewhat orthogonal goals, and so right now I don’t recommend using it as a replacement workflow for package maintainer teams who provide the original “upstream” packaging. For example: I co-maintain MySQL packaging on alioth in Debian (soon moving to salsa), and I’m not even considering integrating this with git-ubuntu.
Specifically, the gap we’re trying to fill with git-ubuntu is to present a consistent git view for all packages. To do this our primary input must be the Debian source packages rather than git trees, as we can’t mandate the use of git in a specific form across the entire Debian and Ubuntu projects. For those of us adding deltas to packages maintained by other teams in differing styles, we’re also working on making sure that our changes can be kept in git for future use (eg. in Ubuntu package merges). This has a side-effect of allowing much easier outsider contributions, as we’re in a position to show them git trees in a consistent form across all packages and accept merge proposals against them.
That’s not to say that git-ubuntu can’t converge on this use case in future. We’ve left its design open in a way that we think will be able to accommodate it in future. It’s just not something we’re focused on right now.
FWIW, the Debian MySQL packaging team tried out salsa at a recent sprint. I really liked it. Being designed to work against git from the start has given the review/merge workflow a big advantage against Launchpad, I think. In terms of being able to cope with the flexibility of git, it seemed much slicker than GitHub to me.
Any Ubuntu Desktop member or Ubuntu Core Developer can push to the ubuntu-desktop bzr branches (and upload those packages to Ubuntu). Everyone else can make merge proposals either in Launchpad or in Salsa. Permissions in Salsa are really flexible. A contributor can be given push access to individual repos or to the entire group. I suspect it will be a lot easier to be granted Salsa push permissions than to join the Ubuntu Desktop or Core Developer teams (since Salsa permissions aren’t directly tied to upload permissions)!
git-ubuntu doesn’t make sense for those packages we sync from Debian. I haven’t used git-ubuntu yet, but I think it’s a bit of a lowest-common-denominator that should work for everything, but that doesn’t mean it’s the preferred way to work with a particular package.
I think we need to consider how closely we want to align with Debian. At least for the ~75+% of GNOME packages that are in sync with Debian, I think the appropriate place to contribute is to propose the change in Debian. Using the same repos (and not just a mirror) is a good way to encourage that.
I don’t think this changes the dynamics of where and when to contribute a change (Debian vs Ubuntu vs upsream).
debian/* branches live on salsa. If you want to make a change there, you can either create a merge proposal or get access to the team and push it yourself.
My thought is that ubuntu/* branches would be pushed to Launchpad. If you want to push an Ubuntu-only change you can either make a Launchpad merge proposal or you can already push the branch if you can upload to the package in Ubuntu. If you then want to forward it you can cherry-pick it to debian/foo and push it up in the usual way.
I’m OK with waiting until next cycle, but I think that looking for improved workflows is a decent goal, and this is an improvement. When we talk about this change, please can we avoid making any perfect-enemy-of-good type of mistake?
That is the major reason why. It’s really really great to have Debian and Ubuntu’s packaging just there in the same place.
It makes merging much easier.
We get shared history, so a lot of bug archaeology - a task which we perform not infrequently - is made easier since you have the history locally already.
There’s a suite of nice tools for working with packages in git. Last week or so I worked on a change like this:
Create an experimental branch
Import the new upstream version
Write the changelog
build
omg, it’s broken
switch to upstream branch (same repository), reproduce the problem
hack, hack, hack, fix, push to upstream
switch back to Debian branch
gbp-pq import - create a temporary branch with one commit per Debian patch
git cherry-pick <the commit I pushed upstream>
gbp-pq export
commit, build, test
This was just a really smooth workflow compared to what I would have had to do with bzr or svn. Of course it’s possible to do this in many other ways, even with no VCS at all, but here we’re talking about being able to work better.
Yeah, a chance to avoid having to use the BTS for some things . More seriously, we know from having MPs on Launchpad (and using PRs on github) that this is a nice way to contribute changes. I’m happy that Debian and GNOME are gaining this facility.
We discussed this more in IRC today. I believe the concensus is that the Ubuntu Desktop Team will not be adopting Git or Salsa for ‘main’ packaging before Bionic Feature Freeze (March). Also, there will need to be a more thorough evaluation of our options and compare with what other Ubuntu teams are doing before any change. (So don’t assume there will be a decision in March either!)
I’d like to propose that Debian GNOME packages that aren’t in main and aren’t in Ubuntu Desktop bzr can use ubuntu/bionic branches at Salsa for now. One particular example is gnome-builder.
Please do
I would also like to use https://gitlab.gnome.org/Ubuntu/ as mirror for such repos [IGNORE THIS, gnome won’t allow groups for a while], and maybe some launchpad git too, so we can have multiple options. But of course we need to define an official remote.
Anyway imho this is the way to go… From a desktop team member that isn’t actually a ubuntu desktop dev, contributing to packaging is a bit annoying and time consuming. Now that finally upstream has moved to something fancier too, we should follow the trend for our packaging too.
. One great thing is that they have full upstream + Debian history, which is really handy if you need to do any forensics (e.g.