►
From YouTube: 2021-03-12 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
B
A
C
I'll
get
the
invite
link
that
did
it.
Okay,
I
got
the
password
great
okay,
I'll,
add
that
to
the
meeting
hi
y'all
nice
to
meet
you
howdy,
just
to
introduce
myself,
I'm
I'm
ted.
I
work
on
the
governance
committee
for
open
telemetry
and
now
that
this,
like
swift
sig,
is
like
really
booting
up.
I
know
you
all
have
been
working
on
it
for
a
while,
but
I
thought
I
would
come
join
the
meeting
and
just
kind
of
see
see
how
things
were
going
over
in
swift
land.
A
Yeah
awesome
I'll,
I'm
bryce
buchanan
elastic.
I
used
to
work
for
new
relic
doing
mobile
instrumentation
mobile
agent,
apm
stuff
and
I'm
doing
the
same
thing
at
elastic
and
we're
really
excited
for
open
telemetry
over
over
here.
So.
C
B
I
started
the
pentametry
suite
code
when
I
was
working
in
my
previous
company.
It
was
a
startup
named
undefined
labs,
where
we
were
interested
in
adding.
We
started
with
open
tracing
support
but
decided
that
to
move
to
a
pentameter
soon,
so
we
I
started
the
project
there,
I
the
when
it
was
more
or
less
usable.
B
I
donated
it
to
the
community
and
talking
with
a
sergey
he
he
is
the
other
maintainer
on
the
repository,
but
he
doesn't
that
good
just
to
control
that
things
are
his
administrator
and
just
usually
pass
my
prs
and
just
merge
just
approve
them.
So
after
some
time,
undefined
labs
was
spot
by
datadog.
So
now
I
am
part
of
datadock
and
in
the
projects
I
am
working
on
data
log
and
some
other
projects.
Also.
We
are
interested
in
supporting
open
telemetry.
B
So
I
continue
my
work
on
open,
telemetry
and
other
works.
So
we
are
data.
Dog
is
committed
to
open,
telemetry
and
supporting
open
telemetry.
So
the
idea
is
continuing
with
supporting
it
awesome
yeah,
so
most
of
the
code
is
originally
mine.
I
have
some
pr's.
Have
been
added
by
some
individual
developers,
but
just
one
just
single
committee
bryce
has
been
probably
the
first
developer,
who
really
made
a
big
pr
to
the
project,
who
really
saw
some
committed
committee
to
it?
Sorry
for
my
english
and
yeah
so
yeah,
so
that
that's
the
state.
B
Now
I
the
current
status
of
the
project,
is
that
tracing
spec
1.0.1,
I
think,
is
covered
right
now
we
have
metrics
more
or
less
also
in
with
the
spec,
with
a
tlp
exporter,
also
following
the
zero
seven
zero
dlp
exporter
and
all
that
all
that
thing
and
I
and
many
exporters
I
mean
I
think
we
have
covered
what
the
original
beta
asks
for
for
the
project
and
my
idea
was
to
if
it
was
possible
to
create
a
first
beta
version
supporting
1.0.
C
Cool
well
that
that
sounds
awesome.
It
sounds
like
this
project's
in
a
pretty
good
spot.
I
I
definitely
have
some
questions
related
to
getting
it
ship
shape
for
for
1.0,
but
I
don't
want
to
hog
the
agenda.
I
see
that
you've
got
a
couple
of
topics
already
on
on
here.
B
Yeah,
the
topics
were
just
suggested
by
bryce,
so
it's
not.
We
can
talk
about
all
of
them
or
we
can
just
move
some
to
the
other
meetings,
since
this
is
the
first
one.
Okay,
so
I
I
think
right
right.
A
A
I'm
trying
to
think
if
I
had
any
like
immediate
topics
that
I
wanted
to
talk
about
right
away,
but
I
don't.
I
don't
think
I
do
the
the
stuff
that
was
really
that
I
was
really
scratching.
My
head
on
was
just
dealing
with
the
the
resource,
objects
and
sort
of
like
dynamic
data
points
that
might
that
might
want
to
be
tracked
in
that
in
that
sort
of
state.
A
But
you
know
just
having
problems
dealing
with
it
in
terms
of
like
the
fact
that
it's
that
it's
a
static
object
and
isn't
really
meant
to
be
updated
now,
but
I
think
I
found
I've
figured
out
like
what
like
how
to
work
around
that.
So
all
the
little
points
of
data
that
were
dynamic
that
might
change
from
here
to
there
I
feel,
like
probably,
should
just
get
tracked
as
metrics.
A
So
a
lot
of
the
other
things
I
wanted
to
like
talk
about
was
just
kind
of
like
project
structure
and
where
things
should
go.
One
thing
that
I
have
put
together
over
on
the
elastic
side.
We
kind
of
have
like
this
agent
thing
and
more
and
more
like
I'm
looking
at
this,
and
it's
really
just
like
a
like,
like
almost
like
a
wrapper
for
just
setting
up
open,
telemetry
and
having
it
talk
to
our
particular
collector,
which
also
is
you
know,
running
the
hotel
protocol.
A
So
it's
really
not
a
lot
going
on
on
our
side
and
one
of
the
things
I
do
have
in
there
is.
I
I
took
the
nsurl
session
instrumentation
that
you
had
in
their
non-show
for
for
data
dogs
and
sort
of
reconfigured
it
to
support
open,
telemetry
p
or
of
the
hotel
protocol.
Geez,
oh
yeah,
but
I
would
like
to
bring
that
back
into
the
hotel
project,
but
it
probably
doesn't
belong
in
the
the
swift
sdk
itself
and
it
probably
belongs
in
its
own
instrumentation
folder.
B
Yeah
we
we,
we
still
don't
support
any
instrumentation
in
the
project.
Currently,
I
think
there
are
other
projects
that
have
a
different,
a
different
repository
for
instrumentation,
for
example.
I
also
have
nsurl
instrumentation,
you
also
have
it
probably.
We
should
have
a
single
instrumentation
but
yeah,
that's
something
that
as
it
was
not
in
the
spec.
I
just
was
waiting
to
have
more
or
less
the
api
stabilized
before
before,
adding
that
but
yeah,
my
idea
was
also
adding
my
url
instrumentation.
B
I
don't
know
I
I
checked
a
bit
what
you
had
in
elastic
in
your
repo,
because
it's
a
public
repo-
and
I
said
you
had
some
basic
support.
I
I
have.
I
have,
I
think,
more
more
support
things,
but
we
can
talk
about
that.
If
we
want
to
add
instrumentation
right
now
or
just
finish
up
some
things,
some
of
the
areas
of
the
project
are
not
very
much
tested.
I
mean,
for
example,
what
you
talked
about
resources
is
some
it's
an
area
that
I
implemented
the
api.
B
B
The
code
should
be
behaving
more
or
less
well,
but,
for
example,
resources
is
an
area
I
haven't
touched
more
than
that,
because
I
am
not
using
that
in
my
data.project
working
on
top
of
it.
I
have
worked
mainly
with
traces,
not
much
with
metrics.
I
have
a
very
basic
metric
exporter
for
datadog
that
I
just
want
to
check.
It
was
working.
I
was
thinking
about
improving
that
more,
but
I
have
not
worked
much
on
that
area
so
and
also
another
area
that
is
not
much
tested
is
the
baggage
thing.
B
A
Yeah
yeah
is
is
baggage.
I
I
don't
have
like
a
really
good
knowledge
of
of
all
the
individual
pieces
of
open
telemetry.
A
I've
been
trying
to
to
figure
it
out
and
understand
it,
but
isn't
isn't
baggage
more
about
like
taking
like
it
like
dealing
with
like
links
in
in
distributed,
shape,
tracing
chains
that,
like
it
almost
seems
like
it,
wouldn't
be
very
applicable
to
a
mobile
sdk
just
because
generally
mobile
sdks
are
going
to
be
like
the
leaf
of
or
the
start
of
most
distributed
traces
right,
or
am
I
misunderstanding?
What
baggage
is
for.
C
Yeah
I
can.
I
can
feel
that
one
back
so
baggage
is
basically
it's.
It's
actually
not
even
really
observability.
It's
just
once
you
get
tracing
set
up.
The
underlying
components
of
tracing
are
context
propagation,
so
you
have
some
way
of
flowing
context
to
the
app
and
then
propagating
it,
and
once
you
have
that
set
up.
People
inevitably
want
to
start
making
use
of
that
system
to
just
flow
their
own
values
to
services
that
are
downstream.
C
A
And
it's
and
it's
just
like
an
easier
api
to
add
things
to
instrumented
traces
that
might
not
be
like
the
actual
span
itself
might
not
be
accessible
by
the
end
user.
B
C
Yeah,
whether
or
not
it's
actually
recorded
as
as
value
I
mean
this-
I
I
think
so.
Two
things
happen.
People
want
when
they
add
baggage.
They
often
want
that
to
get
recorded
as
part
of
the
trace.
C
We
don't
currently
have
anything
specked
out
for
how
that
would
work.
So
right
now,
it's
sort
of
like
someone
can
add
it
as
a
span
attribute,
or
they
can
add
a
like
a
processor
that
adds
baggage
as
like
spam
attributes
everything,
but
we
don't.
We
don't
currently
have
a
model
for
like
trace
attributes
that
like
throw
this
on
the
trace
everywhere,
that's
partially,
because
I
think,
oh,
I
don't
know
anyways,
but
the
main
purpose
of
baggage
is
for,
like
let's
say
you
have
just
a
value
like.
C
Let's
say
you
have
a
value
on
the
client,
like
some
information
that
that
client
has
access
to
like
location
data,
or
you
know.
I
don't
know
what
you
know.
Project
id,
like
you,
know
some
some
piece
of
information
that
you
would
want
to
have
access
to
downstream,
but
it
would
be
difficult
to
access
there
like
either
you
have
to
make
extra
api
calls,
or
it's
like
literally
information.
C
You
don't
have,
because
it's
something
like
the
mobile
client
had,
but
your
your
like
back
end
service
won't
have
right,
but
but
you
just
want
as
like
a
developer.
You'd
like
it
would
be
handy
for
me
to
just
have
this
information,
so
baggage
is
a
place
where
you
can
put
values
into
the
trace
and
then
later
pull
them
off.
Okay-
and
this
is
separate
from
tracing
because
on
the
the
spans
are
actually
a
write-only
interface.
C
The
whole
idea
with
spans
is
that
we
don't
want
people
to
make
any
assumptions
about
what's
happening
under
the
hood
right
the
sampling
might
be
on.
We
might
just
be
dropping
the
data
on
the
floor.
You
know
there
might
not
be
anything
installed
and
so
there's
no
way
to
get
information
out
of
the
rates.
So
if
you're
trying
to
say
like
I
want
to
like
set
this
information
and
later
like
get
it
like,
then
you
use
baggage
for
that
yeah.
A
C
Inevitably,
end
users
come
back
if
they're,
using
baggage
and
they're
like
I.
I
also
want
this
information
on
the
trace
because,
like
you
know,
if
it's
important
enough
for
them
to
be
sending
along,
they
usually
want
to
know
about
it
and,
and
they
so
there's
often
a
question
of
like
do.
I
have
to
do
some
extra
step
here
and
right
now.
The
answer
is,
is
yeah
you
should
you
know
you
should.
C
This
is
where
maybe
having
like
a
convenience
api,
which
is
a
thing
we're
popping
up
like
do
we
want
to
just
have
a
call
that
like
sets
this
as
a
trace,
attribute
and
adds
it
to
baggage
yeah?
It
says
a
span
attribute
and
adds
it
to
baggage,
because
right
now,
they're,
just
just
separate
one
use
case
that
I
think
I've
seen
people
do.
C
That's
awesome
is
a
b
testing
like
a
b
testing
in
like
a
distributed
system,
can
become
a
pain
in
the
ass,
really
quick,
because,
like
three
tiers
down
like
am
I
on
the
a
path
or
the
b
path?
And
how
do
you
actually
manage
that
and
with
something
like
baggage?
C
You
can
just
set
set
a
value
of
like
you,
know,
feature
flag
on
or
off,
or
you
know,
a
path
b
path,
and
then
every
system
downstream
can
just
switch
on
that
rather
than
having
to
like
have
separate
deployments
and
doing
the
stuff
at
the
network
level,
so
cool
so
yeah.
I
expect
people
to
build
cool
stuff
with
baggage
yeah,
not
like
it's
not
on
the
like
critical
path
to
like
getting
tracing
working.
It's
just
like
a
separate
system.
C
D
C
Yeah,
and
likewise
you
mentioned
resources,
resources
are
are
definitely
important
because
that's
that's
sort
of
like
how
you're
indexing
the
services.
One
aspect,
I
think,
there's
some
trickiness
there
around.
We
generally
want
those
resources
to
be
immutable
and
like
set
right
when
you
set
start
everything
up,
but
we
are
running
into
some
trickiness
there,
where
some
resources
that
you
want.
You
have
to
fetch
asynchronously
and
it's
not
like
clear
what
that
api
should
look
like.
C
Should
you
block
the
process,
you
know
while
you're
fetching
this
data,
or
should
you
just
be
rolling
and
then
like
have
the
resources
potentially
be
like
mutating
and,
if
so,
like?
You
know
how?
How
would
that
end
up
working?
So
I
know
that's
I'm
not
sure
the
current
status
of
that
discussion,
but
I
think
we
were
relenting
and
saying
like
okay
yeah,
you
can
just
add
resources
later
and
maybe
your
first
batch
of
spans.
C
But
we
do
want
automatic
resources,
ideally
there's
there's
often
a
set
of-
and
I
imagine
this
is
true
for
like
an
ios
client
in
particular,
where
there's
like
info
that
you
know
the
end
user
is
going
to
want
about
that
client
that
you're
capable
of
you
know
the
sdk
is
just
capable
of
grabbing
itself
yeah,
like
all
the
stock
stuff.
You'd,
ideally
want
to
to
just
have
that
just
be
like
a
configuration
option,
that's
like
on
by
default
that
just
captures
all
of
your
standard
yep.
A
C
Resources
are
just
part
of
the
sdk
right
now
we
actually
don't
even
have
an
api
exposed
for
for
messing
with
resources.
So
it's
just
something:
that's
part
of
sdk
setup,
so
I
would
say:
that's
that's
just
just
part
of
the
sdk.
C
Yeah,
so
I
think
I
would
have
to
look
at
the
spec,
but
that's
an
area
where
I
think
there's
a
little
bit
of
gray
zone
where
it's
like
you,
you
want
to
have
the
the
stock
stuff
happen
automatically,
so
you
don't
want
it
to
be
a
separate
plug-in
that
people
have
to
install,
but
if
people
want
to
write
their
own
detectors,
I
think
these
are
called
resource
detectors.
C
Then
maybe
you
want
to
have.
I
think
the
way
other
groups
are
implementing
it
is
they
have
a
resource.
Detector,
api
and
users
can
add
their
own,
but
then
the
sdk
ships
with
some
that
are
built
in
the
ones
that
are
not
built
in
are
like
the
the
infrastructure,
specific
ones
right,
so
you
have
like
aws,
detectors
and
detectors
and
and
those
you
don't
want,
all
of
those
all
of
those
things
have
dependencies
they
come
with,
so
you
don't
want
them
all
installed
automatically
right.
C
A
C
Yeah
yeah,
maybe
people
are
writing
swift
services.
These
days
that
are
not.
Maybe
we
shouldn't
be
presumptive.
That
swift
is
always
running
on
ios,
but
yeah
and.
B
Those
are
the
things
you
want
back
then
yeah.
The
idea
is
supporting
also
macos,
so
they
should
have
something
there.
Maybe
someone
yeah,
it's
not
the
main
yeah
switch.
Definitely
but
yeah
I
think
apple
is,
is
pushing
in
the
server
space
at
least
themselves,
but
yeah.
You
never
know
how
it
will
end
up
in
that
front,
but
yeah
initially
we
we
are
trying
to
support
that.
B
Also,
there
is
swift
on
linux,
that's
something
that
we
are
currently
not
supporting,
because
we
need
some
specific
mac
frameworks
for
mainly
context
handling
and
the
yeah,
and
the
active
spam
thing
is
working
based
on
some
private
libraries.
C
B
I
have
I
have
plus
in
plans
in
generalizing
that
so
another
version
of
that
could
be
written
in
linux
for
by
linux
experts,
but
I
have
never
I
I
have
always
been
a
mac
developer
or
my
professional
life.
So
I
I
am
not
very
embarrassed
on
linux,
stuff
or
linux
system
stuff.
So.
C
And
this
is
also
why
one
of
the
reasons
why
we
try
to
have
api
and
sdk
separation
is
it
it
in
some
cases
it
might
be
the
case
that
you
have
one
sdk
and
it's
pluggable,
but
if
you
are
running
into
a
situation
where
it's
like,
the
sdk
really
needs
to
depend
on
this
set
of
libraries
or
it
becomes
like
ridiculous.
C
You
have
an
sdk
for
all
you're
running
on
all
the
mac
hardware
and
maybe,
if,
if
it's
not
possible
to
extract
those
libraries
into
plugins
without
it
becoming
like
really
ridiculous,
then
then
you
just
have
a
separate
sdk
for
for
people
running
on
linux,
but
I'm
not
I'm
not
sure
what
the
situation
is
over
here,
like
that's
the
thing
they'll
run
into
in,
like
c
plus
plus,
for
example,
like
we're
writing
a
c
plus
plus
sdk
that'll
work
for
like
most
cases
but
c
plus
plus,
has
so
many
weird
edge
cases.
C
Cool
well,
it
sounds
like
things
are:
are
people
already
using
this?
I'm
curious
like
do
you
already
have
have
this
in
production
anywhere
over
at
datadog?
Yes,.
B
I
mean
it's:
it's
been
just
in
a
product
that
it's
been
dog-footed
inside
datalog
and
in
yeah.
The
product
is
also
in,
but
there
are
no
external
testers
on
my
code
based
on
open
telemetry.
B
A
C
And
and
instrumentation
is
usually
like
a
key
yeah
piece
of
making
it
usable
and
that's,
I
think,
there's
a
question
about
like
where
does
instrumentation
live?
That's
actually
like
a
broad
question.
We're
trying
to
deal
with.
I
see
okay,
so
I'm
not
there.
A
C
I
don't
know
if
you've
been
showing
up
to
like
the
spec.
I
have
a
a
tracing
road
map
that
I
I
pasted
into
the
meeting
notes.
Yes,.
A
I
thought
that
I
don't
know
what's
going
on,
but
my
my
chrome,
it's
just
like
all
like,
like
it
loads
that
page
or
that
dock,
and
it's
just
like
all
like
pixelated
and
stuff.
So
I
think
I
need
to
restart
my
computer
so
I'll
take
a
look
at
that
later.
C
A
No
having
you
here
is
great
having
somebody
with
the
with
the
context.
So
that's
awesome
yeah,
I
figured
it
would
be
helpful.
C
To
give
people
like,
like
just
the
dl
on
where
the
project
currently
is
so
this
is
sort
of
this
doc
is
just
kind
of
going
over
like
what
we
see
is
the
timeline
this
year,
I'm
gonna
clean
this
up.
C
This
is
hard
to
read,
and
I'm
gonna
add
logging
on
here
once
once
that
group
figures
it
out,
but
but
like
the
basic
plan
right
now
is
these
green
lines
are
metrics,
so
the
metrics
work
is
getting
completely
redone
right
now,
so
the
data
model
is
getting
finished
up
and
we're
doing
a
lot
of
work
with
the
prometheus
community
to
ensure
our
metrics
data
model
and
like
how
we're
planning
on
managing
metrics
is
going
to
work
really
well
with
prometheus.
C
So
we're
that's
sort
of
like
the
main
work
over
there
right
now
is
to
make
sure
by
like
end
of
may,
we
have
like
super
strong,
prometheus
support
baked
into
the
the
collector
and
we've
confirmed
with
the
prometheus
community
that,
like
our
data
model,
is
like
going
to
play
nicely
with
them.
So
if
you
were
a
prometheus
user,
you
could
switch
to
using
the
open,
telemetry
client
tool
chain
and
it
wouldn't
be
like
you
know
you
lose
features
or
some
disaster.
C
A
C
Intimidating
and
so
we're
we're
we're
redoing
that
we
want
to
keep
keep
a
lot
of
the
features
like
that.
Josh
mcdonald,
from
lightsteps,
one
of
the
main
people's
been
pushing
that
stuff
forwards
and
former
google
engineer.
But
we
want
to
make
sure
that
we're
keeping
the
the
features
that
were
in
there
but
like
retooling
that
so
that
the
api
is
something
that's
not
gonna
confuse
the
heck
out
of
our
users,
who
just
to
create
a
gauge
and
like
yeah
yeah.
C
C
C
But
so
so
riley
from
microsoft
is
is
kind
of
heading
up
that
work.
So
there's
a
there's,
a
metrics,
a
couple:
metrics
meetings
now
one's
the
data
model,
stuff
one's
the
prometheus
working
group
and
one
is
this
api
working
group?
That's
trying
to
to
to
retool
that
so
that's
coming
along!
C
We
had
some
thrash
in
the
past
where
it
was
like
kind
of
a
moving
target,
and
we
want
to
avoid
that
this
time
around,
but
at
some
point
in
the
summer
that
work
will
land
in
the
spec
and
the
the
hope
is
that
around.
Like
you
know,
september
groups
will
that
have
all
their
tracing
work
kind
of
done,
we'll
be
able
to
focus
on
on
just
shifting
like
a
release
candidate
of
like
the
metric
stuff
and
and
locking
it
down.
C
So
the
the
goal
of
all
those
metrics
working
groups
is
to
make
sure
everything's,
you
know
done
by
middle
of
summer,
so
that,
like
by
september,
we
can
focus
on
like
okay,
this
this
is
stable.
We
have,
you,
know
a
beta
shift,
and
now
we
can
go
to
like
a
release,
candidate
phase
and
and
get
that
kind
of
feedback.
C
So
we
wanna
we're
trying
to
make
sure
all
the
tracing
work
we're
looking
at
doing
kind
of
fits
into
this
box
before
september.
As
far
as
like
new
tracing
work,
just
to
make
sure
that
you
know
september
to
end
of
year,
we
can
be
focused
more
on
just
like
just
like
cleaning
things
up,
and
you
know,
focusing
on
making
sure
the
release
candidate
can
be
can
be
sent
out
and
stabilized
for
first
for
metrics,
the
tracing
work
is
mostly
focused
on
just
like
convenience
for
the
end
user.
C
So
the
work
we're
trying
to
kick
off
right
now
is
around
a
convenience
api.
The
tracing
model
we
have
is
is
good.
We
believe
it's
good
and
it's
useful
for
people
who
are
writing
instrumentation
if
you're,
trying
to
like
instrument
a
framework
and
handle
a
lot
of
different
edge
cases,
but
if
you're
an
application,
developer
and
you've
like
already
installed
all
this
instrumentation
and
that's
good
and
now
you're,
just
trying
to
like
decorate
your
application
code.
C
We
feel
like
that
persona
could
use
more
convenience
and
I
don't
totally
know
what
convenience
means
in
swift.
In
java,
for
example,
this
means
things
like
annotations.
C
You
know
they
can
presume.
You've
already
got
an
active
span
and
some
other
things.
So
so
it's
mostly
just
hey
all
this
stuff.
That
would
make
it
easy
for
an
end
user
who
already
installed
their
instrumentation
to
just
like
you
know,
have
an
api
that
looks
a
little
bit
more
like
logging,
or
something
we're
just
trying
to
figure
out
what
what
that
kind
of
convenience
would
look
like.
C
Guidelines
like
like
it'll
be
different
for
language,
but
it's
also
like
kind
of
similar,
and
so
it's
sort
of
like
these
are
things
like
we
want
to
just
come
up
with
a
list
of
like
what
are
based
on
feedback
like
what
are
the
common
things
people
are
asking
for
and,
like
you
know,
if
you're
gonna
use
a
keyword
to
describe
this
thing,
like
you
know,
try
our
best
to
use
the
same
keywords
across
languages
so
that
you
know
if
it
is
the
same
concept,
we
we
call
it
the
same
thing,
but
it's
it's
a
it's
actually
less
of
a
hard
requirement
than
with
the
the
core
model,
because
all
this
stuff
is
built
on
top
of
the
core.
C
You
can't
really
like
mess
it
up
right.
The
the
core
with
having
the
deal
with
having
the
core
model
really
look.
The
same
across
languages
is
actually
just
ensuring
that
that
it's
all
going
to
like
be
able
to
come
out
as
otlp
and
and
like
all
the
concepts
are
there.
But
really.
This
is
just
like
the
gravy
that
your
end
users
might
might
want
to
have
and
yeah.
I'm
not
sure
what
that
looks
like
in
swift,
I'm
not
a
swift
programmer,
I'm
old,
objective
c
jockey.
A
No
I'm
right
there
with
you
ted,
like
I'm.
I
did
most
of
my
work
you've
seen
too
so
this
new
fangled
swift
stuff,
like
I
was
looking
for
things
like
annotation,
maybe
nacho
can
can
chime
in
but
yeah.
I
don't
think
that
we
have
the
nice
of
these
like
annotations
and
swift.
Yet
if
we're
gonna
ever
get
them.
C
Yeah,
I
know
it's
a
very
dynamic
language,
so
there
may
be
like
things
it
can
do,
but
or
just
like
common
patterns.
Yeah.
B
C
You
know
anyways
anyways,
that
that's
convenience.
The
next
thing
after
that
we
want
to
look
at
on
this
sort
of
track,
is
like
simplif
ensuring
the
installation
is
is
simple
again,
I'm
not
sure
what
this
looks
like
for
swift,
but
one
example
is
just,
for
example,
being
able
to
automatically
install
all
the
instrumentation
packages
that
would
be
relevant
for
your
application,
especially
with
tracing.
C
If
a
user
forgets
to
install
a
key
piece
of
instrumentation,
then
they're,
it's
not
just
they
don't
get
data,
but
their
traces
break
right
like
if
you
don't
install
a
client,
instrumentation
or
something
like
that
and
some
languages
like
java.
You
have
like
this
agent
pattern
where
it
can
do
that,
all
for
you
and
in
python,
there's
like
it's
not
quite
as
clean
as
an
agent,
but
there's
definitely
dynamic
stuff.
That
can
happen
where
it
can
detect.
C
C
Currently,
there's
no
wrapper
around
open
telemetry,
it's
kind
of
like
tinker
toys
like
you,
create
a
tracing
provider
and
a
metrics
provider
and
like
this
and
that
and
but
if
you're,
just
like
I'm
talking
otlp
to
a
collector
like
we
could
wrap
all
of
that
up
into
like
a
you
know,
just
like
a
default
one-liner
and
like
maybe
there's
a
way
to
like
use,
yaml
or
some
other
common
configuration
language
or
if
swift
has
something
that's
like
like
in
python,
they
have
python
ini
files,
and
I
don't
know
if
there's
a
swift
equivalent
to
like
this
is
how
users
swift
developers
configure
their
crap,
but
but
all
of
that
installation
convenience
is
a
project.
C
We
want
to
focus
on
just
doing
some
research
and
figuring
out
what
that
should
look
like
and
then
the
next
one
is
diagnostics.
So
this
is
how
do
we
get
some
kind
of
standard
diagnostics?
Out
of
you
know,
if
a
user
is
like
my
open,
telemetry's
broke,
we'd
want
to
one
be
able
to
say
like
run
it
with
this
flag,
and
then
it
spits
out
like
again
like
a
yaml
file
or
something
that's
just
like
here
is
everything
that
was
installed.
Here's
all
the
configuration
options
that
were
set.
You
know
all
the
information.
C
A
support
person
would
want
you
to
like
paste
into
the
slack
channel
or
whatever.
So,
if
someone's
wandering
into
open
telemetry
slack,
we
can
just
be
like
run
this
thing
and
then
like
paste
paste,
what
it
put
would
it
spat
out?
So
that's
like
one
aspect.
C
The
other
is
like
what
kind
of
like
runtime
diagnostics
do
we
want
to
have
like
like
if
open
telemetry
is
totally
busted
like
how
should
it
log
things
if
it's
not
totally
busted,
but
a
user
is
like
making
api
calls
that
are
causing
exceptions
or
like
the
the
the
span
buffers
overflowing
and
your
exporter,
so
you're
losing
data
like
like?
How
do
we
actually
report
like
those
kinds
of
runtime
problems,
you
know?
Is
there
a
way
we
can
report
them
actually
like
if
it's
running
well
enough
that
it's
sending
data?
C
Is
there
a
way
we
can
report
it
there?
If
it's
so
broke
that
you
know
it's
the
problem,
it's
like
how
how
do
you
report
when
you're
reporting
mechanisms
busted?
How
do
you
report
things
yeah
so
so,
like
that,
that
kind
of
pile
of
problems
we
wanna,
we
wanna
do
some
design,
work
and
figure
out
like
what's
what's
the
right
thing
to
do
there,
so
those
are
like
the
the
three
like
tracing
initiatives
that
we're
looking
at
doing
design
work
on
over
the
summer.
C
C
We
want
to
ideally
have
a
plan
together
by
the
time
may
starts
for
how
we're
gonna
handle
instrumentation,
because
interns
are
gonna,
hit
the
project
starting
in
may
and
we'd
like
them
to
write
instrumentation
and
in
general,
it's
like
critical
that
we
now
that
apis
are
stabilizing,
that
we
solve
some
of
these
problems
and
those
problems
are
related
to
one.
It's
like
there's
one
track,
which
is
like
semantic
conventions
like
we.
C
We
have
some
but
like
we
know
they
could
be
better
like
how
do
we
ensure
that
the
instrumentation
people
write
for
open
telemetry
is
like
at
least
as
good
as
what
you
would
get
out
of
like
equivalent
systems?
C
Part
of
that
just
like
what
are
the
literal
attributes
you
send,
but
some
of
it's
also
like
structure
like
like
for
an
http
request.
You
have
like
a
logical
request,
but
you
may
like
how
do
you?
How
do
you
model
retries
like
if
you
have
a
request,
but
it
did
two
retries
and
then
it
followed
like
a
503,
and
then
you
know
like
tcp
handshake
like
had
to
reconnect
like
all
of
that
kind
of
stuff.
Are
those
are
those
like
events
on
one
span?
Do
we
have
subspans
if
there
are
sub
spans?
C
Do
the
act
which
span?
Does
the
attributes
go
on,
like
there's
kind
of
like
a
pile
of
questions
there
around
some
of
these
core
core
use
cases
that
we
feel
like?
We
need
to
like
actively
investigate
and
then
write
really
clear
guidance
yeah
for
instrumentation
authors,
so
that
and
just
anything
we
can
do
to
ensure
instrumentation
is
going
to
be
high
quality
and
then
also
try
to
stabilize
that
stuff
figure
out.
C
This
is
like
one
of
the
tricky
things
about
having
an
open
source
project
that
talks
to
a
lot
of
back
ends.
Is
you
kind
of
can't
play
catch
where,
like
I
change
the
clients,
but
I
know
they
change,
so
I
change
the
back
end
and
we
want
to
make
sure
we're
not
like
improving
things,
but
the
improvement
is
like
breaking
everybody's
dashboards
and
technical
stuff.
So
so
that's
like
one
pile
of
instrumentation.
C
C
There's
the
buckets
of
stuff,
that's
like
so
core
that
it
gets
installed
automatically
and
that
lives
directly
in
the
the
sdk
like
directly
in
the
core
sdk
repo,
for
example,
in
like
java,
that's
like
fork,
join
pools
and
stuff
like
that.
There's
some
some
like
stuff
that
just
goes
in
and
glues
together,
because
it
like
it
just
has
to
or
your
stuff
isn't
gonna
work
and
then
there's
the
stuff.
That's
just
like
regular
instrumentation
right
like
framework
instrumentation
and
client
instrumentation,
where
you
only
wanna
install
it.
C
If
the
application
is
actually
running
the
target
package
for
most
groups,
they
created
a
second
repo
called
contrib
and
all
of
the
exporters
and
instrumentation
like
all
the
plugins
and
instrumentation
packages
that
aren't
the
core
stuff.
That
would
always
ship
with
the
sdk
ends
up
living
as
packages
and
contrib,
and
that,
like
that,
works
okay
in
the
sense
that
it's
like
okay,
you're,
not
automatically
hauling
in
all
of
these
dependencies,
but
as
that
grows.
C
Usually,
what
happens
is
like
somebody
shows
up
and
wants
to
donate
some,
and
then
you
say
sure,
but
do
you
leave
that
person
on
as
like
as
like
an
owner
in
the
github
repo,
if
you
do
like
if
a
ticket
comes
in
like
who
who
answers
that
thing
also
like
who's
in
charge
of
keeping
the
stuff
up
to
date,
since
this
is
the
place
where
it's
like
a
moving
target
like
language
versions,
are
pretty
slow
but
like
instrument
like
instrumentation
in
the
long
run?
C
This
is
like
the
bulk
of
the
effort
of
the
project,
basically
because
that
stuff's
gonna
change,
so
we
don't
know
where
that's
going
to
go.
If
we
say
like
hey,
we
don't
want
to
maintain
this.
C
You
maintain
this.
Somebody
else
maintains
this.
We
don't
have
the
bandwidth,
then
how
does
auto
installation
work
right?
We
want
to
make
sure
that
users
can
install
all
of
this
stuff
right,
like
the
user,
is
not
going
to
really
have
a
choice
about
installing
that
framework
instrumentation
for
the
framework
they're
using
whether
it's
like
us,
maintaining
it
or
we
said
somebody
else
needs
to
maintain
it
like
they're
still
gonna
install
it,
which
means
they
still
need
a
way
to
like.
C
If
our
auto
installers,
don't
don't
deal
with
those
things
like
it's
not
going
to
be
a
good
experience
for
people,
but
the
flip
side
is
like
security.
We
live
in
this
modern
world
now,
where
like
open
source
security
is
like
supply,
chain
attacks,
and
things
like
that
are
a
real,
genuine,
serious
issue,
and
we
expect
open
telemetry
to
be
like
a
major
project.
That's
going
to
get
installed
in
in
you
know
serious
places,
and
we
don't
want
it.
C
We
want
to
have
at
least
some
story
there
for
it's
not
like.
We
just
auto,
install
the
internet
on
your
computer
for
you
by
default,
so
so
that
that's
just
like
a
a
a
managerial
knot
that
we
have
to
unplug
as
a
project.
C
If
you
want
to
start
adding
instrumentation,
which
I
recommend
you
do
just
create
a
contrib
repo
to
put
it
in
unless
it
you're
talking
about
like
core
framework
packages
that
are
always
going
to
be
available
and
I'm
not
even
sure
like
how
much
is
common
across
ios
and
mac.
These
days
I
mean,
I
know
some
of
it
is,
but
I
assume
some
of
it
isn't
so
that
that
would
be.
I
think
that
for
this
group
it's
sort
of
figuring
out
where
how
does
the?
How
does
the
course
stuff?
C
That's
that
you
are
always
going
to
kind
of
have
presumed
available
right
like
all
the
stuff
that
apple
provides
like
where,
where
does
that
instrumentation
live?
That
should
definitely
be
managed
by
the
core
group
for
sure,
unless
we
can
convince
apple
to
take
it
on
I'm
actually
going
to
reach
out
to
the.
A
B
B
I
said
that
I
was
the
open,
telemetry
maintainer,
that
they
were
open
to
contribute
or
add
or
whatever
they
wanted
nothing
more
from
there
yeah.
So
they
they
even
they
have
added
some
things
about
login
and
having
some
instructors
compatible
with
open
telemetry,
but
they
haven't
shown
anything
and
or
said
anything
more
about
that.
So
it
looks
like
usually
they
make
the
world
on
their
on
their
side,
and
you
know
it's
difficult
to.
B
I
don't
think
they
will.
They
will
want
to
contribute
here,
but
if
you
push
them-
and
it
will
be
great-
definitely
yeah.
E
B
C
I
think
it
would
be
awesome
to.
I
have
like
two
hopes
on
that
from
one
to
like
kind
of,
maybe
if
we
could
get
an
audit
from
some
of
those
people.
This
is
a
thing
where
we're
looking
for
in
the
languages
right
now
is
like.
We
want
end
users
to
give
us
feedback,
but
if
we
can
get
some
like
language
experts
to
to
look
at
the
stuff
too,
that
might
be
helpful
and
then
the
other
part
is
just
native
instrumentation
long
term.
C
Would
they
be
willing
to
to
bake
this
in
or
if
they're
gonna
do
their
own
thing?
Can
we
make
sure,
like
you
know
it?
I
either
like
they
bake,
open
telemetry
in.
B
B
C
Yeah,
that's
my
hope
is
either
they
like
make
sure
it
works.
Well
with
this,
they
you
know,
help
us,
you
know
with
the
instrumentation
and
we
maintain
it
over
here.
They
bake
it
in
or
if,
like
they're
like,
we
don't
want
to
make
a
third
party
thing
in
like
like
one
potential
thing,
I
think,
would
be
awesome
if
they're
like
we
don't
we'll
do
it,
but
it
has
to
be
like
an
apple
thing.
C
I
don't
know
if
you
all
would
be
open
for
it
getting
contributed
upstream
if
it
goes
that
direction,
but
you
know
that
yeah,
absolutely
I
mean
yeah
ideal
is
the.
I
want
these
things
as
core
as
possible.
Right,
like
we
don't
want
to.
The
yeah
like
I
predict,
tracing,
becomes
this
like
requirement
for
languages
in
the
future.
Once
once,
the
end
users
are
like
used
to
doing
this
stuff,
so
much
of
like
the
context
management
crap
is
like
it
feels
awkward
to
be
doing
it
in
user
land.
C
This
is
like
really
something
the
runtime
should
be
doing
for
us.
So
anyways,
I'm
gonna,
poke
them
and
see,
see,
see.
B
Yeah,
it
will
be
great,
I
know,
microsoft
is,
for
example,
is
adopting
all
the
tracing
stuff
internally
and
they're,
using
baggage
stuff
or
headers
automatically
being
transmitted
that
that
would
be
great.
I
mean
I
am
writing
this
stuff,
because
I
need
it
for
my
work
exactly
I
like
the
library
I
like
the
project,
but
some
of
the
stuff
I
must
write
is
something
that
I
would
prefer
other
people
more
with
more
knowledge
of
the
topic
to
to
to
take
it.
B
I
mean,
because
I
know
it
will
make
a
much
better
word
than
I
than
I
can
do.
I
have
written
most
of
the
areas,
so
so,
but
they
are
not
an
expert
on
all
of
them,
so.
C
Right
well,
we'll
try
to
get
more
people
involved
for
sure,
and
I
think
you've
been
doing
a
great
job
personally
but
yeah
if
we
can
get
apple
to,
or
at
least
some
swift
people
like,
even
if
they're,
not
apple
people,
but
just
swift
experts
of
some
form
to
come
to
to
come,
give
an
audit
that
would,
I'm
sure,
would
be
be
helpful,
just
making
sure
the
experts
like
it
and
also
making
sure
the
non-expert
new
users
are
like
like
find
it
approachable.
C
1.0
readiness-
I
don't
know
how
much
you've
thought
about
backwards,
compatibility
and
versioning,
but
this
is
just
by
the
way
one
aspect
we
want
to
figure
out,
which
is
making
sure
that
the
tracing
stuff
when
it
goes
stable
when
we're
adding
features
in
the
future,
to
tracing
thinking
of
just
ensuring
the
way
it's
been
modeled
using
the
language
primitives,
that
it
will
be
extensible
and
not
cause
a
breaking
change
to
existing
instrumentation
and
then
there's
the
other
part,
which
is
when
we
have
new
experimental
stuff
showing
right
like
so
tracing,
is
stable,
but
metrics
is
still
totally
experimental,
breaking
left
and
right,
ensuring
that's
modeled
in
such
a
way
that
people
who
are
pulling
in
just
the
tracing
stuff,
just
as
stable
stuff,
aren't
getting
broken
when
we
make
a
change
to
the
experimental
stuff.
C
So
those
are
those
are
two
things
I
don't
know
if
you've,
given
that
much
thought.
But
those
are
things
to
think
about
before.
Just
before
we
hit
1.0,
we
want
to
make
sure
we
have
a
versioning
story
for
for
how
we're
gonna,
how
we're
gonna
keep
existing
callers
of
the
api.
From
from
breaking
as
we
continue
to
add
new
features,
I
see
a
bunch
of
people
showing
up.
This
must
be
yeah
yeah.
This
is
probably
the
go
meeting
starting
yeah
hi,
rich,
hey,
bryce,
how
you
doing
good
cool.
A
All
right
well
I'll
talk
to
you
too
later:
okay,
yeah,
first
meeting
yeah
nice
meeting.
You
all
sorry
for
watching
your
time,
bye,
bye,
bye,
y'all,.
E
C
Yeah
yeah,
now
it's
the
swift,
stick:
okay,
yeah.
E
Yeah
see
you
well
hello,
everyone
thanks
for
joining
it's
10
a.m,
and
so
we're
not
actually
too
far
behind
by
any
means.
Please
go
ahead
and
add
yourself
to
the
attendees
list
on
the
agenda
and
if
you
have
any
agenda
item
topics
you
want
to
discuss,
please
add
those
there
as
well.
We'll
start
just
a
little
bit
looks
like
there's
some
chat.
E
E
Cool,
well,
I
see
anthony's
here
yeah.
I
think
we
have.
Maybe
we
have
critical
mass
at
this
point
so
that
steve
would
be
here
as
well,
but
he
seems
to
be
every
other
week
in
many
ways,
so
maybe
he'll,
maybe
we'll
watch
the
recording
and
we
can
just
say
hi
that
way
cool.
We
can
jump
into
this
and
get
started
with
the
agenda.
I
wanted
to
start
off
by
going
over
our
project
boards.
There's
been
some
really
great
progress
on
the
optimistry
go
rc
project
board.
E
Three
new
issues
came
in
over
the
past
week.
Definitely
had
some
progress
on
in
progress
and
just
how
much
we're
actually
getting
done
definitely
got
a
lot
of
things
accomplished
this
past
week,
I'm
trying
to
also
identify
prs
that
are
related
to
these
sort
of
rc
tasks
and
tag
them
appropriately
as
well.
It's
somewhat
double
counting
and
it's
somewhat
not
double
counting,
I'm
not
100
sure
on
that.
E
I
don't
think
anybody
on
the
call
cares
or
if
they
do
please
let
me
know,
but
I
think
it's
a
helpful
way
to
visualize
this
so
yeah
I'm
going
to
keep
doing
it.
Just
a
heads
up.
That's
probably
why
that
number's
going
to
go
high,
you
know
for
those
sort
of
things.
The
next
thing
I
kind
of
want
to
dive
into,
though,
is
this
specs
conformance
review.
E
I
was
my
goal
was
to
have
this
done
today.
I
had
one
issue
completed
yesterday,
though,
so
I
was
not
able
to
maintain
my
momentum
in
trying
to
complete
a
lot
of
these
tasks.
That
being
said,
we're
doing
pretty
good.
We
have
18
done
13
to
go
four
in
progress
and
two
are
mostly
done.
This
is
kind
of
just
waiting
on
the
specs,
although
this
one
I
need
to
find
the
linking
pr.
I
think
this
might
actually
be
done.
It
just
needs
to
get
merged,
but
yeah.
E
This
is
something
I
could
definitely
use
some
help
on.
I
really
don't
want
this
lingering
through
next
week,
and
I
really
would
like
to
have
this
done
so
we
can
move
on
to
going
in
and
just
basing
this
everything
off
of
the
don't.
You
go
rc
because
we
have
some
sort
of
inventory
and
audit
done
and
have
it
complete.
That
being
said,
I
understand
it's
open
source.
E
I
can't
like
you
know:
I'm
not
a
task
master
either,
but
I
would
love
if
anybody
on
the
call
is
able
to
commit
to
just
pulling
one
of
these
issues
and
getting
it
done
tomorrow
or
the
next
or
monday,
or
something
like
that
really
ideal.
Otherwise,
I'm
really
trying
to
dedicate
the
rest
of
like
my
time
that
I'm
actually
working
on
this
project
to
maintain
our
duties
and
merging
things
and
then
trying
to
get
these
done
to
make
sure
this
autumn
is
complete.
E
I
would
have
liked
to
have
done
it
had
it
done
today,
but
I
don't
think
I'm
gonna
finish
all
13
of
these
today.
So
that's
just
not
a
possible
thing,
but
yeah.
If
you
are
feeling
inclined,
even
if
you
can't
commit
to
doing
it
today
or
tomorrow,
but
want
to
do
that
on
monday
feel
free
to
jump
in
here.
Just
comment:
if
you
can't
assign
yourself
assign
yourself
if
you
can
assign
yourself-
and
we
can
get
some
momentum
going
on
here-
it'd
be
really
helpful.
E
E
That
being
said
I'll,
get
off
my
soapbox
and
we
can
move
on
and
I'm
sure
you
all
are
sick
of
hearing
me
say
these
sort
of
things,
but
anyways
we're
doing
a
really
good
job.
I
just
I
would
love
to
keep
it
going,
though,
is
all
I'm
saying
next
thing:
first
on
the
agenda
was
david.
We
get
asked
to
have
this
merged.
Well,
look
at
that.
The
maintainers
are
doing
their
job
because
it
got
merged
15
minutes
ago,
or
something
like
that.
E
So
again,
I
want
to
apologize
publicly
to
david
for
having
us
take
so
long
to
get
merged,
but
yeah
thanks
again
for
the
contribution
and
sorry
it
took
so
long.
It's
a
really
great
thing
and
the
goal
here
is
just
iterate
on
it,
and
I
think
this
is
a
really
critical
thing,
as
we
try
to
have
user
adoption
from
people
who
are
already
using
open
senses
so
really
appreciate
it.
Yeah
thanks
cool,
then
moving
on
anthony.
Would
you
want
to
talk
about
this
before
we
do?
The
record
exception?
E
We've
already
talked
about
record
exception
in
the
past.
Can
I
imagine
this
is
going
to
just
spiral.
So
I'm
wondering
if
you
wanted
to
dive
into
this.
F
Here
it's
muted,
though
my
video
is
probably
a
bit
behind.
Oh,
are
you
able
to
hear
me
hey
hold
on?
I
think
I
might
need
to
move
to
another
computer.
E
Oh
okay,
all
right!
Well,
I
think
that
answers
that
question
then
I
think
we
should
jump
into
maybe
some
of
the
record
exception
and
we'll
wait
for
anthony
to
come
back.
Hopefully
he
comes
back
so
I'm
kind
of
interested
what
his
opinion
on
this
one
is
as
well,
but
I
can
just
dive
into
the
the
topic
at
hand
which
I
still
have
to
respond
to,
but
the
idea
is
that
the
specification
itself,
let's,
let's
start
at
the
beginning,
I
guess
for
people
who
aren't
particularly
aware
of
this.
E
I'm
sorry,
if
that's
not
the
correct
word
to
use,
it
recommends
that
there's
a
record
exception
method
on
a
span
and
that
record
exception
method
is
for
languages
that
use
exceptions
in
particular,
and
we
have
currently
a
record
error
method
on
our
span,
and
that
is
something
that
is
using
the
the
go
idiom
of
an
error
and
it
records
that
error
as
a
span
of
m,
it
used
to
set
the
span
status
to
error,
but
it
doesn't
anymore
now
that's
something
you
have
to
do
externally,
with
maybe
some
options
in
there.
E
Still
like
having
that
be
a
unified
call,
but
that
isn't
essentially
considered
as
an
exception
in
the
go
parlance.
Yet
there's
a
pr-
and
we
have
this
issue
here-
to
try
to
merge
the
two
concepts
which
seems
like
it
made
sense
because,
like
it
was
a
kind
of
similar
thing
and
like
you
want
to
record
an
error,
so
it
seems
like
there's
a
problem
and
another
language
is
when
you
record
an
exception,
it
kind
of
seems
like
there's
a
problem,
so
there
was
overlap
there.
E
The
problem
is,
is
that
there
may
in
the
future,
also
be
a
you
know,
recommendation
that
on
a
span,
a
record
error
method
is
added
and
that
it
records
an
error
of
a
particular
format
and
if
that's
the
case,
it
would
paint
us
in
a
corner
to
have
this
record
error
method
record
things
as
exceptions,
which
is
not
necessarily
ideal,
and
it
would,
you
know,
not
necessarily
serve
a
lot
of
the
people
using
this
project.
E
So
that's
not
really
like
something
I
wanted
to
like
kind
of
pause,
and
maybe
we
can
have
some
like
thought
on.
This,
I
think,
was
the
idea,
the
I
think.
There's
an
analogous
thing
for
panics,
but
let's
just
kind
of
maybe
talk
a
little
bit
about
the
errors
themselves.
First,
when
we
dive
into
panics-
and
I
had
suggested-
maybe
going
with
something-
you
know
that
was
unique
for
errors,
but
it
was
also
kind
of
pointed
out.
E
I
think
I
haven't
I've
read
through
this
really
quickly,
but
that
you
know
if
you
do
record
errors,
there's
something
that
are
different
than
exceptions,
but
other
languages
are
recording
them
as
exceptions
and
there's
no
like
standardized
way
to
record
an
error.
Yet
back
ends
are
going
to
be
building
tooling
around
these
exceptions
and
these
event
exceptions
and
visualizing.
These
event,
exceptions
as,
like
you
know
things
that
they
want
to
present
to
the
users
in
some
sort
of
fashion.
That
is
like
useful
for
them.
E
I
know:
there's
definitely
some
a
lot
of
possibility
there
but
like
if
there's
no
standard
way
to
like
unify
and
identify
they're
going
to
be
sending
errors
up
in
a
particular
way.
They're,
probably
not
going
to
be
building
things
for
those,
and
so
all
of
these
errors
that
we're
sending
up
are
just
going
to
be
put
into
a
black
hole.
E
So
it
seems
like
kind
of
like
a
problem,
maybe
not
the
end
of
the
world,
because
you
know
if
enough
users
are
also
experiencing
like
well.
I
have
all
these
other
errors
and
all
these
other
languages,
and
I
want
to
set
them
up
as
errors
eventually
like
it
will
become
something
that
is
sent
up
but
yeah.
E
It
was
identified
that,
like
not
sending
these
up
as
exception
events
could
could
you
know,
have
users
not
be
served
with
what
they
actually
want
on
their
back
ends
so
pause
there
before
we
kind
of
dive
into
the
panic
stuff.
F
F
If
this
is
something
that
the
user
is
calling
an
error,
you
know
a
fault
or
something
like
that:
that's
they
they
can
set
the
error
status
on
the
flag.
I
think
for
us
trying
to
record
this
context,
information
about
an
error
that
happens.
You
know
a
go
error
that
happened
during
the
process
of
this
span.
F
Calling
that
record
error
is
the
most
appropriate
and
idiomatic
for
our
language.
I'm
not
really
a
huge
fan
of
then
putting
them
in
exception
attributes,
but
I
understand
the
desire
to
be
able
to
correlate
them
correlate
across
languages
where
some
languages
are
calling
them
exceptions
and
some,
and
we
would
be
calling
them
errors.
E
Yeah,
so
this
is
an
interesting
problem.
I
think
I
also
don't
know
if
you
missed
the
part
where
I
was
talking
about
like
eventually,
I
don't
think
you
missed.
I
think
you
were
involved
in
the
conversation.
I'm
sorry
derogatory,
but
like
just
like
eventually,
the
spec
may
also
add
something
that
is
record
error,
and
if
we
are
recording
our
errors
as
exceptions,
then
we
would
be
like
we
have
to
make
some
sort
of
incompatible
change
there
as
well.
I
don't
know
if
you
heard
that,
but.
E
Yeah,
although
the
thing
is
is
like
it
may
want
to
make
a
distinction
into
the
events
it
creates.
So,
like
the
record
error
method
from
the
specification,
they
say
to
send
up
events
that
are
titled
differently
than
the
exceptions.
F
Yeah,
so
if,
if
we
add
an
option
to
the
record
error
function
that
we
have
currently
the
method
on
span,
that
would
indicate
to
it
that
it
should
set
the
span
status
to
error,
we
could
also
have
it
set
different
attributes
on
the
event
that
it
creates
in
that
case,
well,.
E
The
event
should
be
titled
differently
is
what
I'm
saying,
though,
like
the
specification
will
require
an
event,
be
titled
error
and
then,
if
it's
an
exception,
be
titled
exception,
and
so
then,
how
do
we,
like
I
mean
we?
Could
we
could
make
it
so
that,
like
if
you
pass
that
you
know
record
as
or
set
an
error
like
you
could
make
that
happen,
but
it's
not
necessarily
like
a
one-to-one
there.
It
seems
like
there's
two
different
use
cases
there
and
also.
E
I
think
that,
like
you
brought
up
another
really
interesting
point
I
wanted
to
call
out.
Is
that,
like,
I
think
this
is
just
embroiled
in
the
concept
of
like?
Should
errors
or
should
exceptions,
be
used
as
control
flow
and,
like
are
exceptions
or
are
errors,
something
that
are
like
unrecoverable
like
things
of
a
program
or
are
they
things
like
and
defile
is
reached?
And
it's
a
signal
you
know
like
these
sort
of
things.
G
So
I
had
a
thought
on
this:
what
if
we
had
a
record
error
that
is
as
bare
bones
as
possible
with
options
to
make
it.
However,
we
want-
and
we
do
include
a
record
exception-
that
kind
of
conforms
to
what
the
spec
is
saying,
because
there's
there's
an
impedance
mismatch
here
between
what
hotel
is
specified
and
what
go
considers
to
be
right.
G
E
E
Impedance
mismatch
now,
you're,
anticipating
the
future,
and
we
just
need
to
make
sure
that,
like
that
also
drives
the
conversation
when
the
future
happens,
because
I
I
definitely
know
that,
like
this
is
a
huge
topic,
there
was
actually
a
sub
sub
sig
spun
off
from
the
specification
to
try
to
just
address
just
errors
themselves,
and
it
was
just
very,
very
contentious.
You
know,
like
my
least
favorite
question,
it
was
always
like.
E
Well,
what
even
is
an
error,
and
I
think
that
we're
kind
of
touching
on
that
here
right
because,
like
you
know,
is
an
error
like
an
unrecoverable
thing
that
the
program
has
like
encountered
or
is
it
like
a
user
control
flow?
Or
is
it
just?
You
know
something
that,
like
we
want
to
log
or
something
like
that
like?
E
You
know
flavor
of
things
here
right
like
we
can
talk
a
little
bit
about
like
if
panics
actually
meet
this
classification
but
like
then
you
would
be
able
to
think
a
little
bit
more
in
line
and
then
our
record
arrow
would
sit
on
the
side
and
you
would
not,
but
then
you
would
also
have
this
problem
like
how
is
it
serving
the
customer
right
or
any
sort
of
user
of
this
because,
like
if
they're
recording
their
errors-
and
it
just
like,
is
creating
an
event
like?
E
G
That
that's
why
I'm
saying
we
kind
of
want
to
have
both
we
have
one
that
falls
into
the
camp
of
this
looks
like
it
just
came
from
java.
We
set
whatever
flags
we
need
to
set
in
that
sense,
and
it's
up
for
the
user
to
decide
that
hey.
This
is
considered
an
exception
in
our
world
right,
whether
it's,
the
the
instrumentation
library
or
the
actual
user
of
the
hotel,
saying
hey.
G
To
use
and
if
necessary,
that
can
then
send
ex
you
know
be
modified
to
send
the
exception
so
that
the
back
ends
can
kind
of
conform
like
you're
gonna.
Have
this
impedance
mismatch,
no
matter
what?
If
they
need
to
get
into
some
particular
back
ends,
they
need
to
do
the
work
to
kind
of
integrate
into
that
back.
End
like
you
can't
solve
all
of
them
at
once,
or
it
might
be
that
when
you
have
that
back
end
exporter,
it
automatically
converts
it
over
to
like
it
converts
the
errors
fans
into
the
sure.
E
Yeah
that
I
mean
that's
totally
valid,
like
you
know,
having
whatever
proprietary
exporter
or
open
source
exporter,
do
like
that
translation.
It
just
needs
to
be
the
clear
that,
like
at
the
exporter
level
like
I
got
an
event,
that
is
a
error
or
an
exception.
You
know
and
that's
the
other
thing
is
like
the
aerosig
dissolved,
with
the
idea
that
we
were
going
to
store
things
as
actually
it
dissolved.
E
With
the
step,
the
status,
the
status
was
going
to
be
reduced
down
to
an
unset,
an
error
or
an
okay
status
and
have
a
description
associated
with
it.
It
and
with
the
anticipation
that,
like
there
may
be
an
entire
future
where
errors
are
treated
as
first-class
signals,
where
there's
like
a
public
api
for
errors
themselves,
but
that
was
something
that,
like
is
you
know
a
thought
process
in
the
future.
E
But
it's
important
interesting
to
think
about
that
because,
like
if
that's
the
case-
and
we
have
this
record
error
thing
that
sits
on
the
side
of
a
span
and
then
in
the
future,
it
becomes
like
a
an
independent
api
like
it'd,
be
very
awkward.
Well,
I
don't
know
about
very
awkward.
It
may
just
be
like
we
would
have
to
bolt
something
on
and
then
we'd
have
two
different
ways
to
handle
errors.
I
guess.
E
One
of
the
things
also
that
I'm
thinking
and
I'm
just
going
to
float
this
is
we
just
get
rid
of
it.
We
don't
particularly
use
exceptions
in
the
go
language
and
having
something
there
right
now,
that's
a
method
for
record
error
that
may
potentially
have
a
collision
with
a
future
addition
to
the
specification
could
cause
us
future
problems.
E
So
I
don't
know
I'm
tempted
to
just
say
like
why?
Don't
we
just
remove
it
until
we
understand
it
and
then
we
would
comply
with
specification
and
at
the
same
time
provide
like
forward
maintainability.
B
F
E
I
mean
I,
I
kind
of
that's
why
I
was
hesitant
to
suggest
it,
but
yeah,
maybe
from
you
know,
with
that
developer
hat
on
that
you
have
or.
E
That
developer
hat
on
right
now,
what
would
it
feel
like
if,
in
the
future
we
have
the
record
exception
or
sorry
record
error,
method,
change
its
behavior
so
instead
of
say,
recording
an
error?
I'm
sorry!
Instead
of
recording
an
event
that
was
of
type
exception,
it
changed
to
forwarding
onto
an
error
api
and
that
api,
you
know,
may
be
handled
differently
by
your
back
end.
F
E
Okay,
yeah
I'm
like
a
little
hesitant
on
the
recorder
for
like
the
event
name
because
like
if,
in
the
back
end,
you
know
in
the
future,
we
want
to
change
the
event
name
that
we're
actually
shipping
up
and
say
we
take
an
accept
or
we
take
a
a
parameter
or
some
sort
of
option.
That
says
like
okay,
you
can
set
the
event
name
like
they'd,
be
fine,
but
then,
if
we
just
change
the
default
behavior
like
that
seems
I
don't
know
it
doesn't
seem
great.
I
guess.
F
Yeah
and
I'm
not
sure
I
would
want
to
allow
the
user
to
specify
the
event
name
directly.
I
I
would
think
more
flags
like
this
should
be
treated
as
an
exception.
This
should
set
the
the
error
status
on
the
span,
that
sort
of
thing,
and
if
we
went
down
that
route,
I
would
probably
want
to
change
the
defaults
event,
name
and
behavior
back
to
error,
as
we
had
had
so
that
it,
it
was
distinct
from
the
things
that
are
contemplated
by
the
spec
but
provide
the
user
an
option
to
say
no.
E
E
Go
back
to
what
we
were
doing
before,
keep
the
error
event
type
and
then,
if
you
pass
an
option,
that's
I
don't
know
what
we're
going
to
call
it
like
treat
as
an
exception
right.
Then
it
changes
the
event
name
to
exception.
It
changes
the
attributes
to
make
sure
they
comply
with
this.
You
know
cement
conventions,
maybe
it
you
know.
You
could
also
tell
to
like
pull
a
stack
trace
in
there
as
well.
E
But
then
then,
it
would
essentially
comply
with
this
like
this
method
here
that
is
specified,
but
otherwise
it
would
have.
You
know
its
own
events,
that
was
an
error
type
and
like
we
can
extend
that
in
the
future.
Is
what
you're
saying.
F
E
Yeah,
the
okay,
so
that
I
think
that's
a
good
idea.
I
think
that
yeah-
maybe
even
just
like
the
idea
that,
like
I
think
oberon
actually
mentioned
this
in
that
in
that
slack
thread,
but
just
like
the
method
that
you're
talking
about
that,
we
could
be
passing
in
or
sorry
the
option
that
you're
talking
about
that
would
be
passing
in
could
be
like
the
error.
Classification
right,
like
the
error,
could
be
a
signal
handler
or
something
like
essentially
like
the
errors
is
used
to
like
communicate
up
and
down
stream.
E
Like
you
know,
I've
stopped
reading
a
file
if
you've
reached
out
to
file
it
could
be
an
actual
like
unrecoverable
error.
It
could
be
a
you
know,
generic
error,
it
could
be
an
exception
like
we
could
have
like
a
you
know,
a
pass
in
an
enum
kind
of
error
thing.
It
would
be
handled
like
based
on
that,
so
we
could
extend
it
in
the
future.
F
E
I
mean
I'm
with
you
on
that.
I
I
like
yeah,
I
I
always
think
it's
uncontroversial
when
somebody
comes
along
and
asks
me
what
even
is
an
error,
so
I
don't
know
like
yeah,
so
I
I
would
like
to
do
that,
but
I
think
that
also,
if
yeah
we
could
make
it
generic
or
something
like
that,
I
feel
like
the
people
that
worked
on
grpc
with
their
status
codes,
probably
thought
it
was
very
uncontroversial.
They
ended
up
with
20
different
status
codes,
so
yeah.
I
imagine
this
the
same
logic
going
on
here.
E
Okay,
I
I
think
I
have
a
direction
or
a
proposal
to
kind
of
like
come
back
onto
the
spec
for
the
error
stuff.
So
the
next
thing,
though
anthony
is
like,
so
how
do
we
handle
panics
right?
Because
those
aren't
going
to
be
like
you,
don't
really
pass
off
a
panic,
the
same
way
that
you
would
pass
off
an
error
or
something
like
that
right.
F
E
Yeah-
and
I
was
kind
of
thinking
about
that
like
it
may
seem,
like
you
know,
steve
pointed
out
down
here
that
like
well,
it's
definitely
not
best
practice,
and
maybe
we
shouldn't
worry
about
it,
because
it's
kind
of
like
the
fringe,
but
some
people
do
use
panics
as
control
flow
right
like,
unfortunately,
it's
a
really
good
example
like
the
json
package
in
the
standard
library.
E
Does
this
like
it's
not
that
uncommon
to
see
people
actually
do
that,
and
so,
if
you're
wrapping
things
in
an
error
and
all
of
a
sudden
like
you
have
just
like
10
000
errors
from
deserialization
or
something
like
that
that
were
just
exceptions
or
on
panics
that
were
being
thrown.
While
you
were
like
trying
to
trace
some
sort
of
event,
is
I
don't
know?
E
Maybe
that
wouldn't
be
such
an
ideal
thing,
and
that
made
me
think,
like
maybe
we
shouldn't
be
auto-generating
an
event
in
the
air
or
the
span
end,
and
that
should
be
something
done
as
like
an
explicit
option
that
you
pass
or
that
you
defer
a
function.
Yourself
was
kind
of
my
thought
on.
F
F
E
It's
not
like
it,
wouldn't
it
wouldn't
cause
events
coming
from
the
marshaller
package
or
the
json
package.
It
would
cause
it
from
like
some
other
user
trying
to
like
use
panics
and
like
as
as
control
flow,
and
then
they
just
assume
the
end's
not
going
to
like
record
an
event
for
them,
and
it's
just
like
it
just
blows
things
up
like
yeah
the
json
package.
Well,
unless
go
wants
to
use
open,
telemetry
instrument,
which
you
know
if
go
authors
are
watching
this
recording.
Please
do
it.
E
I
would
love
that
kind
of
integration,
but
that
you
know
that's
a
pipe
dream
in
a
long
shot.
I
I
just
meant
like
I
could
see
people
using
panics
as
in
the
same
form
from
the
standard
library
and
not
understanding
that
it's
going
to
cause.
You
know
large
number
of
events
to
be
created
because
of
it.
F
F
We
were
to
pull
the
recovery
handler
out
of
span
and
we
would
want
to
provide
some
easy
convenient
way
to
have
right
on,
preferably
almost
automatically.
I
think
because
I
think
that
probably
is
the
most
common
case.
Is
that
if
something
panics
you
you,
you
may
not
even
get
a
chance
to
deal
with
it
yourself.
It
has
to
happen
upstream
right
and
you
probably
normally
want
that.
So
maybe
some
way
to
say
no,
if
a
panic
happens,
don't
treat
it
that
way
or
I
yeah.
I
don't
know.
E
So
I
like
the
idea
of
having
anything
explicit,
a
lot
of
things
we
deal
with
and
go,
are
explicit
and
not
implied
like
side
behavior,
and
so
I
was
recommending
this
function
here,
where
we
would
add
some
sort
of
record
panic
function.
That
would
return
some
sort
of
closure
that
understood,
like
you,
know
the
span
and
any
sort
of
annotation
and
maybe
even
the
scope,
and
that
you
would
defer
that.
So
you
do
something
like
this,
where
you
would
get
the
span
and
then
you
could
just
immediately
say
like
yeah.
E
E
E
E
So
yeah
we
can
move
on
if
anyone,
I
can't
tell
people-
are
just
thinking
really
hard
at
this
or,
if
they're,
really
bored
at
this
point,
which
is
probably
more
likely
the
case
yeah.
E
Cool
then
I'll
I'll
leave
that
please
put
put
more
thoughts
into
the
record
exception,
or
maybe
use
cases,
or
something
like
that.
It's
really
helpful,
because
I
want
to
make
sure
that
we
do
release
something
that's
useful,
but
also
something
that
is,
we
can
maintain
going
forward
and
I
think
that
we're
not
quite
there
yet,
but
we've
got
some
good
ideas
floating
around
here
that
are
going
to
be
useful.
I
think
we
need
to
make
some
changes
just
need
to
make
sure
they're
right,
okay,
cool
moving
on
anthony.
E
The
next
item
was
your
instrumentation.
Well
not
passed
out
to
you.
F
Yeah,
so
I
added
this
hoping
that
lay
would
be
able
to
to
join
us.
I
don't
see
them
there,
but
my
initial
thought
on
this
was,
I
know,
we're
we're
trying
to
avoid
adding
a
whole
lot
of
surface
area
or
really
any
additional
surface
area
too.
That
can
trip
while
we
try
to
get
to
ga
and
I've
been
kind
of
scared
by
the
last
aws
sdk
instrumentation,
pr
that
we
got,
which
was
several
thousand
lines
of
s3
wrappers.
But
after
looking
at
this,
this
doesn't
seem
anywhere
near
as
scary.
E
So
I
I
also
don't
like
to
be
the
only
voice
here,
because
I'd
love
to
hear
other
people's
opinions.
I
know
when
I
used
to
work
at
new
relic.
This
is
an
instrumentation
that
people
wanted.
I
know
another
work
exploding,
business
institution
people
want,
I
know
you
working
at
aws
is
an
interpretation.
You
probably
have
seen
from
like
a
vendor's
perspective,
and
I
know
from
like
just
end
users
perspective.
They
want
this
kind
of
instrumentation,
so
it
seems
important.
I
think
this
is
a
yeah.
E
I
think,
based
on
that,
like
I'm
inclined
to
accepting
these
sort
of
things,
but
I
also
haven't
reviewed
it
like
if
it's
just
a
nightmare
to
to
maintain
this
sort
of
stuff,
then
I'm
pretty
hesitant,
so
I'd
probably
have
to
defer
to
whatever
you're
thinking
anthony
or
whatever
else
the
rest
of
the
community
is
thinking.
F
Well,
it
actually
looks
like
it's
this
you
know.
One
type
with
two
functions
is
what
it's
gonna
end
up
being
one
for
initialization.
You
know,
as
a
request
starts
and
one
for
deserialization
as
you
get
the
response,
so
it
looks
like
it's
actually
going
to
be
much
simpler
and
much
cleaner
than
the
s3
instrumentation
we
had
seen
before,
which
was
very
scary
from
a
you
know,
contemplating
having
to
maintain
it
perspective.
E
E
Yeah
I
mean
I
feel
like
I
should
remember
this,
but
we
just
merged
some
other
ins.
Well,
I
just
merged
some
other
instrumentation
into
the
library.
So
I
don't
think
that
there's
just
a
hard
line
that
we're
not
accepting
any.
I
think
that
you
know
we
talked
last
time
about
the
database
package
instrumentation.
I
think
that
that
one
is
just
like.
I
think,
that's
one,
that
we
both
agree.
E
That
is
more
on
the
side
of
like
let's,
let's
hold
off
on
that,
because
that's
something
that
is
really
complex
and
you
know
explosive
in
many
ways,
and
this
I
don't
think
is
nearly
as
much.
I
also
know
that
like
well,
I
guess
now
we
have
great
representation
from
aws
in
the
project
but
also
just
like
in
in
overall
in
hotel,
like
I
know
that
alita
we
could
get
her
to
like
get
somebody
to
help
us
if
we
needed
some
sort
of
feedback
on
this.
E
E
I
report
to
her
so
she'll,
probably
just
assign
me
perfect
now
I
know
how
to
yeah
this
always
bothers
me.
Anyone
on
the
call
leverage
right
now.
E
Exactly
never
should
have
told
me
that
anthony
but
yeah,
jokes
aside,
I.
E
Totally
fine
and
even
then
like
even
if
you
needed
help,
I'm
sure
you
could
reach
out
to
other
people
in
the
company,
so
that
would
be
helpful,
so
yeah,
I
think
my
answer
is
yes.
I
haven't
had
time
to
review
it.
So
if
you
think
that
that's
something
that
we
should
consider,
I
think
that
I'll
put
it
on
my
docket
to
review.
I'm
going
to
be
very
honest
with
you.
My
priorities
are
to
get
this
done
prior
to
reviewing
this,
so
it
may
not
happen
until
next
week,
but
yeah.
F
Yeah
yeah
and
that's
that's
fine
and
you
know,
as
obviously
someone
from
aws
I'm
not
going
to
merge
this.
You
know
I'll
defer
to
you
on
that.
I
can
give
my
thumbs
up
on
it,
but
I
definitely
want
more
people
to
say
yes.
E
Yeah
yeah,
I
feel
like
this
is
the
first
time
that
we've
had
actual
like
company
conflicts
here,
normally
we're
pretty
agnostic,
but
I
yeah
I
I
I'm
not.
I
don't
think
you've
met
malevolent
in
this
process.
I
trust
a
lot
of
that
coming
forward,
so
yeah
I'll
definitely
try
to
keep
that
keep
going
and
anybody
else
on
the
call
interested
in
using
this
anyone
I
know
from
new
relic
who
also
is
interested
in
having
this
instrumentation.
Please
take
an
eye
and
try
to
review
that
and
yeah.
F
Do
note,
though,
that
this
is
for
the
go
sdk
v2,
which
I
know
I
wasn't
using.
You
know
we
weren't
using
v2
in
my
last
project,
so
I
don't
know
how
much
of
customer
interest
this
will
cover,
but
it
will
be
at
least
something
to
say.
You
know,
here's,
here's,
a
path
to
get
supported,
instrumentation,
okay,.
H
Yeah
I've
used
the
sdk
v1.
When
was
the
v2
release.
Is
it
like
very
recent
that
I
don't
know?
I
presume
it
has
to
be
somewhat
recent?
Okay
yeah,
so
I
don't
have
any
experience
with
it.
I
have
experience
with
v1
as
well,
so.
I
I
know
we
have,
you
know
integration
for
it
for
our
go
agent
new
relic,
but
I
am,
as
usual,
just
playing
catch
up
here
and
I'll
do
what
I
can
to
throw
an
hour
at
it
this
week,
tyler.
E
Awesome
yeah
I'd
appreciate
that
which
I
mean,
I
think
an
hour's
is
just
the
right
amount
of
time
for
600
lines
of
go
code.
Although
it
sounds
like
it's,
just
one
file
is
really
the
meat
of
it
and
then
it's
just.
F
Yeah
really
there's
there's
the
one
file.
The
rest
is,
you
know,
there's
a
ghost
which
is
obviously
going
to
take
a
big
chunk
of
that
there's
tests
and
examples
which
you'll
want
to
look
at
to
see
how
it's
used,
but
the
the
meat
of
it
really
is
that
one
file
and
a
couple
functions
right.
E
Oh,
if
that's
the
case,
then
yeah.
This
is
probably
only
yeah.
This
should
be
like
45
minutes,
rich,
no
big
deal,
okay,
cool.
That
sounds
good
last
item
on
the
agenda.
Also,
if
you
have
any
more
items
that
have
sparked
your
interest,
please
add
them
to
the
agenda,
but
otherwise
anthony
has
proposed
alternate
meeting
times
current
time
conflicts
with
gc
meeting.
F
Yeah,
so
both
ted
and
liz
have,
over
over
the
years,
expressed
dismay
that
they
haven't
been
able
to
participate
in
this
sig
because
the
at
least
the
first
half
hour
of
this
conflicts
with
the
the
governance
committee
meeting.
So
I
was
wondering,
if
there's
a
willingness
or
to
to
consider
moving
to
another
time.
F
Yeah
that'd
probably
be
best
like
I
know
earlier,
is
great
for
me,
but
I'm
east
coast.
So
I
think
most
people
are
west
coast
that
they
probably
have
different
preferences
for
meeting
times.
E
Yeah
yeah,
I'm
very
flexible.
Well
as
long
as
I
don't
have
conflicts,
but
yeah
like
whatever
worst
is.
Is
everyone
still
okay,
thursday,
or
is
that
something
that
wants
to
be
addressed?
Thursday's,
fine,
yeah?
Okay,
just
fine.
E
Okay
yeah,
it
would
be,
I
think,
okay
I'll
I'll,
take
a
look
at
the
open,
telemetry
calendar
and
I'll
try
to
send
out
a
poll
with
open
slots.
I
may
bias
it
by
not
doing
anything
on
friday
if
we
are
going
to
make
days
but
yeah,
okay,
awesome
that
and
I'll
post
it
in
the
slack
channel.
Unless
I'm
saying
this
anthony
did
you
have
a
desire
to
do
this?
I
I
I
jumped
in,
but
I
I
can
do
that
if
you
want
yeah
okay
yeah.
E
F
Sphere
as
well
yeah,
I
will.
I
will
post
it
here
in
the
dock
and
in
slack
I'm
not
sure
how
many
of
my
twitter
followers
care
yeah.
E
G
So
one
of
the
things
I
was
reviewing
the
otlpf
exporter,
spec
that
our
exporters
meet
compliance
with
the
otl
protocol.
I
started
writing
actual
tests
to
see
what
they
were
doing
like
our
clients,
retrying,
which
is
how
I
found
some
of
the
how
we
were
missing
our
spec.
G
I
thought
to
just
put
it
into
a
server
that
potentially
other
other
otlp
implementations
could
use,
and
the
idea
here
is
these
are
this
is
a
server
with
an
export
for
traces
right
now?
That's
all
that
I've
built.
This
is
still
super
proof
of
concept
that
are
broken
in
particular
ways
like
for
retries.
G
G
I
wish
I
had
my
development
environment
up
and
going
and
I'd
give
a
live
demo,
but
I
just
thought,
like
I
wanted
to
get
feedback.
Does
people
think
that
would
be
a
good
idea?
Is
it
worth
pursuing?
Is
it
worth
putting
any
more
time
into
it?
G
So
this
is
a
tool
that
could
be
used
by
other
languages
right.
It's
not
go
specific,
potentially
yeah
like
it's
written
in,
go
because
that's
the
tools
that
I
use
but-
and
I
was
using
it
to
test
the
ghost's
implementation,
but
there's
nothing
that
says
this
shouldn't
be
used
usable
by
anybody
else.
So
I.
E
Have
very
strong
and
positive
reaction
with
this.
Like
this
looks
awesome,
I
think
this
is
really
useful.
I
think
that
when
I
was
writing
a
lot
of
the
otp
stuff,
this
was
kind
of
floating.
In
the
back
of
my
mind,
I
think
we
think
a
lot
a
lot
alike
because
it
seems
like
yeah.
It
should
just
be
somewhat
agnostic.
E
That
said,
I
think
that
one
of
the
best
places
this
could
live
is
in
the
collector
repo
itself,
because
this
is
where
you
would
be
sending
something
so
having
some
sort
of
validation
there
david.
E
I
know
david
you've
been
working
a
lot
in
the
collector
repo
and
you're,
probably
not
paying
attention
too
much,
but
hopefully
I've
given
you
enough
time
to
like
pick
it
up,
but
like
aaron
has
created
like
a
server
essentially
to
validate,
like
anything,
that's
sent
to
the
collector
as
done
within
compliance
of
the
specification-
and
I
was
thinking
maybe
this
could
live
in
the
collector
repo
itself.
Does
that
sound
reasonable.
D
G
G
You
know
concurrent
packets
over
the
wire,
so
I
I
don't
know
like
yeah.
It
probably
wouldn't
marry
very
well
with
the
collector,
but
like
this
was
sort
of
being
like
a
completely
divorce
implementation
from
the
particular
collector
or
any
or
any,
but
any
particular
vendor's
implementation
of
otlp.
G
G
And
then,
if
you
send
the
correct
number,
which
I
think
is
the
the
first
digit
in
that
server
test
block
right
there.
If
you
send
five
retries,
then
within
the
between
five
and
thirty
seconds,
it
will
pass,
whereas
for
like
unknown,
if
you
send
more
than
zero
you'll
fail.
E
G
Some
of
it's
just
I
defined
by
me,
like
how
many
retries
and
how
much
time
is
not
specified
anywhere,
so
your
client
would
have
to
be
set
up
for
that.
But,
okay,
like
I
need
a
detail
down
like
what
I
was
thinking
with
this
like
you
would
set
up
your
client.
It
will
retry
the
correct
codes
for
the
specification.
Here's
your
retry
settings
yeah
like
set
it
up
in
this
way.
E
I
don't
want
it
to
just
go
off
into
the
ether
and
not
really
the
use.
I
really
like
this
idea.
E
I
just
think
that,
like
the
visibility
would
be
really
cool,
if
we
could
have
this
be
a
little
more
visible,
I,
the
first
person
that
comes
to
mind
is
tigran,
because
he
cares
a
lot
about
this
stuff.
If
you
could
run
this
by
him,
I
don't
know
I
mean
he's
all
he's,
always
in
the
collector's
sake.
I
don't
know
if
you
ever
joined
the
collector's
sig,
but
I
think
this
is
something
that
he
would
be
really
interested
in,
supporting
or
or
having
you
contribute
or
something
like.
That
is
my
initial
reaction.
E
I
This
is
great.
We
could
be
doing
all
sorts
of
other
things
with
this
too,
like
hanging
on
to
the
connections
and
not
dropping
them.
One
thing
we
do
with
our
grpc
endpoint
is
have
a
have
a
percentage
of
replies
that
are
going
to
return
a
type
of
error.
I
The
main
challenge
here
is
keeping
it
maintained,
making
sure
it's
up
to
snuff
with
that
collector
yeah.
So
you
know
you
wonder:
well,
should
this
just
actually
be
part
of
the
collector,
so
they
go
into
a
mode.
G
Why
why
I
didn't
really
want
it
as
part
of
the
collector?
Is
I
wanted
a
testable
it
to
be
very
testable
like
it?
It
literally
starts
up
16,
grpc
servers
and
by
the
end
of
it,
like
I
figure
you
have
a
test
case
of
like
25
30,
and
I
just
want
them
all
started
up
and
it
won't
actually
forward
on
anything
like
there
is
no
configuration
whatsoever
that
will
forward
anywhere
anywhere.
G
E
G
E
You-
and
I
think
that
makes
sense
still
just
like
to
sit
in
the
collector
repo
as
like
a
side
project,
or
even
just
like
a
side
utility
that,
like
other
things,
can
dev
depend
on
yeah.
They
also
they
build
distributions
of
the
collector
right.
So
it's
run
as
like
a
binary
in
the
docker
images
like
that,
and
I
I
think
this
could
just
live
as
like
a
an
additional
build.
You
know
that
they.
E
A
another
docker
image,
or
something
like
that.
You
know
like.
However,
they
want
to
distribute
it,
but,
like
then
yeah
like
then
the
javasig
or
erlang
or
python
can
come
along
and
they
can
be
like
okay.
I
need
to
write
this
test
suite
that's
going
to
send.
You
know
these
bad
signals
and
see
if
it's
or
send
signals
and
then,
like
you,
know,
see
if
it's
handled
correctly
by
my
you
know
we
could
have
docs
or
something
like
that,
but
yeah.
I
I
think
this
is
really
useful.
H
E
Yeah
and
so
again
I
think
yeah.
If
you
just
want
to
ping
tigran
on
slack.
He
probably
will
you
know
if
he
maybe
he's
already
built
something
similar
to
this
and,
like
you
can
start
like
working
on
it
or
working
with
it.
I
I'm
the
collector
is
always
in
need
of
contributors,
so
I
imagine
there's
like
massive
gaps
where
they
have
nothing
like
this
yet
but
yeah
he.
He
would
definitely
have
a
lot
more
context
than
I
would.
I
think
it's
useful,
but
he
would
have
like.
E
H
E
Yeah,
I
I
honestly
like
I
thought
it
was
also
like
well,
maybe
I'll
just
say,
because
a
lot
of
the
things
that
I
like
have
like
these
pipe
dream.
Ideas
on
aaron
goes
and
takes,
and
like
spills
not
in
a
week,
was
like
this
cool
idea
where,
like
there's
also
like
the
front
end
inputs
and
like
sometimes
like
there's
a
generic
inputs
say
for.
Like
I
don't
know,
you
want
to
have
like
a
generic,
oh
like
an
http
endpoint,
or
something
like
that.
E
You
want
to
have
you
know,
http
tracing
and
if
you
could
just
have
like
an
http
server
generically
be
run
up
with
whatever
language
and
have
like
a
test.
Suite
you'd
run
against
that
http
server.
I
don't
know
there
are
some
input
sides
of
the
specification.
I
think
that
we
could
also
take
a
look
at,
but
you
know
having
those
generic
across
the
language.
There's.
E
If
you're
interested
there-
and
these
things
seem
something
that
interests
you
like
building
test
suites
off
of
the
specification
doing,
you
know
language,
parsing
and
understanding
what
the
normative
requirements
of
the
specification
are.
That's
also
something
that
we're
looking
at
currently
right
now,
so
there's
a
lot
of
really
cool
ideas,
also
really
good
talks
eventually.
So
you
know
if
you
are
interested.
E
E
You
just
take
your
smartphone
and
you
point
it
at
the
screen
and
yeah
yeah.
I
would
I
would
watch
it.
I
would
definitely
be
interested
in
that
video,
so
yeah,
if
you
do,
please
put
it
in
the
hotel,
go
channel,
love
to
see
that
yeah
we'll
do
awesome,
well,
cool.
We
have
run
to
the
end
of
our
agenda.
Are
there
any
cool
user
stories
that
people
want
to
share?
E
G
So
I
do
have
a
success
story.
We
using
the
the
weird
file
exporter
that
I
wrote
so
it's
not
over
to
a
collector,
but
using
that
we
were
able
to
diagnose
one
of
our
remote
running
processes
and
why
it
was
failing,
and
we
actually
have
now
have
a
chance
to
go
and
fix
it
and
figure
out
why
our
long
tail
processes
are.
So
it
was
somewhat
of
a
pain
getting
a
completely
isolated
thing
to
spit
out
hotel
that
we
could
use,
but
it
was
hotel
all
the
way
through
so
yeah.
G
The
one
pain
point
I
would
have
from
that
is
the
vanity
url
still
isn't
up
to
date
and
gotta
find
bogdan.
G
E
To
track
down,
sometimes,
okay,
yeah,
that's
really
good!
I
I'll
I'll
ping
him
directly
as
well
for
the
end
of
the
url
thing.
H
But
now
I
was
waiting
for
bogdan's.
I
think
joshua
josh
wanted
to
look
at
some.
That's
been
there
for
a
while.
E
He
does
and
that's
why
I'm
going
to
ping
him
for
the
governor
url,
because
I
have
the
inside
scoop
but
he's
also
the
top
contributor
to
the
open
telemetry
project
overall.
So
it's
really
tough
to
fault
him
for
not
being
that
active
so
like
he
puts
he
puts
other
people
to
shame
and
by
that
other
people
I
mean
me
like
he
just
is
incredibly
prolific,
so
he's
just
a
very,
very
over
subscribed
person
but
yeah
I'll
ping
him
about
the
go
vanity
url
thing
and
yeah.
E
Well,
cool
thanks
everyone
for
joining.
I
appreciate
all
the
feedback.
I've
definitely
got
some
action
items
be
sure
to
look
out
for
the
doodle
poll
coming
from
anthony
and
we
will
see
you
all
virtually
again
if
you
want
to
pick
up
one
of
those
issues
for
the
spec
appliance
matrix.
I
really
appreciate
it,
but
we'll
see
you
all
virtually
or
next
week-
and
I
hope
you
all
have
a
good
week.