Agreed, from a certain size on it doesn’t matter how you store the repo any complete sync will take forever…
1 Like
Before we claim a consensus, maybe we should have a little vote? Nothing official, just a show of hands or a quick poll to see where everyone truly stands 
3 Likes
@noughtypixel sounds good, shall we do options as discussed (GitHub, Gerrit, any more options let me know…) or more of an “in a perfect world where the software worked, would you leave GitHub?”
1 Like
I guess GitLab is also an option
Maybe it’s also worth commenting this: Monorepos don't map to our social structure - Development - NixOS Discourse
I don’t know enough to argue for or against each model tho.
The same argument is often used for using Discord and in my opinion, creates a never ending circular problem (I forgot the name of the exact term 
).
A bit like “nobody makes game because there’s not enough users” and “many people aren’t willing to make Linux their main os because of the lack of games”. (it’s a bit better now with Valve but you get my point). Same thing with vr games.
I can understand that it might be a kiss of death to choose something that people are reluctant to use, especially if it’s already hard to find people.
At the same time, I also tend to think that if we don’t make the switch at the start, we will never do it. soft-locking ourselves in,
Finally, why not listen to the great philosopher who said “don’t let dreams be dreams […] just do it”.
5 Likes
and like others, I wonder if forge federations will change everything.
1 Like
In my view the best course of action is:
- Fork Nix on the same forge (GitHub) today
- Build the foundation of Aux, working through the roadmap
- Once sustainable, transition to a self-hosted forge
We get going quickly and existing nixpkgs maintainers are able to switch over immediately. The low friction to start is probably important in order to gain escape velocity. Then, once we’ve gotten Aux to the place described in the roadmap, we can mirror other foss communities that have self-hosted their infrastructure.
11 Likes
Agreed, other things worth focusing on while Aux is bootstrapping.
Some problems get harder over time, but I don’t think this is one of them. * With one exception; I think Aux should actively avoid dependency: no reliance on github actions, webhooks, or any other github specific features.
4 Likes
That might be nice. When I was looking to set up a ci at work for my nix projects, I would have liked that there were more examples not using github actions.
1 Like
Also, if we go with a mono&distributed system, then the packages can be hosted on whatever. It will be more so a decision of what to host the monorepo and core on.
I may be okay with some intermediate, necessary actions happening so long as it is understood that they will need to be scrapped and replaced with another CI system that we control in the future.
For sure, and to be clear I think using those features is fine. Its depending exclusively on them is the danger.
Like flakehub did this a bit with github actions; it would’ve been fixed if there was a guide for running the publish action locally/manually.
1 Like
I’m torn, because this seems like an executive decision which kind of to me seems against the ethos of Aux, but I think its one I agree with. If we decide now, with the limited userbase, it might not be representative of the future userbase. If we get the ball rolling and then ask, we could get something better. I do think that getting started is the best thing to do. I vote for soft forking ASAP on github and adding something to the top of all the READMEs in the root dirs of each about this.
2 Likes
Yeah part of the difficulty here is that our long-term goals are around established, elected governing bodies with delegated authority. Right now we don’t have those (as was mentioned in the roadmap) and decisions have to be made. I want to gather as much input from people on these foundational questions, but at the end of the day someone needs to decide and take action. In the future that will be the role of governing bodies (eg. Steering Committee). For now we may have to bear with the less-than-ideal situation of discussion followed by a possibly less-than-ideal decision.
I’ve mentioned this before, but this is the reason that I posted the values, goals, and roadmap. In doing so I wanted to avoid any unnecessary wheel spinning or arguing about things that didn’t get us to a place where we have solved the problems we experienced in the Nix ecosystem. Getting there is going to take some time and especially at the beginning while things are bootstrapped we are going to have to make do with what we have.
3 Likes
I don’t like the executive decisions either, but I do think theres going to need to be some until the steering committee is formed and governance established. Which kind of requires getting basic infrastructure running.
IMO: “Can it be fixed later?”
- If yes (no extra difficulty) we just need to accept executive decisions, get it working and move on
- If yes, but with much difficulty (mid level foundation stuff) then we should debate it heavily but not let it block the project.
- If no (basically set in stone) we should debate fiercely on it, block on it, and push back on executive decisions
Git makes it easy to switch where the data is stored, and even keeping two sources in sync/mirrored. Even with CI, thanks to containers, its decently easy to switch from one CI to another. We just need to avoid depending on github in a way were it snowballs into a big problem later.
Who is on the steering committee, how the packages are done (distributed or centralized), what the project will be named, those things, if done wrong, are nearly impossible to change/fix later. And I think its right to call out executive decisions there.
4 Likes
Yeah, for some topics there is a healthy amount of discussion to be had. The name, for example, has some caveats as it currently exists. Overall, though, I think we’re moving in a positive direction.
1 Like
Excuse me for being blunt here, but that is just incredibly naive. Gitea has been trying for years to rid themselves of Github and become self hosted, and they are building a forge. Claiming that “Git makes it easy to switch code hosting” is only true if everything a forge is about is just the code. In case of Github (or any proprietary service, really), it’s fighting yourself out of a walled guarden, hoping that you’ll actually be able to if the time comes.
3 Likes
I think Codeberg and Forgejo serve to counter that argument, being entirely self-hosted including for development.
5 Likes
They do, but only by burning all the bridge, treating Gitea as a hostile fork.