I wonder if there was any (tentative) roadmap for the future of nix/nixos available somewhere ?
For nixpkgs there is
Not so much for nix:
Mostly I am interested in nix future (I get that for nixpkgs, there is a focus on cross compilation right now, the rest depends on PRs), as this is my biggest pain point. I feel like the whole channel management/NIX_PATH/setting the root expression (sometimes it’s -f, sometimes -I nixpkgs=…, some other times it’s a positional argument) is kind of a mess. Nix 2 has laid the fundations but there is still much space for improvement so I am curious about the different priorities for 18.09/19.03 etc.
Having some kind of roadmap might help contributors choose issues they want to tacke.
The current practice seems the other way around: the development is driven by individuals with their own priorities, i.e. it’s mainly about people working on changes that those individuals chose.
I could state some “project-wide priorities” for 18.09, for example, but I’m not convinced that would do much difference beyond what changes I can manage to make myself.
Hmm, I think it might be useful to state project-wide priorities
(preferentially changing at each release): it would help people who want
to help but don’t know what to do find ideas.
Then, it may not be worth the time spent devising these priorities,
depending on how many people are actually in this situation.
@vcunat I agree for the nixpkgs part but the nix component is written by a much smaller community that must have some idea for the future. Bascially I am curious as to when I can recommand nixos to friends without having them to hack around the twisted specifics of the UI.
To be clear, I don’t mean the roadmap as a mandatory bullet list to complete. Hell it’s opensource it must remain fun ! I just meant it as a tentative roadmap, like it would be nice to push this first if any good will is around.
There’s a milestone for every release in our github repo, though this mechanism isn’t too much used so far. In any case, if you (anyone) want to help, let me post a few suggestions;
Hydra failures. We try especially when stabilizing a release, but it’s best to maintain such continuously. Especially platforms than x86_64-linux still have relatively lots of these, but I don’t expect anyone to expend much effort for platforms (s)he doesn’t otherwise use. 18.03 ZHF: 18.03 Zero Hydra Failures (generic + x86_64-linux) · Issue #36453 · NixOS/nixpkgs · GitHub
aarch64-linux in particular – we officially stated we would like better support since 18.03, but so far it’s only happened partially. Apparently it didn’t catch enough interest.
staging branch. Mass rebuilds also pose a risk of mass breakage, and that occasionally happens. In the last months our staging branch has been in a bad shape (under-maintained, most likely), which slows down integration of such changes, perhaps including security mass-rebuild fixes. It needs someone to do something about the breakages (triage, test, fix or revert).
maintain package(s). I believe we should shift maintenance of most packages to people that don’t maintain hundred(s) of them. If you actively use some package(s) in nixpkgs, consider getting into meta.maintainers and giving them some love, especially if there’s noone there or someone who doesn’t have much time for it.
Regarding nixpkgs, I think that the current release managers should have a say over one or two big features that they would like to see happening in the next release. This would help us align behind a few major goals at each release, and also give something back to the release managers for all their work.
This is a great idea! I really like this approach of setting personal milestones, it’s very much in line with the current development practices.
At the start of a new release, all the contributors could say what their personal goals are, let’s say on a new Discourse Thread. This would help broadcast interest and help others help on those goals.
Then at release, include the results of each project in the release notes. This is a great way to celebrate contribution and is also good PR.
@vcunat thanks for mentioning the staging problems. It’s not sthg I had in mind since this process is a bit more underground.
As for maintainers, it does seem limiting that either you give full control over the distribution or nothing. Surely there are solutions for more granularity. (per-file rights, github bots).
Apart from the nix UI problems, one other thing that is of interest to many (I think) in the community is an integration path to nixups/home-manager. I sometimes want to contribute to either project but feels like it would end up wasted when merged. There are some nice home-manager modules that nixpkgs users would want to use and vice-versa. Seems like duplicated work could be removed if one could set paths in nixpkgs modules (like generate the .vimrc in $HOME instead of /etc)
Maintainership doesn’t need to mean push/write access. And I’ve never heard of someone misusing the rights (roughly a hundred people has push access in the past few years).
It’s not fun maintaining a package if you can’t push updates yourself. There have been legitimate complaints of stalling PRs which IMO can only be solved by having more people with push rights.
Having a hundred persons being able to push seems like a security problem. Even if you trust people not to be malicious, they can lose their laptop, use different standards of security etc. Some kind of limited push rights would alleviate the very trustworthy core people to spend more time on the bigger picture.