►
From YouTube: 2021-03-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).
C
C
B
D
Hey
there
so
yeah,
I'm
from
elastic
and
we've
been
working
on,
improving
the
ios,
slash
swift
agent
and
the
two
fellas
that
kind
of
work
on
that
project
sergey-
and
I
forget
the
other
fellas
name
ignacio-
are
both
open
to
starting
a
sig,
but
I
don't
really
know
how
how
it
works.
D
E
Yeah
totally
so
it's
pretty
straightforward,
just
create
a
ticket
in
the
community
repo
by
ticket.
I
mean
issue
requesting
that
that
the
sig
be
set
up.
The
the
main
thing
we
ask
of
pigs
is
that
they
have
a
a
weekly
or
bi-weekly
meeting,
that's
on
the
calendar
and
have
a
slack
channel
in
the
cncf
slack
where
people
can
get
a
hold
of
them.
E
The
next
step
after
that
is
just
to
try
to
expand
the
roles
out.
So
if
there
are
already
two
maintainers,
which
I
believe
there
are
that's
great
but
then
try
to
get
other
people
committed
to
working
as
additional
maintainers
or
at
least
approvers
on
the
project,
so
that
there's
enough
enough
approval
voices
that
it's
not
just
you
know
like
one-person,
show.
B
D
Okay,
so
I'm
using
I'm
I'm
former
new
relics,
so
I
I'm
still
kind
of
using
their
terms.
Okay,.
F
E
That's
what
it
is
in
there
just
to
clarify
it's
an
api
and
sdk.
It
might
be
a
good
time
to
for
that
group
to
maybe
get
some
cross-pollination,
or
at
least
like
a
tc
review
as
to
what
the
current
state
of
it
is.
Since
it's
been
a
couple
people
just
a
small
group
of
people
working
on
it,
I
know
you
have
that
checklist
bugged
in
it
might
be
worthwhile
to
go
through
that
checklist
with
them
sooner
rather
than
later.
F
Yeah
we
we
can
do
that.
Definitely,
but
I
think
we
should
start
with
having
a
seat
and
then
I
would
recommend
the
seek
members
to
invite
one
or
two
of
the
tc
members
in
maybe
one
of
the
meetings
discuss
what
we
can
do,
how
we
can
make
sure
because
of
the
the
history
of
that
rep
or
how
can
we
make
sure
that
it
follows
the
new
set
of
rules.
E
Yeah,
so
I
think
that
repo
has
kind
of
a
funny
pedigree.
I
think
it
was
initially
donated
by
undefined
labs,
and
then
mr
nacho
bonafante
has
has
been
working
on
it
and,
I
believe,
he's
from
datadog.
E
F
What's
the
current
implication
of
the
old
maintainers
and
stuff,
is
it
zero
to
none?
Are
they
still
active?
We
probably
need
to
talk
to
them
as
well.
To
see
right,
I
mean
I
don't
know
what
what's
the
situation
there.
I.
D
All
right,
cool,
I'll,
I'll,
open
up
a
community
ticket
and
yeah.
Maybe
we
can
get
some
more
of
those
other
bullet
points
in
that
in
that
ticket
once
it's
made,
if
you,
if
you
look
at
the
commit
history.
E
It's
it's
almost
entirely.
Ignacio
who's
been
working
on
it.
A
Yeah
basically
they're
having
a
pair
of
discussions,
and
there
are
some
issues
regarding
what
should
we
consider
as
a
breaking
change
and
whatnot
and
just
wanted
to
get
the
discussion
started.
We
already
had
some
discussions
last
week,
or
maybe
even
the
week
after
before
that,
and
this
is
basically
to
cover
two
specific
cases.
I
think
we
covered
the
sdk
changes
case
now.
It's
about
additive
changes
I
set,
which
means
adding
members
to
existing
classes
or
interfaces.
A
The
first
one
is
regarding
components
which
is
like
you
know,
stuff
that
we
offer
to
users
like
stump
processor
right,
like
we
want
to
add
this
force,
flush,
metal
and
whether,
on
that
regard,
I
think
that
that's
actually
a
nice
thing
to
have
specifically
the
force
flush.
But
the
question
is
whether
we
can
make
sure
that
we
can
expose
this
functionality
in
a
nice
way
that
it
doesn't
break
the
code
of
you
know
of
existing
users.
A
The
second
one
is
the
public
apis.
You
know
things
that
are
additive
and
both
impact.
The
actual
api
like
spam,
set
attributes
and
there's
a
pr
from
manure.
A
Regarding
that-
and
it
looks,
it
looks
great-
I
think
something
that
will
be
of
great
help,
but
we
want
to
make
sure
it
won't
break
things
this
I
see
now
that
there
is
an
open
issue,
the
link
there
thanks
so
much,
whoever
added
it
yeah.
I
just
wanted
to
get
some
feedback
and
general
feeling
about
this.
E
So
a
couple
of
things
for
adding
things
to
the
the
public
api
or
the
instrumentation
api.
We
might
need
to
come
up
with
some
new
terms
here
by
the
way,
since
those
plugin
interfaces
are
something
we're
talking
about
more
and
more,
but
the
public
instrumentation
api.
The
super
duper
primary
thing
there
is
that
future
is
that
there
is
not
any
kind
of
dependency
conflict
with
different
packages,
importing
different
versions
of
that
api.
E
It
may
be
the
case
that
we're
expecting
people
to-
or
it
is
the
case,
we're
expecting
people
to
move
up
to
the
latest
version
of
the
sdk
and
be
able
to
keep
all
their
sdk
components
in
sync.
But
you
have
to
assume
that
api
calls
are
going
to
age
and
ideally
not
get
touched,
so
so
the
overriding
goal
there
is
to
not
create
changes
that
would
cause
old
callers
to
break
or
to
have
the
compiler
break
on
you
if
you're
trying
to
import
multiple
versions
there.
E
E
So
so
that's
that's
the
distinction
on
the
public
end
for
the
plug-in
interfaces.
It's
the
opposite
distinction,
we're
expecting
the
end
users
and
the
ecosystem
to
to
use
those
interfaces
to
write.
You
know
plug-ins
and
when
we
create
a
new
version
of
the
sdk
with
a
new
version
of
those
plug-in
interfaces,
the
old
existing
plug-ins
still
need
a
way
to
work.
E
G
So
yeah
yeah,
I
think
it
does
make
sense.
I
think
we
we
had
this
discussion
a
couple
times
already.
I
see
the
risk,
consensus
and
understanding
of
how
this
should
be
handled.
I
tried
to
list
all
those
cases
in
the
issue
that
are
linked
there,
but
I
believe
it's
now
probably
just
time
for
somebody
to
go
over
and
document
this
as
a
pr
against
the
spec.
E
I
can
try
to
write
that
this
week
if
someone
else
wants
to
make
that
proposal
that
that's
also
fine,
but
I
agree.
This
is
something
that
that
should
be
added
to
the
spec.
A
I
guess
my
question
is
specifically
just
to
be
super
clear
whether
we
would
need
a
new
interface
for
adding.
Like
just
say,
we
want
to
add
force
flash
to
sony
sport,
spanx
porter
spam
processor.
Do
we
really
need
a
new
interface?
Can
it
be
added
safely
there
what's
approach.
F
Depends
on
the
language
correct,
like
in
languages
where,
like
java,
where
you
can
have
a
default
implementation
for
a
method
in
an
interface,
I
think
that's
a
very
good
approach.
I
think
the
approach
should
include
you
either
you
either,
for
example,
for
for
duck
typing
like
go.
They
may
even
invent
a
new
interface,
flasher
or
whatever
and
say,
if
span
exporter
implements
that
interface,
because
it's
cheap
to
to
do
do
this
so
anyway,
all
of
these
things
can
be
done
in
case
of
of
these
things,
we
need
to
know.
F
What's
the
default
behavior
and
most
likely
for
a
bunch
of
things
will
be
a
knob.
It
is
what
it
is
I
mean,
but
even
for
two
interfaces.
F
I
think
you
need
a
default
implementation,
because
somehow
you
need
to
convert
from
one
to
another
instead
of
having
two
interfaces,
so
you
still
need
to
to
have
internally
a
default
implementation,
and
probably
the
only
thing
that
we
require
is
to
define
this
is
the
new
function
or
functionality
that
we
add-
and
this
is
the
default
implementation,
how
that
is
achieved
by
a
new
interface
and
make
internally
conversion
between
them
or
by
adding
a
default
method,
or
something
like
that.
It's
it's
up
to
the
language.
A
Right,
that's
that
totally
makes
sense,
and
that
takes
me
to
my
next
question,
which
is
what
about
the
public
api
there.
You
know
there
is
a
specific
pr
from
android
regarding
adding
set
attributes
or
set
all
attributes
to
spam,
but
that's
the
actual
api
that
the
end
end
user
is
touching
right.
Tigran.
You
made
a
comment
there.
What
jury
was
mentioning
that
you
know
well
julie
and
nikita
were
having
some
feedback
there,
which
makes
things
very
well.
A
A
E
We're
talking
about
a
public
interface
like
a
span,
adding
methods
would
not
be
a
breaking
change.
The
the
clarifying
point
here,
though,
is
when
implementers
go
to
add
this.
They
have
to
add
it
in
a
way
that
it
doesn't
cause
a
dependency
conflict,
but
but
to
clarify
we're.
If
someone
has
implemented
span
and
we
add
a
method,
we
expect
them
to
update
their
implementation.
E
It's
possible
that
end
users,
might
you
know,
wrap
span
or
something
in
some
kind
of
interceptor,
but
I
think
that
actually
points
to
our
like
spam.
Processor
interfaces
not
being
sufficient
in
some
way
if
people
are
doing
that.
So
even
though
that
might
happen,
that's
kind
of
an
edge
case,
and
I
think
it's
it's
okay,
if
I
mean
that's,
basically,
someone
made
an
implementation.
They
just
made
a
tiny
one.
E
That's
what
I'm
saying
like
it's
the
only
case
where
I
see
like
end
users,
code
being
broken
outside
of
like
someone
wrote
their
own
sdk
is
if,
instead
of
writing
a
span
processor
or
like
doing
something
through
the
sdk,
what
they
did
was
they
implemented
like
span
interface
and
then
did
some
interception
there
and
then
called
out
to
span
and
then
were
swapping
that
thing
into
their
code.
Somehow
right,
so
they
shimmed
it
on
the
outside
anyways,
it's
an
edge
case.
E
I
don't
think
people
are
going
to
do
much
of
this,
but
it's
not
it's
not
a
case.
We
care
about
from
the
perspective
of
avoiding
breaking
change.
It's
just
ensure
that
that
you're
not
going
to
create
a
dependency
conflict
with
with
old
versions.
E
A
E
So
I
oh,
I
will
make
it
my
task
to
get
this
written
this
week,
and
this
is
just
going
to
clarify
the
public
api
works.
The
way
we
just
said
for
plug-in
interfaces
when
they
get
added
to
the
spec.
New
methods
need
to
include
a
default
description.
As
token
says,
I
think
that's
the
right
approach.
If
we
add
these
things
old
spam
processors
us
need
to
work
right,
so
old
plugins
still
need
to
work,
which
means,
if
we're
adding
a
new
method
or
adding
new
functionality.
E
There
needs
to
be
an
explanation
of
like
what
the
default
would
be
there
if
the
underlying
plugin
doesn't
implement
it.
H
So,
to
make
sure
I'm
understanding
this
correctly
we're
we're
saying
that
we
are
okay
with
adding
methods
to
interfaces
in
the
public
api
that
would
be
implemented
by
the
sdk,
and
if
that
means
that
a
new
version
of
the
api
doesn't
build
with
an
older
version
of
the
sdk,
because
it
doesn't
have
that
method
implemented.
We're
okay
with
that,
we'll
require
users
to
upgrade
their
sdk.
That's.
E
Correct
and
then
to
make
sure
that
that's
not
a
nightmare,
we
have
to
ensure
that
the
sdk
can
be
upgraded
without
a
lot
of
breaking
changes
right,
which
means
like
if
it
breaks
their
config,
that's
annoying,
but
the
the
real
problem
is
if
it
broke
the
plug-ins
right.
That's
where
you
would
have
this,
this
nasty
situation
where
the
instrumentation's
moved
up
to
like
a
new
version,
but
you
can't
move
your
sdk
up
because
you
depend
on
a
plug-in
and
that
plug-in
author
hasn't
like
updated
their
plug-in.
E
H
Yeah
tyler,
we
may
want
to
look
at
the
the
thing
he
was
talking
about
about
version
pending
with
recursive
dependencies
between
the
api
and
the
sdk,
to
make
sure
that
if
some
instrumentation
pulls
the
api
to
a
new
version,
the
sdk
gets
pulled
along
with
it.
B
Perfect
all
right
next
up
is
lalit.
I
Yeah,
hey,
so
we
have.
Hopefully
this
should
be
quick
question
I
mean
so.
Basically
this
is
specific
to
c
plus
plus.
As
of
now,
the
question
like
we
have
started
documenting
our
sdk
and
the
api,
and
we
just
wanted
to
understand
from
other
maintainers.
I
First
of
all
whether
there
is
any
guideline
or
recommendation
where
to
host
these
documentations,
like
I
see
multiple
places,
open,
telemetry
and
io,
which,
as
of
now,
has
a
getting
started
guide
from
all
the
languages.
So
is
that
a
place
where
we
can
choose
our
own
place,
take
it
up
pages
or
read
the
docs
dot
to
rg
or
anything
else
which
we
are
free
to
use
any
of
the
documentation
based
on
our
choice.
Or
is
there
any
recommendation
here.
J
Is
a
really
excellent
question,
not
only
for
c
plus
plus,
because,
right
now
we
have
an
issue
that
nobody
is,
has
their
job
being,
keeping
the
open,
telemetry
io
docs
in
sync,
with
anything
they
were
kind
of
created
without
maintainers,
really
being
consulted
on
how
that
was
going
to
be
maintained
and,
for
example,
right
now.
K
E
E
B
E
Yeah,
even
if
they
have
to
be
generated
by
a
human
like,
even
if
it
has
to
be
part
of
the
maintainer's
checklist
to
go,
make
a
pr
against
the
docs
that
should
just
be
I
copy
pasted
the
markdown
over
here
and
hit.
You
know,
pull
request,
send
it
shouldn't
be
the
case
where
the
docs
are
are
different
enough
from
each
other
that
it's
actually
like
the
maintainer
has
to
go
like
hunt
through
these.
These
other
docks
it
should
be.
E
It
should
be
automatable
that
that
would
be
my
proposal
for
how
we
solve
this
john.
Does
that
make
sense
to
you?
Does
it
like
seem
reasonable?
E
If,
like
you
know
as
a
maintainer,
you
would
just
as
part
of
the
checklist
when
you
update
your
docs
in
markdown
in
your
repo,
you
have
to
at
least
for
some
time,
just
copy
paste
that
same
thing
into
the
website.
J
I
mean
it
is
a
solution.
I
don't
think
it's
a
great
solution.
I
think
that
having
docs
in
two
places
is
going
to
always
be
problematic
because
and
right
now
they
don't
look
the
same.
It's
not
exactly
the
same
content
yeah
that
would
have
to
change
so
I
mean
I
guess
I
would
say
that
the
docs
team
should
own
this
problem.
Whoever
that
is,
I
don't
even
I
know,
austin
kind
of
has
led
that
it's.
J
B
I'm
curious
what
like
particularly
ted.
Your
thoughts
are,
if,
if
we
limited
the
docs
on
opentelemetry.io
to
just
a
few
getting
started
guides
like
sort
of
explaining
like
these
are
the
sdks.
This
is
the
collector
like,
like
very
high
level,
things
that
are
not
specific
to
a
particular
sig
and
for
anything
that
was
language
or
sig,
specific
or
component
specific.
The
website
just
points
people
to
the
source
of
truth
for
docs,
whether
that's
read
the
docs
or
github
or
somewhere
else.
E
Nor
does
like
read
the
docs,
or
these
other
things,
and
the
website
right
now
like
bottoms
out
on
those
search
results,
because
there
isn't
a
lot
of
information
there,
and
ideally,
I'd
like
to
get
to
a
point
where,
when
people
search
for
information
about
open
telemetry,
the
thing
they
find
are
like
the
official
docs
and
how
it
works,
that
that
would
be
one
reason
to
to
try
to
make
sure
at
least
at
least
the
core
stuff
on
that
is
available
on
that
website.
L
N
As
I
said,
I
inherently
see
a
couple
different
problems
manifesting
themselves
into
one
centralized
problem
here.
It's
every
language
is
going
to
have
a
different
implementation
of
how
they
push
the
docs
out
to
production,
and
then
we
have
to
have
like
a
collection
of
all
of
those
documents
in
a
centralized
location.
It
sounds.
L
N
Opencemetery.Io
is
the
place
where
a
lot
of
the
information
should
be
found,
but
I
think
that
it's
like
a
two-fold
problem.
It's
like
how
do
we?
How
do
we
give
observability
to
the
documentation
for
observability
and
how
do
we
make
sure
that
all
of
the
maintainers
have
the
doc
platform
that
they
need
for
their
specific
language?
Implementation
to
work
well,
and
it
sounds
like
having
open
symmetry.I
would
be
the
breaking
off
point.
N
Two
docs
for
each
of
the
individual
languages
might
be
a
good
point,
but
I
think
we
just
need
to
build
a
consistent
story
around
what
needs
to
live
in
in
open
telemetry.
I
o
versus
what
needs
to
live
in
each
of
the
individual,
six
repos
or
github
or
read
the
docs
or
you
know,
whatever
sort
of
documentation
of
the
day.
You
have
right.
E
Yeah
yeah,
I
think
we
just
have
to
sort
out
like
what
one
like
it.
It's
probably
insufficient,
just
to
say,
go
put
all
your
docs
on
the
website.
Right,
like
that,
doesn't
make
sense.
You're
not
going
to
put
the
the
auto
generated
api
docs
up
there,
for
example,
like
the
javadoc
stuff,
probably
doesn't
go
up
there,
but
that
the
website
should
link
to
like
ways.
People
can
get
different
versions
of
those
stocks
and
it
should
contain
the
the
high
level
stuff
around
how
to
get
started
and
how
to
use
the
public
api.
E
One
thing
that
hopefully
makes
this
a
little
bit
easier
going
forward
is
like
after
1.0
the
api
should
settle
down
a
bit,
but
we
know
that's
like
not
totally
the
case.
We're
going
to
be
adding
things
and
you
know
metrics
is
coming.
So
it's
always
going
to
be
the
case
when
a
new
release
comes
out,
there's
going
to
be
some
kind
of
doc
change
likely
that
happens
somewhere.
E
So,
even
if,
even
if
we
clarify
what
exactly
should
be
on
the
website
and
regularize
it,
which
I
think
we
should
do,
I
think
that
was
maybe
where
you're
getting
at
bob
is
like
at
least
like
have
some
clarity
of
like
these
are
the
docs
that
should
be
on
the
website
and
try
to
make
the
docs
in
your
readme,
like
we
haven't
regularized
like
these
kind
of
getting
started
docs
across
the
different
cigs.
N
Exactly
exactly
ted,
that
was
my
point.
It's
like
to
me
from
my
perspective,
if
I
was
a
new
end
user
of
open
telemetry,
what
I'd
want
to
do
is
I'd
want
to
go
to
opentelemetry.io
check
out
how
to
implement
a
very,
very
basic
implementation
of
whatever
language
I
like
and
then
read
more
information
on
wherever
that
information
is
so
it
sounds,
it
seems
to
me
like
we
almost
need
just
like
you
said
a
very
generalized
like
this
is
how
you
get
started.
This
is
where
you
can
go
see
the
full
documentation
for
your
spec.
N
E
And
if
we
could
make
it
so
that
that
stuff
could
just
get
you
know
automatically
pulled
from
each
repeat
readme
or
from
each
repo.
That
would
be,
I
think,
the
ideal
solution
there,
but
I
think
we
will
have
to
have
a
a
middle
step
where
we
we
set
this
up
by
hand
and
make
sure
we're
setting
it
up
the
right
way.
E
Yeah-
and
I
also
agree
with
john
that
we
do
have
a
com
sig-
that
is
like
kind
of
owning
these
docs,
and
we
should
ask
them
to
maybe
start
coming
to
this
maintainers
meeting
come
up
with
a
plan,
get
it
approved
by
the
maintainers
and
then
like
help
move
the
docs
into
whatever
this
new
new
format
is,
is
going
to
be
it
the
the
way
it's
currently
working,
where,
where
there's
just
kind
of
people
working
on
the
website
and
writing
docs
over
there
and
then
like
the
maintainers,
are
over
here
like
clearly
that
that's
not
going
to
work
going
forwards.
E
B
J
Yeah
I
mean
the
real
next
step
is
we
have
very
very
out
of
date,
docs
for
java
at
the
moment,
on
the
open
tone
trio
site?
In
fact,
there's
broken
links,
there's
all
sorts
of
stuff
in
there.
That's
just
looks
really
bad
and
none
of
the
code
will
work
at
the
moment
so
like
we
need
a
probably
a
quick
action
item
to
get
that
stuff
up
to
date.
I
don't
know
that
I
will
have
time
to
do
it
today,
but
I
log
an
issue
in
the
website
to
get
it
updated.
E
J
I
do
think
your
call
out
of
you
know
having
the
the
coms
group
put
a
proposal
that
maintainers
can
be
on
board
with,
rather
than
kind
of,
the
way
things
work
now,
as
the
comms
just
did
their
own
thing
and
like
not
really
any
kind
of
collaboration.
So
that
would
be
that's
really
important.
I
So,
just
to
I
mean
I
want
to
summarize
my
understanding
here
that
we
really
do
want
to
have
the
high
level
documentation
in
open,
telemetry
dot
io.
It
should
be
in
sync
with
what
we
have
in
our
root
repo
and
for
the
more
lower
level
documentation
like
api
and
sdk
documentation
that
can
that
can
live
on
language
specific
places
where
they
want
to
decide
on
where
they
want
to
live,
and
that
will
not
be
sync
with
the
to
the
open
telemetry.io.
E
I
believe
that's
what
we're
agreeing
on,
but
the
caveat
from
what
what
john
yana
mentioned
is
that
the
website
should
point
you
to
the
versioned
versions
of
of
those
other
docs
since
going
directly
to
github
to
look
at
that
info.
Isn't
isn't
sufficient.
O
P
Is
is,
is
that
the
dc
checklist
that
we're
talking
about
here,
yeah
that
fear
is
still
open?
I
think
you
know
one
commenter
left
is
still
still
open.
You
know
yeah
baldwin
left
any
any
idea.
What
the
response
there
is.
You
know
I
think
we
should
close
on
the
tc
rather
quickly,
java
and
c
c
sharp
have
made
it,
but
there
are
other
languages,
especially
python
node.js,
we're
kind
of
waiting
on
hearing
from
the
tc
process
any
yeah.
When
that
will
be
closed.
A
Yeah
for
fighting,
we
are
already
running
that
I
already
opened
a
few
issues
after
reviewing
that,
so
the
plan
is
to
continue
doing
that
this
week
for
javascript.
I
have
no
idea,
sadly,
but
the
other
plan
is
that
specific
pr
to
merge
it
soon
like
this
week?
Okay,
thanks,
hey.
A
K
E
If
we
have
a
look
at
this
roadmap,
I've
updated
this
based
on
feedback.
So
there's
a
new
diagram
with
a
new
proposed
timeline
for
how
we
chunk
our
work
into
coherent
chunks
and
try
to
maintain
focus
on
each
chunk
rather
than
being
spread
too
thin
across
a
whole
bunch
of
different
initiatives.
E
So
I
just
want
to
briefly
go
over
what
those
chunks
are
and
then
I
would
like
feedback
on
the
stock.
I
plan
if
maintainers
are
okay
with
it,
releasing
this
at
end
of
week
as
something
onto
our
blog
describing
this
roadmap,
but
I
want
to
make
sure
maintainers
feel
comfortable
with
the
the
rough
layout
that
we
have
here
before.
E
I
do
that,
so
the
basic
idea,
if
we
just
look
at
this
diagram,
we've
got
metrics
which
are
in
green
metrics,
are
a
long
ongoing
project,
they're
going
to
be
in
kind
of
a
prototyping
phase
till
about
june,
and
then
after
june
the
maintainers
will
be
expected
to
start
getting
more
involved
and
then,
from
september
to
november.
That's
when
we
want
to
get
everything
like
locked
down
and
ready
for
for
a
stable
release
of
metrics.
E
So
part
of
the
goal
is
to
fit
the
rest
of
this
work
in
a
by
end
of
august,
so
that
maintainers
will
be
able
to
focus
on
doing
release,
candidates
and
releases
from
september
to
november.
E
There's
a
bunch
of
different
projects.
The
project
that
seemed
to
require
the
least
amount
of
design
work
is
the
convenience
api.
So
this
is
just
we
have
our
apis,
but
some
of
them
feel
a
little
lower
level
for
like
common
things
that
application
developer
would
do
and
so
just
having
a
simpler
api
just
higher
level
convenience
methods.
I
don't
think
I
have
to
go
over
this
in
detail
because
I
think
maintainers
know
what
I'm
talking
about.
E
When
I
talk
about
this
api
there's
been
a
request
for
like
a
little
bit
of
spec
work
here,
but
I
don't.
I
don't
think
we
really
need
to
spec
this
out.
We
just
need
to
have
some
time
over
the
next
two
months
to
actually
actually
focus
on
doing
this,
and
if
we're
focusing
on
this,
as
a
group
that'll
help
us
be
able
to
kind
of
cross
talk
with
each
other
and
collaborate
and
figure
out.
E
You
know
where
the
bumps
are
so
I'm
proposing
that
kicks
off
next
week
and
we'll
work
on
that
for
two
months,
starting
at
the
beginning
of
april,
we'll
have
a
bit
of
overlap,
come
in
which
is
beginning
to
discuss
how
we're
going
we're
not
beginning
to
discuss
from,
for
the
month
of
april
figure
out
how
we're
going
to
manage
our
instrumentation
ecosystem,
and
we
want
to
do
this
sooner
rather
than
later,
because
one
instrumentation
is
really
important,
but
two
we're
going
to
have
interns
start
arriving
in
this
project
around
may
and
one
easily
paralyzable
source
of
intern
work
is
writing
instrumentation,
but
if
we
don't
have
clarity
ourselves
for
like
where
we
want
this
instrumentation
to
go,
how
we
want
to
manage
it,
what
kind
of
improvements
we
want
to
make
to
the
semantics,
I
know
john,
has
questions
around.
E
You
know
what
happens
when
you
have
like
a
logical
http
span
and
lower
spans.
How
do
we
want
to
configure
this
stuff?
These
are
questions
that
I
think
we
need
to
to
address.
As
a
group,
I'm
hoping
we
can
address
them
in
a
month
and
that
will
give
us
the
preparation.
E
We
need
so
that
when
those
interns
start
arriving,
we
can
be
assigning
them
to
to
working
on
this
instrumentation
and
when
we're
reviewing
that
instrumentation
we'll
be
able
to
follow
a
checklist,
that's
the
ultimate
goal
with
instrumentation
is
like
can:
can
it
be
quantifiable,
or
at
least
very
easily
verifiable
against
docs
and
other
resources
as
to
whether
this
instrumentation
is
correct
or
not?
E
So
interns
will
be
around
may
through
end
of
august,
and
ideally
they
can
focus
on
instrumentation,
and
maybe
you
know
other
small
projects
that
people
can
come
up
with
that.
Don't
distract
the
maintainers
too
much.
E
The
next
project
is
setting
up
the
installation
experience
improving
the
installation,
experience
finding
ways
that
we
can
simplify
that
experience
for
users
who
are
just
rolling
out,
especially
if
they're
rolling
out
some
kind
of
default,
rollout
like
they're,
just
rolling
out
with
otlp
and
either
talking
directly
to
a
back
end
that
supports
otlp
or
talking
to
a
collector
and
then
using
the
collector
to
configure
what
they're
talking
to
just
making
sure
that
path
is,
is
straightforward,
making
sure
that
installing
instrumentation
and
those
things
is
straightforward.
E
So
once
we
figure
out
our
instrumentation
story,
we'll
move
on
to
to
working
on
that
problem
and
that'll
be
a
month
of
kind
of
prototyping
and
discussing
and
then
a
month
to
to
try
to
lock
down
what.
Whatever
changes
we
identified
in
the
first
month
that
we
want
to
make
to
each
report.
J
Can
I
step
back
one
step
sure
for
the
instrumentation
design
month,
whatever
that
ends
up
being?
Is
that
going
to
include
actually
getting
stability,
guarantees
nailed
down
for
instrumentation
and
telemetry.
E
E
Like
what
story
do
we
have
to
have
straight
so
that
you
know
we
can
actually
go.
Ask
a
bunch
of
people
to
build
this
instrumentation
for
us.
I
don't
know
that
we
have
to
sort
out
our
stability
guarantees
to
to
do
that,
but
I
do
think
it's
important.
E
C
I
thought
that
we
decided
for
1.0.
There
were
no
telemetry
stability
guarantees,
so
we
were
planning
to
release
one
zero
of
the
java
agent
and
not
have
any
guarantees
around
telemetry
stability.
G
G
G
J
From
my
latest
reading
of
the
specs
around
telemetry,
that
isn't
the
impression
that
I
get
from
what
from
reading
things
that's
correct,
yeah,
so
go
ahead.
So
so,
if
we
want
to
say
that
we're
literally
saying
we
have
no
stability
guarantees
on
telemetry
for
1.0
and
you
that
we
are
releasing
things
at
1.0
without
stability
guarantees,
we
need
to
make
that
I
think
incredibly
clear
everywhere,
where
there
is
going
to
be
instrumentation
released
at
1.0.
G
Yeah,
that's
one
of
the
options.
If
we
don't
like
that,
then
we
will
so
we,
it
means
delaying
the
release
and
in
that
case
I
would
make
it
high
priority
for
us
to
actually
figure
out.
What's
the
story
around
guarantees
rather
than
let
it
stay
there
for
another,
so
many
months
right,
we
have
an
issue
open
there.
E
But
it's
just
to
to
clarify
two
two
points:
one
this.
What
it
says
in
the
spec
is
we're
asking
that
instrumentation
not
declare
it
one
itself
1.0.
Until
we
sort
out
this
story,
I
guess
the
agent
itself
counts
as
instrumentation.
It
is
kind
of
two
parts.
You
know
the
stability
of
the
agent
versus
the
stability
of
the
telemetry,
so
I
do
apologize
that
you're
kind
of
stuck
in
the
middle
there,
but
I
also
think
it's
not
as
simple
as
just
defining
like
like
what
a
guarantee
is
right.
E
Like
there's
a
number
of
open
questions,
I
think
john
has
raised
a
number
of
them
around.
How
do
we
actually
handle
some
of
these
use
cases?
So
it's
hard.
It's
not
just
a
matter
of
saying.
E
Okay,
we've
figured
out
what
our
guarantees
are
like,
like
there's
a
number
of
changes
we
may
want
to
make
now
that
we
wouldn't
want
to
make
after
we've
declared
things
stable,
and
I
think
that's
the
harder
problem
right
like
it's.
We
get
feedback
from
users
right
now
that
it's
like,
besides
needing
the
ability
to
configure
some
of
this
stuff,
there's
just
some
confusion
around
even
basic
stuff.
E
G
If
any
did
any
previous
before
open
telemetry
instrumentation
project
provide
any
sort
of
guarantees
to
the
instrumentation.
G
G
B
I
don't
know
I
never
saw
anything
like
that.
Yeah
open
census
didn't
because
we
never.
I
don't
think
we
ever
hit
a
1.0
yeah.
E
Yeah,
we
didn't
provide
that
there
because
we
hadn't
gotten
to
this
point.
Yeah.
E
Though,
was
the
the
bar
we're
trying
to
set
our
temporary
implementations,
yeah.
G
Exactly
I
I
don't
disagree,
I'm
just
saying
that
if
it
worked
for
how
many
decades
of
instrumentation
existed,
maybe
it
can
work
for
another
few
months
or
a
year
before
we
figure
out.
What's
the
right
solution
to
this,
not
a
strong
opinion,
but
I'm
just
suggesting
that
maybe
it's
okay.
If
not,
then
we
do
need
a
solution
for
that
and
we
need
to
do
it
quickly,
rather
than
delay
the
release
of
auto
instrumentation
by
another
year,
because
we
don't
know
what
to
do
about
the
guarantees.
E
So
can
I
just
get
a
quick
check?
We
have
a
number
of
maintainers
who
have
worked
at
places
like
new,
relic
and
dynatrace
and
places
that
have
been
around
for
a
long
time.
What
is
the
approach
to
stability
in
those
organizations
like
how
much
of
a
priority
is
it
to
ensure
that
stuff
is
stable?
J
So
I'd
say
it's
a
little
bit
different
because,
like
a
new
relic,
the
back
end
teams
were,
I
mean
we're
all
one,
two
with
all
one
team,
and
with
this
we
don't
have
a
back
end
right.
So
it's
a
lot
harder
to
kind
of
apples
to
apples
that
comparison.
J
M
But
I
think
tigran
that
you
know,
as
david
is
also
highlighting.
Kubernetes
has
a
you
know,
idea
of
stability,
and-
and
I
do
think
that
you
know
this-
is
an
emerging
area
and
open
source
projects
per
se.
But
on
the
other
hand,
enterprise
open
source
needs
to
provide
that
stability,
guarantee
right
and
and
that's
done,
standardly
in
products
all
the
time.
M
But
and
then,
as
someone
mentioned,
you
know
when
you
have
one
team,
that's
easier
to
get
to
faster,
but
on
the
other
hand
we
can
totally
do
it
as
a
project
too.
G
Yeah
yeah,
no
just
to
make
it
clear,
I'm
not
saying
we
should
not
provide
guarantees.
We
absolutely
should
it's
just
that
we
have
a
choice.
We
either
tell
that
it.
We
don't
know
yet
how
to
do
that,
but
we
still
make
a
release
and
make
it
available
for
people
to
use
or
we
delay
it.
But
in
that
case,
if
we
decide
that
we
want
to
delay
until
we
figure
out
the
story,
I
would
like
to
make
it
a
priority
for
us
to
figure
that
out
so.
C
E
E
Yeah,
well,
I
think
the
goal
is
to
have
it
to
have
this
ideally
figured
out
by
may
so
that's
two
months
months
from
now,
but
I
clearly
this
is
like
the
overriding
priority,
so
we
can
push
this
up
even
sooner.
My
hope
is
that
we
can
be
working
on
the
convenience
api
issues
without
without
too
much
having
to
spend
too
much
of
our
spec
debating
work.
My
hope
is
like
that's
a
little
bit
more,
just
like
like
work.
E
I
just
want
to
make
sure
we
get
to
the
point
where
maintainers
feel
like
they
can
get
to
work
on
on
improving
the
convenience
layer
of
the
api
or
shoring
up
whatever
it
is
that
they
think
is
like
difficult
with
the
api
today.
E
So
I
just
kind
of
want
to
get
that
cleared
out,
because
I'm
hoping
that
will
be
a
short
discussion
and
then
we
can
turn
our
attention
fully
to
instrumentation
and
I
kind
of
agree.
We
should
not
move
on
past
this
instrumentation
problem
until
we
feel
like
we've
gotten
it
to
to
a
stable
place
in
a
place
where
we
could
call
things
1.0.
G
So
for
for
instrumentation,
so
I
there
is
an
issue
that
I
opened,
which
outlines
some
approach
that
possibly
could
work,
and
I
haven't
been
working
on
that
until
now.
So
if
we
believe
that
we
want
to
not
to
release
auto
instrumentation
until
there
is
an
answer
to
what
stability
means
there,
then
I
can
try
to
maybe
expedite
that
and
have
a
proposal.
I
do
believe
it
will
require
a
discussion,
a
thorough
discussion,
it's
not
something
that
we
can
do
easily
and
quickly,
but
at
least
let's,
let's
start
sooner
rather
than
later.
E
C
So
so
yeah,
so
our
our
feeling
from
the
with
the
java
agent
since
there's
about
a
hundred
different
instrumentations,
is
that
pretty
much
there's
going
to
be
continual
improvement
to
you
know
one
of
those
constantly,
and
so
you
know
if
we
do
need
to
bump,
then
you
know
with
major
versions
with
telemetry
changes.
Like
we've
seen,
you
know,
proposals
to.
If
we
add
a
span
attribute,
you
know
to
bump
the
major
version.
E
O
I
I
it's
very
weird
idea
for
for
me
to
bump
a
major
version.
If
we
change
the
name
of
a
span
produced
by
the
by
some
instrumentation,
we
certainly
are
going
to
do
that
and
if,
if
we
are
making,
if
we
are
following
somewhere
by
the
book,
it
means
that
we
will
have
like
200
version
pretty
soon
and
some
what's
the
point
yeah.
G
And
that's
not
a
solution
right,
that's
not
really
a
solution.
You
need
to
have
a
different
solution,
but
really
you
have
to
with
the
current
understanding
you
have
to.
If
you
follow
it
formally,
you
don't
have
a
choice
and
I
think
that's
the
wrong
approach.
We
don't
have
to
follow
that.
We
need
to
have
a
different
approach.
G
G
E
E
Can
batch
changes
up
and
and
think
about
it
from
that
perspective,
but
yeah
until
we
have
like
some
definitive
form
of
like
what's
stable
around
around
this
instrumentation
like
I,
I
guess
you
can
try
to
make
a
call,
but
if
it
is
something
that's
like
a
big
enough
change
that
that
people's
dashboards
would
break
around
tracing.
K
L
O
I'm
trying
to
I'm
I'm
trying
to
to
understand,
and
I
I
can't
totally
understand
that
if
we
change
the
name
of
the
attribute
that
may
break
some
dashboards.
O
E
That
that's
been
the
the
blocker
on
this
whole
telemetry
stability
issue,
frankly,
is
like
the
the
only
form
of
we
definitely
won't
break
anyone
anywhere.
Is
we
don't
change
a
single
thing
about
the
instrumentation,
but
that
seems
like
inconceivably
impossible
and
not
useful.
I
think
it's
impossible,
but
we
don't
actually
haven't
actually
done
the
work
to
figure
out
like
what
what's
the
middle
ground
there
right.
G
H
It's
they
don't
seem
to
not
view
it
as
part
of
the
api
of
the
thing
that
is
versioned,
but
I
think
nikita
that's
kind
of
what
you're
getting
to
it
as
well
right
as
we're
talking
about
data
values
here,
not
programming
interfaces.
Exactly
so.
H
E
From
that
nikita
can
I
can
I
ask
that
we
table
this
just
because,
like
I
don't
think
we're
gonna
figure
out
the
the
actual
guarantees
in
the
next
three
minutes.
I
think
the
question
is
like
trask,
you
know:
does
the
group
feel
comfortable
with
you
releasing
like
a
1.0
of
of
the
the
agent
in
the
current
state
and
just
being
trying
to
use
your
best
judgment
and
be
somewhat
conservative
around?
You
know
bumping
the
major
virgin
number
if
there
are
if
there
are
instrumentation
changes
that
seem
beyond
trivial,
so.
C
The
plan
that
the
plan
that
we
had
discussed
was
to
release
one
zero
now
that
the
java
api
is
one
zero
release.
The
java
agent
one
zero
and
explicitly
not
make
any
stability
guarantees
around
telemetry
and
not
try
to
be
conservative,
about
additions
to
telemetry.
Just
know
that
the
telemetry
is
still
evolving.
C
Think
the
if
that's
not
if
that's
not
good,
then
you
know
we
can.
We
can
wait.
I
I
don't
personally
have
any
pressure
to
release.
I
think
we
should
check.
Alolita
aws,
I
think,
was
the
main
driver
of
releasing.
E
Yeah,
I
I
do
understand.
I
mean
the
agent's
in
a
little
bit
of
a
different
spot.
Simply
because
we're
talking
about
the
thing
people
use
to
also
install
all
the
things
right
and
we
want
to
say,
like
that's
stable
right,
you
can,
you
can
use
this
it'll
install
everything,
okay
and
like
stuff
is
stable
and
that's
so
that's
a
little
bit
different
than
in
the
other
languages.
Where
we
have
individual.
E
You
know,
contrib
components,
we're
just
trying
to
say
those
contrib
components.
Don't
don't
mark
all
of
those
things
as
stable
just
yet,
because
we
don't
know
what
that
means.
Oh.
C
E
M
C
Cool
awesome
well,
look
look
forward
later
this
week,
hopefully
for
an
announcement.
E
G
We
run
out
of
time
so
maintainers,
please
have
a
look
at
the
pr.
I
just
want
to
make
it
very
clear.
There
is
zero
intent
to
control
the
language
six
here.
The
intent
is
to
just
help
you
guys
right.
So
please
have
a
look
at
the
pr
if
you
think
the
way
that
it
is
worded
does
not
reflect
that
intent.
I
would
like
to
change
it
and
I
would
like
to
know
if
we
go
with
this
approach.
I
would
like
to
hear
thoughts
from
you.