Move from Github to Gitlab?
-
@libremax said in Move from Github to Gitlab?:
For some free software is a political, ethical and even philosophical subject, for others it's only business as usual with the banal predation methods of globalized financial capitalism.
It's not a matter of love/hate.
UBports is lucky not to be a business and to be able to act in accordance with principles.I don't see where principles apply here: Github has never been free software, it has always been propitiatory software and infrastructure supported by investment and revenue from commercial services. Only the source of investment is changing.
I understand that some hate Microsoft, and I certainly don't love them (ask my wife!), but they have done good as well as bad. If they want to fund infrastructure for source control without asking any more in return than Github already gets then why should we care?
-
Perhaps what's really needed for FOSS, is the Wikipedia model: everything open and accessible, and if or whenever the foundation needs financial help, then ask the community for donations.
-
Ok so here my 2c...
I fully support the move to GitLab, but not for any real reason to do with Microsoft acquiring GitHub (although i do get others concerns). For me it's more about the project management aspect of UBports.
GitLab supports groups and subgroups so it's easier to organise our 300+ repositories, making it easier for everyone to find their way round, and also visualise the different parts of the project/platform and how they fit together. There could be groups for Unity8, System Apps, Core Apps, Packaging, Infra, Documentation, Tooling, Working Groups, Experimental... the possibilities are endless but each group is easy to digest and only contains repos specific to each groups goals. On GitHub you just get a giant list of all repos and you almost have to remember repo names as paginating through the list is just painful if you can't.
GitLab supports issues, milestones and kanban boards at both group and project level. This makes it really easy to organise per project as well as at the group level and get a higher level view of what's going on. You can also move issue between projects which is handy!.
GitLab CI would also be a great thing to have at the project level. Each project could define it's own pipeline for merge requests, doc generation, building and publishing clicks to open-store etc... and not have to use an external tool like TravisCI. Jenkins is probably still the right tool for the building ubports repo and could continue to build debs on changes to master, xenial, bionic branches. But allowing a project to define it's own pipeline, even attach their own hardware via a dedicated gitlab runner in my opinion is quite a powerful thing. Members of the community could even offer up spare hardware and create a pool of runners for UBports
GitLab releases new features nearly every month, so things can only get better.
GitHub is serving it's purpose right and doing the job ok, so it definitely doesn't need to be rushed if a decision is made to move.
-
I am okay with moving to GitLab. I think this platform has more benefits than most out there right now, including GitHub.
Regardless, I am in favor of waiting so the projects can be finished. Despite GitLab having lots of tools to help people migrate to their platform and what-not, they are a bit overloaded right now and moving 300+ repositories now will take days or even weeks. It will be a complicated task and if we do it now it will take longer than we can take.
The strategy should be planned in a future meeting by the devs and decide on what is the best course of action to minimize recursions and find the best occasion to make it happen.
-
Read also the much friendlier post here https://blog.github.com/2018-06-04-github-microsoft/ which explains a lot (to me).
BR
-
@flohack day 0 damage control.
-
@alan_g principles still do apply. You just have to compare track records with FOSS from Github and from Microsoft.
FOSS people will not embrace Microsoft and are leaving Github by the thousands.
Shall UBports stick aroung and wait to be thrown in the same bucket as Microsoft by the FOSS comunity?
Many Linux folks still say Ubuntu is a spyware years after the issue has been fixed. The name stuck. So don't expect now that everybody will be "rational" and I guarantee you UBports and Ubuntu Touch might be dismissed by some people for not taking a firm stance now.
And UBporrs will move to some other service one way or anorher because there will always be somebody new to start this discussion again, again and again. -
I don't see where principles apply here: Github has never been free software, it has always been propitiatory software and infrastructure supported by investment and revenue from commercial services. Only the source of investment is changing.
I understand that some hate Microsoft, and I certainly don't love them (ask my wife!), but they have done good as well as bad. If they want to fund infrastructure for source control without asking any more in return than Github already gets then why should we care?
The choice for UBports to go on GitHub had never been publicly discussed. It doesn't mean it was a perfect solution and every one was fully comfortable with it.
Now that it's publicly discussed, whatever triggered the discussion, why not seek a better solution both in operational terms and in terms of consistency with the principles specific to free software (GitLab is an open source SAAS, it's not perfect but better than non open source SAAS like GitHub) ?
-
@flohack said in Move from Github to Gitlab?:
Now reading that Gitlab uses Google cloud for all their services and I asking myself if Google is less evil than MS (probably not).
so is needed a google account to use gitlab or report an issue?
-
Both, microsoft and google , are large companies which have to make money for their shareholders. And they do it the american style. Everybody shall be able to read about the odd actings in the past (or have a look in their terms and conditions!). So unless the target of both companies is still unchanged, the methods will be the same. So why trust any of them?
On the other side, which could be reliable alternatives? -
@Flohack what would you think: How many people would have to spent an euro per month to get our own gitlab or whatever (just in the case gitlab isn't working at all without google even if self hosted) server?
-
@aury88 No. Their server infrastructure is rented from Microsofts Azure cloud at the moment, but they announced they will eventually move to GoogleΒ΄s cloud.
-
@hummlbach Its not only the money. The greatest offering if Github, Gitlab etc. is nearly no possible data loss. Their replication and backup is hard to fulfil as a small organization. Hosting your own means lot of headache, nightly calls and endless hours in front of the restore console
-
-
GitPub, anyone? https://github.com/git-federation/gitpub
-
@flohack so now I need a Microsofts Azure account and then I will need a google account in order to use Gitlab?
also are we talking about GitLab CE or GitLab EE ?
it seems you can host GitLab CE on your own server in a container, or on a cloud provider (that you choose). -
@aury88 No you can either create a Gitlab account or use an existing google, twitter, github or bitbucket account to sign-up/register
-
@aury88 we want to avoid self-hosting. We are not in the position to guarantee availability and secured data when we do it our own. Thats the whole idea of a cloud service, you have 24/7 access and no need to worry about server hardware failure, ISP network headache, let alone the 200 security patches you have to do each week. If you never run servers and services your own you might think its easy nowadays. Believe me its not.
I have experience from my workplace (sudden virus alerts? Forget your day, you sit and isolate virtual machines until midnight, then try to remove the virus, then patch everything etc. ), from private projects - 1 Harddisk in RAID1 dies, but the RAID decides to get damaged and you again loose data, and the last backup is a week old.) etc etc.
The cloud should theoretically decouple all this from eventual failures and problems. And yes, those services cost a lot of money, so its only feasable when you aggregate many many users on them. And yes, this is something companies can ask money for. Because its still much cheaper as any disaster that can happen.
We are not a critical mass, have no employees and no budget to do this our own.
BR
-
@flohack said in Move from Github to Gitlab?:
@aury88 we want to avoid self-hosting. We are not in the position to guarantee availability and secured data when we do it our own. Thats the whole idea of a cloud service, you have 24/7 access and no need to worry about server hardware failure, ISP network headache, let alone the 200 security patches you have to do each week. If you never run servers and services your own you might think its easy nowadays. Believe me its not.
I think we are not bringing costs to the table and, I mean. for an open source project, I'd say that is a major concern and self-hosted services like these have significant implications.
Despite not being related to the Foundation in any way other than a small contributor, I think self-hosted does not make much sense for many reasons.
-
@flohack said in Move from Github to Gitlab?:
@aury88 we want to avoid self-hosting. ...
If you never run servers and services your own you might think its easy nowadays. Believe me its not.
...
I have experience from my workplace ....I think you're totally misunderstanding me. I have absolutely in any way proposed or even thought UBPorts need/must doing the self-hosting . my question/answer was more to understand why you seem to be putting at the same level a service now owned by microsoft and in which therefore all the access data from now on will be collected and stored by microsoft (basicaly now you need a microsoft account to fork, put a issue, upload a code/PR, start a project etc on github, ) with another service that (optionally and only) use google services for their server infrastructure because of technical reasons that you so well explained.