>>> 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. _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
