►
From YouTube: 2021-02-01 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
C
C
Morning,
all
right,
let's
get
started.
I
have
the
first
topic
on
the
agenda.
Very
short,
as
we
discussed
last
week,
we
were
going
to
password
protect
the
zoom
meetings
that
is
now
done.
They
all
have
the
password
7777
I've
embedded
that
into
the
calendar
link.
So
assuming
for
the
people
who
open
via
the
calendar,
you
probably
didn't
notice
anything.
C
A
A
I
have
a
related
gender
item
that
I've
added
later
on
to
go
over
the
spec
1.0
tagging
they're
tracking
prs
specifically,
so
they
aren't
track.
They
aren't
related
to
a
p1
issue
stopper.
I
also
got
some
other
news,
but
I
can
also
continue
sharing
for
the
next
agenda
item.
If
you
like.
A
C
Yep
perfect,
did
you
have
the
next
topic
there's
no
name
on
it.
A
A
F
A
Yes,
just
want
to
let
the
community
know
I'll
be
stepping
away
from
hotel
at
the
end
of
this
week.
This
is
something
that's
been
I've
planned
for
several
weeks,
so
it's
not
something
sudden.
That's
like
come
out
quite
recently
related
towards
anything.
So
I've
been
playing
this
for
a
while,
and
I
just
want
to
say
that,
like
I've
had
a
really
good
experience
working
with
everyone
in
the
open
source
community-
and
I
think
it's
really
awesome
how
companies
different
companies
can
collaborate
on
on
a
common
technology
common
idea.
A
I've
also
been
thinking
with
tetsuo
he's
on
technically
on
vacation,
but
joining
us
on
this
city
call
on
the
issues
on
the
logistics
of
the
issues
that
I've
been
tracking
related
towards
rga
and
the
regular
reports
I've
been
giving
and
specifically
for
the
metrics
issues.
I've
also
been
taking
with
j
macd.
A
C
C
E
Totally
andrew,
thank
you
so
much
and
really
sad
to
you
too.
C
A
I'll
be
stepping
away
from
from
open
source
stuff
for
at
least
a
month,
okay,
but
I'm
not
closing
any
doors.
Okay,
you
know
I
I
like
working
with
open
source,
but
at
least
a
month.
A
Is
for
I'm
speaking
with
carlos
about
tagging,
1.0
specification,
repo
and
the
issues
that
are
related
to
making
that
happen.
Sorry,
these
are
pr.
J
Yeah,
actually
I
added
them
as
actual
items.
I
know
this
is
more
like
kind
of
a
specification
conversation,
but
if
we
have
time
by
the
end
of
the
call,
we
can
discuss
the
technical
details
and
hopefully
we
have
enough
people
here,
you
know
to
come
to
an
agreement
and
if
not
tomorrow,
but
yeah-
that's
let's
discuss
those
by
the
end
of
this
call.
Please.
K
K
So
yeah,
both
jaeger
and
open
telemetry
have
traditionally
participated
in
outreachy,
which
is
an
internship
program.
I
guess
jp
is
saying
he
can't
be
a
mentor
this
year,
but
if
people
are
interested
in
mentorship,
they
should
reach
out
to
him
through
this
issue
or
through
through
contacting
him
directly.
K
E
Definitely
I
mean
I've
I've
mentored
on
preachy
before
and
and
it's
it
is
a
great
great
initiative,
so
I'll
I'll
reach
out
to
jp
great.
L
L
K
I
think
it's
tricky,
I
do
agree
with
you
nikita
that
it
comes
up
often,
and
it
is
sort
of
like
perfect
versus
the
enemy
of
good
enough.
The
ideal
solution
is,
we
know
all
of
this
stuff
right
at
the
very
beginning,
but
that
doesn't
seem
feasible
all
the
time
and
you
hit
an
issue
specifically
around
startup.
Where
are
you
going
to
wait
for
all
these
things?
K
There's
some
that
maybe
we
want
to
wait
for,
because
they're
they're
absolutely
critical
for
identifying
the
service,
but
there
are
others
where
maybe
it
just
means
that
some
spans
aren't
as
well
indexed
as
all
of
the
spans
right,
like
you'll,
have
some
traces
or
metrics
that
are
occurring
before
these
resources
come
in
and
what
are
the
implications
of
that?
Obviously,
no
one
thinks
that's
good.
The
question
is
whether
or
not
that's
better
than
simply
not
having
those
resources.
K
So
I
think
that's
that's
an
important
debate
to
have.
Personally,
I
think
we
should
go
ahead
and
allow
it,
because
I
think
it's
reasonable.
I
did
see.
E
K
L
K
Yeah,
I
might
go
a
step
further
and
say
we,
as
the
providers
of
the
open,
telemetry
standard
lib
shouldn't,
be
treating
these
as
mutable.
I
don't
know
if
we
should
go
far
as
like,
literally
technically,
preventing
the
end
user
from
from
doing
that.
K
The
reality
is,
you
can
take
the
resource,
object
and
replace
it
with
a
new
one.
I
I
don't
know
if
we
want
to
make
it
more
restrictive
than
that
you're
going
to
get
into
technical
details.
That'll
make
that
difficult
to
do
and
presumptions
about
whether
we're
smarter
than
the
end
user
about
solving
what
problems
they
may
encounter
in
production.
L
We
couldn't
expect
the
operator
to
always
remember
to
change
that
environment
very
able
to
set
that
resources
if
we
can't,
if
we
can
detect
them
during
runtime
and
on
the
other
hand,
yes,
if
we
only
allow
to
add
new
attributes,
then
in
theory
backhands
can
even
backfill
those
to
the
to
already
to
previous
spans
or
or
traces
again.
Shifting
burden
from
the
operator
developer
to
well
back-end
developer,
which
is,
I
think,
much
sensible.
K
L
K
I
think
that
it's,
the
more
subtle
distinction
of
when
we
do
auto
detection,
which
we're
already
doing
is
it
a
requirement
that
that
auto
detection
occur
before
the
sdk
starts,
producing
any
information.
In
other
words,
should
we
block
startup
in
order
to
do
this
as
a
requirement,
or
should
we
say
that
as
the
process
is
running,
you
know
you
may
want
to
to
add
these
things
later,
as
as
providers?
I
think
we
should
do
our
best
to
make
sure
the
data
is
consistent
and
provided
at
the
beginning,
but
presumably
end
users
can
write
more.
K
Somebody
somewhere
can
write
more
resource
detectors
right,
like
yeah,
more
and
more
resource
detectors
are
going
to
come
out
and
the
question
is
like:
do
all
of
them
have
to
happen
before
startup?
Or
can
you
have
resource
detectors
that
are
too
asynchronous
for
that
to
be
appropriate
and
then
the
second
question
is:
are
there
resources
that
might
literally
change
without
a
restart
of
the
application,
and
so
you
would
have
some
resource
detector,
that's
polling
in
the
background
that
may
want
to
to
change
this
stuff
at
any
time.
L
K
L
Why
we,
we
are
trying
to
keep
the
scope
small
if
we
have
some
resource
resources,
which
can
be
auto
discovered
only
a
little
bit
later
so
delay,
but
immutable
or
append
only
resources.
That
would
already
be
a
good
good,
a
good
step
for,
for
I
not
currently
advocate
for
totally
mutable
resources.
No
that's
to
be
big
of
a
can
of
water.
K
I'm
the
only
one
talking
here
besides
you,
but
I
would
say
it's
reasonable.
I
think
we
should
avoid
where
this
has
made.
The
code
complicated
in
the
past
is
trying
to
ensure
all
of
these
resources
get
onto
every
batch
of
spans.
That's
produced,
and
so
part
of
this
is
abandoning
that
idea
and
saying,
like
look,
you
may
in
the
future,
from
this
same
service
get
resource,
I
mean
we
append
the
resources
to
every
batch
is
my
understanding
right.
K
So
you
know
it
just
may
be
that
in
the
future,
this
this
service
may
provide
a
different
batch
of
resources
and
then
in
the
api,
how
we
implement
it.
We
we
do
our
best
to
perhaps
ensure
that
it's
not
easy
for
users
to
remove
a
bunch
of
resources
by
accident
or
something
like
append.
Only
like
you
said
yeah,
yes,.
K
M
H
E
J
M
L
Because
the
argument
is
that,
if,
if
I
want
to
have
a
if
I
want
to
have
an
information
about,
for
example,
which
version
of
tomcat
my
application
is
running
in
then
a
I
want
that
to
be
a
resource,
not
a
span
attribute,
because
that's
type
more
or
less
static
b.
I
don't.
I
don't
want
to
force
operator
to
detect
to
set
that
version
as
an
environment
variable,
because
well
then
he
he
will
have
to
remember
to
change
that.
On
version
upgrades.
G
I
think
this
is
kind
of
specific
to
the
java
auto
instrumentation,
because
the
java
agent
starts
up
at
jvm
startup
and
we
don't
have
the
the
whole
like
environment
available
yet
like
what
the
users
app
is
going
to
be.
We
have
the
basic
class
path,
but
that
can
still
be
mutated
and
subclass
loaders
and
all
that
kind
of
stuff.
M
But
trust,
that's
that's
a
good
point,
but
let's,
let's
let's
understand:
when
is
there
a
moment
in
time
when
we
can
say
okay,
all
the
resources
will
be
available
before
the
first
span
is
emitted.
Is
that
a
statement
that
is
correct.
M
L
M
L
H
H
E
H
L
M
L
H
Is
there,
like,
I
mean
append,
only
we're
saying
it's
not
mutable,
it's
depend
only
we're
not
going
the
full
step
of
declaring
it
mutable.
But
what
does
that
change?
If
we
say
that
now
really
it's
not
immutable,
it's
actually
immutable
because
that's
the
reality
it
may
change
whatever
we
record
there
may
change,
because
we
record
things
that
are
which
tend
to
change
over
time.
L
J
M
So,
that's
that's
probably
the
most
important
part
of
this.
I
think
I
think
what
we
learn
from
this
is.
There
may
be
impossible
cases
where
we
literally
have
to
do
this.
Okay,
if
we
literally
have
to
do
this,
let's
assume
what
would
look
like
an
api
for
this
and
see
see
if
our
current
api
can
be
changed
to
that
or
are
we
gonna
have
to
break
the
entire
thing
or
like
break
compatibility?
M
H
Change
the
api
so
you're
saying
we
don't
need
to
do
it
now,
but
let's
have
a
sketch
of
an
api
to
make
it
clear
that
it
is
a
possible
path
forward.
We
will.
E
H
L
L
N
What
would
we
use
is
the
prioritized
list
of
immutable
objects
that
go
into
that
grouping
right,
like
you're
talking
about
having
an
append
only,
but
there
are
certain
pieces
of
that
puzzle
that
we
would
want
to
stay
immutable
forever.
Are
we
gonna
keep
an
explicit
list
of
those
or
how's
that
gonna
work.
K
And-
and
I
do
think
it's
worth
it
to
continue
exploring
these
use
cases
so
far
when
it's
come
up.
We've
ended
up
resolving
this
in
a
manner
where
we
can
get
all
the
information
at
the
beginning.
K
Yeah
well
I'm
suspicious
about
the
fast
id
in
general
and
even
whether
a
solution
like
this
would
be
helpful
there,
because
I
suspect
that
is
an
issue
where
there's
going
to
be
an
insistence
that
the
batching,
the
exporting
of
spans,
be
blocked
until
a
resource
resolved,
which
is
not
what
we've
been
talking
about.
Up
to
this
point,
yeah.
K
I
I
I
do
think
what
you're
proposing
is
something
that
can
be
added
as
a
backwards
compatible
change
in
the
sense
that
I
don't
see
any
of
the
existing
apis
needing
to
change
the
exporter
api
and
all
these
things
don't
really
need
to
change
in
order
to
to
facilitate
this.
It
just
means
you
know
when
things
get
handed
resources
or
ask
for
resources
the
object
they
get
back,
maybe
a
different
reference
to
a
different.
M
K
I
believe
what
resources
are
handed
to
the
exporters
right
is
that
correct
from
the
perspective
of
the
apis
that
we
currently
have,
that
plug-in
authors
would
use
or
that
the
person
the
application
owner
starting
the
the
sdk
up?
I
don't
see
any
of
those
interfaces
having
to
change,
because,
because
of
this.
K
We
should
review
that,
but
that's
my
impression
is
that
it
it's
not
currently
something
that
would
result
in
a
change
and
even
an
api
that
says
you
know
get
resources
wouldn't
necessarily
be
affected
by
this.
If
it's
not
done
through
an
interface,
if
it's
instead
done
through,
like
I
literally
have
some
direct
reference
to
something
and
that
reference
changes
I
mean,
I
think
that's
maybe
a
language
specific
thing,
but
but
I
currently
don't
see
this
as
something
that
would
that
would
cause
a
backwards
and
compatible
change.
K
O
Maybe
it's
worth
reviewing
that
we
just
implemented
the
resource
api
in
c
plus,
I
should
say
I
just
reviewed
the
pr
to
do
it
like
recently,
and
it's
unspecified
how
a
resource
goes
from
the
sdk
to
the
exporter,
so
like
languages
get
to
make
that
choice
there,
which
I
think
means
from
a
compatibility,
the
spec
level
you're
free
to
do
whatever
the
hell
you
want
from
an
actual
practical
level.
It's
more
a
question
of
where
do
you
need
this
in
which
language
it
sounds
like
java
needs
this
most?
O
So
I
would
answer
the
question
with
java.
I
would
also
actually
challenge
whether
or
not
we
really
need
to
show
that
the
api
can
be
done
in
a
backwards
compatible
way
in
the
sense
that
I
think
all
changes
we
make
post
1.0
will
be
done
in
a
backwards
compatible
way.
I
think
we
need
to
figure
out
how
to
do
backwards
compatibility.
I
don't
think
we
have
to
evaluate
this
right
now,
prior
to
1.0
and
say:
can
we
do
it
in
a
backwards
compatible
way,
because
I
think
the
answer
needs
to
be
yes
for
any
change.
O
We
want
to
make
whatsoever
and
I
think
it's
possible.
I
think
we
can
get
clever
and
we
can
do
it.
It's
more.
Are
we
comfortable
taking
on
some
of
the
ugliness
that
will
have
to
happen
to
do
it?
That's
the
real
question
going
on
there,
but
I
don't
think
like
I
just
want
to
throw.
I
don't
think
you
need
to
do
this
api
evaluation
because
we
can
do
a
backwards,
compatible
change.
Just
how
ugly
are
we?
O
Okay
with
it
being
and
specifically
to
answer
the
resource
question
I
think
you're
totally
fine,
having
had
to
just
re-examine
the
spec
and
look
at
it
and
see
if
it's
plus.
K
Yeah
and
that's
all
I
was
saying
josh
is
like
I,
I
I'm
not
concerned
about
doing
this
post
1.0
means
we
won't
be
able
to
do
it
or
that
it
would
be
horribly
ugly
to
do
it
in
any
implementations
we
currently
have
so
so
I
don't.
I
don't.
I
think
it's
not
not
a
critical
issue
for
for
1.0,
but
obviously
it's
important
for
some
languages
to
do
it.
K
So
we
should
figure
out
what
those
specific
issues
are
and
make
sure
they're
getting
resolved,
maybe
without
opening
the
door
too
wide,
because
we
we're
not
that's
something
I
would
like
to
avoid
is
just
adding
tacking
this
on
without
being
clear
about
like
what
problems
we're
solving
somewhere
and
how
we're
gonna
mitigate
the
problems,
we're
gonna
create
by
solving
those
problems.
O
K
Yeah,
I
will
say
the
way
the
fast
run
times
are
implemented,
are
a
total
pain
in
the
ass
for
us,
and
that's
like
not
our
fault,
it's
it's
those
that
compute
fabrics
issue
to
the
degree
to
which
that
you
know
it's
all
sort
of
done
after
the
fact
right
we're
trying
to
glue
together
stuff
that
isn't
aware
of
what's
what's
happening,
because
it's
old
technology
trying
to
be
run
in
a
new
manner
and
and
so
we're
kind
of
pushing
the
boundaries
of
what
people
have
been
trying
to
do
on
those
platforms
and
so
to
some
degree.
K
Some
of
this
stuff
may
actually
be
in
those
cases
having
to
go
to
the
fast
providers
and
being
like
look.
This
is
like
th.
This
is
creating
like
a
difficulty
for
observing
what's
going
on
over
here,
and
maybe
we
could
possibly
even
get
some
changes
happening
there.
It's
not
clear
to
me
that
we'll
actually
be
able
to
solve
all
these
issues.
On
our
end.
C
K
K
I
actually
might
that's
somewhat.
My
hope
is
that
that
the
connections
are
good
enough,
that
you
know
the
the
pain
is
felt
internally
as
it.
C
Might
be
yeah
I
mean
I
was
at
google
recently
enough
to
know
that
that's
definitely
true
right,
like
josh
and
I
were,
and
and
the
rest
of
the
ot
team
at
google
were
in
many
meetings
with
the
cloud
run
team
about
how
how
they
could
improve
it,
because
of
course
they
want
their
own
customers
to
get
better
observability
too
yeah.
C
J
Okay,
so
that's
me
with
the
stuff
yeah
those
I
don't
know
whether
we
should
go
full
full
power
on
these
items,
but
basically
the
two
remaining
items
for
declaring
the
sdk
tracing
portions
stable
and
frozen
one
of
them.
This
is,
as
you
may
remember,
from
renaming
trace
to
traces.
J
I
think
then,
in
general
there
was
agreement.
Although
people
especially
asking
native
english
speakers,
they
said
that
they
slightly
prefer
trace
and
tigran
has
a
point,
a
very
valid
point
about
using
traces,
because
this
is
what
the
collector
uses
and
this
there's
a
feeling
that
more
people
are
using
the
collector
these
days
more
than
the
trade
does
than
the
actual
api
and
sdks
in
different
languages.
J
So
basically
we
need
to
come
to
an
agreement
one
way
or
another,
and
my
latest
comment
on
that
front
was
that
I
think
that
the
collector
is
using
traces,
but
as
a
single
word,
so
it's
fine.
You
don't
have
to
you
know,
to
kind
of
link
mentally
whether
we
are
using
traces
or
traces
in
the
environment
variables,
because
you're
using
a
different,
you
know
complete
id.
J
K
And
to
address
layton's
concern,
we
are
planning
on
marking
these
environment
variables
stable
as
part
of
the
1.0
I'm
correct
and
believing
that
right.
J
Yeah
yeah,
I
think
that
that's
the
overall
feeling
josh
also
talked
about
that,
and
I
agree
with
him
and
other
people.
There
was,
of
course,
the
possibility
of
making
them
not
stable,
but
I
think
it's
a
big
risk.
I
couldn't
go
for
that.
B
M
M
Let
me
let
me
explain
one
thing
here:
right
now:
half
of
the
environment
variables
uses
use
traces
and
half
use
trace.
So
I
think
the
state
that
we
are
right
now
is
undesirable,
because
that's
super
easy
for
users
to
make
mistake.
They
will
not
know
which
one
has
singular,
which
one
has
plural.
They
will
put
s
or
not
put
s
on
some
of
them.
So
we
have
to
be
consistent.
Is
that
a
statement
that
everyone
agrees
with,
or
do
we
have
to
to
even
discuss
that.
O
O
It's
just
not
something
you
can
do
going
forward,
and
I
think
this
is
the
kind
of
change
that
needs
to
start
being
done
incrementally,
and
the
second
point
I
want
to
make
is
about
top
down
versus
bottom
up
of
consistency,
right,
raising
an
issue
in
the
specification
and
then
allowing
sdks
to
become
consistent
and
then
changing
the
formal
specification
to
define
the
consistency
versus
the
spec
changes
and
then
all
the
sdks
have
to
follow
suit
and
change
everything
in
their
code.
O
Having
watched
some
of
the
sdk
sigs
and
been
a
part
of
them,
the
top
down
force
changes
from
the
specification
do
cause
a
good
bit
of
churn
and
it's
okay,
but
I
think
especially
post
1.0.
That
practice
has
to
invert
right.
You've
got
to
wait
for
the
sdks
to
get
on
board,
and
then
you
can
change
the
specification
and
the
spec.
The
specification
has
to
kind
of
allow
for
previous
experience
and
new
experience
for
a
time
right.
O
That's
that's
my
point
here
is:
I
think
it's
at
that
time
in
the
life
cycle,
the
project
to
really
start
doing
that
and
the
consistency
is
important.
Yes,
but
you've
got
to
temper
it
with
with
churn
that
you're
causing
users-
and
there
are
people
using
this,
but
do
you
know
the.
M
The
history
behind
these
do
you
know
why
I
propose
this
pr.
I
I
don't
know
why
you
propose
the
pr
now.
Can
you
look
at
the
first
comment
like
there
is
a
follow-up
on
on
something
that
was
like
a
week
ago.
Like
the
first
description,
can
you
go
up?
Who
is
presenting
yeah?
There
is
a
follow-up
after
yeah,
so
there
was
a
change
a
week
ago
from
all
of
them
were
named
span
underscore
and
people
were
changing
these
two
traces.
M
So
now
my
problem
is
that
with
span,
I
was
okay
because
it's
either
span
or
trace,
but
now
I
have
half
of
them
called
traces,
half
of
them
called
trace.
This
is
such
error
problem
for
me.
For
me,
you
you,
you
don't
have
a
worse
case
than
this,
like
I
bet
you
that
people
will
read
and
will
not
know
which
one
are
traits
which
one
are
traces.
O
Yeah,
I
I
agree
with
that.
Again.
I
think
you
temper
this
with
stability
right.
You
have
docs
that
say
to
use
this
right.
You
have
people
using
one
of
them.
It's
just
a
matter
of.
Let's
make
it
consistent,
but
balance
it
with
the
stability
aspect
of
how
fast
you
make
people
move,
and
do
you
just
flip
the
spec
from
a
to
b?
Is
that
a
change
that
we
want
to
continue
doing?
That's
all
I'm
asking
is
like
yeah.
O
Can
we
go
through
a
migration
process
right
like
you,
you
just
recently
submitted
pr
to
the
proto
repo
that
I
looked
at
that
has
you
know
the
regular
deprecation
flip
of
let's
deprecate.
What
was
there?
Let's
add
a
new
thing.
I
think
that
this
is
the
kind
of
thing
that
we
that
needs
to
happen,
and
I
don't
I
I
was
trying
to
encourage
that
in
this
pr.
That's
that's
mostly
what
my
point
is
is,
let's
start
behaving
like
the
1.0
is
already
out.
O
M
So
for
me
for
me:
yes
indeed,
you
are,
you
are
raising
a
good
point,
but
there
is
the
small
frustration
of
the
other
pr
was
changing
completely
like
from
span
to
to
trace,
and
we
didn't
follow
that,
and
probably
we
should
just
have
a
date
or
or
something
that
we
say
from
now
on.
We
do
it
this,
because
otherwise
the
same
argument.
I
can
make
like
why
the
other
pr
did
not
follow.
O
M
One
thing
that
I
would
like
to
hear:
if
we
start
doing
this
is
when
do
we
remove
things
when
we
are
allowed
to
remove
things,
for
example,
or
maybe
say
never,
and
if
the
answer
is
never
it's
still
never
for
for
removing
these
things,
I
I
think
I
think,
or
maybe
I'm
just
naive,
but
I
think
we
lose
a
small
opportunity
window
to
to
fix
this,
for
example,
in
a
way
that
will
not
have
to
deal
with
this
deprecation,
but
I'm
fine.
Let's
it's
it's
just,
let's
make
a
decision
when
that
happens,.
J
Yeah
I
would
like
to
challenge
that,
and
you
know
just
just
would
say-
and
I
could
say
after
1.0,
then
let's
not
change
everything,
let's
not
remove
anything.
Now,
it's
the
last
opportunity.
So
please
let
let's
allow
ourselves
to
make
one
final
set
of
changes
and
be
done
with
that
and
after
that,
no
more
changes.
M
Okay,
we
we
keep
saying
that
so
I
I
hear
george
point
and
we
keep
seeing
that
and
his
his
worry
is
valid,
that
we
have
a
habit
that
we
may
not
be
able
to
correct
after
one
zero,
yeah
and
and
and
from
an
external
user
or
or
a
late
commer
in
this
community.
M
I
think
it's
it's
a
valid.
It's
a
valid
point,
seeing
the
community
moving
this
way
with
no
no
idea
of
how
we
should
do
this
after
one
zero.
We
keep
saying
that
we
will
do
this,
but
we
are
not
applying
that
and-
and
I
think
I
think
that's
that's
to
josh
point-
I
think
there
is
a
big
chance
that
this
habit
will
continue
after
1.0.
K
Josh
to
just
to
jump
in,
we
can
do
this
in
concrete
terms,
which
is
we
have
an
rfc
process
with
the
oteps,
and
we
can
make
a
requirement
for
oteps
to
be
prototyped
in
a
certain
number
of
languages
before
they're
accepted
we've
already.
E
K
To
do
this
practice
anyways,
but
the
more
we
rely
on
that
process
being
one
where
we
implement
things
first,
as
part
of
proposing
the
change
and
then
approving
that
change
in
the
otep,
and
only
then
does
it
go
into
the
spec
that
that
process
allows,
I
believe,
the
kind
of
flow
you're
you're
looking
for.
D
I
think
I
heard
two
distinct
concerns
between
what
you
said
ted
and
what
josh
said.
One
is
allowing
experience
to
inform
what
we're
doing
in
spec,
which
I
think
is
exactly
the
point
you're
making
now,
but
the
other
one
is
allowing
a
migration
period
for
users
of
the
sdks
or
users
of
implementations
right
and
so
the
migration
period
concern
is,
is
distinct
right.
The
otep
thing
would
not
give
us
that.
K
Yeah
and
post
1.0
yeah,
we
can't
it's
it's
not
even
just
a
migration
period
to
be
clear:
it's
you
can't
remove
it
outside
of
the
support
guarantee
window.
So
if
you
look
at
the
versioning
and
support
document,
that's
a
one
year
period
for
sdks
and
plugin
interfaces
and
a
three
year
period
for
something
in
the
public
api
or
the
instrumentation
api,
maybe
start
calling
it.
K
Yeah
that
would
be
covered,
there's
also,
to
my
mind,
there's
no
problem
with
just
supporting
deprecated
environment
variables,
even
even
with
this
change
right
here,
there's
nothing
blocking
implementations
from
just
continuing
to
support
a
deprecated
mvar,
which
I
would
recommend
for
the
collector
or
any
any
system.
K
That's
you
know
already
feels
like
they've
crossed
the
threshold
with
their
users
definitely
continue
to
maintain
those
old
environment
variables
right,
that's
very
cheap,
so
there's
almost
no
reason
not
to,
but
I
completely
agree
that
we
we
have
to
stop
thrashing
about
on
these
issues
right
and
just
accepting
that
we
have
to
live
with
our
choices.
J
Because,
no,
I
could
say,
let's
follow
this
totally
honestly,
honestly,
the
problem
that
you
mentioned
at
first,
the
lack
of
consistency,
is
a
problem.
Let's
just
go
with
consistency
and,
let's
I
could
say,
let's
go
with
this
pr.
Let's
verify
that,
just
just
in
case
that
all
of
the
rest
of
the
stuff
with
deception
of
the
collector
is
using
these
and
that's.
N
E
E
E
O
Yeah
so
having
inherited
something
terrible,
not
terrible,
but
something
where
no
one
considered
stability
and
it
broke
every
single
release
and
having
to
build
an
entire
ecosystem
of
a
build
tool
around
trying
to
invent
stability,
aka
scala,
if
you're
ever
curious,
why
scala
has
weird
artifact
names
in
david,
central
yeah
yeah?
O
That's
me
and
my
team
anyway,
you
will
be
amazed
at
how
creative
you'll
get
if
you
just
limit
yourself
like
literally
this,
is
about
the
community,
saying
we're
ready
for
1.0,
let's
go
and
we're
going
to
deal
with
any
mistakes
we
made,
because
this
is
not
the
only
mistake
that
we've
made
not
it's
not
just
this.
It's
not
just
this
pr,
there's
a
whole
ton
of
them
and
they're
waiting
to
be
discovered
kind
of.
Like
the
you
know,
resources
and
adding
things
to
it.
That's
an
awesome
bug
to
have
that's
so
good.
O
That
means
people
will
use
us
because
we
have
like
you're
finding
real
problems
now
right,
but
the
only
way
we
get
real
users
is
to
be
stable
and
to
get
people
on
board
and
to
take
the
dependency.
If
you
continually
churn
the
sdks,
imagine
what
users
feel
okay,
they're
gonna
feel
even
more
turn.
Only
the
most
excited
and
engaged
in
telemetry
people
will
jump
on
you,
you're
not
gonna,
hit
the
people
who
don't
want
things
to
be
stable
and
not
care
about.
O
You
now
remember
I'm
coming
as
a
build
tool
owner
where
the
worst
thing
you
can
do
as
a
build
tool
is
make
people
understand,
build
tools,
that's
the
worst
thing
you
could
ever
do
right
and,
to
some
extent,
we're
gonna
have
a
little
bit
of
that,
so
it
it's.
This
is
a
decision
the
community
needs
to
make
of.
When
do
we
declare
stability?
O
I
agree
with
you:
there's
an
opportunity
to
change
it
now,
we're
not
1.0,
but
the
thing
is:
when
were
we
supposed
to
be
1.0
and
how
many
of
those
oh,
this
is
our
last
moment
to
make
a
change
moments.
Have
we
had
right?
How
many
times
has
that
happened
in
this
community?
It's
been
constant
since
I've
been
involved
right.
We
have
to
do
this
before
1.0,
because.
K
K
So
I
agree
with
you,
but
but
you're
making
it
sound
as
if
we're
not
doing
that
and
what
this
is
you're
saying
this
is
the
moment
when
we
should
do
that,
and
I'm
saying
like
this
is
the
moment
where
we
are
doing
that,
and
the
question
is:
is
this
last
final
change
worth
it
or
should
we
should
we
drop
it
on
the
floor
and
a
number
of
us
are
saying
like
look,
please,
let's
just
make
it
consistent
right
now
and
have
deprecated
environment
variables
for
people
who
who
for
projects
that
need
them,
but
I
completely
agree
after
after
you
know,
february
15th,
or
whenever
we're
officially
announcing
this
like
that
door
is
closed
and
everything
from
that
point
forward
relating
to
tracing
has
to
be
backwards
compatible
and
all
the
work
we
do
in
metrics
has
to
be
compartmentalized
in
such
a
way
that
it
doesn't
destabilize
any
of
the
tracing
stuff
that
people
are
already
using
and
that's
just
a
hard
requirement.
K
I
do
wish
that
you
know
in
again
an
ideal
world.
We
would
have
eased
our
way
into
this
culturally
more
than
we
have.
But
that's
you
know
I
mean
it's.
The
the
same
thing
we've
been
talking
about
like
nothing's
ideal,
but
I
have
a
lot
of
faith
that
it's
it's
fine
like
the
the
tracing
stuff,
I
think,
is
actually
very
stable
at
this
point
and-
and
I
don't
think
we're
gonna-
have
a
problem
being
backwards,
compatible
going
going
forwards,
but
you're.
O
Yeah
yeah
and
I'm
sorry
if
what
I
said
was
more
intense
than
what
I
really
intend
I
was.
I
was
I'm
always
a
little
bit
of
a
hyperbole
guy.
The
my
point
being,
though,
that
the
most
important
thing
is
the
mindset-
and
you
ted
specifically,
has
really
been
pushing
the
mindset
here
right
and
I
think
there's
been
friction
and
that's
what
I'm
trying
to
push
on
is
that
friction
we
need
to.
We
need
to
invert
our
mindset
to
where
there's
no
friction
around
stability
right
and
there's
friction
around
breaking
stability.
O
That's
that's
the
shift
and
yes,
it's
started
to
happen.
I
would
even
argue,
though,
I'm
getting
bug
reports
of
metric
users
and
that
terrifies
me.
People
are
trying
to
take
a
dependency
on
this,
and
you
know
that,
like
there's
there's
a
level
of
stability,
we
need
to
start
thinking
about
that.
I'm
just
throwing
out
there.
O
This
is
the
kind
of
thing
that
I
think
we
could
do
it
in
a
way
where
we
get
to
change
the
spec
and
have
stability
right,
and
so
that's
why
I
threw
out
the
question,
but
I
agree
with
you:
the
community
is
moving
in
the
right
direction.
I
didn't
intend
to
go
as
quite
as
far
as
maybe
I
implied
so
I
apologize
if
it
came
across
that
way,
but.
K
It's
really
fine
yeah.
I
just
want
to
emphasize
that
you
know
we're
we're
in
this
process
right
now.
It's
not
that
we
haven't
started
it,
but
I
completely
agree
even
things
that
are
marked
as
quote-unquote
experimental
still
like
semantic
conventions,
for
example,
are
a
thing
I
want
to
talk
about
this
at
spec
meeting
tomorrow,
because
we're
linking
from
stable
portions
of
the
dock
in
the
sdk
to
something
that
is
experimental.
K
The
semantic
conventions
and
people
are
saying
hey
this
isn't.
This
is
incorrect.
It
shouldn't
be
written
this
way,
I'm
like
what
is
correct
relative
to
what
we
have
said
decided
to
do.
But
that
means
like
if
we're
gonna
keep
some
things
experimental
that
doesn't
it's
not
the
same
as
saying
we
can
just
thrash
them
around
right,
like
some
things
are
maybe
still
experimental,
because
we're
wanting
to
reserve
the
right
that
maybe
we
should
get
past
ourselves,
reserving
the
right
on
some
of
these
things.
K
I
kind
of
presume
when
we
make
a
big
announcement
around
tracing
stable,
we're
going
to
see
a
bump
in
usage
and
those
users
are
going
to
be
even
less
even
more
allergic
to
change
than
the
users
we
already
have
so
you're
completely
right
in
saying,
like
our
general
culture,
around
stability
has
to
has
to
improve,
because
it's
just
it's
like
the
concrete
starting
to
set.
You
know.
M
Okay,
so
I
think
everyone
agrees
and
probably
we
should
not
make
a
decision
right
now
and
probably
we
should
sleep
on
it
until
tomorrow
I
would
say,
but
as
as
we
mentioned,
we
have
two
remaining
issues
before
declaring
1.0
this
one
and
the
other
one
is
josh
pr
which
I
think
we
need
to
resolve
one
way
or
the
other.
We
either
accept
them
or
we
drop
them
and
that's
it,
but
I
think
at
least
this
one
for
for
george
pr.
I
think
we
should
merge
it
right
away
and
fix
this
yeah.
J
M
M
Do
we
want
to
have
different
tags
for
for
trace
and
metrics,
or
the
tag
will
be
one
zero
and
we
will
say
that
matrix
is
not
stable,
based
on
the
status
of
the
message
of
the
the
the
document,
but
so
so
the
point
is
where,
if
we
stay
at
zero-
and
we
say
that
trace
is
stable,
then
then
is
one
option.
The
second
option
is
we
go
to
one
zero
and
we
say
metrics
is
not
stable.
C
Which
one
is
better
like
open
I'd,
say
one
zero,
while
clarifying
that
metrics
is
unstable,
it's
probably
preferable
just
because
it
implies
that
the
first
there
is
part
of
it
that
is
now
stable.
E
K
Yeah,
I
have
a
pr
right
out
right
now
that
that
marks
almost
every
document
as
being
either
stable
or
experimental.
That's.
M
No,
no,
that
should
be
merged
anyway,
that
that
should
we
should
have
at
every
document
the
status
of
that
document.
That's
fine!
But
now
now,
in
terms
of
the
tags
that
we
put,
do
we
put
one
zero,
which
means
the
documents
that
are
not
stable
are
not
stable
via
the
status
or
we
keep
zero.
Something
and
the
documents
that
are
stable
are
stable
via
stuff.
M
So
so
it's
it's
it's
very
similar
one
way
or
the
other
some
documents
via
the
status
will
will
have
a
different
different
meaning
than
the
version
of
the
tag
that
we
put
in
the
in
the
in
the
repo.
So
that's
the
the
the
question
is:
is
the
opt-in
or
opt-out
like
opt-in,
meaning
like
do
we
opt-in,
stable
documents,
or
do
we
opt
out
unstable
documents.
K
K
So
maybe
the
more
nuanced
question
here
is:
how
do
we
batch
up
and
release
spec
changes
going
forwards
in
a
way
that
allows
maintainers
to
to
target
a
specific
version
of
the
spec,
because
I
think
right
now
there
has
been
an
issue
with
people
are
kind
of
just
running
to
keep
up
with
the
latest
unmer
the
latest
unreleased
portion
of
this
spec,
and
we
should
probably
change
that
and
also
practice
semver,
which
means
you
know
we'll
be
making
breaking
changes
potentially
to
like
metrics
or
the
logging
stuff,
and
those
things
should
be
doing
potentially
major
version
bumps
right,
like.
M
E
K
K
Of
the
spec
and
now
we're
saying
it
works
this
way,
and
so
you
know
the
spec
version
number
will
just
just
increment
a.
M
K
B
K
B
K
How
are
we
failing
the
user
if
we've
got
specific
stability
guarantees
around
each
portion
of
the
document?
Right
like
it's
not
like,
because
you
are
going
to
2.0
that
it
means
you're
allowed
to
break
a
stability
guarantee
somewhere?
No
it
doesn't.
It
doesn't
mean
that,
like
we
have
like
specific
definitions
of
stable
and
experimental,
and
we
have
definitions
of
like
support
guarantees
associated
with
those
things
right
like
that's,
where
we're
applying
our
guarantees,
not
with
the
version
number
of
the
specification
so
because.
M
M
Why
the
version
number
matters
at
all?
Why
do
we
not
stay
at
zero
and
we
just
use,
as
I
proposed?
We
just
use
the
statuses
as
the
status
quo
of
things,
and
we
just
don't.
I
mean
for
me
for
me,
it
will
be
a
fail
again
will
be
a
fail,
a
big
fail
if
we
end
up
in
may
when
and
when
metrics
will
be
done
with
specs
10.0.
K
I
guess
I
don't
see
why
that
would
be
a
fail.
It
would
be
a
fail
if
we
broke
stability
for
things,
not
that
we
virgined
according
to
senbeir,
but
we
can
keep
talking
about
this.
I
think
this
calls
gone
long.
E
I
just
had
one
one
question
the
which
I
had
on
the
agenda
and
that's
again
I
would
like
to
get
a
repo,
because
I
would
like
to
you
know,
find
all
the
issues
for
the
prometheus
work
that
is
getting
done
and-
and
this
was
discussed
in
the
governance
committee-
and
you
know
there
is
a
model
of
the
kubernetes
where
group,
the
groups,
being.
You
know,
having
a
reaper
for
tracking
progress
so
again
would
like
to
kind
of
recommend
that
for
also
us
using
this
for
work
group
activities.
E
Of
course,
these
are
then
tied
back
into
the
sixth,
but
just
being
very
specific.
M
What
what
group,
I
think
about.