Recent searches
Search options
Good morning, day, evening, or night, wherever you are! 
May you all stay safe and have a happy and successful day. 
I'm currently looking to find an alternative hosting for my #opensource projects on #GitHub. Evaluating #Gitea now.
I personally like GitHub, but I dislike that it is a #centralized vendor lock-in silo. On the other hand, it's reach and acceptance in the opensource scene is still unmatched.
I want to prevent the use of the discussion feature. Any tips other than #discord?
@MarkusEicher Have you seen @Codeberg ? I intend to use them going forward.
Not sure about the discussion feature though.
@MarkusEicher for discord I'd recommend element which is very similar to discord
Hi, and thanks for the tip. Appreciate your support. Bookmarked this.
@MarkusEicher always a pleasure 
@MarkusEicher If you are interested in #Gitea also check out @Codeberg, one of the bigger Gitea hosts. They just started a fork (due to not-so-ideal governance changes in the original project) that aims for a decentralized/federated version of Gitea (if I understand correctly), called @forgejo https://codeberg.org/forgejo/forgejo
@MarkusEicher could I gently suggest also using GitHub? For public code you get free code security features and CI/CD with Actions, plus CodeSpaces:
The security includes Dependabot, CodeQL and Secret Scanning, plus private vulnerablity reporting.
It doesn't negatively affect diversity if it is *also* available on GitHub.
(I work at 
)
Hi there, and thank you for your input. I appreciate any opinions and suggestions on this topic.
I really like #GitHub. The only reason I'm looking for alternatives is the nature of the solution being #centralized and vendor dependent. I personally don't think that there are #decentralized or better #distributed solutions that match the feature set and offer of #GitHub today. Nonetheless I need a #foss solution for #opensource that gives me full control over all the data.
@MarkusEicher GitLab is quite close to GitHub in many aspects, we are using both at work in parallel. I don't see GitHub creating a vendor lock-in silo, since you can migrate at least code and issues to other tools (like GitLab), but yes, it is centralised.
Hi Martin, and thanks for your input. My goal is certainly not to diss #github, but to find out, if there are ways to achieve the same level of manageability and #CICD automation with #decentralized, better #distributed solutions. The outcome may well be a no. Then my project need to decide if we want the reach and ease of use of GitHub or #gitlab, or accepting more work and complexity to be independent.
As soon as you use GitHub Actions and CodeSecurity features, you're locked in imo.
@MarkusEicher @mhier IMHO it doesn't matter much if you use #github or #gitlab or any other. It is easy to move around the code, or even setup server mirrors.
Of course if you use something like Actions you may feel locked in, but you would be as well if you used Jenkins. For me the best is to design your CI/CD so that your pipelines contain the smallest logic possible and the logic is moved to scripts. That makes moving to a different server easier (I had to do it, and it went smooth)
@pecessonamigosnocomida @mhier
Hi there and thank you for your input, I appreciate your support. These are good points and I will try to wave them into the project documentation. One point I don't fully understand is, that you said one would potentially be locked in too when using #Jenkins instead of #GitHub actions. Could you please tell me why this would be the case?
@MarkusEicher @mhier Your pipelines typically contain things steps like: clone, choose branch, run this command, store this file, send a notification...
You also need to choose when that is run: manually, when branch changes, when opening a PR...
That config+steps need to be saved in git as well (so you have control over changes). On Actions that would be a yaml file, for Jenkins a declarative or groovy script. But those files are vendor specific, for that I said put the less logic on them.
@pecessonamigosnocomida @mhier
Got it, thanks a lot! 
@pecessonamigosnocomida @MarkusEicher Our pipelines unfortunately got quite complex over time: https://github.com/ChimeraTK/JenkinsConfiguration/tree/master/vars
It won't be easy to move to a new system while keeping the same functionality. Still, there are two types of vendor lockin: If you use GitHub actions, you can't even move to a different SAAS provider or host it yourself. With Jenkins or GitLab you have that freedom at least, even when you still have to stick to the chosen platform.
@mhier @pecessonamigosnocomida
Great input, thanks. I will need some time to dig deeper into that, but at first sight, these groovy scripts are pretty advanced stuff. Thanks for the link.
@MarkusEicher @pecessonamigosnocomida Those scripts are also rather special for our situation. Just an example why we are "vendor-locked" to Jenkins to some extend 
@mhier @MarkusEicher Well, you can host your own #GitHub Actions runner, that is exactly what we do (but of course you still need GH).
But I see your point. The problem you have is essentially what I was referring to. Now you have a lot of logic on Jenkins scripts and that is locking you in. So for me it is more important the design rather than the technology used. I see the excessive complexity on CI/CD somehow as #techdebt that may be limiting the options of the project. Keep things simple :)
Yes, our pubic launch announcement is imminent, basically coinciding with this next #Gitea release.
Forĝejo will remain a drop in replacement, as we continue to develop out #ActivityPub based #forge #federating capabilities.
You have a great day!
#tallship #FOSS #Fediverse #ForgeFed #Forgejo
.
@MarkusEicher I recommend @Codeberg, a Gitea-Instance that is run by a German Non-Profit and solely hosts #OpenSource/#FreeSoftware.
@MarkusEicher @Codeberg Also have a good day. Happy hacking from Austria.
Thanks, Shelenn. A friend provided a VPS so this might happen sooner or later. Depending on my health and time status. But I want to find out, if there is also anything around fully #distributed for #Git. #P2P or #IPFS kind of stuff.
@MarkusEicher I definitly recommend element too. It can be a challenging to use for new users, it needs a bit of time to adapt, I would advise you to share your xp with them to make them more comfortable to use it.
Hi, and thanks a lot for the input.
I need to try it out once I find the time and I will add it to the project for sure. Then my own and the experience of others can be helpful for others. Always a good thing to share imo. Have a great day!
@MarkusEicher cool. Have a good day!