Follow

Use , they said. Itโ€™s Free Software, they said. They will respect your privacy. Theyโ€™re the good ones.

@cathal @jwildeboer Gitea is a good way to go, with git.fsfe.org we've made excellent experiences. You don't even have to self-host, services like codeberg.org or gitea.com come to the rescue. All Gitea is missing in regards to decentralisation is federation between their instances

@mxmehl @cathal yes. Federation is essential. The squaring of the circle by recentralising git feels wrong.

@jwildeboer @mxmehl @cathal Just spin up multiple instances, run cron jobs to sync, and add multiple remotes to local repos. That's absolutely possible and makes Git decentralized.

@CyReVolt @jwildeboer @mxmehl This imagines that git hosting is just about git, which isn't really true. It's about having a well integrated way to tie git into issue management, features, project management, documentation, builds, etc. etc

@cathal @jwildeboer @mxmehl Maybe that's why some projects use mailing lists and have their docs within the repos. Assets can always be built from the sources, ideally.

@CyReVolt @jwildeboer @mxmehl Yea but.. software is also not only for people who know and use git. Documentation isn't really document-ey if your actual users can't access it because they don't know git.
Also, as a software developer, I detest email passionately and would rather switch careers than have to use email to organise anything.

@cathal @CyReVolt @jwildeboer There already is an issue for it, and some people worked on a standard. Unfortunately progress seems to be stalled
github.com/go-gitea/gitea/issu

@mxmehl @CyReVolt @jwildeboer Gitea is a community fork from Gogs, so they are already missing the main dev behind the core. I get the impression that they are underresourced..

@cathal @CyReVolt @jwildeboer Quite the opposite. When I started using Gogs, the main dev was quite unresponsive and annoying bugs have not been solved. Gitea is a community fork, they introduced a lot of great features meanwhile, and they are very open to outside contributions. But obviously, they operate on a much lower budget.

So feel free to sponsor them on opencollective. They are 100% #FreeSoftware and deserve our support

@mxmehl @CyReVolt @jwildeboer Oh I didn't mean they were neglectful. Just that they inherited a huge community from Gogs, and I don't know if they have enough active devs to keep up with the interest.
I self hosted for a while and need to boot that server back up. And contrib'ing on OC is a solid suggestion.
I know some Go also, should see about contributing code if possible..

@cathal @CyReVolt @jwildeboer As far as I can tell they are a very diverse team, there is no benevolent dictator, and I noticed that since its foundation a lot of new very active devs have joined, and not many have left.

Look at the number of different authors of pull requests for instance: github.com/go-gitea/gitea/pull

@cathal @mxmehl @jwildeboer @CyReVolt Documentation can be in git and still be approachable for users: https://doc.coreboot.org/ is automatically compiled from markdown files in a git repo.

@patrick @jwildeboer @mxmehl @CyReVolt But how do they contribute to docs, translations, etcetera? That's why Wikis are such a nice feature of Gitlab, and such a shame to lose.
We should always be pushing to make software development more inclusive to non-devs, it's the only way we end up making more things relevant to non devs. Crucial for accessibility, too.

@cathal @patrick @jwildeboer @CyReVolt I'm not sure whether you implied that, but #Gitea has wikis as well. They offer basically everything an average developer needs. So it's like Mastodon in comparison to Twitter, except that the users on different instances cannot easily connect and contribute comments or PRs.

#Federation would be a huge boost for Gitea (and other software supporting such a standard) and break the network effect that benefits Github and Gitlab.

@mxmehl @patrick @jwildeboer @CyReVolt Oh I love Gitea, I'm gonna go back to self hosting a server for me and some friends with this recent shove from Gitlab.

@cathal @patrick @jwildeboer @mxmehl We actually dropped the Wiki and switched to sphinx for the docs in coreboot. I'd like to oppose the idea that "git is only for devs"; many documentation contributions come to projects from non-devs via git. That's actually what many projects even recommend for first-time contributers. :)
Also, nothing keeps you from hosting a wiki independently. It's another way of decentralization, decoupling infra.

@cathal @CyReVolt @mxmehl @jwildeboer Once users contribute, they are contributors. As contributors we can expect them to use the tools of the trade. We dropped the wiki because it led to poor drive-by contributions in a corner of the project that was outside our processes.

I'd also be interested to have a web tool to simplify the editing process of a git backed documentation base (translations don't matter for coreboot, we don't have UI), but doing it that way ensures that it's part of the review process we have in place.

@patrick @cathal @CyReVolt @jwildeboer

First of all, the complexity of the tool defines the threshold new users have to take to contribute. Git is quite complex for inexperienced users, they have to read a lot of documentation first. We had to make the experience in the FSFE that you can lose valuable contributors by that.

On the other hand, #Gitea but also Github offer editing files/creating PRs via the web interface only. Branch names ("patch-1") are not really helpful then, but it works

@mxmehl @patrick @CyReVolt @jwildeboer More informative patch names could probably be fixed with a PR to add a "describe your edit" box, like Wikipedia does.
I agree by the way, I know far more people who will never contribute of it requires a terminal, than I know people who will. And making things elitist by saying "you must be this techie to contribute".. well, you do you. But I think it's a regression in culture-not progress.

@cathal @jwildeboer @CyReVolt @mxmehl It's possible to create a new change to coreboot's documentation without ever seeing a terminal, review.coreboot.org allows for that (even if the flow for creating an empty, open change is all but straight forward). If there's a way to streamline that, I'm all for that, but I haven't found that yet (and there's so much other stuff that competes for attention to implement it myself).

What I'm not open to however is to silo away documentation into a place where devs only get to see it by chance. That's what happened with the wiki we used to have, and that's what happens with a wiki in Github/Gitlab/Gitea - even if it were to be stored in a separate git namespace.

In my experience documentation really needs to live in the source tree (and undergo the same review processes as source code) to have a chance to remain synchronized and current. The other route would be to have writer communities that are strong enough to take care of that manually and on their own, but that's a weak spot in most open source projects.

tl;dr: hide git, for all I care, but keep documentation and source close together or they'll drift apart.

@cathal @mxmehl @patrick @jwildeboer Git neither requires anyone to be "techie" nor to use a Terminal ever. You can use one the dozens of GUI Tools out there. Posing the assumption of elitism is what actually creates it. No FUDding, please. :-)

@CyReVolt @mxmehl @patrick @jwildeboer He fact that even professional devs have to keep checking stack overflow to figure out how to fix git borks suggests things are not so straightforward even when the terminal is elided.
It's not FUD to say "professional tools built for software development are designed with professional software developers in mind".

@cathal @jwildeboer @mxmehl @CyReVolt I did IT support for a living for several years. If the amount of support need by professionals is what you're looking for, my recommendation is a pencil and index cards. Everything else fails in unexpected ways.

@CyReVolt @patrick @jwildeboer I agree to @cathal. At the FSFE, we manage our website with Git and ask voluntary translators to contribute their work through it. Although we invested a lot of time in documentation, it's a burden for many to contribute.

Git is an awesome tool, and I wouldn't want to miss it, but if you're not used to Git it can drive you crazy. The whole idea and concept is genius, but very unintuitive for many people. If you made diverging experiences, feel blessed :)

@CyReVolt @cathal @mxmehl @jwildeboer you don't even need cron jobs: gitea has "fetch from somewhere else" built in. But there's still room for improvement (but then, where isn't?)

@jwildeboer amazing isn't it? We are meant to believe that with all their expertise, they couldn't code their own telemetry collection, and also that they care about our privacy, but you aren't allowed to turn this (totally innocent, not selling your data at all folks!) option off.

@jwildeboer
They said though that if you have DNT enabled in your browser this would prevent telemetry snippets from loading.

@jwildeboer you can selfhost tho, thats the entire point why people recommend gitlab.

@jwildeboer If you're using their "proprietary services", you're not using Free Software.

If they did this to their free-of-charge users, that would be a different issue.

@yojimbo AFAICS theyโ€™re doing it to all gitlab.com users. Only when you run your own instance without support you are exempted. Am I wrong?

@jwildeboer gitlab.com is not free software, that is what @yojimbo wamted to say, i believe.

@laufi @jwildeboer I agree now that's what I should have said - actually I think I got it wrong in my first comment.

@jwildeboer I think you're correct.

I see external third-party trackers in their public non-logged-in page right now, pointing to Marketo, Google Analytics, Cookiebot, Bizible as well as the 'normal' but still uncool swifttype, fontawesome, cloudflare.

Mind you, they could self-host all the endpoints, and no-one would be sure that's what they were doing. So doing it openly is at least a little less scummy.

@yojimbo blocking API access until youโ€™ve accepted the new terms with no opt-out possible however is kinda scummy IMHO.

@jwildeboer @yojimbo that's what they said in the email. Community release for self hosting keeps being clean.

@yojimbo @jwildeboer I got this email and I have only ever signed into Gitlab with my Github account to comment on a issue.

@jwildeboer Soโ€ฆ don't use EE - it's a company and has always been. There is gitlab-ce (or FOSS). This is OS.

@jwildeboer Meh - others were faster, of course :awesome:

โ€ฆand once again: self hosted won. It's worth the hassle. Every gorram time.

@jwildeboer gitlab is free software. gitlab.com is not
use free software :)

@jwildeboer never fooled me, all I needed was to understand they follow the proprietary relicensing method of business...

@jwildeboer At GNOME we use a hosted Community Version. Not sure if that will be affected.

@brainblasted @jwildeboer From the email:

"For Self-managed users: GitLab Core will continue to be free software with
no changes. If you want to install your own instance of GitLab without the
proprietary software being introduced as a result of this change, GitLab
Community Edition (CE) remains a great option. It is licensed under the MIT
license (https://en.wikipedia.org/wiki/MIT_License) and will contain no
proprietary software. Many open source software projects use GitLab CE for
their SCM and CI needs. Again, there will be no changes to GitLab CE."

@jwildeboer this is quite sad. On the bright side running omnibus community education is super easy and then you can keep control. Thank you so much for sharing.

@mnw @jwildeboer It is indeed very easy. Beside some braindead sysctl calls, that will fail in an unpriviledged LXC container. Justโ€ฆ never fire this on some bare metal (or VPS) when _other_ stuff is installed. It will easily be thrown under that bus ๐Ÿค“

@jwildeboer
I thought Gitlab was open-source?!?

And I just setup everything on Gitlab...

Guess I'll be looking at Gitea or another alternative.

@jordan31
Gitlab CE is free software, but that's not what gitlab.com is running. If you're setting up a gitlab instance for yourself, you're good. This change only affects gitlab.com.
@jwildeboer

@jwildeboer If you read the whole email, that only happens on installarions they have to support. Gitlab.com and EE installs.

If you go the actual open source route and install CE on your owm server these script are not there.

@Routhinator The affected users are those that use gitlab.com and in the near future those that use the gitlab Enterprise Edition. So AFAICS all paying users/customers of gitlab. Am I wrong?

Sign in to participate in the conversation
social.wildeboer.net

Mastodon instance for people with Wildeboer as their last name