Infrastructure Upgrades/Changes: Git(ea)

Matthew Brush mbrush at
Sun Oct 8 09:49:16 CEST 2017

On 2017-10-07 03:21 PM, Simon Steinbeiss wrote:
> Hi everyone,
> there have been discussions around our current infrastructure - be it
> hardware or software - and following Gnome's discussions around moving from
> cgit/gitolite+bugzilla to something that feels a little less dated and
> provides more integrations (they are ogling at Gitlab) we have also had
> several discussions of our own.
> We have started writing up requirements for the new infrastructure (again,
> both hardware and software) and have started looking into candidates more
> concretely.
> For the software one hard requirement is self-hosting, a few more are
> features we would like to either get or not lose over the status quo. Of
> the candidates we took into closer consideration (Gitlab and Gitea) we have
> been leaning towards Gitea. In short, Gitea is a very Github-like (some say
> it's a clone), lightweight piece of software that provides a Git server
> (with collaboration features like pull-requests), a very simple issue
> tracker (like the one of Github) and a very simple internal wiki. The
> latter two components can either be disabled or redirected at external
> services.
> In order not to get stuck in endless discussions (which could be dragged
> out by the fact that people have lives and can't always participate in the
> discussions) I would like to propose that we try to move ahead with a
> switch to Gitea.
> I know that feels a little dramatic and I'm hoping to also spark some
> discussion here, but it's not as brutal as it may sound.
> The current proposal for phase 1 would be the following:
> 1) Replace cgit/gitolite with Gitea (for browsing and administering Git
> repos)
> 2) Keep Bugzilla and Dokuwiki for their purposes (you can see the
> integration in the instance Skunnyk set up)
> The migration and setup of the Xfce repositories can be automated quite
> nicely (Skunnyk has already done that) so that part is not a real blocker.
> What we have to figure out to some extent is
>   * how to manage permissions (there are organisations, teams and per
> repository permissions as different layers for which we will need a concept)
>   * how to best migrate/set up the hooks (both for the Github mirror and the
> bugzilla comments)
>   * to what extent to allow everyone to register and create forks (what
> private repos are in cgit atm) in order to submit pull requests
> For the future Gitea still provides the following points (imo):
>   * issue tracking (migrating away from Bugzilla)
>   * release management (potentially replacing by uploading
> signed tarballs to Gitea)
>   * continuous integration integration (yeah, double the integration!)
>   * considering whether we ever want to use the internal wiki for anything
> So far we haven't really found anything where Gitea lacks over
> cgit/gitolite feature-wise. (Even the hyperlinks on Bugzilla issues work.)
> However this does not mean that we will potentially find any drawbacks of
> this situation. The good news is that switching back is not very painful,
> as far as we can tell. As only Git management moves to Gitea that's the
> only part that would have to be switched back.
> Finally I would argue that it would be beneficial to try this out for real
> (instead of toying with a staging instance over a longer period of time)
> because we already have limited resources, so toying with stuff is usually
> something people don't have too much time for anyhow. While I can easily
> push to both cgit and Gitea, this doesn't mean I'll be familiar with the
> features or way of working of either (as I'm in both cases only using the
> Git command-line locally as my main interaction).
> So anyway, that's the proposal in full. I know it was/is a lot, but thanks
> for reading and even more so for commenting and a healthy discussion.

This sounds cool.

I only really ever work on Mousepad, but my observations (pain points) 
of the current infrastructure which could probably be solved during the 

   * Multiple logins to remember/manage (ex. bugzilla, git, wiki, 
mocha?, etc)
   * Git using SSH keys rather than username/password credentials (even 
if technically superior) is more cumbersome for those not accustomed to it.
   * Making releases is difficult, requiring knowledge of some custom 
software and workflow. I can never seem to figure it out (hence Mousepad 
having extremely infrequent releases). Something simple like Github 
releases would be cool.
   * Inability to grant permissions to trusted contributors for the bug 
tracker component or Git push rights myself.

Personally, I'd prefer if Xfce was just on Github so I don't need 
additional credentials and to learn other software, but I can understand 
some people don't like relying on 3rd parties for such things. The 
biggest advantage of Github, which is especially important for a project 
like Xfce, is to reduce friction for contributors, making it easy for 
people to contribute without the overhead of signing up for yet another 
website account and learning a new software. I myself often don't report 
bugs or submit trivial patches to projects due to this burden.

Thanks for working on this.

Matthew Brush

More information about the Xfce4-dev mailing list