Infrastructure Upgrades/Changes: Git(ea)

[André Miranda]

I agree with Matthew, GitHub would be more comfortable to me and perhaps new
comers, but I completely understand the reasons of not moving to it.

With that said, if my opinion is worth, I'm fine with gitea, seems to be 
simple,
offers more features than cgit and is not as heavyweight as gilab, so it
strikes a nice balance.

Also thanks for looking into that.

Cheers,
Andre Miranda

On 10/08/2017 04:49 AM, Matthew Brush wrote:
> 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 archive.xfce.org 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 switch:
>
>   * 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.
>
> Regards,
> Matthew Brush
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> https://mail.xfce.org/mailman/listinfo/xfce4-dev