[Nix-dev] [Nix-commits] SVN commit: nix - r30127 - innixos/trunk/modules:config installer/cd-dvdinstaller/generations-dir installer/toolsinstaller/tools/nixos-deploy-networkmisc security services/miscservices/monito...

[Shea Levy]

On 10/30/2011 12:03 PM, Michael Raskin wrote:
>> On 10/30/2011 11:46 AM, Michael Raskin wrote:
>>>> On 10/30/2011 11:19 AM, Peter Simons wrote:
>>>>> Author: simons
>>>>> Date: Sun Oct 30 15:19:58 2011
>>>>> New Revision: 30127
>>>>> URL: https://nixos.org/websvn/nix/?rev=30127&sc=1
>>>>>
>>>>> Log:
>>>>> Reverting revisions 30103-30106: "always set nixpkgs.config.{state,store}Dir", etc.
>>>>>
>>>>> After the change from revision 30103, nixos-rebuild suddenly consumed
>>>>> freaky amounts of memory. I had to abort the process after it had
>>>>> allocated well in excess of 30GB(!) of RAM. I'm not sure what is causing
>>>>> this behavior, but undoing that assignment fixes the problem. The other
>>>>> two commits needed to be revoked, too, because they depend on 30103.
>>>>>
>>>> Hi Peter,
>>>>
>>>> In the future, can you please bring up an issue like this on the mailing
>>>> list before just reverting another developer's work? I'm more than happy
>>>> to work with you to get that problem resolved while getting what I need,
>>>> but straight up removing my work without even giving me a chance to fix
>>>> it is inappropriate.
>>>>
>>>> Thanks,
>>>> Shea
>>> "Eat 30GB" seems close enough to "broken".. Given that the earlier
>>> revisions are trivially accessible, reverting revisions that break
>>> trunk usability seems a reasonable thing.
>>>
>> I agree, but it's not obvious that the problem is due to a bug in my
>> work, and no one else has seen this problem (and I've used this code on
>> my tiny netbook with 4 g total ram+swap), so at least some confirmation
>> that others see this issue would be nice.
> To both Peter and Shea: was the build performed as root? Was it
> performed via nixos-rebuild? Was NIX_REMOTE set?
>

First built a livecd with nix-build as non-root with NIX_REMOTE unset, 
then within a VM built a system with nixos-install.

>>> It seems that for most people the evaluation result doesn't change,
>>> so unlike stdenv-updates branch, a branch for these changes would be
>>> cheap to merge.
>>>
>> True, but as you said things shouldn't change for anyone else and I'm
>> testing on my machine and not seeing these problems, so how should I
>> determine when the branch is ready to merge? Each stage of changes is in
>> and of itself useful to me, it's not like only the end result will be,
>> and with these changes I can already install my system. Future changes
>> will be added as I find problems, so I could be out of sync with trunk
>> indefinitely.
> Merging from trunk is often a good idea.
>
> After a merge from trunk, it could be a good idea to ping the latest
> complainers with a question "Does this work now?"
>
>
>
Ok. I have no problem developing in a branch, I just don't know how I'll 
know "now I'm finished, time to merge into trunk". But this is 
orthogonal to the issue of reverting another developer's work with no 
advance notice or proof of widespread problem.

~Shea