[Nix-dev] [***SPAM***] Re: Improving the Developer Experience in the Nix Community

[Michael Raskin]

>>> Well, it was just an example. My point was merely that it's not enough to point out a problem, whenever possible you should point out solutions and be willing to do the legwork necessary to implement them.
>> The real problem is that for many things it does look like the problem
>> is in value clash. There are people who want less lost patches and more
>> committing whatever is not too disruptive and there are people who want
>> more review, but they are objectively overloaded and so sometimes lose
>> patches and, seemingly, consider rate of loss unfortunate but 
>> acceptable.
>You're talking a lot about value clash here. That's why I opened this thread, because we have people with different values but no one is really coming out and saying "this is what I want, this is why what's here now is bad". It's possible that when all is said and done there's no decision we can come to that will satisfy all parties, but we can't know until we know what the parties actually want. Please, if you have a vision for what the nix projects could be but aren't, share it. Otherwise it's highly unlikely that the nix you want to be will come into existence.

Well, I admire nix-the-packaging model. 

There are some things that I consider good with various evaluations
in the community (some of them towards the end I never formulated 
before - but now that I think of them...):

- There is a reasonable public place where I can see every package 
expression used by any committer. So, if someone uses a git-head version
of kernel, it would be nice to see what overrides were needed.

- There is a reasonable way for partial overrides of packages. That way
when I look at a private overrided package I can see what the changes 
relative to trunk are. Better yet if the changes are semantically 
separated (where applicable). Currently it is partially enough - 
changing preBuild usually means copying and editing. 

- There is a way to add support for marginal improvements to the default
builder without full rebuild (why would we want to need stdenv-updates
just to add xz support?)

- The big packages used by many people are regularly and succesfully 
built in a centralized way

- On the level of Nix as a package manager, there is a way to roll back
everything but GC

- There is a simple way to declare something an acceptable substitute of
something else.

- There is a simple way to derive a version of package with dependency
versions changed (for use with subsituters, mainly)

- There is a way to replace subsituted package with a "better" 
substitution or native build

I do not expect that any of them are widely shared (except existence of
LibreOffice packages and rollback possibility, I hope), but as starting
points..

Also, 

I value fast addition of new packages/new package versions above rarity
of local breakages in the fastest-moving branch. I separately value not
turning contributors away above avoidance of short glitches.

I think that having a partially-incompatible previous version (unless 
there is a security issue) and a few bleeding-edge snapshots in addition
to the default release in the main package set is more often beneficial 
than harmful.