►
From YouTube: 2021-02-23 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).
B
A
B
A
Hoodies
got
mine,
I
I
guess
if
for
people
who
didn't
maybe
attend,
kubecon
san,
diego
yeah.
B
I
think
there's
maybe
some
like
international
people
that
were
supposed
to
get
them
and
then
you
know
pandemics
happened.
D
A
Before
we
start
hey
bob,
did
your
blog
post
get
published.
F
F
Yeah,
maybe
they're
just
trying
to
you
know
whatever.
D
Yeah,
don't
see
other
things
on
the
agenda,
so
maybe
you
can
dig
into
this.
I
wanted
to
call
the
maintainer's
attention
to
this
doc.
Let
me
share
my
screen
here.
D
So
this
is
about
planning
the
the
next
phase
of
open
telemetry,
just
to
do
a
quick
overview
of
what
we're
thinking,
we're
trying
to
get
a
more
concrete
timeline
together,
going
forwards
this
year
being
able
to
properly
kind
of
gantt
chart
out
time
blocks
figuring
out
when
things
like
the
metrics
work,
for
example,
is
going
to
land
as
like
something
in
the
spec.
That
maintainers
will
want
to
turn
their
attention
to
so
that
we
can
get
metrics
out
the
door
quickly.
D
But
in
the
meantime
we
want
projects
like
that
to
remain
more,
like
smaller
groups,
doing
more
thorough
design
and
prototyping
work
so
that
we're
not
kind
of
like
thrashing
on
metrics
the
way
we
sort
of
were
on
tracing
in
the
meantime.
That
gives
us
a
window
to
continue
to
work
on
our
existing
offerings.
D
You
know
api
and
sdk
stability,
but
there's
sort
of
like
all
of
the
stuff
that
that
goes
on
top
of
that
and
different
projects
are
in
different
shape
relative
to
the
projects
listed
in
this
stock.
But
these
are
the
the
the
things
that
users
have
given
us
feedback
about,
where
they
would
like
to
see
improvement
in
the
project.
D
So
I
kind
of
see
the
the
next
round
of
work
and
it
seems
like
we
have
about
five
to
six
months
in
which
to
do
this.
Work
should
just
be
focused
on
kind
of
cleaning
up
what
we
currently
have
expanding
the
amount
of
instrumentation
that
is
available,
so
I
can
just
walk
through
this
very
quickly
and
then
maybe
we
can
just
have
a
quick
discussion
just
get
feedback
from
maintainers
about
what
they
think
about
all
of
this,
and
if
we
have
time
after
that,
maybe
dig
into
one
of
these
projects.
D
D
D
They
don't
know
what
instrumentation
packages
they're
going
to
need
in
order
to
ensure
their
traces
are
being
propagated,
and
so
especially
for
that
new
user.
That
kind
of
like
first
time
experience
with
open
telemetry.
I
think
we
could
do
work
there
to
make
that
process
simpler
and
easier
for
people.
D
I
think
this
is
especially
helpful
for
new
users,
because
in
open
source,
users
tend
to
have
like
a
pretty
low
tolerance
for
like
how
much
they
want
to
muck
about
when
they're
exploring
a
new
prof
project
before
they're
kind
of
like
this
is
too
complicated
if
they
really
need
it.
For
like
a
production
thing,
then
they're
willing
to
dig
in
and
do
the
work
but
open
source
projects
that
tend
to
be
successful
at
attracting
a
big
user
base
also
tend
to
have
a
easy
to
get
started
story.
D
I
think
of
frameworks
like
rails,
where
rails
is
super
complicated
framework,
a
lot
of
plug-ins,
a
lot
of
ins
and
outs
engines
all
this
crazy
stuff.
But
it's
still
something
where
you
can
just
get
started
with
a
little
cli
tool
or
whatever
and
just
be
like
bam.
D
I
have
a
project
and
just
just
get
straight
to
work
so
figuring
out
what
that
would
mean
for
for
open
telemetry,
I
think,
is
an
important
thing
to
focus
on
over
the
next
five
months
and
aspects
of
that
where
people
currently
kind
of
have
some
trouble
like
package
management.
Do
they
is
there
a
way
to
just
have
an
easy
mode
where
you
get
all
of
the
packages
encapsulation
of
configuration?
D
So
is
there
a
way
to
configure
open
telemetry
that
seems
kind
of
like
concise
and
elegant?
This
varies
across
projects.
How
much
we
have
a
well
factored
project,
but
that
can
kind
of
look
a
bit
like
tinker
toys
when
you're
setting
up
a
bunch
of
providers
and
things
once
you
understand
open
telemetry.
You
appreciate
having
control
over
all
that
stuff,
but
for
the
new
user
doesn't
know
what
any
of
that
is
having
something
like,
maybe
a
default
setup
that
they
can
get
running
when
they're
say
running
locally
in
their
development
environment.
D
D
Open
telemetry
can
be
hard
to
debug,
especially
when
you're
new
and
you're
not
even
sure
what
it's
supposed
to
be
doing
in
the
first
place,
and
part
of
this
is
like
you
know,
when
your
observability
tool
doesn't
work.
How
do
you
observe
what
your
observability
is?
So
that
can
be
problematic?
The
the
other
thing
open
telemetry
has
to
tangle
with,
I
think,
just
naturally,
as
a
result
of
what
it
does
is
a
lot
of
the
errors
or
mistakes
you
can
encounter
when
you're
setting
it
up
result
in
silent
failures.
D
So
it's
not
the
case
that
you
get
an
error
message,
saying:
hey.
You
forgot
to
install
a
plugin
for
your
http
library,
so
traces
aren't
going
to
propagate
or
hey
you
misconfigured
your
propagators,
so
you're
trying
to
use
baggage,
but
you
didn't
turn
the
baggage
propagator
on
or
using
b3
in
this
service
and
trace
context
in
this
other
service.
It's
not
those
aren't
errors
that
that
it's
easy
just
to
get
an
error,
log
and
kind
of
start
from
that
breadcrumb.
D
So
looking
at
ways
that
we
could
improve
diagnostics
so
that
a
user
could
say
get
a
printout
of
like
what
their
configuration
is
and
what's
installed,
or
things
like
that,
something
that
would
be
easy
to
say
copy
and
paste
into
slack
and
be
like
I'm
having
trouble.
This
is
my
setup
things
like
that
I
think
are
worth
exploring,
because,
even
as
like
an
experienced
person,
I
often
find
when
I'm
trying
to
set
this
up
for
real
with
someone
on
a
real
system.
D
You
could
just
run
into
little
mind
enders,
so
figuring
out
a
way
that
that
we
can.
We
can
simplify
things
for
a
basic
use
case,
but
I
don't
think
that's
a
substitute
for
for
having
diagnostics
to
help
people
through
this
stuff.
D
The
third
thing
is
just
like
a
convenience
api.
I
think
we've
been
talking
about
this.
A
lot
open,
telemetry
is,
is
well
factored,
but
that
also
means
in
some
languages
there's
a
number
of
different
packages
you
need
to
use,
and
the
api
is
really
kind
of
designed
to
paint
all
the
way
out
to
the
edges
and
cover
all
the
different
use
cases
you
might
want
to
use.
D
But
when
you're
an
application
developer,
not
someone
necessarily
writing
like
library
instrumentation,
but
like
an
application
developer,
your
use
cases
are
often
like
pretty
basic,
and
you
can
make
a
lot
of
assumptions
like
you
can
assume
say
that
there's
an
active
span
available
and
when
you
start
making
some
of
those
assumptions
there's
often
a
a
simpler
api
or
more
declarative
api.
We
could
give
people
that
just
kind
of
covers
those
those
basic
use
cases
and
two
varying
degrees.
Different
languages
are
doing
something
like
this,
but
there's
been
a
request.
G
D
Are
doing
on
this
front,
so
that's
the
thing
that
I
think
would
just
basically
making
the
api
from
an
application
developers
perspective
a
little
more
elegant,
so
their
application
code
doesn't
get
full
of
open
telemetry
code
when
they
want
to
use
it.
So
annotations
are
another
great
example
of
things
that
make
this
nice
for
people.
H
It's,
like
all
of
our
documentation,
has
normally
been
like
here's
how
to
use
the
very
complicated
api
with
a
bunch
of
try
catches
and
a
finally
and
all
this
kind
of
stuff,
and
if
you
just
say
don't
do
any
of
that
stuff,
if
all
you
need
is
to
add
an
attribute
to
existing
span.
Here's
how
you
do
it
if
you
want
to
create
a
new
span,
here's
how
you
do
it
one
line
simple,
and
it
makes
a
big
difference
to
everybody
in
the
field,
especially
trying
to
use
this.
D
Stuff
for
the
first
time,
absolutely,
I
think
we
need
to
have
like
one
set
of
docs.
That's
for
people
who
are
like
instrumentation
authors
who
want
to
get
down
in
the
weeds
and
then
yeah
this
super
simple
stuff
for
the
application
developer
yeah,
it's
crazy
like
when
you
go
from
like
managing
a
span
to
just
typing
with
span
at
the
top
of
your
method,
it's
and
like.
Where
would
you
put
that
span
management
if
you're
trying
to
wrap
a
method
you
know
other
than
like?
D
There's
it
just
really
makes
life
easier,
so
any
language
where
we
can
do
that
kind
of
stuff?
It's
it's
helpful
and
even
in
languages
where
we
can't
there's
often
like
convenient
things
that
maybe
don't
work
in
every
situation,
but
just
like
a
closure
that
that
manages
to
span
for
you
or
whatever
so.
B
G
B
G
B
D
Yeah
totally,
I
completely
agree.
There's
like
it's
sort
of
like
assume.
Someone
has
set
this
up
properly
for
you
already
either
that's
auto
instrumentation.
Did
it
or
somebody
did
it
and
and
you've
got
context
propagation,
all
the
good
stuff
already
there
and
you
just
want
to
quickly
decorate
your
application
code
with
additional
stuff
to
make.
You
know
your
data
better
yeah.
We
tend
to
have
docs.
D
That
right
now
are
like
very
basic
examples
of
like
here's,
how
you
use
the
span
or
tracer
api,
but
they're
not
really
tied
into
like,
like
the
real
world
scenario,
so
there's
this
kind
of
gap.
Likewise
for
instrumentation
developers,
there's
kind
of
a
gap
between
like
here's
an
example
of
what
the
api
does
versus
like
here's,
how
you
would
use
it
in
these
use
cases.
I
think
people
tend
to
to
fall
into
that
gap
right
now,
so
that
would
be
great
and
on
the
same
vein
instrumentation.
D
This
is
like
the
biggest
bug
bear,
I
think,
in
open
telemetry.
In
the
short
term,
all
the
effort
is
on
getting
these
clients
like
up
and
running
and
working
properly
and
all
of
that,
but
over
the
long
term.
Instrumentation
I
predict
is
the
the
the
huge
amount
of
effort,
like
I
believe,
work
on
instrumentation,
ultimately,
over
the
next
couple
years,
we'll
probably
dwarf
the
work
we're
putting
into
the
clients,
because,
presumably
that
client
work
will
maybe
taper
off
a
bit.
But
instrumentation
is
like
something
that
never
goes
away.
D
G
I
have
a
comment
on
this.
I
think
this
is
obviously
very
important.
I
think
equally
important
for
us
is
to
create
an
environment
where
other
third-party
developers
actually
start
doing
the
instrumentation
rather
than
us
doing
it.
So
it
may
be
an
effort
better
spent
for
us
to
create
that
place
where
it's
very
easy
for
them.
We
encourage
them
to
do
that,
instead
of
us
doing
actually
all
of
that
work.
D
Totally
yeah,
I
I
definitely
think
if
you
look
at
the
discussions
we've
had
so
far,
they
tend
to
not
be
focused
on
like
I'm
having
trouble
writing
instrumentation.
We
we
can
all
do
that.
That's
it's
not
that
complicated,
but
it's
like.
Where
does
it
go?
Does
it
all
live
in
one
giant,
contrib
library,
if
there's
third
party
stuff,
that
other
people
are
hosting,
do
we
install
that
for
them
automatically
in,
like
our
get
all
your
instrumentation
package
launcher
things,
or
do
we
not
trust
that
stuff?
D
And
I
do
wonder
whether
projects
that
are
focused
on
having
things
like
test
harnesses
or
things
that
can
help
help
you
write
instrumentation,
but
also
let
you
judge
the
quality
of
instrumentation,
so
that
people
don't
need
like
a
personalized
review
from
a
maintainer
necessarily
to
to
understand
whether
they
did
it
right
and
then
something
like
a
registry
or
just
how
are
we
going
to
manage
all
of
these
endlessly
growing
repos
in
a
way
where
we're
still
doing
security
checks
and
things
like
that,
but
we're
also
making
sure
the
user
doesn't
have
to
hunt
across
the
internet
to
find
these
things
and
install
them
themselves.
D
So
that's
just
it's
just
a
number
of
things
that
kind
of
pull
on
each
other
in
different
directions
like
we
want
it
all
in
one
big,
auto
instrumentation
package,
so
there's
like
a
one-stop
shop.
But
how
does
that
work
with?
We
don't
want
to
write
it
all
ourselves
and
we
prefer
other
people
maintain
it.
Yeah.
D
It's
definitely,
I
think
what
tigran
says
is
if
we
build
the
environment
and
the
structure,
if
we
focus
on
that
and
focus
on
documentation
explaining
to
people
how
to
do
this
stuff
and
even
starting
to
beat
the
drum
on
like
native
instrumentation.
I
think
it's
like
slightly
early
for
that,
but
that's
like
an
ultimate
goal.
G
I
D
Couple
reasons:
one
we're
only
just
going
stable
right,
so
I
think
it's
almost
like
inappropriate
at
this
time
moment
to
be
like
jam
this
thing
into
your
project
in
a
way
that
you
can't
pull
it
out.
We
don't
want
people
ever
putting
open
telemetry
into
their
their
project,
natively
and
then
later
tearing
it
out
for
some
reason
and
complaining
about
it.
D
I
Experience
that
might
be
might
be
not
that
great
I
mean
I
mean,
in
my
opinion,
sometimes
can
be
misdirected
effort
for
us
or
somebody
else
to
write,
for
example,
auto
instrumentation
for
some
connection
pool
library.
Instead
of
that
connection
pool
library
to
built
in
instrumentation
to
itself,
it's
like
in
some
sense
wasted
effort
not
exactly
but
duplicated.
At
least.
D
So
so
we
have
to
do
the
work
of
building
out
this
ecosystem
anyways,
but
I
agree
that
it
does
seem
like
if
we
built
the
instrumentation
first
and
then
they
built
it
in
natively
that
might
be
duplicate
effort,
but
at
the
same
time,
if
we
already
have
some
instrumentation
and
we
go
to
them
and
be
like,
do
you
want
to
bake
this
in
like
it,
it
might
help
give
library
authors
a
guide
to
to
work
with,
to
a
certain
degree.
I
think.
B
There's
always
going
to
be
a
need
for
the
existing
instrumentation,
because
people
aren't
going
to
go
back
and
write
these
plugins
for
already
released
things,
especially
if
they
don't
already
have
some
way
to
do
that
right,
like
you're,
not
going
to
see
back
ports
of,
I
don't
know,
pick
something
kafka
client
like,
especially
if
the
work
is
already
done,
and
it
already
serves
a
purpose
like
I
think,
you'll
see,
maybe
see
maintainers
agree
to
go
on
a
moving
forward
basis.
B
Keep
in
mind
like
open
tracing,
existed
in
a
fairly
stable
state
for
several
years
and
had,
I
would
say,
fair
to
midland
adoption
in
projects
where
it
wasn't
explicitly
added
by
like
a
stakeholder
right
like
you,
didn't
necessarily
see
this
huge
upswell
of
like
oh
yeah.
Let's
go
add
that
in
I
without
more
evidence
to
the
contrary,
I
don't
know
if
open
telemetry
is
going
to.
B
G
Yeah,
it
is
definitely
a
long-term
goal
and
I
think
we
need
to
make
it
easy
and
we
also
need
it
needs
to
be
easy
and
it
needs
to
be
necessary
for
the
third-party
developer.
G
Easy
means
that
we
have
to
make
it
easy
necessary
means
that
open
telemetry
has
to
be
so
popular
that
not
having
open
telemetry
instrumentation.
Is
your
life
in
your
library
is
going
to
be
a
point.
That
is
something
something
negative
about
your
library
right.
So
that's
very
far
away
from
now
right.
D
If
it's
value,
if
it's
value-add,
I
would
avoid
negativity
but
yeah
if,
if
it's
the
kind
of
thing
where
users
are
starting
to
go
to
library,
maintainers
and
be
like,
could
you
add
this
because
I
like
it?
That
would
be
ideal.
Yeah,
maybe
another
point
nikita
is.
I
do
think
we
should
start
talking
about
this.
D
This
is
the
other
thing
we
need
to
start
doing
more
in
public
on
the
website
and
the
blog
it's
just
just
kind
of
starting
from
the
beginning
and
reiterating
you
know
the
basic
value
proposition
of
open,
telemetry,
the
project
structure,
how
everything's
divided
up
like
our
ultimate
goals
of
native
instrumentation,
getting
that
story
out
there
and
clear
on
the
website
and
other
places.
I
definitely
think
it's
time
to
do
that
work.
I
just
would
maybe
hold
off
trying
to
like
lobby
lobby
projects
too
hard
to
to
use
it.
D
So
like
integration
testing,
someone
can
write
an
integration,
testing,
harness
and
kind
of
sort
that
out
and
get
that
whole
thing
going.
It's
not
like
all
the
maintainers
have
to
deal
with
that
all
at
once.
D
So
some
of
these
are
things
that
I
think
our
small
projects
that
it
would
be
nice
to
flush
out,
because
the
more
we
flush
them
out
the
easier
it
is
for
a
group
to
come
in
and
pick
it
up.
For
example,
if
we
want
to
get
more
resources
from
like
one
of
the
you
know
existing
contributors
having
more
projects
that
can
happen
in
parallel
that
don't
involve
the
maintainers
having
to
to
manage
it.
D
All,
I
think,
would
be
a
way
we
can
parallelize,
and
so
I
tried
to
identify
things
that
were
critical
for
ga,
there's,
also
stuff.
That
would
just
be
rad.
I
listed
yes,
one
which
is
like
my
little
dream.
Project,
which
is
once
c
plus
plus,
is
ready.
It
would
be
cool
to
start
binding
that
things
to
languages
that
are
say
like
single
threaded,
where
you
could
see
a
big
performance
boost
if
people
wanted
to
take
on
a
c
plus
plus
dependency.
D
That's
like
a
cool
project.
Someone
could
kind
of
go
work
on
in
a
corner
and
not
bother
people,
but
other
people
feel
free
to
add
to
these
lists.
This
is
where
this
is
the
area
where
I
think
we
can.
We
can
just
like
start
kind
of
blue
skying
ideas.
C
J
I
really
like
that
idea,
but
I
would
say
always
know
to
have
way
more
code
to
maintain
and
more
code
to
deal
with,
but
anyway,
let's,
let's
move
to
the
next
topic.
I
think
we
can
discuss
when
the
time
comes
with
this
nice
to
have
if
it's
worth
it
or
not
doing
it,
but
just
document
some
of
them.
D
D
Many
of
them
maybe
involve
a
certain
amount
of
design
work
and
then
trying
to
get
ultimately
a
timeline.
We're
going
to
put
up
on
the
open,
telemetry
website
kind
of
explaining
what
we're
going
to
do
over
the
next
five
months
and
then
expectations
around
metrics
kind
of
landing
and
logs
and
other
things
like
that.
D
So
so
that's
the
goal.
I
don't
know
how
much
other
things
we
have
on
the
website.
There's
there's
some
sorry
website
on
the
meeting
notes.
D
Maybe
we
can
go
through
the
rest
of
the
meeting
and
if
there's
time
at
the
end
come
back
to
this,
but
I
would
love
feedback
either
through
slack
or
or
anywhere
or
just
you
know,
comments
in
this
doc
about
ideal
ways
to
to
put
these
projects
together
and
manage
them
or
questions
and
concerns,
or
anything
like
that,
because
we'd
like
to
get
this
this
cooking
over
the
next
couple
of
weeks.
So
maybe
this
is
something
we
can
roll
out
a
bit
through
asynchronous
discussion
in
slack.
A
Or
even
synchronously
in
some
of
these,
these
calls
in
upcoming
weeks
right
because
we've
typically
been
so
focused
on
the
tracing
release.
That's
done,
metrics
isn't
necessarily
something
as
maintainers.
We
need
to
focus
on
at
the
moment
quite
as
tightly
as
we
were
before.
So
I
think
this
becomes
the
main
topic
of
discussion
going
forward.
D
D
We
have
something
that's
more
like
concrete
plans
that
people
are
kind
of
excited
about,
and
also
my
hope
is
that
maintainers
feel
like
they
have
a
sense
of
what's
coming
up
and
how
much
time
they
have
to
focus
on
things,
so
they
can
time
box
stuff
feedback
in
general
from
maintainers
about
whether
they
feel
like
they're
context,
switching
too
much
where
there's
like
too
many
things
flying
around
they're,
not
sure
what
to
work
on.
D
A
Awesome
bob
I
signed
you
up
for
the
next
topic.
If
you
just
wanted
to
spend
a
minute
on
on
your
user
feedback,
blog
post
sure
so.
F
For
those
unaware
we
posted
a
blog
post
last,
I
think
it
was
last
friday
about
the
user
feedback
research
document
that
ted
conjured
up
ted
also
did
some
wonderful
illustrations
for
that
blog
post
and
was
an
editor,
so
I'm
giving
them
extra
credit
where
it's
due
we
had.
So
we
had
a
really
good
time
learning
about
what
it's
like
for
a
practical
implementation
of
our
library
with
with
a
client.
So
we
found
somebody
that
had
symphony
knowledge,
but
no
ph
open,
telemetry,
php
knowledge
and
that
person
was
able
to
implement
our
library.
F
It's
still
very
rough,
just
in
case
you're
curious,
but
they
were
able
to
take
a
look
at
it
and
they
gave
us
some
really
great
feedback
and
I'd
encourage
other
other
cigs
to
do
this
too,
because
it
gave
us
a
bunch
of
ideas
about
things
that
we
just
had.
No
clue
that
we
needed
to
implement.
I
use
the
analogy
at
my
workplace
often
that
I
know
how
the
engine
works,
but
I
very
rarely
drive
the
car
and
I
think
that
that
perfectly
encapsulates
the
feedback
we
got
from
this
document.
F
F
I
know
ted
was
talking
a
lot
about
this
with
making
things
a
lot
more
of
a
delight
for
end
users,
and
I
think
doing
like
getting
feedback
like
this
can
be
really
helpful
in
order
to
see
where
your
library
is
gapping
from
what
an
end
user
would
expect
for
a
production
implementation
of
something-
and
most
of
these
changes
have
nothing
to
do
with
api
or
sdk
wouldn't
be
breaking.
F
So
this
might
be
a
really
good
thing
for
one
of
your
interns
to
tackle
or
for
somebody
who's
new
to
the
project
that
wants
to
get
started.
That's
a
great
end
user
experience
or
somebody.
That's
new
ish
to
the
project
could
solicit
or
like
take
the
feedback
and
make
it
actionable
in
ticket
form
or
whatever.
So
I
would
very
much
encourage
others
to
follow
ted's
document,
because
it
was
helpful
for
us.
A
Awesome,
thank
you
bob
all
right.
Next
is
me
and
ted
doing
the
burn
down.
I
don't
know
if
we
really
need
to
go
to
it
too
much
today,
but
I'll,
just
very
quickly,
present
and
otherwise
cut.
This
short
just
give
me
a.
D
A
All
right,
so
we
have
18
metric
spec
issues,
I'm
not
going
to
go
into
those.
We
can
go
over
those
on
the
spec
call
in
the
metric
spec
calls.
We
have
one
remaining
trace
issue
that
we've
had
punted
from
ga,
so
it
was
no
longer
required
for
ga
that
allowed
for
ga
and
that's
the
otlp
and
sorry
otlp
json
trace
support.
So
that's
on
its
way.
A
I
think
that
was
particularly
important
for
opens
for
the
browser
like
front-end
javascript
library,
but
it
isn't
being
used
everywhere
and
that's
basically
the
update
for
this
week.
I
didn't
attend
the
spec
calls
last
week,
but
I
will
be
continuing
to
attend
them
regularly
starting
this
week.
So
I
don't
have
a
whole
lot
of
other
context.
But
if
there's
anything
people
want
to
discuss
here,
we
can
otherwise
I'll
move
on.
D
D
So
we're
going
to
think
about
how
we
can
have
like
separate
project
boards
and
maybe
some
some
automation
that
helps
keep
them
in
sync,
where,
if
you
just
apply
a
label,
they'll
put
on
the
board
and
things
like
that,
but
definitely
if
people
have
processes
through
using
github
projects-
and
things
like
this-
that
they
think
are
good
processes
that
are
helpful,
definitely
open
to
feedback,
especially
interested
in,
like
looking
at
other
projects
that
are
that
are
doing
this
kind
of
thing,
if
you
think
they're
doing
a
good
job.
A
All
right
and
next
bogdan,
your
question
is:
adding
a
new
method
to
the
public
api,
a
breaking
change.
J
So
I
saw
this
in
the
specs
and
some
of
the
people
raised
the
issue
that,
for
example,
adding
a
new
functionality
to
the
span
like
ads
full
or
something
like
that
will
be
a
consider,
a
breaking
change,
and
I
think
we
need
to
clarify
that.
We
follow
somewhere
and
based
on
the
same
where
this
is
not
a
breaking
change.
But
maybe
I'm
wrong,
and
I
want.
J
K
K
K
For
for
whom?
For
what?
For
any
end
user
that
depended
on
that
interface,
so
say
if
you
have
a
particular
interface
that
we're
exporting
and
a
user
has
defined
some
sort
of
structure
to
implement
that
interface
and
we
go
and
we
update,
we
add
a
method
to
it.
Their
structure
no
longer
implements
that
interface
and
it's
a
compilation
error.
But
that's
not.
I
mean.
J
Okay,
who,
who
is
that
persona
like
because
that's
not
an
instrumentation
for
sure,
that's
most
likely
an
alternative
implementation
or
maybe
an
app
well.
K
I
mean
it
doesn't
really
matter
about
the
you
know
the
persona,
it's
a
breaking
change.
Like
I
mean
it
you
can
you
can.
I
can
construct
a
person,
but
at
the
end
of
the
day
like
if
there
is
a
person
and
that
person
will
experience
a
compilation
error
due
to
the
fact
that
we've,
you
know
added
a
method
that
would
cause
you
know,
that's
that's
a
breaking
change
and
that's
not
compatible
with
center
easy
yeah.
No,
that's
not
like
any.
You
know.
K
K
L
L
L
H
G
J
No
I'm
let's
first
understand
and
then
jump
to
solutions.
I
mean
yes,
indeed,
java
has
this
way
of
defining
default?
Other
languages
may
have
a
way
to,
for
example,
ex
put
expose
abstract
classes
instead
of
interfaces.
The
way
java
did
before
java
8
for
for
this,
but
I'm
I'm
curious
and
asking
is
this
consider
a
breaking
change
or
not
in
the,
and
if
it
is
how?
How
can
we
make
sure
that
we
structure
the
project
in
a
way
that
this
is
not
going
to
block
us
to
move
forward.
G
J
E
from
from
specs
purpose
is
adding
a
new
method,
consider
a
breaking
change
and
we
should
do
a
v2
or
is
this
has
to
be
resolved
language
by
language
and
every
language
finds
its
way,
defining
a
new
interface,
adding
default
method,
implementation
whatever
it
is
that
I'm
asking
from
specification
perspective
and
from
from
theoretically
like
if
we
want
to
add
a
new
functionality.
That
requires
a
new
method
on
a
on
an
interface
on.
L
D
D
We
need
to
make
sure
we're
running
that
by
at
least
a
chunk
of
the
maintainers
right,
because
I
have
found
in
the
past
that
the
answer
is
truly
somewhat.
It
depends
to
give
an
example
from
from
open
tracing.
We
wanted
to
add
the
ability
to
like
get
trace
id
that
wasn't
on
there.
So
we
wanted
to
add
that,
but
it
turned
out
there
were
a
number
of
implementations
out
there.
D
Already
that
had
already
implemented,
get
trace
id
and
since
open
tracing
had
was
structured
in
a
way
where
you
were
expected
to
bring
your
own
implementation,
we
had
to
think
of
just
literally
think
of
a
different
name
for
that
method,
to
ensure
that
it
didn't
collide
with
the
thing
that
was
already
there.
So
that's.
D
Of
like
you
need
to,
I
think,
when
we
go
to
add
new
functionality,
I
don't
think
we
should
just
assume
attacking
them
that
all
all
functionality
is
equal.
If
that
makes
sense,
but.
J
But
that
example
with
get
trace
id
by
the
way,
it's
a
another
good
example.
Should
we
care
about
the
fact
that
an
alternative
implementation
extended
our
public
interface
with
some
method,
I
would
say
no,
I
would-
and
I
would
say
they
should
probably
prefix
their
methods
with
their
stuff
in
a
way
that
they
allow
us
to
to
not
break
things.
So
so
I
think
this
has
also
to
be
commented
on
our
specification
that
alternative
implementations
should
not
steal
the
names
for
for
our
interfaces.
G
Confused
confused
with
this
discussion,
so
adding
a
function
to
an
interface
is
not
a
breaking
change
for
the
color
of
the
interface.
It's
a
breaking
change
for
the
implementer
of
the
interface
correct.
Now
right!
So,
if
we
want
to
add
an
api
that
is
available
for
callers,
we
should
be
able
to
do
that.
The
open,
limited
specification
tells
that
there
has
to
be
an
in
an
op
sdk
right.
G
That
provides
everything
that,
if
you
add
a
new
api,
call
that
knob
should
implement
it
at
the
same
time
right,
correct
and
if
your
sdk
is
not
yet
implementing
that
api.
It's
your
job
to
actually,
when
you're,
releasing
an
sdk
to
implement
that
that
is
a
breaking
change
for
the
sdk
writer
for
the
person
who
writes
the
sdk,
but
it's
not
a
breaking
change
for
the
user
of
the
open,
telemetries
api.
E
I
think
well
that
that
may
depend,
though,
right
so
like
some
interfaces
like
span.
Processors
are
likely
to
be
implemented
by
users
and
if
we
were
to
add
methods
to
those
that
could
have
widespread
breaking
changes
to
a
lot
of
implementations
that
are
out
of
our
control.
D
We
really
want
to
separate
out
what
are
interfaces
that
are
plug-in
interfaces
that
we're
providing
to
other
people
versus
interfaces
that
are
we're
just
expecting
people
to
use
these
interfaces,
we're
not
expecting
them
and
generally
that
is
super
compartmentalized,
both
in
our
code
and
in
the
spec
right,
like
the
what
we
call
the
api
does
not
contain
anything
in
it
that
a
user
is
expected
to
implement
everything.
The
user
is
expected
to
implement
are
plug-in
interfaces
that
are
part
of
the
sdk,
and
so
that
isn't
with
the
api.
D
The
number
one
thing
that
we're
trying
to
avoid
just
to
be
clear
is
that
different
versions
of
the
api
are
incompatible
with
each
other.
Right,
like
that's,
maybe
that's
just
obvious,
but
that
that
is
the
thing
we
have
to
preserve
at
all
costs,
because
we
don't
want
libraries
that
are
using
older
versions
of
the
api
to
no
longer
be
able
to
compile
with
other
libraries
that
have
moved
on
to
a
new
newer
version.
D
So
when
we
say
like
api
compatibility,
that
that
is
what
we're
actually
talking
about,
ensuring
that
users
can
continue
to
upgrade
to
the
latest
version
of
the
sdk.
In
the
latest
version
of
the
api
and
not
have
that
break
their
code,
there's
like
a
middle
ground
of
like
well
what,
if
a
user
like
intercepted
or
did,
did
something
with
these
apis
that
that
we
didn't
intend
for
them
to
do,
but
they
did
it
anyways.
D
D
You
have
to
to
move
forward
and
update
that
stuff,
but
for
people
who
are
purely
writing,
instrumentation
they're
the
people
we're
focused
on
when
we
say
no
breaking
changes
in
the
api,
but.
J
K
Right,
so
I
think
that's
a
really
good
point
that
I'd
like
to
kind
of
maybe
address,
because
what
you
kind
of
just
said
is
like
two
years
ago
I
haven't
been
on
this
project
for
two
years.
I've
been
on
it
for
a
little
while,
but
I
you
know-
and
I
know,
there's
people
that
are
coming
out
of
the
project
after
me.
I
don't
have
context
of
what
you're
talking
about.
K
I
don't
see
that
in
any
of
the
documentations
for
the
onboarding,
and
I
think
that's
something
that
we
could
do
a
better
job
at
communicating
to
developers
coming
on.
I
think
that
a
lot
of
the
concern
that
you
just
had
is
something
that
we
can
solve
and
it's
something
that
we
can
definitely
address.
I
know
in
goes
specifically.
If
we
don't
want
somebody
to
be
implementing
an
interface
we
can.
We
can
work
with
that.
K
We
can
construct
things
in
a
proper
way
so
that
that's
not
actually
going
to
happen,
but
I
didn't
these
things
are
not
aware,
like
not
a
part
of
something
that
I
knew
about.
So
I
I
don't
know.
I
think
that
there's
some
opportunity
here
where
we
can
do
a
better
job
like
as
a
community
and
making
sure
that
we
identify
you,
know
these
decisions
and
capture
them.
So
other
people
can
you
know
on
board
on
this
in
this
fashion,.
D
G
D
We
are
going
to
have
the
ability
to
add
more
functionality.
No
one
on
the
call
is
saying
that
we
can't
do
that.
So
don't
confuse
the
problem
with
the
solution
like
we're
gonna
be
able
to
do
this.
It's
just
a
question
of,
for
example,
the
people
write
and
go
just
need
to
have
some
clarity
about
how
to
express
this
to
their
end
users
and
just
think
about
when
they're
adding
functionality.
Maybe
in
some
cases
that
might
mean
that
new
functionality
comes
on
a
separate
object
rather
than.
D
A
J
Read
the
document
read
the
comments
in
the
specification
about
these.
I'm
not
referring
one
of
the
tc
member
mentioning
one
of
the
spec
commit
that
this
is
a
breaking
change
and
we
need
the
major
upgrade
bump
when
we
were
talking
about
one
thing.
That
was
not
actually
on
an
interface,
but
this
issue
was
raised
from
one
of
the
tc
member
that
we
cannot
do
this
and
I
want
I'm
not
gonna
discuss
with.
Is
this
possible
or
not?
J
G
D
Yeah
nev
has
a
comment
here
in
the
chat
that
I
think
sums
it
up.
It's
like.
Is
it
a
case
where
interface
has
been
taken
too
literally,
where
api
is
really
defining
a
contract?
So
I
do
think
we
need
to
clarify
this
more
right.
Obviously,
we
have
maintainers
that
have
questions
about
this,
but
it's
not
the
case
that
I
think
the
project
has
been
misdesigned
and
we're
not
going
to
be
able
to
do
these
things.
It's
just
that.
D
We
need
to
clarify
to
implementers
that
the
what
we
call
the
api
is
the
instrumentation
api
and
we
mean
no
breaking
changes
purely
from
the
perspective
of
like
our
different
versions
of
that
api
package
compatible
with
each
other
and
that's
what
we're
going
with
there
not
with
if
someone
implemented
one
of
these
interfaces,
for
whatever
reason
they
may
have
to
fix
their
code
as
we
change
it,
just
like
how
the
sdk
you'll
have
to
use
a
more
modern
version
of
the
sdk
to
use
a
more
modern
version
of
the
interface,
and
that's
that
is
totally
fine.
D
J
Which
comment
you
were
referring
to
berkman.
Can
you
I
will
point?
I
will
post
just
one
second
and
what
about
the
plugins
like
propagator
like
spam
exporter?
Do
we
not
apply
the
same
rule
there.
D
So
we
have
the
way
we
wrote
this
into
the
backwards
compatibility
guarantees
is
that
we
would
maintain
stability
with
those
interfaces
for
a
year
after
a
new
one
comes
out.
So
that
means,
if
we
come
out
with
a
new
interface
that
breaks
the
existing
one,
then
that
has
to
come
in.
As
like
say,
you
know,
span
processor
v2,
but
the
sdk
still
supports
spam
processor
v1
for
some
amount
of
time
before
before
retiring.
That.
J
D
You
are,
but
that's
going
to
create,
potentially
a
breaking.
That's
a
breaking
change
for
end
users.
If
you
do
that.
J
D
I
would
say:
yeah
I
mean
we
can
have
a
discussion
about
whether
or
not
we're
not
exactly
following
senpai
but
to
mine,
to,
I
think,
there's
maybe
a
core
thing
here
which
semver
you're
going
to
version
relatively
rapidly
and
bogdan
I've.
I've
noticed
you
you
feel
like
it
would
be
bad
if
we
versioned
the
spec
and
error.
J
J
D
D
If
we
want
to
use
the
major
version
bumps
to
to
really
just
mean
instrumentation
was
busted
like
if
we,
if
we
want
to
do
that,
I
think
that's
fine,
that's
just
different
than
following
semver
exactly,
but
it's
not
the
case
that
if
we
change
make
changes
to
things
like
the
sdk
or
the
sdk
plugins
that
it's
that
somehow
means
as
long
as
since
we've
done
that
we've
technically
made
v2
of
the
spec.
Therefore,
it's
totally
fine
to
go
change.
D
The
instrumentation
interfaces
like
we're
not
going
to
change
the
instrumentation
interfaces
in
a
breaking
way,
ideally
for
the
life
of
this
project,
or
at
least
for
a
very,
very
long,
do.
J
J
D
E
And
the
the
spec
calls
out
that
the
versions
of
the
api
and
the
sdk
are
separate
as
well,
so
we
could
have
a
v2
of
the
sdk
that
has
a
new
implementation
of
those
plug-in
interfaces
without
changing
the
v2
of
the
api.
V2
of
this,
the
sdk
depends
on
v1
of
the
api.
Everything
continues
to
work
as
as
expected
for
instrumentation.
J
Sure
sure
sure
independently,
which
is
trying
to
go
independently,
but
what
I'm
trying
to
say
is
if,
if
we
do
a
major
bump
every
six
months,
that's
a
fail
because
we
will
not
be
able
to
to
have
everything
work
together,
because
let
me
explain
something
you
do.
You
do
have
v1
and
v2
api
correct,
let's
assume,
and
you
have
half
of
your
instrumentation
instrumenting
with
you
on
half
of
them
instrumented
with
v2.
J
How?
How
do
you
make
things
to
work
together?
You
have
to
maintain
bridges.
You
have
to
maintain
a
lot
of
things
that
will
be
extremely
complicated
for
everyone
to
to
to
work
with
correct.
I
mean
it's,
it's
possible
it's
code,
but
I'm
trying
to
to
be
rational
and
understand
that
it's
going
to
be
almost
a
huge
pain
for
for
everyone.
If
we
end
up
having
a
major
release
every
day.
D
Yeah,
we're
not
we're
not
gonna
we're
not
gonna
do
that
with
certainly
with
the
api.
This
is
just
a
question
of
the
version
number
for
the
spec
who's,
the
target
audience
for
that.
If
the
target
audience
is
maintainers
and
we
release
a
new
version
of
the
spec
that
we
expect
broke
something
somewhere.
D
Therefore,
we
want
to
do
a
major
virgin
bomb
so
that
they
know
the
alternative
is
to
to
go
away
from
senvair
and
say
that
breaking
changes
to
sdk
packages
are
still
just
a
minor
version
bump
of
the
spec.
You
just
have
to
read
the
spec
and
figure
out
what
changed,
but
even
if
we
do
use
major
version
bumps,
we
can't
make
breaking
changes
to
the
api.
We've
made
a
commitment
that
we're
just
not
going
to
do
that.
D
So,
even
if
the
api
may
rev,
that
does
not
mean
it's
okay
to
break
the
api
or
sorry.
Even
if
the
spec
revs
major
version
numbers
to
track
sdk
changes,
we
can't
break
the
api.
We
also
want
to
limit
ourselves
to
breaking
the
sdk
right
like
that
means
like,
if
we're
going
to
make
breaking
changes
there.
Ideally,
we
we
kind
of
like
bundle
them
up
or
at
least
think
about
what
we're
doing
right
like
we
don't
want
to
be
creating
a
lot
of
thrash
for
maintainers
on
that
front.
E
D
And
that's
a
classic
thing
I
found
with
frameworks
is
there's
often
a
case.
You
want
to
update
the
framework,
but
you
can't
move
to
the
latest
version,
because
some
plug-in
you're
using
is
still
stuck
on
the
old
version,
like
that's
like
a
classic
gotcha
with
frameworks,
so
keeping
those
apis
stable
is
really
helpful.
G
J
G
Think
so
I
I
disagree
with
this
notion.
I
don't
think
that
so.
First
of
all,
I
think
it
will
be
very
confusing
if
we
start
incrementing
the
major
version
number
of
the
spec,
while
not
incrementing
the
version
number
major
version
number
of
the
api.
I
think
it
will
just
be
confusing
for
people
to
understand
what
is
happening
there.
I
think
the
the
actual
question
that
we
have
with
this
pr
the
force
flash
edition.
I
think
it
is
doable
in
a
way
that
it
is
not
a
breaking
change
right.
G
It
just
needs
to
be
a
different
second
version
of
that
interface.
There
are
ways
right
to
do
this
in
a
way
that
is
not
breaking
anybody.
No
single
existing
line
of
code
will
break
if
you
introduce
this
as
a
new
interface
v2
of
the
previous
interface
and
new
people
who
want
to
implement.
This
are
welcome
to
do
that.
They
just
need
to
be
aware
that
there
are
two
versions
of
the
interface
now
supported
in
open
telemetry,
but
open
telemetry
continues
supporting
the
old
one.
We
don't.
G
D
This
is
all
very
doable,
but
as
we
move
into
stability,
we're
definitely
going
to
have
to
think
about
these
things
just
just
more
thoroughly.
It
might
be
the
case
that
we
want
to
bundle,
make
sure
we
bundle
up
changes
to
an
interface
like
spam
processor,
for
example,
rather
than
dribbling
them
out.
We
do
have
to
be
more
pay
more
attention
to
the
stable
portions
of
our
code
when
now
that
they're
stable,
but
that
doesn't
mean
we
can't
change
it.
We
just
have
to
be
thoughtful
about
it.
J
G
C
G
J
J
I
A
D
J
Functionality,
I'm
not
asking
for
removing
things,
because
that's
a
separate
discussion
and
that's
probably
impossible
to
do
in
any
language
in
any
way
easy.
But
I'm
asking
for
new,
adding
new
functionality
is
that
that
requires
new
api
functions
on
the
interface
that
we
expose.
Is
that
consider
breaking
change
or
not?
It's
a
it's.
A
subset
of
the
changes
that
I'm
asking
for
not.
D
Yeah
and
we
got
to
wrap
up
but
yeah,
I
think
that's
totally
reasonable.
Everyone
expects
that
we
can
do
that
as
far
as
does
the
spec
have
to
care
about
the
maintainers.
Of
course
we
have
to
care
like
we
don't
want
to
be
like
thrashing
the
maintainers,
but
that
doesn't
mean
we.
We
can't
put
things
in
there
that
that
forced
maintainers
to
get
a
little
creative.
D
We
just
want
to
make
sure
that
that
we
have
a
good
feedback
loop
going
as
we
start
to
change
this
stuff.
J
That's
why
that's
why
we
discuss
here
in
the
maintainers
meeting,
not
in
a
specs
meeting
and
I'm
asking
maintainers
to
tell
us
if
we
are
saying
not
saying-
and
we
have
a
discussion
here
so
yeah.
I
think
it's
very
important
for
the
maintainers
to
to
give
us
feedback
on
all
these
changes
and
what
is
possible
and
not,
and
I
think
I
would
probably
start
just
documenting
what
specs
can
do,
while
not
increasing
the
major
version.
D
Sure
I'll
have
a
review
of
that
versioning
dock
and,
if
it's
not
clear
in
there
actually,
maybe
this
is
a
separate
dock
that
versioning
dock
we
have
so
far
is
actually
focused
on
the
clients
and
how
they
work.
We
don't
actually
have
a
document
that
explains
how
to
spec
versions
itself,
so
that's
actually
just
a
thing
that
needs
to
be
ready.