Hello all, On Mon, Oct 03, 2011 at 01:41:50AM +0400, Michael Raskin wrote: > > > Since stdenv updates are infrequent, we’d rather not do it “just” for > > > Bash. Instead we usually bundle a list of stdenv package upgrades > > > (libc, GCC, Coreutils, etc.), hence the branch name. :-) > > > >I am sorry if I happen to be dull, but I have difficulties understanding > >your message, because I don't know who you refer to as "we". You are > >speaking for yourself, I suppose? If you are not, then who are you > >speaking for? > > It is percieved as established practice in the project. I agree > with Ludo's statement and has stated this explicitly quite > recently which makes "we" technically correct, but that's not the > point.
I also agree with what ludo and Michael states, so I feel a bit part of the 'we'. > Merge has significant one-time build overhead, so it doesn't > occur without near-consensus. Ludo stated some conditions for > merge. So, until he either finishes ensuring that these > conditions are met or explicitly gives up, merging stdenv-updates > branch is a bad idea. Some people using nix would not mind a stdenv-updates merge into trunk: in the sense that they will accept a full rebuild soon. Not that they accept the current state of stdenv-updates. That acceptance of a new stdenv, at least for me, comes with two conditions: I don't want a second stdenv update soon. So this next update coming should be tested enough, and bringing enough new packages. I think now it's a matter of getting a common consensus of "update stdenv-updates stdenv packages to the versions we want now, freeze them, and start stabilising the full branch for a merge to trunk soon". I'm for it. Anyone waiting for a new release of something, or against a stdenv merge? (I see ludo updated a battery of packages today, I hope that puts stdenv to the newest code released) Regards, Lluís _______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
