GeezerVison

Ilya (@iSazonov) PipelineMaxStackSizeMB is a regular powershell setting in Windows PowerShell. You are treating it as a policy setting instead of a regular setting in powershell core. I disagree with that. I think it should be a regular setting just like executionpolicy or ConsolePrompting.

Dongbo Wang (@daxian-dbw) What is "policy" in the context?

Software\Policies\Microsoft\PowerShellCore - I believe it is "policy"?

Software\Microsoft\PowerShell\1\ShellIds or
Software\PowerShellCore - I believe it is "regular settings"? Do you say that we shouldn't use Registry for this settings and keep its only in a config file?

What is "policy" in the context?

It's short for "Group Policy Settings". Those are the settings that are originally under "Software\Policies". Each of the settings has a corresponding GPO in "Local Group Policy Editor" in Control Panel. The new PowerShell Core ones will also be available in the editor. We will publish a .admx file for them.

The settings that are not originally under "Software\Policies" are regular powershell settings. As far as I understand, we don't use Registry for those settings but only refer to the config file.

Thanks for clarify!

As far as I understand, we don't use Registry for those settings but only refer to the config file.

Is this PowerShell MSFT team solution? And why?

Registry is common place for Windows applications to store settings:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724871(v=vs.85).aspx
https://msdn.microsoft.com/en-us/library/ms973902.aspx

This is critical for enterprises. By using GPO/GPP, they can centrally manage (distribute polices and settings too) applications on workstations and server farms.
For example, if they receive feedback from employees that their scripts fail because of a stack overflow, the enterprise administrator can easily propagate the parameter value as a default that does not overlap local settings at the application or user level.

For PSCore6, we want to have configuration not in the registry. This makes it easier to deploy via zip, for example, as well as support side-by-side more simply. I do agree that for an enterprise, we should support GPO. In which case, there is no issue with having both configuration and policy.

This makes it easier to deploy via zip, for example, as well as support side-by-side more simply.

The ability to have settings in the registry does not conflict with zip and side-by-side. (We could even enhance our API to support applications by type and name)

Steve Lee (@SteveL-MSFT) What your conclusion about #5947? - I'd move it in RFC repo but it's frozen. I would have moved RFC repo here with label like RFC-* - so we get more feedback.

I created PowerShell/PowerShell-RFC#111.

Should we wait the RFC?

@PowerShell/powershell-committee reviewed this and don't believe that the stack size should even be a configurable setting until there is a clear need to make it settable. Recommendation is to not even have it settable despite what Windows PowerShell did.

Steve Lee (@SteveL-MSFT) Stack size default is different on different platforms - should we set the same default internally to get predictable behavior on all platforms? I think it make sense - see the original Issue.

Ilya (@iSazonov) yes, @PowerShell/powershell-committee agrees to changing the default on all systems. We thought the only point that needed discussion from the committee was configuration.

A new PR was submitted based on the committee's review: #6224
I will close this PR.