Does the NixOS project have any interest in moving? If so, to where?
As far as I know there isn’t much better than github right now. (I’m
still waiting for federated PRs before picking a git server,
personally). All other systems either have no developer community, or
isn’t much better than github (hear: gitlab).
However, I think there may be a point in moving the bug tracker:
it’s the part that’s most at risk (all the rest of the work done could
very easily be recovered by anyone’s git repository, so this is not an
issue), and anyways there were already issues with github’s bug tracker
(impossible to give people rights only on the bug tracker without making
them committer, etc.).
That said, I don’t know of a usable bug tracking system (hear: with as
much bling bling as github does) with the requested features and that
could be very easily used with a github account (because I think
requiring everyone to create an account on the bug tracker just for
posting an issue would be a big usability issue). If you know one maybe
a move could be imagined?
I’m not really aware of anything particularly fancy, I’m afraid. I’m looking into moving my own repositories onto a self-hosted GitLab instance.
Self-hosted GitLab (or gitea, or anything else) instances have a huge
drawback: they require all contributors, from the issue reporter to the
contributor, to have an account on it.
So I don’t think that’s viable for NixOS. Well, until a federation
system exists where we can say “you got a choice between making an
account here or using an account on one of your servers or any other
federated server”, but that’s not coming yet, though I’m seeing much
more movement in this domain since the purchase was announced.
The reason why I have hopes for a bugtracker is because, sure, it’d make
the part of “getting us independent of GitHub” done (migrating a git
repo is basically free if anything goes wrong), but mostly because it’d
bridge a gap that’s already felt in the way people contribute (having
non-committers tag PRs, etc.). Oh, and because I have higher hopes for a
bugtracker properly implementing remote accounts than I have for a git
webui.
For instance, MantisBT looks like pretty featureful (including OAuth and
even “anonymous login”), but… it looks bad. Missing the required bling
bling of nowadays’ web.
So I’m not sure there is a good solution right now, unfortunately… That
said hopefully others would have more clues?
1 Like
It’s not true federation, but it looks like GitLab supports OAuth, so you could allow people to log in with their Google/FB/GitHub/BitBucket/GitLab.com accounts.
2 Likes
The GitLab folks seem to have a lot of interest in improving federation in the future:
1 Like
Whats the fuss? What has changed for nix with that purchase?
7 Likes
Hello,
sorry for the intrusion but… Does really Nix{,OS} development
need such services? I mean historic BIG projects like Linux, Emacs,
Gcc, … are developed, even today, simply via mail, of course with
good MUAs their devs know well how to use them, well integrated in
SCM (like what we can get with Emacs+notmuch+magit, (Neo)Vim etc).
Some of them have also WebUI but all the project run around a
mailing-list. There is a nice LWN article on that “classic” model:
NixOS already have a very nice experiment (1) of a decentralized
distro model, ZeroNet for websites is also another limited option.
We do not have anything that can work-out-of-the-box but distributed
or at least decentralized solution have enough developed to draw a
possible evolution path and GitHub&c does not change tomorrow.
IMVHO in 2018 it’s time to think about going distributed simply
because in the past universities play a role in FOSS community,
have resources and so offer hosting, mirror services etc for free
many big companies do the same but that’s not true today. Choose
“another GitHub” does not solve anything, simply temporary patch
a potential problem and communities have not enough resources to
afford classic “client-server” model.
Sorry for my poor English
(1)
https://sourcediver.org/blog/2017/01/18/distributing-nixos-with-ipfs-part-1/
NixIPFS · GitHub
– Ingmar
2 Likes
Looks like the current NixOS Gitlab module is somewhat broken, sadly. After #41495 it will at least run, but services that require Gitaly (such as creating a repository) are still broken.
GitHub is now owned by a company that directly competes with NixOS (Windows, Windows Server), and has previously shown itself to be ridiculously hostile to both the FOSS community (SCO lawsuit, Halloween documents, “Linux is a cancer”, Secure Boot (especially for ARM devices), etc) and their users (Windows 10 telemetry, forced updates, Office switching to a subscription model, etc).
You still need some form of client-server model, both for hosting the mailing lists and as a place for users to download the repository from.
1 Like
Because it’s hard to move the non-git-repository parts of our GitHub presence, the pain of switching to another service is probably about equal to the maximum pain Microsoft could inflict on us. Is there something worse you are imagining they can do than to suddenly delete all our issues, PRs, etc?
I have a theory that nixpkgs helps GitHub as a real-world stress test.
1 Like
Yes, there is worse: deleting all the issues, PRs, etc. without us
having time to backup / migrate them first.
Currently, I seem to remember there is an API for extracting all this
data from GitHub. Migrating exactly the issues / PRs onto another more
controlled system (what I’m proposing) would mean that this last part of
the project that is “in the hands of GitHub thus Microsoft” would be safe.
That said I’m also proposing this as issues were already noted with the
GitHub issue tracker, otherwise I don’t think it’d be worth it.
1 Like
Hello,
You still need some form of client-server model, both for hosting
the mailing lists and as a place for users to download the
repository from.
True, but migrating a ml is relatively easy, loosing nothing;
migrate from a proprietary platform to another maybe not as
easy and some information maybe lost… To be more specific
actual GitHub alternatives are relatively few, actual ml vendor
are many, scattered around the world, with an enormous set
of offers.
I do not say anything can be moved to a distributed solution
right now, but some thing can be moved, some other can be
moved form “proprietary” solution to open and standard ones,
some other can be studied with attention.
If Plan9, at it’s time, was able to design a, reasonably working,
thing we can’t have with today’s tech… Well something is surely
wrong IMVHO and it’s time to rethink evolution.
– Ingmar
GitLab’s import-from-GitHub feature seems to migrate everything (git, issues, PRs) in one go, linking everything to the corresponding GitLab accounts if they have one.
Additional discussion here Move from GitHub long-term · Issue #41448 · NixOS/nixpkgs · GitHub
1 Like
The biggest problem we have with GitHub right now is not Microsoft, it’s the lack of mapping between a package and it’s maintainer(s).
Let’s say that I am the maintainer of the direnv package, I won’t automatically get notified if a new issue is opened for that package. Even if I am notified, I can’t merge changes unless I am given write access to the whole of nixpkgs. If the package is out of date, there is no great way for me to track this. All the other serious distros have a solution for this.
For example ArchLinux maintains a “core” repository for the base distro and then has individual repos in AUR for all the extra packages. As a package maintainer I am given my own git repo where users can post issues to it.
Debian has a repository with issue tracker for each package. Canoncial built their own solution as well.
@peti gave a great talk last NixCon on OpenSuse and how they handle the packaging problem. Each maintainer has their own project where they can issue builds against different releases. OBS seems like a great self-service platform.
While looking for a GitHub replacement I would really like us to consider these and maybe look at other package repositories to see how they are doing. Most likely this would require us to change how nixpkgs is being composed.
4 Likes
Indeed, that’s my biggest gripe with nixpkgs atm. I don’t think it can be maintained efficiently as a single monolithic repository on GitHub anymore.
I’m against moving nixpkgs itself from GitHub unless there’s actually an issue with MS, since that’d take a rather huge amount of effort until all the integrations and tooling and links catch up, and we don’t have that much time to spare.
But with the advent of cachix, maybe we could finally start a community repo, slowly migrating our apps out of nixpkgs into individual control?
What would change is that you basically have an additional mirror and channel entry in your config, and the community repos can reference specific snapshots of nixpkgs as base.
Where things get weird is referencing other dependencies from the community repos, which i’m not sure is possible without I(mport)F(rom)D(erivation). But I think a lot of projects would benefit from more relaxed rules immensely, so that could be a good thing.
2 Likes
I’m not suggesting GitHub is a perfect fit for nixpkgs (I would prefer GitLab, but that doesn’t really address your points), but I don’t entirely agree with all your arguments either.
Let’s say that I am the maintainer of the direnv package, I won’t automatically get notified if a new issue is opened for that package.
Couldn’t that be easily fixed by a bot now that meta.maintainers contains GitHub usernames and package names are supposed to be in the commit messages anyways?
Even if I am notified, I can’t merge changes unless I am given write access to the whole of nixpkgs.
I think that can be viewed as a feature. While unfortunately parts of nixpkgs are not up to the standards of the official repositories of some big distros, the quality/level of trust is still higher than in the AUR.
That is because changes have to go through the PR process (except those of maintainers, but if I understand correctly that is supposed to change).
If the package is out of date, there is no great way for me to track this.
What do you mean by that? Like an outdated flag on the AUR? Why not just create an issue?
As opposed to the AUR, you could even fix it yourself and submit a PR. Thats another advantage of the current system: packages are much more community maintained and not really “owned” by a single maintainer.
1 Like
While looking for a GitHub replacement I would really like us to consider these and maybe look at other package repositories to see how they are doing. Most likely this would require us to change how nixpkgs is being composed.
Not only package repositories — Rust has bors as a bot.
A benefit of an open source solution — even if we use a hosted version —
would be that it is possible to make integration tests for bots that
merge in the name of a user, and if we have a bot that we can test
end-to-end it can be much less scary to hack on it… Especially for
newcomers to the bot development.
(there if ofborg, and there are people who are currently working on the
mock environment for testing it, and if that environment could include
a real copy of the target repository, that would be nice indeed)
This doesn’t work for issue submission since the user is not forced to select the affected package. But I agree that a bot like ofborg could be added some more heuristics to try and map issues back to maintainers. That would tie us even further to github though.
That would tie us even further to ofborg, not really to GitHub.
My last reading of ofborg code was that it had a specific GitHub comment
parser and comment writer, so that would be the only piece of code that
would need to be rewritten would be these two elements. And it turns out
crates.io appears to have a crate for GitLab as well as the one for
GitHub that is currently used, so even though the migration would likely
not be obvious, it should still be possible and not as bad as rewriting
things from scratch.