So an unfinshed PR counts as “in upstream” now? Its sat there for like 8 months. It is in draft.
We can have different definitions, but this doesn’t cut it to me.
6 Likes
Okay, and how did that happen?
Is Eelco the only person with a commit bit? If he isn’t, then why hasn’t anybody else carried the torch? If he is, then why would you expect him to be excited about helping a project whose community has not been kind to him?
Open core, as I’ve seen it, usually does have proper black-box components that source is not available for. This feature does not appear to be that.
5 Likes
you say this as if its a one-way street, and you know, it isn’t.
3 Likes
Because Eelco, who raised the PR, also marked it as a draft and it is therefore unmergeable, yet it’s somehow ready for DetNix
4 Likes
Okay, I get there’s a lot of learned helplessness here.
It sounds like the problem for the moment is that the parallel-eval stuff is in a draft PR whose author isn’t available (for whatever reason). This happens all the time, this isn’t the end of the world.
Is there a faster way to get this moving again other than forking the nix repo, manually applying the patches, and opening a new PR? If not, that’s fine, but this does feel like a relatively easy logjam to clear.
3 Likes
Yet they were available for their employers fork. Sounds like a conflict of interest…
6 Likes
There is no need to be rude.
If the original PR author doesn’t want to continue, then they should close their PR so that it is clear what is happening. I’d consider it rude to grab their stack of patches and apply them without clear intent from the original PR author. We are striving for clear communication and fostering community, aren’t we?
4 Likes
As far as I understand, their fork does not have parallel eval yet either, but they are planning to add it soon. Maybe it will coincide with stabilizing the PR?
I am not sure I follow, isn’t their Nix fork also open source? Doesn’t open core mean that the core of a project is open source, but additional features are proprietary? (It’s totally possible that there are closed features that I missed.)
1 Like
You’ve (1) missed the point and (2) I don’t need a git tutorial.
Again, no need to be rude.
4 Likes
That’s not helpful, don’t be mean–I was referring specifically to a seeming emergent behavior where folks were not using the tools they had on hand because they felt disempowered due to prior conflict. Please don’t add fuel.
Here’s the thing: it may not be possible to resolve it amicably. That’s fine. Adults can exist in a world where other adults they don’t agree with also exist.
Assuming we can’t get everybody to hug it out, the next best thing we can do is address the technical problems and get spun up so that we don’t end up with bottlenecks like this again.
Sure, Eelco was slow to do whatever because of gestures broadly. But, the problems are pretty similar to if he got stuck on a desert island, died, or burned out. For a healthier future, we need to build our toolbox to focus on how to solve around this sort of stuff without continually slashing at each other.
7 Likes
Sure, and building our healthier toolbox starts with… good communication!
EDIT
I don’t think just pulling in their patches is a great solution either, as we’ve already seem quite a bit of community hostile marketing from DetSys, and I don’t think their spin on ccpNix pulling in their fork’s patches would be charitable. That goes hand-in-hand with the other things mentioned above.
4 Likes
The announcement is a good statement of the priority being github:NixOS/nix, at least. Long term, I hope there’s more momentum there and fewer PRs being blocked for various reasons, so another part of the solution is how to continue to improve how smoothly things are running on the Nix team to get more things into core Nix.
One actual suggestion is to adopt more of an optimistic merge approach. We have this in nixpkgs with by-name. The other example listed is pessimistic merging, which seems somewhat familiar:
In the worst case, patches can wait for weeks, or months, to be accepted. Or they are never accepted. Or, they are rejected with various excuses and argumentation.
(…)
[Pessimistic merging] tells new contributors, “guilty until proven innocent,” which is a negative message that creates negative emotions. Contributors who feel unwelcome will always look for alternatives. Driving away contributors is bad. Making slow, quiet enemies is worse.
Some seriously good advice in there, we should consider it. 
21 Likes
I think we can all agree on the potential trademark issue if the SC or board places a trademark policy on “Nix”.
I also think it’s disrespectful to be calling Nix itself CppNix. This is a term coined by the Tvix folks but popularized by the Lix people. Also don’t take this as me hating on the Lix or Tvix people, I know many of them and think their work is to be appreciated. We should all come to agree that no matter who is working with Nix or it’s forks or distributions that what we’re all involved in is a great piece of technology and software which originates from Eelco Dolstra.
Another thing is I can see this hurting future Nix and NixOS adoption if companies and organizations see the fragmentation of the community. We’re at the point where community growth is increasing more every year. We cannot ignore the potential support from companies and organizations. We cannot rely solely on individual contributions.
32 Likes
mod hat on: if you want to get in touch with the moderation team, please contact us : Moderation Team | Nix & NixOS
6 Likes
If we’re concerned about ‘looking bad to companies’ (are we?), then we should perhaps put our effort into directly and proactively addressing the root causes of that problem, rather than trying to do reputation management and give it a new coat of paint.
10 Likes
I think we may be able to pivot this into something constructive. Of course, if it devolves further into “$X should step down” maybe we overestimate the ability of the community to be constructive about this issue.
Could we maintain a subdirectory in NixOS/nix of contributed plugins that just get built with the rest of Nix? Here’s an example of one. If users have trouble developing them due to limited API surface, we should fix that.
Note that this is consistent with the opening keynote of Planet Nix, where Kelsey Hightower recommended making language extension points accessible to contributors. Plugins are a language extension point. We could make them more accessible.
11 Likes
I think we really should be concerned about the appearance of the community outside the community. I can’t count the numerous times I’ve brought Nix up and heard people mentioning the drama. I wouldn’t doubt if we’ve missed sponsors or partnerships because of it.
I agree. However, I see this as an issue that’s currently being solved. The SC and board are full of members with extensive contributions towards Nix.
13 Likes
How so? There’s got to be a way to differentiate Nix the language and Nix the implementation, cppnix is a fine name for the first Nix impl.
How do you plan to solve the confusion between Nix the language vs. Nix the implementation?
14 Likes
I like github:nixos/nix
3 Likes
We could certainly do that. But in this case, the problem isn’t really technical, thus a technical solution is not apt. The fix for social problems is not technical, and no amount of technical wrangling or changes will fix a social problem. Social problems require social solutions, and I hope the SC is working on something to bring resolution, no matter what it is, so we can all move on (or off).
6 Likes