> In the Linux kernel development process, the only official tree is Linus' > kernel tree. Linus only works with a small group of people each maintaining > a subsystem of the kernel, such as the memory manager, I/O scheduler etc. > These subsystem maintainers have their own tree (which they regularly merge > with Linus' tree) and they have other people that they work with. This > organisational structure is what Linus calls "a network of trust". This > development model makes sense for Linux. >
US Military and the civilian Incident Command System call this "Span of control": One person can do no more than five things well. So, the one person in charge divides responsibilities to 5 or less subordinates. This goes on down the line until actual work transpires. As you say, the use of a DVCS is merely a technical device to facilitate the hierarchical organizational structure. > > For Nixpkgs/NixOS and other Nix subprojects, we haven't really properly > thought about such a development model and I have never heard any concrete > suggestions what we should do and what we shouldn't do. > > I can lay no claim to long history with this project, I can only tell you what features distinguish it from other efforts in my mind, and how I hope to be able to use it one day. At your core is "Nix". Nix's primary feature is that it manages software installations and software consistency for many masters: system admins as well as users. If you get any larger than a single-person company, these two masters are commonly at odds. What I hope for is that Nix/NixOS inspires an enterprise software deployment model where end users (such as myself) can package and install software specific to my needs, while leaving the security and network configuration to the CIO. And of course, the big benefit is the common pool of packaged software called "The Distribution". Everyone should benefit from the distribution. But there should also be a feedback loop to capture new packages and common configurations developed by those who use the distribution; and there should be a plan for handling variations on a theme. This should be scale invariant, like a fractal pattern: the same processes which allow competing end-users within a single organization to coexist should also allow competing organizations to coexist "within" a single distribution. So the question in my mind is not: "How does the community come to agreement on the One True Way to which everyone must adhere?" The question is more: "What organizational structure retains flexibility for subcommunities having differing interests while maximizing the common benefit?" This is compatible with the original Nix philosophy of allowing "variants" to coexist side by side. Switching to a DVCS is definitely a step in the right direction, but it's just a tool, and can't resolve the human disputes. Other tools may need to evolve which make some of the human disputes moot. Management and integration of "small forks", may require that Nix expressions start to understand URLs instead of just paths. And end users may want to pick and choose packages from multiple small forks, because they don't totally agree with the decisions made by any individual project. It seems to me that Nix, Hydra, and the proper application of channels should be able to minimize the amount of end-user compiling required to install a truly custom hybrid system. Seen from this perspective, the "nixpkgs/nixos" repositories are rather monolithic: You'd have to manually assemble a complete Nix expression in a directory on your system, composed of "some" free-nix expressions and "some" NixOS expressions. Then you'd have to manually merge in changes as time goes on. Is there a better way to modularize Nix expressions into libraries, such that assembling a complete expression could be automate-able? Maybe instead of a static "composition", do the composition with a Nix-compiler? (a Nix-linker?) I think NixOS and/or free-nix should both allow for a new reality: the end-user's computer may not be installed from a single upstream source of expressions. Modular things, allowing for coexisting variants, make for harmony. Monolithic things make people compete so that they're not the ones who get left out. Anyway, that's what I see Nix's potential to be. Bryce Bryce
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
