I think the general consensus is that we all want to migrate away from github, but it can’t exist without it. The activity of nixpkgs alone would cripple any alternative software hosting. It’s a finance problem, not one of philosophy. If we stuck to our guns with not choosing github, then we might as well close our doors now because it just can’t exist. Of course, the talks with codeberg are still happening, but I’m pointing out that github is seen as a necessary evil.
5 Likes
We’re definitely have going to consider these political issues and demonstrate that we can come to a friendly consensus on them, or else we’ll end up being too similar to nix. I’m very confident that we can do this.
(Also, IMO, @toastal’s specific points are all correct. I’d be fine with a compromise solution though.)
3 Likes
I think the general consensus is that we all want to migrate away from github
I wish I could agree but when I speak this argument now know I’m not talking alone. One of the greatest things about GitHub is how many people already have accounts there and how many people have been contributing to nixos over there already. Why should we have to move them just because we have a new forge. But also some of the major concerns from people on the original announcement post was to stay on GitHub.
The biggest concern for myself though is UI. Gitlab has horrible ui in my experience but can be worth it for their CI/CD. Forgejo/gitea is a solid choice and like wise GitHub. But the biggest no for me would be something like sourcehut.
1 Like
The workflow that goes thru MS GitHub for Nixpkgs is so, soo flawed tho. I’m not sure what the solution here is, but it’s not a good workflow that gets incredibly bogged down & reviews takes weeks to merge & another week for Hydra to build. It would be nice to see if someone has been working some other patch-based workflow like a mailing list, but, like, a UX that isn’t intimidating or flawed in different ways. There is a lot of room for improvement.
1 Like
I agree my language was too strong, I should have been more conservative in my wording. More input from more people should be had, but I remain skeptical on the practicality. I think my dream scenario is that its hosted on the fediverse, so we can all use the frontends we want to. I also have some issues with github with respect to inclusion – I think that anonymous PRs would be a great addition and that’s currently not on github.
@toastal, what about it is flawed? To me, it seems an organizational issue, not a platform one.
1 Like
GitLab is not just slow, but also owned by VC money & publicly-traded on the NASDAQ while have the ‘eh’ open-core model as well as now trying to sell its AI model thingy. But at least you can self-host it.
1 Like
Aside the organizational issues of monorepo you are probably alluding, the UI/UX for the pull request model are optimized for telling folks what to do in comments instead of maintaining & merging. For instance, I saw someone suggest swapping two lines of code in the review for the contributor which took a week to get that rebased & re-reviewed instead of the maintainer saying “good job” & fixing that nit themselves as the base logic wasn’t flawed, just a stylistic issue. This back & forth wasted folks’ time & slowed the merge as the maintainer was a reviewer, not a maintainer (IMO). Additionally, it becomes very difficult to work with patchsets that depend on other patchsets in review but unmerged which also slow the process along with the merge conflicts that arise when patches are out of order (insert something about “patches should commute”).
1 Like
So this seems to be another argument in favor of something like Gerrit. Maybe we should start a poll.
What options do we think are feasible? So far I’ve seen
- GitHub
- Gerrit
(& some discussion that suggests Forgejo and also seems to conclude that it’s unlikely to be workable). Is this correct? Are there any more options before we make this poll?
2 Likes
I think the issue with a poll right now is that we haven’t fully weighed our options yet. I would vote for Forgejo but I’ve resigned myself to github. I’d like to see more discussion on the viability of different platforms first before we poll.
I agree that it’s too early for a poll, unless we want to have an extremely non-binding poll just for fun.
1 Like
(I had second thoughts)
I think it might make sense to have a poll to check that we take @toastal’s points seriously, with one of the options being “We will mainly use github at first but we will work towards making its use non-mandatory”.
Not adding too much to that conversation in aggregate, but more thoughts to chew on…
Mailing list should at least be listed even if unlikely & flawed. Perhaps there should still be an inbox to support for those that do not wish to create accounts. Self-hosting isn’t that expensive depending on the tools chosen, how much data is actually retained, doing more testing/CI on the contributors machine before submitting patches, & size of the community.
While new, I’m quite impress with the tech decisions for the Ayllu project in the Git realm, but lists itself as targeting small-to-medium-sized communities–& I’m very curious how the plan to handle patches in the long run. Unfortunately, Nest isn’t ready to host projects of any size.
While new, I’m quite impress with the tech decisions for the Ayllu project in the Git realm, but lists itself as targeting small-to-medium-sized communities–& I’m very curious how the plan to handle patches in the long run. Unfortunately, Nest isn’t ready to host projects of any size.
My biggest issue with this is that I don’t want the UI to erk people, thus making it easy for even the beginners to contribute, and I think the best way to avoid this issue is to not leave the current list of:
- Codeberg (or alternate gitea/forgejo)
- GitHub
- GitLab
1 Like
I don’t want the UI to [i]rk people
This assumes that MS GitHub’s approach to UI is defacto due to being good vs. being familiar to many with many learning institutions teaching it first like they do with other Microsoft products like Word, Excel, Windows, etc. I personally don’t agree that having a proprietary Markdown fork or WYSIWYG editor for comments makes a UI better than another, but this is not some hill I would die on, but nor would I make the UI design coat of paint being anything that would sway my opinion of a forge one way or another over the featureset & performance (self-hosted, you could just slap on a custom CSS file & it can look like whatever you want).
Yeah I agree that their (GitHub) UI is the best, hence the existence of graphite, but it is known and used commonly by many which is probably its strongest argument.
Is there any example Gerrit website (where a project is being hosted on Gerrit) you could link? I’m interested in checking it out.
Sure, I’m involved in the LibreOffice project and we use Gerrit for code review: https://gerrit.libreoffice.org/q/project:core
We have misc other tooling around repositories, involving gitiles (repository browser) and cgit
Another example is TVL, where depot uses gerrit for code review: https://cl.tvl.fyi/q/path:%255Etvix.*
And sourcegraph as a repository browser: README.md - depot - Sourcegraph
Gerrit is very focused on code review, you won’t find lots of features like repository browsing in the core, but you can extend it with other tools
2 Likes
I agree with @toastal that using GitHub as a forge would be a huge step in the wrong direction given the ambitions of this project. Generally, I am a strong proponent for free software to run on free (as in freedom) infrastructure, so GitHub would be a serious red flag for me.
With regards to forgejo / Codeberg: Codeberg is a general purpose forge hosted on forgejo. Self-Hosting forgejo would allow us to make educated decisions how to store data as it’s largely a copy of the same thing (eg. deduplicated file systems). If we can make improvements to forgejo in the process, so much the better. I believe hosting a seriously large project on a forgejo instance will only improve things for the FOSS community as a whole, so win-win-win.
I also want to address two assumptions made here.
-
The amount of caused by nixpkgs contributions is too much for forgejo to handle.
That may of course be the case at the moment, I can’t dispute that. It is, however, very unlikely that we will be at the point where we have to handle that load, if ever. We are starting out small, our infrastructure can grow with the problems. We don’t have to start out planet-scale. -
We can migrate later
Thats a promise that is rarely fulfilled. Once people start getting productive, they built tools and processes around the infrastructure they have. One reason nixpkgs will never migrate of Github is because it has entrenched itself fully into the platform, with tools like ofBorg that are crucial to keep the maintenance going being completely tied to how Github functions.
And lets not forget, the other direction is also true: We can always migrate from Forgejo to Github, the main difference being that with Forgejo, we are actually guaranteed to get all our data back out again. With Github, we are betting on the whims of a proprietary entity with a well known history of locking you into their products.
3 Likes
My favorite pithy quote to around your first point:
Choosing proprietary tools and services for your free software project ultimately sends a message to downstream developers and users of your project that freedom of all users—developers included—is not a priority.
– Matt Lee, Opinion: GitHub vs GitLab | Linux Journal
2 Likes
Things would be easier if there were suitable free forges. But GitLab is open core, Gitea and Forgejo would crumble if they needed to host Aux, just from the size alone: every fork on Gitea/Forgejo is a copy of at the original repo with at best the full history of the main branch. The size of the current nixpkgs repo appears to be around 4Gb (see later), and has 12400 forks. If we only had half of the size of the repo, and a hundredth of forks, that’d still be ~248Gb. Not exactly unsustainable, but it grows very fast.
And that’s just the size. There are so many other ways both Gitea and Forgejo would crumble under the load. I would love to say otherwise, because as a Forgejo contributor, I obviously want it to succeed. But it’s simply not at a stage where it would be able to support a project of Aux’s size.
nixpkgs repo size
❯ expr $(curl -s https://api.github.com/repos/nixos/nixpkgs | jq .size) / 1024
4025
4 Likes