<[email protected]> <[email protected]> <[email protected]> <[email protected]> <[email protected]>) Mime-Version: 1.0 Content-type: text/plain; charset="UTF-8"
> > I don't think this accurately reflects the reasons we use > > stdenv-updates. We don't put it all in the same branch because more > > fine-grained branching is expensive, we put it all in the same branch > > because we want the eventual merge of the changes to happen at the > > same time. > >exactly who is "we"? Please speak for yourself. I, for one, do not want >unrelated changes to be merged in one commit, because that habit breaks >extremely useful tools such as "git bisect". One commit and one branch are different things. >Besides, having many different stdenv/* topic branches does not imply >that each of them must be merged into master separately. You *can* merge >them all at once, of course, if you want to. It just so happens that I >wouldn't want to do that because the practice violates elementary >principles software engineering. The problem is that actually merging them one-by-one is costly. Trunk should receive one rebuild. And it is established practice to reduce the count of stdenv rebuilds. Also, there is little happening in NixPkgs that should be classified as software engineering. Everything non-trivial in packaging is about finding out upstream quirks. To run NixOS, I need maximum amount of packages in stdenv-updates to be non-broken. Tracking what is broken where across five topic branches is insanity even without second-guessing what will start working on merge. _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
