Arch Linux bugtracker migration to Gitlab completed
archlinux.org
archlinux.org
It's a pretty bad look to claim that you offer a free version for individuals when there's not actually any way to get it from gitlab.com. Your only option is an email capture for a free trial of enterprise. Even the install docs redirect you to an email capture.
Of course there is a way to install enterprise for free, and it's full of nags and enterprise-only features that prompt you to upgrade.
You have to already know what CE means and you have to find it through a search engine. Even the install docs barely mention it. I got all the way through the install process and configuration before I realized I'd installed the enterprise version. I only found CE by searching for ways to hide the enterprise upgrade nags.
It's an extremely bad look, and people like me who care about privacy and open source are gonna be turned away. I explicitly decided against gitlab for this reason. I only came back because the other options are worse.
I get wanting to promote the paid offering, but completely burying the actually-free version and only offering an enterprise trial behind an email capture is pretty hostile. It's against the spirit of FOSS and I'm very disappointed.
> What happens after my free trial ends?
> Your GitLab Ultimate trial lasts 30 days. After this period, you can maintain a GitLab Free account forever or upgrade to a paid plan.
I agree that CE should have been more prominent on gitlab.com - it's practically impossible to discover - even if you know what you are looking for.
GitLab CE instructions used to be the default. Paying customers would find they installed GitLab CE by default and run it, and then want to use features. They’d have to install GitLab EE over it. Well if they’re a year or two behind in upgrades, that transition can be painful and require services.
This created alot of anger and frustration from enterprises who paid for GitLab or wanted to convert to paying for GitLab. The solution was simple; install GitLab EE by default per the instructions. Because FOSS folks will search out the free editions. Yet customers won’t; and they’ll get caught with the CE edition unable to migrate to EE.
The move wasn’t one built on bad faith to move people to paid versions; or somehow bury the CE versions. It was to reduce paid customer frustrations. Even now GitLab docs talk about running GitLab directly from source.
In this section there is an explanation and a link to the package server. Pick the CE and follow the install documentation
https://about.gitlab.com/solutions/open-source/join/
They offer everything in Ultimate, including 50k hosted CI minutes, and the requirements seems reasonable (basically, everything needs to be public, have an open-source license, and you can't profit from add-ons or services).
The drawback is that it looks like you have to apply for it to use it.
Next to using GitLab.com SaaS, Open Source Program members can also choose to self-manage their GitLab instance -- like Arch Linux.
> The drawback is that it looks like you have to apply for it to use it.
This is a requirement, yes, but should not take too much of your time. You can learn how the process works in https://handbook.gitlab.com/handbook/marketing/developer-rel...
update: ahh I see there is a "migration" popup on the 404 page.
[1] https://about.gitlab.com/solutions/open-source/join/
[2] https://handbook.gitlab.com/handbook/marketing/developer-rel...
If you have a commercial offering, you can probably afford to pay for your tools.
I've followed the gitlab migration and every package and distribution change that warranted community notification for more than a decade.
It's such an empowering feeling to have tracked all the changes to the distribution over a decade. The Arch maintainer culture has managed to provide consistent high quality communication and documentation.
Most of the news doesn't require action on my part, being a subsystem or package I don't use. They use the news channel sparingly and the distribution is minimal and clean. News arrives only every other week or so and is succinctly written in one or two paragraphs.
It's a distribution for those who love precision and professionalism.
Plus Freedesktop, GNOME, U-Boot, and probably more I am not aware of.
At this point, even if GitLab decided to close down their CE offering, I think there is enough momentum in the community to keep it going (at least for a little while).
https://rachelbythebay.com/fun/som/
Plugging in for GitHub gets a score of about 90%. GitLab is in the mid 30%'s. (Assuming Arch is keeping a backup mirror of the bugtracker, etc on a private instance somewhere.)
That seems good enough to not bother with actually hosting it yourself. I'd rather they spend volunteer time on stuff other than applying security patches to a giant beast of a web service.
Ansible role for gitlab: https://gitlab.archlinux.org/archlinux/infrastructure/-/tree...
Gitlab playbook: https://gitlab.archlinux.org/archlinux/infrastructure/-/blob...
This is really clean! I'll definitely be using it as a reference for IaC done right. Congrats on the migration.
> How many distros now have their own GitLab instance?
Open Source project partners are listed in https://about.gitlab.com/solutions/open-source/partners/
More insights into GitLab for Open Source in https://about.gitlab.com/solutions/open-source/ and the Open Source program handbook page in https://handbook.gitlab.com/handbook/marketing/developer-rel... -- created an MR to update the section at the bottom with Hacker News examples. https://gitlab.com/gitlab-com/content-sites/handbook/-/merge...
https://about.gitlab.com/blog/2023/09/11/migrating-arch-linu...
Mentioning it as it never did well on HN, but probably interesting in light of this post.
Spamcheck is available for all tiers https://docs.gitlab.com/ee/administration/reporting/spamchec... For licensing reasons, it can only be included in EE, and not CE. https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6259#n... You can run GitLab EE with the free tier as well.
There is also a huge volunteer cost here where we have to manually make accounts.
I'm a big Arch fan but moved to Fedora because the overhead of managing updates in a rolling release got to be too much, and Fedora is very similar to Arch in conventions it follows, so most of my knowledge transferred over seamlessly (other than package manager of course). Moving to Mac OS though seems like it would render most of your knowledge/experience useless. I got stuck on a macbook for a short-term contract and found it maddening and confining in so many ways
Also, I guess it really doesn't matter in the end because all my development happens in Debian containers anyway. Hell... I could even use a Surface Pro and it would only slightly annoy me lol - the absolute beauty of containers!
Fedora? Maybe it was because of rpm prerequisite hell vs apt-get/pacman's auto install of whatever is needed, but moved away from RedHat after around 5.0/6... but then again, I'm sure that's all changed too. Maybe I'm just old :)
Looking forward to possibly contribute.
I know this is off topic but does anyone know how are we on having packages with lto by default and multiple -march? Is the new pkgctl going to allow multiple automatic rebuilds?
My new company is considering adopting Linux and is considering Ubuntu, and I pitched Arch because I really want to use the AUR again. I don't like installing PPAs with Ubuntu.
I was just having a conversation with a coworker about Jira vs Gitlab and why it doesn't make sense for us to switch to Jira over using Gitlab issues. After test driving it for a few weeks and now with a little "nudge" of backing from Arch with this post about how they have migrated to it, I was able to convince my coworker that Gitlab issues is more than enough for what we do and that adding Atlassian on top of that would only add to costs. FWIW, I love Atlassian Jira+Confluence duo. I don't like Bitbucket at all. It feels very antiquated and Jenkins-like. The UI theme isn't the issue, it's the layout, the nav, the construction that just rubs me the "we don't care about your productivity" way.
I think most of the work Valve does is upstream from Arch though but it's trickling down very fast (with arch, sometimes hours, if it's an AUR-Git package, seconds).
https://www.youtube.com/watch?v=h7YbqrJ0_nM
PS: The core of Valve's technical contribution is around the SteamDeck. You already know it runs Linux, Proton, yadayadayada. An obvious fact that only clicked for me after being mentioned in the presentation: if you aren't in the Steam store but want your app on the SteamDeck the primary option is a Linux version (distributed through flatpack). That (commercial) incentive alone is a huge benefit. Suddenly you can make a business case why your product maybe should support Linux.
For anyone reading this: virtually every piece of code is upstreamed to the projects themselves (Mesa etc.), there is no reason to jump to Arch for gaming.
But on top of that, they contribute a ton of things that benefit even people who never touch Steam. Valve slings graphics stack and GPU code, and of course Proton/Wine, Gamescope, and a handful of other things. They are awesome about upstreaming stuff, and when it's not upstreamable (say for example a new or standalone project) they tend to open it.
If you write an email to the accountsupport email though (as instructed) you'll get an account quickly :)
Git is free software and always has been. All these forges being split between community and enterprise are just so clearly people trying to make money on the popularity of other technology.
There don't appear to be any one-time purchase options, either. So, a subscription so you can collaborate with other people... Yeah, no.
cgit and Mantis and bugzilla all still work and are actual libre software.
Too much work to navigate.
The news post should be updated to include the above.
I did, I left Arch Linux and went to Gentoo where I could have control.
Arch is a shadow of what it was under Judd. phrakture was the worst thing to happen to that distro's culture.
Personally I find that suspicious behavior in an allegedly open ecosystem.
I assume this brings better integration between SCM and bugtracker.
It might mean less bug reports from users who find bugs, but aren't deeply affected by them.
The upside is a lot less garbage in your issue tracker.
OpenID was supposed to fix a lot of problems and doesn't appear to have, at all.
Anyway, there are lots of people who are not only knowledgeable enough but also skilled enough to triage bugs, but don't want to go through the rigamarole of a new account, e-mail, clicking a verification link, reading the bug report guidelines, etc.
Putting walls up to contribution is indeed a good way to get fewer people contributing. There's no guarantee the ones stubborn enough to still report bugs are reporting any better, though.
GitHub docs are really polished in comparison too.