On 21/08/17 10:23, Илья Шипицин wrote: > > 2) The travis-ci setup for coverity and an early check of github pull > requests (which only is an early staging area for patches to be sent to > the -devel list later). > > So I think we have everything that gitlab offers covered. Let's not add > another setup to maintain. > > > what I suggest is not "implement gitlab-ci immediately", I also do not > want to support more configurations. It's rather "let us take gitlab-ci > into account and implement it when there'll be appropriate task for it"
I agree that we should not duplicate the Travis/GitHub efforts. But I think it is good to look at alternatives to that setup as well from time to time and spread out how we use various free services. Not that we change anything now and today. But keep the options open to see if there are better alternatives in a longer run. One of my biggest concerns regarding both Travis and GitHub is that they are free services built on proprietary solutions. Which means, our usage is completely depending on their willingness and grace. If they decide to change their business model, we're back on scratch unless we decide to follow along and take the consequences of their change - which may result in needing to cash out or accept fewer features. GitLab is different, in the sense that in addition to offer a free service (which is even less restricted than GitHub), they also offer the software running their service as an open source package you can host yourself. Or you can cash out for their enterprise solution, with even more advanced features and improved support. On top of that GitLab allows you to export most of your (meta)data in addition to the source code. So if GitLab changes their business model, we have an escape route. And a company who provide that possibility needs to be much more weary and careful to how they treat their users so they won't escape (unless they deliberately want that to happen, as part of a business decision). If I had to choose today which service provider to use, I would go for GitLab instantly. Because of their business model, I trust them more. And I don't see their solution been worse or better than GitHub. It is different, not 100% comparable and doesn't have the same amount of traction which GitHub does (if that is really important; I'm not convinced it does). But GitLab allows users to authenticate with GitHub credentials, so if you're on GitHub already it doesn't cost you that much to log into GitLab. Bottom line: I appreciate the efforts of Ilya. I think it is valuable work. I also don't think we should switch right now, but if there are some clear and obvious benefits of GitLab-CI over GitHub/Travis-CI, I think we should consider to switch within a reasonable time window (perhaps 3-6 months after decision is taken?). _But that decision cannot be taken without some clear and concise evidence of GitLab-CI being superior and worth the efforts of switching_. Without any evidence, we're just painting the bike shed. If changing, I prefer changing to a feature-improved bike shed. -- kind regards, David Sommerseth OpenVPN Technologies, Inc
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
