[openlp-dev] Exploring GitLab

[Raoul Snyman]

Hey Simon,

On 2018-08-21 06:56, Simon Hanna wrote:
> I've created a repository on GitLab, and copied all the history over
> (takes about 15 minutes on my laptop). I've created it to play around
> with it, and to be able to showcase stuff. It's available here
> https://gitlab.com/thelinuxguy/openlp

Thanks for your work on this, it looks good.

> The CI jobs are not as customizable as jenkins, but you can do most of
> the things you can with jenkins. Here's the output of one job
> https://gitlab.com/thelinuxguy/openlp/-/jobs/90836097

At the end of the day, we're just running a bunch of commands on 
Jenkins. If GitLab can do the same, we're probably good to go.

> Coverage doesn't get rendered in html by default, but we can use the
> builtin "Pages" feature to serve them like I did in Mailman here
> https://mailman.gitlab.io/postorius/

Coverage is *nice* but I don't think many people actually look at it (I 
could be wrong though!). I find it useful, especially for figuring out 
what needs testing, but I think we could live without it if necessary.

> Issues/Bugs can be tracked using the issue tracker
> https://gitlab.com/thelinuxguy/openlp/issues and can be organized using
> kanban boards https://gitlab.com/thelinuxguy/openlp/boards

I like the integrated Kanban board :-)

> Theoretically the crash reports could be directly sent to GitLab using
> the service desk 
> https://docs.gitlab.com/ee/user/project/service_desk.html

Oooo, that would be nice. We'd need some filtering though.


> GitLab also comes with a wiki, but I think that the existing wiki in 
> use
> today is superior. 

I've not used GitLab's wiki, but MediaWiki is pretty much the gold 
standard of wiki software.


> Things that I think would improve by using GitLab/Git:
> * Easier to use web interface
> * Active and Rapid development of GitLab (new/good features are added
> constantly)
> * Easier to configure and run CI (All I did was write a couple of lines
> and it already does most of the stuff automatically)
> * Git has IDE support, for people who don't like command line
> * Basically every developer today knows something about git while
> * Easier to find tutorials/documentation

Agreed.

> * Git is much faster than bzr for branching/merging/showing
> logs/pushing/pulling ...

I've not really encountered this "speed" problem. People cite it all the 
time, but I still don't really see it.

> * CI for Mac is integrated (you need to provide a runner yourself
> though)
> https://about.gitlab.com/2016/03/10/setting-up-gitlab-ci-for-ios-projects/
> * CI for Windows apparently also works (you also need to provide a
> runner) but I haven't tried it yet. Appveyor should also work

Basically the same as what we currently have with the Jenkins slave 
running on the Mac in my office, and Jenkins offloading to AppVeyor.

> * Integration with jenkins is available, so the current setup can be
> used as well

Not sure if this would give us any advantage, I think it would probably 
be better to just switch to GitLab's CI completely (well, as completely 
as we can).

> * Popularity of bzr is low https://goo.gl/gjBcUs (I don't think search
> trends should be the norm, but it shows something)

It's what I call the GitHub effect ;-)


> Importing Code from bzr to git, is no problem. Importing existing bug
> reports however doesn't seem to be very transparent. There is a request
> on GitLab's issue tracker about importing from launchpad, but it's not
> implemented yet https://gitlab.com/gitlab-org/gitlab-ce/issues/47399
> 
> Mailman did import the old bugs
> (https://gitlab.com/mailman/mailman/issues/10) but you loose some
> information like authors. Other projects appear to just not import the
> bugs, and maintain two trackers during a transition period especially
> when there are lots of old bugs that might not be relevant anymore

Yeah, I just had a quick look at GitLab's API, and you cannot set the 
author for an issue. *sad face*

-- 
Raoul Snyman
+1 (520) 490-9743
raoul at snyman.info