[openlp-dev] Exploring GitLab

Kyle Russell bkylerussell at gmail.com
Tue Aug 21 10:47:22 EDT 2018

Wow, thanks for putting that together!  I agree that gitlab has lots of
features to offer that simplify or improve development workflows.

Maybe it would be good to summarize some of these points on a page in the
wiki, along with some of the concerns with switching away from or reasons
to stay with bazaar?  (Maybe there's already a page like that.)  Then
there's a place to comprehensively analyze what makes the most sense for
the project.

I fully recognize that I'm new to bzr and openlp, so my opinion probably
counts for less than two cents, but so far I haven't seen any bzr feature
that would make me want to switch all my projects away from git. :)

On Tue, Aug 21, 2018 at 9:56 AM Simon Hanna <simon at hannaweb.eu> wrote:

> Hi,
> 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
> For the testing, I've created docker images which are available here
> https://github.com/simhnna/openlp-docker The images are built
> automatically and pushed to the docker repository here
> https://hub.docker.com/r/simhnna/openlp/tags/ I've created three images:
> ubuntu, debian-stable and debian-buster. This allows for easy testing
> using the respective distros. All CI configuration lives in one file
> https://gitlab.com/thelinuxguy/openlp/blob/gitlab/.gitlab-ci.yml
> 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
> 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/
> 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
> Theoretically the crash reports could be directly sent to GitLab using
> the service desk https://docs.gitlab.com/ee/user/project/service_desk.html
> Merge requests would look like this
> https://gitlab.com/thelinuxguy/openlp/merge_requests/1
> Theoretically small fixes and such can be written write in the browser
> using their webide https://docs.gitlab.com/ee/user/project/web_ide/
> GitLab also comes with a wiki, but I think that the existing wiki in use
> today is superior.
> 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
> * Git is much faster than bzr for branching/merging/showing
> logs/pushing/pulling ...
> * 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
> * Integration with jenkins is available, so the current setup can be
> used as well
> * Popularity of bzr is low https://goo.gl/gjBcUs (I don't think search
> trends should be the norm, but it shows something)
> 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
> _______________________________________________
> openlp-dev mailing list
> openlp-dev at openlp.io
> https://lists.openlp.io/mailman/listinfo/openlp-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openlp.io/pipermail/openlp-dev/attachments/20180821/f85c52aa/attachment.html>

More information about the openlp-dev mailing list