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?


OpenStack-dev mailing list

Reply via email to