On 12/02/2014 04:25 AM, Ben Nemec wrote:
1) A specific reason SHELLOPTS can't be used.
IMO leave this alone as it changes global behaviour at a low-level and that is a vector for unintended side-effects. Some thoughts: - We don't want tracing output of various well-known scripts that might run from /bin. - SHELLOPTS is read-only, so you have to "set -x; export SHELLOPTS" which means to turn it on for children you have to start tracing yourself. It's unintuitive and a bit weird. - Following from that, "DIB_DEBUG_TRACE=n disk-image-create" is the same as "disk-image-create -x" which is consistent. This can be useful for CI wrappers - pretty sure SHELLOPTS doesn't survive sudo, which might add another layer of complication for users - A known env variable can be usefully overloaded to signal to scripts not in bash rather than parsing SHELLOPTS
I'm all for improving in this area, but before we make an intrusive change with an ongoing cost that won't work with anything not explicitly enabled for it, I want to make sure it's the right thing to do. As yet I'm not convinced.
For "ongoing cost" -- I've rebased this about 15 times and there just isn't that much change in practice. In reality everyone copy-pastes another script to get started, so at least they'll copy-paste something consistent. That and dib-lint barfs if they don't. This makes "disk-image-create -x" do something actually useful by standardising the inconsistent existing defacto headers in all files. How is this *worse* than the status quo? -i _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
