On Friday, June 29, 2012 at 1:22 PM, Daniel Pittman wrote:
Pieter is absolutely right that reporting errors on the output channel
is a bad habit in Puppet - it makes us wildly different to the Unix
standard. Every normal application behaves the way we do now - errors
to stderr - and if the
On Thu, Jun 28, 2012 at 8:00 PM, Daniel Pittman dan...@puppetlabs.com wrote:
Do you think the message, check STDERR in each of the node,
node_aws, and node_vmware subcommands is adequate?
No, mentioning STDERR is terrible UX, even if I know what it means. :)
I think a better approach would
On Thu, Jun 28, 2012 at 8:00 PM, Daniel Pittman dan...@puppetlabs.com wrote:
No, mentioning STDERR is terrible UX, even if I know what it means. :)
I think a better approach would be to capture the error and report it
meaningfully.
The mockup does that, albeit before the rest of help output.
On Fri, Jun 29, 2012 at 9:11 AM, Randall Hansen rand...@puppetlabs.com wrote:
On Thu, Jun 28, 2012 at 8:00 PM, Daniel Pittman dan...@puppetlabs.com wrote:
No, mentioning STDERR is terrible UX, even if I know what it means. :)
I think a better approach would be to capture the error and report
On Fri, Jun 29, 2012 at 10:22 AM, Daniel Pittman dan...@puppetlabs.com wrote:
So, perhaps the title of that should change from available
subcommands to all subcommands or something?
That was the key part that, to me, was worth making that change - that
these were absolutely *not* available,
Hello,
We're trying to come up with a nice way to indicate when a Puppet
module like cloud provisioner breaks a Puppet subcommand because of
missing dependencies.
When this happens in the current 3.0rc branch, all help for all
subcommands is unavailable. This isn't very helpful.
We're planning
On Thu, Jun 28, 2012 at 5:37 PM, Jeff McCune j...@puppetlabs.com wrote:
We're trying to come up with a nice way to indicate when a Puppet
module like cloud provisioner breaks a Puppet subcommand because of
missing dependencies.
When this happens in the current 3.0rc branch, all help for all
