►
From YouTube: 2022-09-13 meeting
Description
cncf-opentelemetry@cncf.io's Personal Meeting Room
A
B
C
A
E
F
F
G
G
So
I've
been
thinking
a
lot
about
the
prometheus.
What
to
do
about
prometheus
name
spacing,
and
I
don't
actually
think
the
solution
we
arrived
at
last
time
is
good.
I
we
got
some
feedback
that
there
are
languages
where
picking
a
prefix
might
not
work
well,
and
I
actually
think
the
best
thing
to
do
here
is
to
first
do
no
harm.
G
G
To
adjust
it
later,
I
wanted
to
maybe
explore
the
option
I've
been
leaning
towards
was
suggested
by
bogdan,
I
think,
which
is
to
take
a
similar
route,
that
prometheus
does
and
make
it
a
convention
to
add
a
prefix
to
your
metric
name
rather
than
try
and
be
too
too
crafty
with
how
we
go
about
it,
and
this
would
basically
mean
that
we
change
naming
style
guides
to
suggest
that
people
use
a
unique
enough
prefix
for
metric
names
and
try
and
make
metric
names
unique,
and
that
would
just
that
would
give
us
the
sort
of
no
conflict
property
that
we're
looking
for,
and
I
think
it
would
likely
benefit
exporters
other
than
prometheus,
which
have
some
expectation
that
metric
names
are
relatively
unique.
G
F
B
But
the
sdk
owner
or
the
application
owner
the
grant
already
has
that
capability
right
now
they
can.
I
mean
we
can
give
them
a
view
configuration
to
to
manipulate
all
the
metrics.
So
it's
not.
I
that's
why?
One
of
the
reasons,
the
thing
that
I
was
asking
david
since
the
beginning
is
who
is
the?
B
C
What
would
happen
if,
regardless
of
everything,
a
clash
still
happens,
then.
B
A
G
F
B
E
E
G
Metrics
logged
in
generally
info
metrics
are
used
for
this
sort
of
case.
So
c
advisor
has
a
container
info
metric,
that's
sort
of
a
within
a
single
endpoint
used
to
provide
something
that
could
be
joined
with
cpu
usage.
To
give
you,
you
know
the
image
hash
or
something
right
so
infometrics
generally
are
used
for
this
purpose.
Target
info
is
just
an
infometric
for
your
target.
E
And
without
introducing
new
attributes,
we
are
basically
unable
to
introduce
a
new
info,
it's
kind
of
what
we're
up
against
here
david.
It
makes
me
wonder
if
we
can
append
something
to
the
instance
attribute
value,
for
example
like
if
the
instances
always
call
import,
we
could
do
hostile
import,
underscore
scope
id
as
some
sort
of
join
key,
potentially.
G
So
I'll
share
my
idea.
I
think
this
can
be
done
as
a
follow-up,
because
I
don't
think
it's
quite
as
necessary
as
the
name
spacing
question
and
it
feels
a
little
unsatisfactory,
but
I
think
it
would
still
be
good
to
have
a
scope
attribute
that
has
the
prefix
in
it,
but
it
would
be
optional,
meaning
you
could
still
have
the
concept
of
a
short
name
or
whatever
we
decide
to
name
it.
B
G
We
have
two
options,
actually
I'll
explain.
Both
I
was
making
some
assumptions
so
I'll,
try
and
step
back,
but
we
have
either
we
can
have
a
single
metric
called
say,
open,
telemetry,
scope
info,
which
only
has
two
keys.
It
has
name
and
version
the
reason
why
it
can't
have
additional
keys
say
for
other
scope.
Attributes
is
because
again
for
prometheus,
the
set
of
label
keys
on
a
metric
must
be
the
same
across
all
instances
of
the
metric.
That's.
G
Prometheus
it
used
to
be
allowed.
It
is
now
rejected,
so
you.
G
E
G
G
I
believe
it
okay,
so
one
option
is
to
have
a
single
metric
with
only
two
keys
name
and
version,
and
that
way
you
could
choose
exactly
which
instrumentation
name
you
wanted
to
join
with
what
and
you
would
get
the
version,
but
you
would
have
to
know
the
name
up
front,
or
at
least
the
relationship
between
your
prefix
that
you've
put
on
your
metrics
and
the
name
or
we
could
have
a
different
metric
for
each
scope.
G
As
labels
on
those
metrics
and
that
would
be
allowed
since
they
no
longer
share
the
same
metric
name,
so
I
was
assuming
we
wanted
to
preserve
scope
attributes,
which
is
why
I
was
proposing
the
the
second
there,
which
is
where
you
have
a
unique
one,
and
then
you
get
the
property
of.
If
you
make
your
prefix
the
same
as
your
scope
attribute
short
name,
it
makes
it
easy
for
users
to
conceptually
join
between
them.
G
If
they
want
it
means
we
could
potentially
in
the
prometheus
receiver,
sort
of
reverse
that
process
and
reconstruct
the
scope
correctly.
G
But
I
am
hoping
to
start
that
we
can
just
settle
the
namespace
question
and
figure
out
what
the
implications
of
that
are.
If
people
are
comfortable
with
that.
E
I
support
that
david.
I
think
we
should
move
forward
with
the
eliminating
complicated
naming
rules
and
address
this
scope.
Attributes
question,
hopefully
using
the
second
of
your
of
your
two
options.
There.
I
Yeah,
I
agree,
I
think
what
you
said
makes
sense.
I
think
it'd
be
nice.
If
the
prometheus
exporter
could
log
a
warning
if
name
collisions
are
detected,
and
you
know
I'll
put
a
view,
configuration
that
could
select
the
conflicting
instrumentation
scopes
and
you
know
you
know,
suggest
how
you
might
change
the
the
name
of
the
metric
with
the
view
to
avoid
the
conflict.
F
G
Okay,
I
will
try
and
write
up
a
version
of
this
that,
hopefully
we
can
all
make
sense
of.
G
G
Okay,
if
it's
all
right
I'll
move
on
to
my
next
item,
which
is
related,
it's
actually
sort
of
related
again
how
to
deal
with
conflicts.
But
this
time
it's
about
the
bridge,
spec
pr
or
the
the
metric
producer
spec.
Pr-
and
this
question
is
whether
or
not
we
want
to
allow
collisions
between
scopes.
G
E
I
I
put
this
draft
up
last
friday,
as
a
sort
of
thought
that
I
had
had.
This
is
about
our
debate
over
scope,
attributes
and
whether
how
to
unblock
the
release.
So
the
the
history
is
that
bogdan
pointed
out
correctly
that
in
in
a
world
where
scope
attributes
are
identifying
and
a
legacy
collector
exists.
E
For
example,
you
will
completely
destroy
that
data
if
you're
not
careful,
it's
another
case
of
violating
what
we
call
a
single
writer
rule,
and
so
we've
been
talking
about
how
to
unblock
the
release
by
correcting
this
somehow,
and
I
think
we
all
agree
not
that
we
don't
want
to
roll
back
the
concept
of
spell
patrick's.
E
So
there
are
two
pr's
I
think
I
put
up
one
of
them
and
I'll
admit
it's
just
kind
of
an
idea
that
was
loose
and
hanging
around,
but
I
felt
like
no
one
had
mentioned
it,
so
I
decided
to
state
it.
The
way
I
see
our
the
requirements
here
are
that
your
name
has
to
be
unique
in
order
to
preserve
the
property
that
we're
trying
to
preserve
the
way
that
I
that
occurred
to
me
that
we
could
preserve
that
uniqueness.
E
In
a
backwards
compatible
way
is
to
put
redundant
information
in
the
name,
including
all
the
attribute
values.
It
begins
to
look
a
lot
like
an
http
user
agent
string
where
you've
got
at
least
one
primary
name,
as
well
as
a
bunch
of
optional
name,
value
pairs
and
some
comments,
and
those
are
all
the
things
I
needed.
E
That's
the
that's
the
whole
idea.
I
think
it
helps
us
out
of
this
situation
and
even
in
a
few
years
from
now,
we
could
figure
out
how
to
stop
being
redundant
in
that
way.
If
we've
succeeded
at
essentially
eliminating
all
the
old
software
that
didn't
understand,
unique
scope
attributes.
So
that
was
that's
the
brief
pitch.
I
think
the
other
option
is
to
call
scope,
attributes
essentially
non-dinner
thing
and
that's
tigran's
proposal.
Would
you
like
to
say
more
keegan.
F
Yeah,
I
think
so
my
understanding
is
that
you're
proposing
a
way
to.
I
guess
if
we
combine
what
I
suggested
and
you
suggested
we,
we
get
both
possibilities
there.
If
you
need
your
attribute
to
be
identifying,
you
put
it
as
as
part
of
the
scope
name,
the
way
that
you
defined.
If
you
needed
to
be
non-identifying,
then
it's
it's
a
regular
attribute
is
that
is
that
correct
to
say
so?
F
Yes,
that
sounds
correct,
yeah
yeah,
so
I
guess
the
question
is:
there's
only
one
use
case
that
I
know
of
where
the
scope
attributes
need
to
be
identifying
and
I'm.
I
don't
feel
very
strong
about
that
use
case
to
be
honest,
to
to
push
for
having
the
possibility
the
option,
the
ability
to
make
the
attributes
identifying
yeah.
B
So,
first
of
all,
tigran
there
was
another
proposal
between
your
and
my
and
josh.
I
made
one
and
got
some
approvals
already,
so
if
you
want
to
prove
that
in
review
will
make
us
faster.
Second,
I
think
just
for
this.
We
should,
because
we
want
to
unblock
the
release
as
soon
as
possible.
B
We
should
go
with
making
the
scope
attributes
non-identifier,
but
but
make
sure
we
call
out
that
it's
a
user
error
to
not
to
not
it
will
create
scopes
with
the
first,
with
the
same
name
version
and
and
and
schema
url,
but
different
attributes.
The
reason
to
do
this
is
because
we
want
to
leave
us
the
open
door
of
allowing
these
and
and
and
making
them
identifiable.
B
E
Can
I
ask
clarifying
just
to
make
sure
everyone's
on
the
same
page
about
what
we're
prohibiting
here?
I
believe
what
you're
suggesting
it's,
that
you
can
only
create
one
instance
of
an
attribute
set
for
every
distinct
name
version
of
schema
url,
because
it
preserves
the
distinctness
property
that
we're
all
trying
to
achieve.
Okay,
that
was,
I
believe
that
was
actually
a
suggestion
that
came
out
earlier.
Just
essentially
saying
that
I
was
proposing
that
this
forces
us
towards
a
1.0
and
in
1.0
you
are
able
to
do
the
thing
that
we
just
said.
E
You
can't
do
it's
pre
1.0,
where
we
somehow
don't
know
whether
scope
attributes
are
available,
that
we
have
this
problem.
So
I
I
would
propose
that
we
say
this
is
simply
prohibited
until
you're
on
a
1.0
platform.
I
don't
know
exactly
how
we
declare
that
there's
been
forever
a
request
to
put
the
version
identifier
into
the
protocol,
which
was
one
approach.
We
don't
have
to
do
it
that
way,
but
somehow,
if
we
could
change
our
protocol
to
say
now
we're
1.0
now
you
can
use
more
than
one
scope
attribute
set.
B
The
version
it
doesn't
need
to
be
in
the
product
called
josh,
I
think
it
needs.
The
protocol
needs
to
ask
the
receiver
about
the
version.
It's
it's
more
or
less.
You
need
a
negotiation
there
to
to
know
the
version
that
the
the
receiver
knows.
Not,
I
mean
just
mentioning
your
version
in
the
request
does
not
help
with
this,
because
you
can
determine
the
version
by
looking.
If
there
are
attributes
or
not
it's
it's
it's
about.
E
I
think
we
could
replace
the
service
with
new
service
names
to
to
declare
the
new
version,
for
example,
but
you're
right
negotiation
is
also
the
key
feature
of
my
proposal,
which
was
that,
like
in
two
years,
I
don't
really
want
to
keep
including
these
attribute
values.
In
my
name,
I
can
negotiate
this
like.
E
Well,
I
like
this.
I
like
this
proposal,
just
prohibit
it
and
it
means
that
your
attributes
might
get
dropped,
but
it
also
means
we
can't
use
these
attributes
for
the
one
example
that
I
thought
we
were
all
after,
which
was
to
do
the
prometheus
short
name
thing
or
something
along
those
lines.
So,
if
we're
not
going
to
use
scope,
attributes
to
solve
scope,
adjectives.
B
Name
is
fine
because
you
don't
change
the
parameter
short
name
for
the
same
for
the
same
scope,
full
name
like
the
the
scope
name,
the
identifier
part
is
not
changing
and
you
don't
change
the
short
name
for
multiple
io
grpc,
open,
telemetry,
jrpc
stuff.
So
so
I
I
don't
think
it's
prohibiting
that
part.
F
Yeah
you're
right
so
non-identifying
here
simply
means
that
you
cannot
obtain
two
distinct
instances
using
different
sets
of
attributes,
but
because
the
short
name
is
ever
going
to
be
a
single
value
for
that
particular
library,
that's,
okay!
You
can
obtain
it
all
right.
That's
all!
That's
a
problem.
B
You
cannot
change
it.
You
can't
change
it
yeah,
it's
immutable.
So
essentially,
if
the
property
is
immutable,
it's
fine
and
it's
immutable.
In
this
case
you
we
don't
want
to
allow
people
to
change
it
over
time.
F
I,
like
it,
okay,
so
I
think
I
I
agree
with
bogdan's
proposal.
It
leaves
the
door
open
slightly,
at
least
for
us
to
make
refinement
on
this.
So
we
say
you
should
not
do
that.
You
must
not
do
that
if
you
do
that,
it's
undefined
behavior
and
we
make
can
make
the
release
it
unblocks
it.
It
brings
it
back
to
the
state
that
it
was
before
this
change
and
then
we
we
have
time
to
think
about
what
do
we
want
to
do
in
the
future?
So
I
like
it.
B
D
F
I
don't
hear
any
objections,
so
that's
good.
Do
we
return
to
david's
postponed
question?
I
guess
right.
F
F
E
Answer
from
the
perspective
of
having
authored
some
of
the
conflict
resolution
and
management
discussions
earlier,
I
I
would
treat
it
the
same
as
if
two
instrumentation
packages
produced
conflicting
metrics
with
the
same
names
and
identities
literally
like
tiguan
just
said
it's,
it's
a
conflict
that
you
weren't
able
to
to
do
legally,
and
I
think
jack
also
suggested
a
nice
resolution
path.
The
the
the
reason
why
I'm
so
supportive
of
the
views
in
general
is
that
it
helps
us
give
the
user
a
workaround
for
all
this
type
of
problem.
E
G
E
I
Yeah,
I
don't
so,
let's
see
if
you,
if
a
producer
can
only
have
a
single
instrumentation
library
and
it
needs
to
produce
from
multiple
instrumentation
libraries.
It
can
just
be
act
as
multiple
producers.
You
can
just
register
multiple
producers,
one
per
per
scope
or
instrumentation
library,
whatever
we're
calling
it.
I
So
I'm
not
necessarily
opposed
to
that.
I
don't
know
of
any
use
cases
where
you
would
want
to
have
a
metric
producer
that
has
multiple
scopes.
B
I
And
and
furthermore,
so
the
now
that
I
think
about
it,
a
metric
producer
can,
even
if
it
registers
a
single
instrumentation
scope,
that
scope
can
conflict
with
one.
That
is,
you
know
just
for
open,
telemetry
instruments,
and
so
you
know,
I
don't
think
a
metro
producer
having
a
single
scope
actually
like
avoids
this
conflict
problem,
and
so
why
not
just
let
it
pass
through
yep.
G
Originally
I
originally,
I
had
thought
that
we
could
do
something
more
creative,
perhaps
and
drop
the
metric
producer
metrics
entirely
or
something.
If,
if
we
wanted
to
maintain
the
invariant
that
you
only
ever
get
one
copy
of
a
scope
in
a
batch
of
metrics,
but
it
sounds
like
that
becomes
infeasible
with
metric
producers.
H
I
think
maybe
my
question
is
up
next
about
otlp
json
stability
yeah.
I
was
just
gonna
raise
this
again
as
we
started
talking
about
this
in
the
early
summer.
I
think
july
was
when
we
were
last
discussing
it
and
I
think
tigran
came
up
with
a
list
of
conditions,
kind
of
to
declare
that
declare
otlp
to
be
1.0,
and
I
don't
think
there
was
anything
that
was
like
contentious
or
controversial,
but
I
do
think
that
summer
vacations
got
in
the
way
and
kind
of
put
this
work
on
the
back
burner.
H
So
I
just
wanted
to
kind
of
bring
it
back
up
and
see,
see
if
anybody's
been
thinking
about
this
or
see.
If
anybody
has
any
thoughts
on
blockers
or
ways
to
move
this
forward,.
F
F
I
would
wait
with
merging
the
pr
that
I
had
until
we
make
this
release,
because
I
think
this
simple,
let's,
let's
just
make
the
release
it's
been
too
long
now,
but
after
that
we
can
probably
refocus
on
this
one,
and
I
think
there
was
there
was
maybe
one
thing
remaining
there
figuring
out
whether
we
have
the
helper
in
arms
or
no,
and
that
is
probably
only
the
only
one
that
I
remember.
That
is
where
we
have
different
opinions
there.
So
once
that
is
resolved,
I
think
we're
good.
F
F
So
I
think
most
of
those
are
actually
already
implemented,
like
it
says,
implement
json
into
other
languages.
That's
correct,
yeah!
We
do
have
implementations
already
if
I'm
not
wrong,
so
I
anyway
yeah
you're
right.
So
if
any
of
those
actually
require
an
action,
then
they
need
to
be
turned
into
issues
and
we
need
to
execute
those.
J
Yeah
actually
tigran.
If
you
have
time,
maybe
you
can
take
that
you
know
they
can
champion
that
this
is
important
for
for
us
for
light
steps.
So
we're
happy
to
spend
cycles
there
yeah
so.
F
J
C
Hi
guys,
so
this
is
about
the
definition
of
the
boolean
environment
variables
on
the
sdk,
so
I've
updated
the
request
with
the
suggestions
and
fixes
to
the
language
that
people
have
been
suggesting
and
there's
an
outstanding
problem
that
needs
to
be
sorted
out
over
there.
C
C
Then
we
adopted
default
as
false,
but
now
there's
there
seems
to
be
some
some
issues
around
this
and
around
renaming
of
environment
variables
that
are
named
according
to
to
this
invention
that
we
are
establishing
here,
and
so
I
don't
know,
I
don't
know
if
tyler
has
read
the
the
thread
and
what
his
opinion
on
the
the
contributions
that
were
added.
D
I
I
I
can
give
a
quick
summary
of
it
and
so
effectively,
so
we
decided
to
name
boolean
environment
variables
such
that
the
the
default
value
is
always
false,
and
so,
if
you
leave
the
the
environment
variable
blank
or
nil
or
whatever,
it's
always
named
such
that
that
is
aligned
with
what
you
do
want,
that
that
is
equivalent
to
false
and
that's
always
aligned
with
what
you
want.
The
default
value
to
be
mark
brings
up
this
point
that
that
presents
an
issue
if
you
ever
want
to
change
the
default
value
in
a
next
major
version.
I
So
let's
say
you
want
to
switch
the
default
value
for
some
environment
variable
from
from,
like
you
know,
false
to
true,
you
have
to
introduce
a
different
name
for
that
environment
variable
to
match
this
rule,
and
then
you
get
into
this
weird
state
where
you
have
like
two
versions
of
the
environment:
variable
name
floating
around
one
would
that's
like
foo
enabled
and
one
foo
disabled.
You
know
for
major
version,
one
and
major
version,
two
and
so
yeah.
J
D
I
D
But
like
I
don't,
I
don't
understand
like
when
we
would
need
to
change
the
default
and
if
we
do
need
to
change
the
default,
I
have
no
problem.
Deprecating,
an
old
environment
variable
for
a
new
one.
That
actually
is
what
we
wanted.
I
think
that
that
also
not
only
would
make
it
clear
to
the
end
user,
but
it
would
also,
I
think,
be
in
line
with
what
their
expectation
is
like.
D
D
I
Well,
if
you're
not
setting
the
environment
variable-
and
you
know
you
change
the
default
value
from
false
to
true-
then,
regardless.
I
D
The
way
it's
defined
is
like
you
have
to
positively
say,
like
this
is
going
to
be
disabled,
so
I'm
going
to
disable
the
trace
sdk
and
then
in
the
next
release.
We
say,
like
you
know
what
actually
we
want
this
to
be
defaulted
to,
true,
so
the
user
upgrades
and
then
all
of
a
sudden
they
have
no
traces
coming
out
and
that's
because
we've
changed
the
default
and
their
understanding
of
the
default
variable
of
the
hotel,
trace,
sdk
being
disabled
has
fundamentally
shifted
underneath
them
without
them
actually
understanding
it
and
understanding
it
explicitly.
D
And
if
you
keep
this
mentality-
and
you
say
like
well
actually
no
like
that-
that
can't
be
the
case
that
environment
variable
needs
to
be
redefined.
So
now
we're
going
to
have
it
so
that
this
environment
variable
is
redefined
and
that
environment
variable
is
going
to
default
to
still
being
false.
But
it's
going
to
be
trace.
Sdk
enabled
right.
D
The
user
is
extremely
clear
as
to
what
that
actually
is
going
to
mean,
then,
if
they
want
to
then
do
an
upgrade.
It's
completely
fine
like
there's
no
change
in
behavior
for
them,
and
if
they
want
to
explicitly
buy
into
this
one,
they
may
be
using
a
deprecated
environment
variable,
but
they
still
have
no
change
in.
But
in
behavior
like
the
the
way
that
you
actually
redefine
the
the
default
of
an
environment.
Variable
is
problematic
because
it's
not
forward
compatible
like
you
were
going
to
have
change
of
behavior
and
break
user
expectation.
C
D
I
also
I
just
want
to
point
out
that,
like
I'm
on
the
hook
for
this,
for
trying
to
define
more
of
a
configuration
file,
but
I
think
environment
variables
have
a
limited
use
and
I
think
you
know
like
if
you
start
trying
to
think
about
changing
default
behaviors
and
changing
like
configuration
options
like
that,
like
I
think,
there's
configuration
at
a
broader
sense
of
open
symmetry
that
needs
to
be
addressed.
D
I
the
thing
with
this
proposal
is:
if
you
want
to
change
the
default
variable,
I
can.
I
can
think
of
zeros
instances
where
that's
actually
gonna
be
the
case
like
I
don't
know
where
it
is,
and
then,
if
you
give
me
one
like
there's
just
no
reason
in
my
mind
that
you
wouldn't
be
able
to
say
like
yeah
like
changing
the
default
variable
is
changing
the
the
behavior
of
the
open
cylinder
tree
like
sdks,
like
that,
doesn't
seem
like
a
a
great
user
face
like
in
fact
like.
D
I
I
think
what
mark
was
proposing
and
again
I
don't
feel
strongly
about
this.
I'm
just
trying
to
you
know
articulate
the
argument,
so
we
can
try
to
make
some
progress
here
synchronously,
but
his
his
proposal
was
that
this
is
the
change
would
be
in
a
major
version
bump.
So
you
know
if
you
wanted
to
change
the
default
version
in
the
next
major
version,
not
a
minor
version.
G
D
I
I
can't
think
of
an
example
either
where
you
would
want
to
change
the
default
behavior
I
mean
we
only
have
one
example
of
of
you
know
a
language,
agnostic,
environment
variable
that's
going
to
be
a
boolean.
We
have
more
in
java,
but
I
I
want
to.
I
don't
know
any
that
we
would
want
to
change
the
defaults
for.
D
I
mean
I
I
yeah
okay,
I
hear
you
now
like
a
major
version
of
that
would
be
a
time
where
you
would
have
changed
behavior.
I
do
think
that
that's
necessarily
not
some
something
you
would
want
to
do
changing
behavior.
You
could
still
do
this
in
a
backwards
compatible
way,
especially
if
you
have
this
deprecation
strategy,
where
you
would
deprecate
that
environment
variable.
D
D
But
when
a
new
user
comes
there,
there's
there's
a
there's,
a
level
of
confusion
they
already
have
with
the
project
and
adding
to
them
to
that
confusion
as
to
whether
or
not
they
need
to
be
sending
an
environment
variable.
For
this
thing
to
run
it's
not
something
we
want
to
be
doing,
and
I
think
that's
that's.
C
Okay,
so
do
you
guys
agree
that
I
should
state
there
that
the
renaming
of
these
variables
should
be
should
not
be
done
between
major
versions?
Then.
D
Absolutely
I
mean
that's
in
the
same
sense
that
changing
the
default
of
a
configuration
option
shouldn't
be
done
like
that,
doesn't
seem
like
a
really
like
unless
it's
like
a
numeral
value
for
like
limits
or
something
where
it
would
be
more
inclusive
or
less
inclusive,
depending
on
like
research
like
it
just
seems
like
changing
default
is
changing
the
expectation
of
the
users,
and
I
think
that's
something
we
need
to
be
very
cautious
of,
and
in
this
situation,
changing
from
enable
to
disabled
is
a
is
a
breaking
change.
D
But
I
also,
I
also
think
that,
like
this,
this
is
a
really
great
definition
in
that
sense,
because
it
communicates
to
the
developer
that
that's
a
breaking
change
and
if
you
wanted
to
do
something
different,
you
need
to
create
a
different
approach
to
it.
So,
in
such
a
sense
like
defining
a
new
environment,
variable
seems
completely
relevant
because
you
need
to
be
thinking
in
that
sense.
It
is.
It
is
essentially
completely
saying
to
the
user,
like
we
have
a
completely
different
way
to
actually
address
this
configuration
option.
D
D
Yeah,
I
I'm
happy
to
take
a
look
at
the
pr
like
I
said
I
can
prioritize
it
later
today.
I
didn't,
let's
just
say,
being
underwater
is
where
I'm
at
so
yeah.
C
Anyway,
thanks
very
much,
it
has
been
a
long
journey,
but
I
think
we
have
a
really
nice
definition,
almost
ready
thanks.
Everyone.