Starting with the 20.10 cycle, I would like to move Xubuntu repositories to GitHub. Doing so makes it easier for contributors to join and submit contributions to the project, while also reducing many of the headaches of managing and reporting on project data.
We transitioned all of our code to the Git VCS two years ago with the 18.10 cycle, citing the following reasons.
Xubuntu Git Workflow
Xubuntu and its various projects have used Bazaar since the beginning. Bazaar has served us well in the past, but there are several compelling reasons for us to transition. And the Xubuntu 18.10 cycle is the perfect time for us to move.
Consistent Workflow: Git is now used by all of our upstreams. Debian, Xfce, and Shimmer Project all use Git. Upstream contributions become easier with a familiar process.
Familiarity: Git is one of the most popular version control systems for open source projects. New contributors are more likely to have used Git in previous projects.
Development Activity: Git continues to be actively maintained and supported, with regular releases and bug fixes. The last Bazaar release was over two years ago.
Application Support: Many applications provide support for Git in one way or another. Thunar's VCS plugin and Geany's GeanyVC plugin provide addon support for managing Git repositories. Atom and Visual Studio Code, two of the most popular IDEs available for Linux, have native support for Git.
Meanwhile, we highlighted the following issues:
Linking Series to Git Branches: This is currently not possible. Series only help to identify which code branches are associated with each version lines. Instead, consider pushing each version line as a separate branch in your project.
Translation Imports & Exports: Launchpad does not currently support automatic synchronization to/from Git branches. Instead, you can create an git-to-bzr code import, and import translations from this Bazaar branch. You can periodically download the translations for a project and sync them manually.
Unfortunately, little has changed in the last two years. The issues we identified then are still present, and require unusual workarounds or additional processes to make work at all. This means that daily packages don’t include translations, translation-specific build issues are not identified until the last minute, and that several releases might be tagged without the translations that happened in between.