►
From YouTube: 2021-05-13 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
Howdy,
we
didn't
have
the
the
notes
colonized
ahead
of
time
here.
C
Yeah
tyler
is
out
today,
and
I
forgot
that
I
had
agreed
to
take
over
and
I've
been
being
a
bad
maintainer
and
haven't
become
prepared.
So,
let's,
let's
fill
in
these
notes
as
no.
C
If
anybody
has
anything
to
add
to
the
agenda,
please
do
so.
I
think
our
project
board
is
looking
pretty
good.
We
are
currently
at
if
I'm
not
mistaken,
two
issues
in
to
do
still
probably
the
same
two
that
were
there
yesterday
or
last
week.
Let
me
see
if
I
can
break
this
out
and
share
my
screen,
so
everybody
can
follow
along.
That
will
probably
be
helpful.
C
Okay,
so
we
have
three
to
do
great.
We
we've
gained
one.
C
Minus
one
excellent
and
we
are
up
to
291
don
that
is
plus
nine
excellent
and
we've
landed
some
some
of
the
significant
work
that
was
outstanding.
I
think
the
unified
configuration
and
initialization
robert
this
pr,
if
I'm
not
mistaken,
is
largely
ready
to
go.
There
were
a
couple
of
packages.
C
Sorry,
let's
go
to
the
oh
there's,
not
a
pr
linked
yeah.
We
can
find
it
this
way.
So
there
were
a
couple
of
packages.
You
mentioned
that
we're
going
to
require,
trace
and
metric
that
are
used
externally
and
would
require
some
more
refactoring.
C
A
C
All
right,
I
think
my
preferred
100
release
was
about
a
year
and
a
half
ago,
but.
C
I
would
really
like
to
have
an
rc
available
next
week.
I
think
that's
a
realistic
goal
if
we
can
get
this
finished
up
so.
A
Maybe
maybe
you
can
open
the
project
and
maybe
just
show
what's
the
issue,
so
you
maybe
you
you
have
some
insight
if
it's
critical
in
your
opinion
or
not.
A
B
C
A
A
It
can
be
changed
generally
because
you
still
can
have
access
to
this
config
and
there
are
some-
and
there
is
some
stuff
which
is
already
calling
this
new
config,
this
new
config
new
tracer
config
function.
So
basically
initially
I
started
the
couple
like
encapsulating
some
stuff.
Like
I
have
hidden,
I
have
unexported
the
string.
I
have
created
a
getter
for
it,
but
after
like
30
minutes,
I
I
told
myself
no
it's
too
much
it's
better
to
to
create
a
separate
pr,
because
it
will
be
just
the
second
war
of
worms.
D
A
D
A
little
bit
of
time
to
work
on
this
next
week.
D
I
can
take
it
over
if
it's
just
the
tracer
config
and
I
maybe
have
a
second
I'll-
maybe
have
a
second
one
for
the
metrics
config.
If
it's
similar.
C
Okay
and
then
the
tracer
option
we
can
apply
the
same
changes
to,
though
right
is
anything
using
the
nothing
should
be
using
the
the
methods
out
of
here.
So
we
should
be
able
to
make
these
unexported
and
remove
private,
as
was
done
with
all
the
rest
and
apply
that
to
all
of
the
different
option.
Types
that
are.
D
Yeah
I'll
go
through
all
of
them.
If
you
want
to
assign
it
whatever's
left
over
on
that
to
me,
is
there
prs
already
merged
for
anything
or
either.
D
C
There
is
one
pr
out,
I
don't
think
it
has
been
merged
because
I'm
the
only
one
who's
approved
it,
yet
it
just
went
ready
for
review
this
morning.
So
if
anybody
with
the
approval
bit
can
review
that
and
give
it
a
look,
it's
look
at
this.
It's
a
lot
of
the
the
same
stuff.
You
would
expect
to
see
a
lot
of.
C
Apply
and
yeah
yeah
changing
things
up
that
were
just
functions
into
interfaces
or
changing
interfaces
that
had
an
exported
apply
to
unexport
them
that
sort
of
thing,
so
it
should
be
a
fairly
straightforward
review
and
then
see
the
other
outstanding
issue
we
have
in
progress
is
the
removing
the
metrics
dependency
from
the
otlp
exporter
you
gustavo,
do
you
have
an
update
on
where
we're
at
with
that.
A
E
That
there
is
still
things
that
I
need
to
do
like
create
models
for
the
proto
apple
story,
and
I
also
I'm
concerned
about
how
we
can
get
this
pr
open
because,
as
it's
as
it
is
now,
it
contains
like
nine
thousands
of
changes
and
that's
going
to
be
joe
review.
I
guess
I
will
need
to
split
that.
C
Okay,
so
I
think
excuse
me,
I
think,
before
we
had
talked
about
your,
your
approach
was
going
to
be.
C
Your
approach
was
going
to
be
to
to
structure
separate
modules
with
metrics
and
trace
transport
types
and
then
individual
exporters
as
well.
That's
still
the
the
approach
that
you're
you've
taken.
E
I
have
changed
it
a
little
bit.
I
have
actually
created
removed
these
protocols
folders
at
all.
Let
me
see
if
I
can
like
share
subscribe.
E
Can
you
see
my
screen?
Yes,
okay,
so
I
actually
create
two
folders
here:
otlp
metric
and
otlp
trace
and
inside
that
there's
the
otlp
trace
gerpc
and
the
otlp
trace
http.
E
A
Because
of
the
conflict
changes,
I
was
thinking.
Of
course
you
know
just
a
little
idea
if
it
may
not
be
easier
just
to
merge
those
packages
like
otl
b,
trace,
http,
grpc
and
internal
into
just
the
hotel
elp
trace,
because
basically
there
are
a
lot
of
like
hacky
ways
that
this
this
code
in
the
internal
package
is
reused,
and
it's.
C
Yeah,
it
was
supposed
to
be
separate
modules.
I
think,
because
I.
A
C
A
C
C
A
C
E
C
The
sorry
I
think
otlp
trace
in
this
would
be
a
module
that
has
the
internal
back
edge
yeah.
A
B
C
C
Changed
with
the
addition
of
modules
and,
if
not
just
provide
an
additional
bound
yeah,
but
that's
obviously
something
that
should
be
fairly
easy
to
prove
one
way
or
the
other
yep.
C
C
B
D
Start
mean
start
overlapping
with
all
the
other
trace
packages
that
we
have.
C
A
C
The
last
part
of
the
name
is
what
would
create
overlap
just
grpc
in
that
model,
which
would
then
shadow
everything
or
conflict
with.
D
B
D
B
Because
we're
I
remember,
we
talked
about
this
months
ago,
but
where
we're,
I
guess,
we're.
We
know
that
people
could
rename
their
imports,
but
I
think
we're
saying
we
don't
want
to
force
them
to
have
to.
Is
that?
Why
yeah
choosing
these
names
yeah
yeah,
which
is
a
little
weird
that
if
we,
if
we
know
that
they're
always
going
to
be
imported
together,
it
makes
me
wonder:
do
they
all
need
to
be
separate
packages?
B
C
But
they're
not
necessarily
all
going
to
be
imported
together
right
so
like
ocop
trace,
no
tlp
trace
grpc
might
be
imported
together
and
otlb
trace
enough.
You
have
to
trace,
http
might
be
imported
together,
but
grpc
and
http
won't
yeah.
Okay,
yeah
your
trace
might
be
important,
but
metrics
won't
yeah.
It
looks
it
feels
a
little
weird
but
yeah.
I
understand
the
rationale
now
and
yeah.
That
does
make
sense.
D
Yeah,
it
feels
a
little
weird,
but
it
would
be
very
like
you
would
always
have
to
import
the
like
to
configure
both
trace
and
metrics.
Grpc
you'd
have
to
import
grpc
twice:
you'd
have
to
import
trace
and
metrics
twice
and
you'd,
probably
also
import
the
api
level
trace
and
metrics,
so
that
you're
doing
that,
as
well
as
maybe
even
the
sdk
trace
and
metrics,
and
then
on
top
of
that
you'll
also
import
otlp
to
create
the
overall
otlp
driver.
F
So
I
mean,
I
think,
that's
a
that's
an
interesting
point
and
I
think
it's
an
important
one
to
kind
of
think
about
the
usability
of
this
it
is.
It
needs
to
be
balanced
as
well.
F
Something
that
wasn't
also
said
was
just
like
people
were
saying
that
you're,
probably
gonna,
not
use
factors
together,
but
like
one
of
the
important
parts
that
we're
doing
here
is
to
keep
in
mind
that,
like
we're,
trying
to
isolate
versioning
so
like
the
metrics
and
trace
stuff
is
not
gonna
be
in
lockstep,
and
it's
gonna
have
stability
just
incongruity
there,
as
well
as
logs
whenever
that
shows
up,
and
the
other
side
is
dependencies
right,
so
the
http
driver
does
not
have
the
same
dependencies
as
the
grpc
one,
and
you
know
the
other
side
to
like
having
users
say
like
well
we're
going
to
give
you
the
cadillac
solution
that
has
everything
already
installed.
F
Well,
that
also
is
going
to
be
like
massively
bloated
for
things
you
don't
actually
need,
for
you
know
a
telemetry
library
right
like
this
is
like
one
of
the
things
that
we're
trying
to
also
do
is
provide
a
minimal
set
and
to
try
to
have
a
lightweight
overhead
on
anybody
who
includes
these
dependencies
in
the
project.
F
Yeah,
I
I
that's
a
good
point.
I
know
that
at
like
splunk
and
when
I
was
working
at
new
relic
as
well
like
these
kinds
of
pain
points
are
things
that,
like
we
solve
or
try
to
solve,
for
the
user
is
try
to
like
cut
through
a
lot
of
that
configuration
and
provide
that
cadillac
solution,
and
I
don't
know
if
maybe
that's
just
kind
of
like
the
answer.
F
Is
you
know
let
vendors
deal
with
this
or
let
a
third
party
come
along
and
say
like
this
is
my
preferred
view
of
the
worlds,
and
this
is
how
I'm
going
to
like
set
it
up
by
default
and
then,
if
you'd
like
that,
just
import
my
package
right
and
if
you
don't
go,
go
deal
with
it.
You
know
it's
kind
of
the
other
side
of
things.
F
We
do,
and
it's
been
a
long-standing
question
and
the
most
that
we've
said
about
it
is
that,
if
you're
going
to
have
it,
it
needs
to
be
an
api.
It
can't
just
be
a
file
format,
but
outside
of
that,
no
one
has
picked
up
the
torch
actually
done
anything
with
like
defining
the
api
defining.
What
file
formats
are
supported,
defining
how
that's
going
to
look
yeah.
That's
you're,
not
alone.
C
C
Yeah,
but
you
can't
do
atlp
without
protobuf.
Can
you.
F
No,
oh
right,
so
it
isn't
http
as
well,
so
nevermind
yeah
take
it
back.
So
it's
just
your
pc.
F
C
F
D
B
A
C
There's
been
concern
about
version
conflicts
with
grpc
and
users
who
have
applications
that
depend
on
old
versions
of
grpc,
want
to
be
able
to
use
otlp
over
http
but
skip
the
the
grpc
conflict.
C
I
don't
know
how
many
users
there
are
out
there,
like
that.
I
don't
know
how
important
a
use
case
that
is,
and
I'm
not
sure
how
we
quantify
that.
As
you
say,
aaron
we
could
easily
quantify
how
big
the
binary
ends
up
being.
We
can
even
quantify
how
big
your
go
sum
file
ends
up
being,
although
I
think
that
matters
a
whole
lot
less
right,
especially
if
it's
still
constrained
to
the
otop
module.
If
you
don't
want
otop,
you
use,
jager
or
or
some
other
exporter.
Well,
the
yeager
uses
grpc
as
well.
A
A
D
F
B
170
yeah
another
angle
to
consider
here,
unfortunately
involving
writing
yet
more
packages
is
to
consider
say
that
we
have
this
kit
of
parts
approach.
You've
got
whatever
these
nine
packages
or
something
whatever
the
cross
product
gives
you
all
the
configurations
you
might
want.
B
B
D
Yes,
steve-
I
was
actually
thinking
about
this
earlier
this
week
and
why
I
suggested
a
configuration
api.
D
Is
you
have
the
problem
of
if
you
know
how
to
configure
a
thing
you
have
to
have
it
imported
right
like
it
has
to
be
part
of
your
library
and
if
there
was
something
else
that
we
could
depend
on
as
the
thing
that
the
users
interact
with
as
an
application
developer,
to
do
the
configuration
that
can
separate
a
lot
of
those
concerns.
D
So
what
I'm
not
to
kind
of
defer
this?
But
I
want
to
talk
with
you
afterwards,
maybe
later
next
week
about
doing
this
and
seeing
if
we
could
maybe
come
up
with
an
idea
on
how
that
might
look.
B
Sure,
yeah
yeah,
I
remember
I've,
only
put
one
of
these
together
so
far,
and
I
just
remembered
the
experience
of
being
a
harrowing
two
and
a
half
hours
of
fumbling
around
and
being
amazed
when
it
finally
worked.
So
I've
been
actually
reluctant
to
try
any
other
combinations.
B
It
worked
beautifully
but
figuring
out
just
from
reading
go
doc
and
you
know
looking
trying
to
chase
references
around
figuring
out
what
what
I
was
missing
was
hard.
So.
B
C
But
yeah
yeah
hearing
more
about
that
experience
may
still
be
helpful
because,
though
we
fixed
that
error
that
I
think
caused
you
a
significant
time
sync,
there
may
have
been
other
pain
points
that
that
you
encountered
that.
B
Some
of
this
comes
to
you
from
riding
the
bucking
bronco
of
going
version
diversion
so
in
other
words,
you
have
something
that
works,
and
then
you,
you
know
edit
go
mod
or
whatever,
and
you
you
bump
yourself
up
to
the
next
version.
You
play
this
game
and
figuring
out.
Where
did
it
go
where's
that
thing
now?
F
I
mean
it's
like
I
write
half
these
changes
and
I
still
am
confused
when
it
comes
time
to
upgrading
things.
So
I
can
only
imagine
it's
even
more
confusing
if
you
don't
have
any
context.
B
F
C
Hopefully
we're
down
to
the
very
last
few
eggs
to
break,
but
I
think
that
makes
it
all
the
more
important
that
we
we
get
something
for
this
otlp
exporter
that
will
be
able
to
be
stable,
because
we
we
need
to
get
a
stable
release
in
the
in
the
near
term
and
we
need
oclp
trace
exports
for
that
metrics.
I
I
think
we've
got
more
time,
but
I
would
also
like
to
avoid
ending
up
with
something
for
traces
and
something
else
for
metrics.
F
So
have
you
thought,
through
the
idea
of
maybe
just
having
a
duplicate
exporter
in
the
metrics
directory,
that's
in
the
exporters
directory
and
that
exporter
would
import
the
standard
one
and
then
wrap
it
essentially
and
build
it
up
to
support
metrics
there.
F
I'm
not
trying
following
so
in
like
so
so
if
you
took
the
existing
otlp
exporter
and
we
just
ripped
out
all
of
the
metrics
portions
of
it,
and
we
just
essentially
leave
it,
as
is
just
like
the
drivers
for
grpc
and
http
and
like,
but
it
doesn't
support
metrics
and
then
in
the
metrics
directory.
F
We
would
have
a
different
exporter
there.
That
would
wrap
the
otp
exporter
and
it
would
add,
on,
like
all
the
export.
You
know,
methods
to
support
the
the
metrics
pipeline.
There
essentially
be
the
additional
exporter.
E
E
B
F
F
C
F
F
Like
did,
does
the
original
remain,
or
is
that
something
that
like
because
I
was
looking
at
like
the
cis
package,
the
external
repository
today,
and
it
was
like
just
links
to
the
standard
library
at
this
point,
because
it's
all
merged
in
so
I
don't
know
like
if
they
just
do
a
redirect.
Maybe
at
like
the
package
level
or
at
like
you
know
the
code
level
or
something
like
that.
F
Yeah
well
that
yeah-
and
maybe
that's
just
the
answer-
is
that
it
depends
on
the
package.
It
could
be
a
variety
okay,
but
I
think
I
also
just
realized.
Maybe
gustavo
was
also
talking
about
the
fact
that
we
didn't
want
to
change
their
initial
import
so
like
what's
working
right
now
for
the
otlp
exporter,
if
you
wanted
to
keep
using
metrics
you'd
have
to
change
your
import
path.
Maybe
that's
what
well?
You
have
to
change
everything
anyways,
because
we're
going
to
like
restructure
how
things
are
composed
so.
B
F
G
F
I
think
this
is
going
to
become
a
like
a
more
and
more
pressing
questions
like
how
we
we
make
this
happen.
I
feel
like
a
lot
of
the
metric
stuff
is,
is,
at
this
point,
it'd
be
ideal
if
it
could
just
almost
rip
it
out.
I
know
every
time
that
a
test
failure
happens
in
that
package.
I'm
like
really
frustrated
and
still
you
know
it
exists
in
the
repo
given
it's
it's
something
that
we're
trying
to
like
not
release,
and
it's
just
getting
in
the
way
at
this
point.
F
We
talked
with
josh
a
little
while
ago
about
trying
to
balance
supporting
the
legacy
stuff
that
we
already
have
released,
even
though
it
was
an
experimental
like
approach
versus
just
ripping
off
the
band-aid
and
throwing
it
in
the
trash
and
saying
like
metrics
are
no
longer
in
this.
You
know
repository
after
this
version
or
something
like
that,
because
that's
that's.
F
Future
I'd
like
to
get
josh's
input
on
this
one,
though
I
think
I
think
he's
written
a
few
things
in
this
issue.
I
don't
know
gustavo
if
you're
talking
with
him
somewhat
regularly
or
if
he's
somewhat
dedicated
other
parts.
F
Okay,
maybe
that's
the
way
to
progress
this
issue
and
not
just
stall
the
meeting
completely.
It's
just
to
say:
maybe
we
could
touch
base,
maybe
maybe
we
can
set
up
a
meeting
with
with
you
guys
and
whoever
else
wants
to
join
on
this
one.
C
So
my
concern
is
that
I
would
like
to
move
quickly
on
this
because
we're
we're
in
mid-may.
I
would
very
much
like
to
have
an
rc
out
this
month.
Ideally
we
will
be
able
to
ship
next
week.
I
think
we've
got
two
outstanding
issues
that
that
really
need
to
land
one.
That's
got
a
pr,
that's
ready
with
a
couple
of
changes
that
might
need
to
happen
and
then-
and
then
this
one.
C
So
if
there's
a
way
forward
for
us
that
we
think
will
be
acceptable
and
we'll
cover
90
of
our
concerns,
perhaps
that's
the
way
we
ought
to
go
and
we
should.
We
should
set
a
deadline
for
ourselves
to
to
decide
one
way
or
the
other,
which
way
we're
going
to
go.
F
Yeah,
I
I
agree,
I
think
it's
one
of
those
things
that,
like
the
thing
that
like
when
I
hear
these
sort
of
things
like
it's
getting
in
the
way
of
getting
a
stable
release
out
is
that
we
should
just
I
take
the
atomic
approach
and
just
blow
it
all
away,
or
we
need
to
just
isolate
it
and
put
it
in
its
own
repo,
because
there's
a
really
clear
partition
at
that
point,
and
it's
really
easy
to
make
that
demarcation
where
we
say
like.
Oh,
we
found
the
units
package.
F
What
is
this
doing
here?
Just
put
it
in
the
metrics
thing
like,
which
is
what
we
did
and
that
works
right.
So
it's
the
same
thing
I
think
you
could
say
for
the
otlp,
if
we
could
do
that
solution
where
it
wraps
the
trace
one-
and
we
just
say
like
okay,
we'll
put
that
in
the
metrics
package,
and
I
think
I
think
we
have
paths
forward
here
like
I
think,
there's
ways
to
get
us.
You
know
deprecated
strategies
that
we've
talked
about
and
just
like
move
forward.
F
C
I
think
there's
also
a
way
forward
for
us
to
declare
that
we've
got
a
v2
of
the
otlp
exporter
before
we
v2
anything
else
right.
We
we
can
have
a
new
major
version
of
that.
If
six
months
down
the
road,
we
realize
that
what
we
decided
on
still
has
significant
problems
and
we
need
to
change
it.
Then
we
create
a
v2
of
that
exporter.
F
C
We
take
that
would
be
fine
right
because
v2
is
gonna
have
to
live
in
a
separate
import
path.
Anyways,
okay,.
B
B
It's
pretty
hard
to
figure
out,
like
you
know,
you're
staring
at
it,
trying
to
figure
out
what
what
to
pass
as
an
argument,
because
we
have
a
lot
of
interfaces
and
so
go
is
not
unlike
something
like
java
go
is
not
great
at
being
able
to
ask.
Oh
what
are
the
implementations
of
this
interface?
How
do
I
figure
out
which
things
can
fit
into
this
slot
here?
B
F
B
If
you're
willing
to
break
the
abstraction,
the
abstraction
layering
in
documentation,
you
can
help
this
a
little
bit.
So
let's
say
that
you've
got,
you
have
a
function
parameter
like
you
know
some
sort
of
constructor
function
and
it
wants
a
whatever
an
exporter
and
you
could
say:
well.
The
exporters
really
live
in
some
other
package
and
in
this
package,
all
we
do
is
we
define
the
interface
in
the
documentation
you
could
write.
B
Exporters
available
are
blah
blah
blah
blah,
even
though
you
really
shouldn't
you
shouldn't
be
have
that
awareness
flowing
in
that
direction,
since
it's
only
documentation
as
far
as
the
compiler
is
concerned,
you're
not
violating
any
of
the
intended
separation
of
concern
there
to
help
direct
users
say
like
if
you
land
at
this
point,
you're
trying
to
figure
out
what's
passed,
your
likely
choices
are
this
or
that
they
just
happen
to
live
elsewhere.
B
F
B
F
B
Do
I
think,
there's
still
it's
still
a
young
enough
technology
nobody's
really
sure
what
the
right
answer
is
long
term
and
recall
that
we're
we're
taking
a
principled
approach
rather
than
saying
we're
going
to
kind
of
try
to
pretend,
like
modules
don't
exist,
just
have
one
we're
trying
to
use
them
to
our
advantage.
But
it's
not
clear
yet
whether
or
not
it's
hurting
us
more
than
it's
helping
us.
C
Yeah,
it
definitely
adds
some
some
maintenance
overhead.
It
adds
some
cognitive
overhead
in
terms
of
needing
to
figure
out
which
modules
you
need
to
put
in
your
go
mod,
although
I
think
ides
help
a
lot
with
that
in
terms
of
limiting
how
much
you
need
to
think
about
that.
But
given
that
our
our
design
intent
for
splitting
the
module
so
granularly
was
to
try
to
minimize
the
dependencies
that
people
needed
to
pull
in
to
pull
in
any
one
individual
piece
of
the
sdk
where
they
have
choices
about
which
pieces
they
want
to
use.
D
I
have
a
question:
I've
not
used
open
telemetry
outside
of
go.
Does
any
other
language
offer
that
kind
of
granularity.
F
I
mean
java
does,
but
that's
just
because
everything's
all
packaged
very
neatly
like
that.
Yeah.
A
D
My
my
thought
is
like
when
you
build
the
final
product
and
you
look
at
like
the
nodes
modules
or
the
python.
Whatever
the
dependency
chart
is,
if
I
were
to
go
into
the
open
telemetry
portion
of
that,
I
wouldn't
see
like
the
jaeger
modules
from
python
or
the
javascript,
or
anything
like
that.
If
I
didn't
actually
import
yeager.
C
A
A
This
is
like
one
exporter,
another
exporter,
exporter,
exporter,
exporter,
instead
and
now
instrumentations
everything
else
and
some
exporter,
and
I
haven't
seen
any
like
separation
between
the
tracer
between
the
tracer
and
metrics,
because
I
think
that
I
think
there's
already
something
for
matrix,
but
I
will
need
to
check
it
out.
I
think
that
basically,
this
stuff
probably
has
also
some
kind
of
metrics
included,
but
I
will
need
to
check
it
out
for
sure
it's
not
separated
here
in
the
name
that
it's
only
for
traces.
G
Yeah
I
think.net
lives
on
the
wild
side.
F
Yeah,
the
java
group-
I
know
john
watson
is
really
critical
about
isolation
on
that
kind
of
stuff
and
the
star
files
that
they're
building
are
really
specific.
They
put
a
lot
of
effort
into
that.
If
I
remember
correctly,.
F
Yeah,
which
also
means
that
they
go
on
the
schedule
of
whatever.net's
release
pipeline
schedule
is
so
it's
yeah.
Interesting
is
a
good
word
for
it.
F
E
F
Okay,
I
think
I'd
like
to
maybe
take
a
look
at
it.
Just
look
at
it
from
like
a
practical
standpoint,
because
it
may
not
be
as
bad
as
I'm
thinking.
It
also
may
be
worse
than
thinking.
I
don't
know.
F
C
If,
if
you
were
around
at
the
very
top
of
the
meeting
where
we're
discussing,
I
think
gustavo
said
that
his
concern
right
now
was
how
does
he
present
the
the
changes,
one
pr,
multiple
pr's,
how
to
break
them
up
if
multiple
pr's,
because
they
they're
a
lot
of
changes
just
in
terms
of
lines.
F
Throw
it
in
a
throw
it
in
a
draft
and
send
it
over
the
wire,
and
I
don't
know
if
yeah,
if
it's
ten
thousand
lines
I
guarantee,
I
won't
be
able
to
read
it
if
it's
a
thousand
lines,
there's
a
possibility.
If
it's
I
mean
this
is
an
important
one
I
might
be
able
to.
If
it's
100
lines,
I
yeah
that's
a
great
size
but
yeah.
C
C
Happening
in
the
collector,
I've
been
having
trouble
reviewing
code
that
people
have
written
as
a
big,
huge
chunk
and
then
tried
to
break
up
and
bring
in
piecemeal.
So
I'm
like
well,
I
see
you're
introducing
this.
What
does
it
do
where
is
it
used?
Why?
How,
for
what?
So,
that's
also
kind
of
hard
to
review.
D
F
Yeah
well,
it
sounds
like
aaron's
volunteering
to
review
it
so
definitely
getting
getting
a
draft.
That
sounds.
E
Great,
I
could
open
apr
by
tomorrow
with
only
a
exporter,
for
example,
otlp
trace
http
and
the
the
things
that
it
needs
to
work.
I
guess
that
would
be
easier
to
review
if
we
should
keep
going
with
this
or
not.
C
C
Okay,
I
think
tyler
has
added
one
more
thing
to
the
agenda.
Suppose
we
can
move
on
to
that.
You
want
to
talk
about.
F
Sure
let
me
move
this
tab
and
share
my
screen
real
quick
here.
F
So
I
was
talking
a
little
bit
about
this
last
week.
There
is
this
issue
that
was
opened
and
closed,
really
quick,
because
the
span
options
that
are
passed
to
end
some
of
them
just
don't
take
effect.
It's
captured
in
a
comment
here,
and
this
was
specifically
implemented
a
while
ago.
F
I
think
for
good
reason.
I
think
there
was
a
good
reason
we
wanted
to
restructure
some
of
the
options
here
and
just
leave
it
open
for
like
if
another
sdk
wanted
to
actually
support
both
start
and
end
options
that
were
the
same
instead
of
like
the
default
open,
telemetry
sdk,
they
should
be
able
to
do
that.
The
problem
is,
is
that
when
it's
causing
confusion,
obviously
like
people
don't
understand
like
you
can't
pass
this
links
thing
to
the
stand
end,
even
though
this
compiles
and
runs
like
there's,
no
panic.
F
So
while
it
can
happen
like
it
drops
it
on
the
floor
and
it's
in
the
specification
itself,
it
says
that,
like
links
can't
be
added,
this
is
actually
said
in
the
api
I
found
when
I
went
and
look
back
at
it.
So
in
some
way
I
actually
don't
know
if
it's
valid
for
us
to
allow
certain
options
to
be
passed
to
this
end
method
in
general,
because
the
api
says
you
shouldn't
be
doing
it
and
maybe
we
should
be
restricting
it,
which
isn't
necessarily
how
I
like
to
define
apis.
F
But
that's
not
really
up
for
me
at
this
point
because
it's
defined
in
the
specification.
So
I
I'm
kind
of
thinking
we
go
back
and
I
feel
really
bad
about
that,
because
I
was
the
one
that
said
we
should
move
away
from
it,
but
I
I
wanted
to
see
just
everyone
else's
opinion
if
they
think
that
we
should
provide
separate
options
for
both
end
and
start.
I
think
jana
had
said
originally
don't
do
that.
It's
provide.
F
C
Think
we
are,
there
are
things
that
you
can't
prove,
or
you
probably
shouldn't.
I
don't
know
if
you
can't
provide
at
start
that
you
can
or
should
at
end
like
status
right.
Does
it
make
sense
to
provide
a
status
at
the
the
start
of
a
span
when
you
haven't
done
anything
with
it?
Maybe
if
you've
already
got
all
the
information
you're,
just
constructing
the
status
or
constructing
that
sure
of
yourself.
F
Well,
so
yeah,
I
think
the
original
reason,
one
of
the
things
that
was
motivating
me
on
this
one,
was
there's
a
user
at
a
new
relic
when
I
was
working
there,
that
was
kind
of
pointing
out
that,
like
sometimes
you'll
start
a
process
early
on
without
having
things
registered
or
without
having
a
tracing
system
set
up
or
something
like
that.
Maybe
you
want
to
delay
the
creation
of
that
span
and
you
can
do
that
because
we,
you
know
you
can
accept
a
time
stamp,
so
you
can
retroactively
say
like
well.
F
This
was
actually
started
back
then,
so
I'm
going
to
like
give
it
that
retroactive
timestamp
and,
at
the
same
time
like
you,
can
also
like
you
know,
you
know,
set
links
or
or
something
about
that
like
startup.
I'd
actually
go,
look
and
see
what
other
things
you
can
pass
to
start
that
you
can't
necessarily
do
at
the
end.
F
So
like
you
essentially
are
required
to
do
that
at
that
point,
because
if
you
start
the
span
when
the
process
starts
and
then
you
try
to
end
it
and
you
know,
go
like
oh
by
the
way.
I
also
found
out
that,
like
this
thing's
linked
later
on
in
the
process,
you
can't
set
the
link
at
any
later
point
in
time.
You
do
have
to
wait,
so
it
was
a
little
bit
like
a
frustrating
thing
so
essentially,
like
you'd
have
to
save
all
the
state
that
eventually
like
at
the
end.
F
You
would
create
and
end
this
man
at
the
same
time
essentially,
but
I
don't
know
like
that
sort
of
frustration
seems
like
the
the
exception
rather
than
the
general
case,
so
I
I
think
it
was
nice
to
be
able
to
like
say
like
yeah.
You
could
pass
all
this
stuff,
but,
like
I
know
that
in
new
relic
we
didn't
write
our
own
sdk.
F
That
accepts
links.
You
know
for
the
end
method,
so
like
it's
just
the
same
thing
like
if
that
was
the
instrumentation,
which
I
think
I
ended
up
not
being
used
in
the
end
but
like
that
was
just
getting
dropped
on
the
floor.
If
you
did
provides
the
end
anyways,
so
it
wasn't
really
a
useful
thing
to
allow
that
so
yeah.
I
agree.
I
think
maybe
just
restricting
this
background
to
what
we
want
is
what
we
want.
B
Yeah,
I
think
that
also
the
to
the
extent
that
we'll
get
to
the
point
of
ides
helping
with
this
sort
of
thing,
it
would
surely
be
nice.
It
was
a
type
error
type.
You
know
tight
match
failure
to
say
this
doesn't
fit
here.
I
think,
even
at
the
risk
of
maybe
duplicating
some
types
or
I
don't
know,
if
there's
something
to
do
with
aliasing
or
something
but
like
I
understand,
we
don't
want
to
write
the
code
multiple
times,
but.
F
C
The
implementation
of
these
functional
options
typically
are
one
lines
right,
so
we're
setting
some
links
or
appending
some
links
to
a
list
of
of
lengths,
we're
setting
the
ends
time
or
start
time
on
a
span
right
so
with
timestamp.
C
I
think
we
used
to
have
just
a
with
timestamp
which,
when
set
it
as
a
start
option,
what's
at
the
start
time
was
that
as
an
end,
option
was
at
the
end
time,
and
I
think
we
ended
up
moving
to
separate
options
because
we
created
this
life
cycle
thing,
which
we
can
then
go
back
to
if
we
have
separate
start
and
end
options
right,
because
then
that
one
with
timestamp
could
have
an
apply
start
and
apply
and
apply
event
methods
on
it,
which
could
do
subtly
different
things.
C
It's
setting
different
fields
on
the
same
structure,
it's
working
on,
so
you
get
some
consistency
in
the
the
feel
of
the
use
of
the
option,
even
though
it
does
different
things
and
has
different
areas
of
applicability.
F
Yeah,
that's
actually
something
I'm
thinking
of
one
of
the
reasons
we
did
want
to
remove
this
is
we
had,
I
think,
two
options.
One
was
with
start
time
and
the
other
one
was
with
end
time,
which
is
yeah.
I
think
we
can
solve
that
problem
and
unify
it
into
one
of
these
things.
Just
fine.
We
don't
have
to
have
two
options
there.
F
D
C
F
That
the
life
cycle
is
also
a
span
option,
so.
F
If
you
pass
with
attributes,
you
can
pass
that
as
a
stand
option
you
can
pass
with
timestamp
as
a
span
option.
C
Yeah,
so
the
thing
to
look
for
would
be
apply
span
so
anything
that
has
that
apply
span,
which
I
think
would
it
would
add,
then
timestamp
and
right
attributes
yep.
F
Yeah
attributes
links
the
new
root
and
the
span
kind
like
none
of
these
are
actually
valid
for
the
end,
except
for
the
time
stamp.
That's
literally
what
the
specification
says
you
should
take
as
an
option
as
the
time
stamp,
the
optional
timestamp
so
yeah.
We
could
have
it
that
this
is
like.
You
know,
apply
spam
start
and
apply
spam
end,
and
this
could
implement
both
and
all
the
other
ones.
Wouldn't
I
think
we
would
be
in
the
right
direction
here.
F
C
And
I
suppose
can
take
attributes
right,
so
we
we
could
add
a
span
end
option.
I
think
all
of
the
the
current
span
options
are
span
start.
F
Yeah,
I
actually
don't
know.
Let
me
double
check
on
that
really
quick.
F
F
Well,
I
don't
think
this
the
specs
as
you
can,
and
I
definitely
I'm
like
I'm
reading
the
code
like
it
doesn't
do
anything
with
the
attributes.
If
you
pass
them
here,
doesn't
it.
F
Yeah
and
so
let
me
double
check
again,
but
this.
F
F
B
Understand
like
right
now
we
have
many
ways
to
add
attributes
which
can
be
a
little
confusing.
Somebody
wants
to
be
like
well
what's
the
best
way
and
since
it
doesn't
really
matter
it's
like
when
you
know
it
say
say
what
you
know,
but
but
dropping
things
is
surely
evil.
You
know,
even
if
we
decided
sorry,
you
can't
do
this
at
the
end.
B
C
Should
yeah
yeah,
I
think
if
the
spec
doesn't
prevent
us
from
setting
attributes
at
the
end,
then
that
should
be.
B
Fine
does
it
change
any
interaction
with
span
processors.
C
Spam
processors
get
invoked
at
the
ends
of
the
end
method
right
so,
if
we
add
the
attributes
to
the
span
before
that,
it
would
be
no
different
from
the
user
calling
set
attributes
and
then
calling
end.
Okay.
B
Yeah
because
I
know
I've
got,
I
have
lots
of
code
where
I've
got
to
defer
and
it
calls
set
attributes,
and
then
it
calls
span.end
where
you
know
like
that,
I'm
already
trying
to
do
it
at
the
end
right
before
I
send
the
span
off
so
clearly,
that's
one
way
you
can
you
get
away
without
it
accepting
them.
F
Yeah,
I'm
with
you,
so
there
are
things
like
this
that
are
a
little
troubling.
You
know
like
they're,
just
embedded
in
in
this
specific
thing
like
specifying
links,
so
the.
C
C
You
can,
you
can
add,
you
have
to
add
them
at
start.
If
you
want
them
to
be
considered
by
samplers
by
headsamplers
at
least
right
right
right,
you
can
add
them
at
any
point
after
and
you
can
always
add
attributes
and
then
end
immediately.
C
So
I
don't
think
it'll
be
a
problem
to
not
take
attributes
in
end,
especially
since
the
the
spec
does
say.
The
only
option
it
takes
is
timestamp.
C
I
think
giving
an
option
to
set
the
status
and
attributes
at
the
end
would
make
sense,
but
it's
not
in
the
specs.
So
I
would
be
fine
also
with
not
allowing
that
and
requiring
users
to
just
call
those
methods
on
the
spam
before
they
end
it.
F
Well,
okay,
so
I
think
that
we
could
always
add
some
more
things
to
this,
but
I
think
there
still
is
going
to
be
the
underlying
question.
This
is
like
this
function,
or
this
method
should
not
accept
the
with
links
option
and
currently
it
does.
Yes,
there
should
be
a
different
set
of
options
for
ends
than
for.
B
Start
another
thing
just
just
while
we're
on
the
topic.
I
want
to
see
that
if
you
think
about
this
symmetrically
with
starting,
it's
also
kind
of
silly
that
you
can
provide
attributes
when
the
span
starts
and
then
immediately
set
them
afterward
too
right.
Unless,
unless
you're
writing
some
sort
of
like
constructor
function
and
you
you
our
factory
function,
you
want
to
return
the
span
as
a
one-liner.
You
know,
rather
than
binding
it
to
a
variable
calling
set
attributes
and
then
returning
it
or
something.
So
I.
C
Don't
know
the
critical
thing
there,
though,
is,
is
that
starting
a
span
runs
the
sampler
and
the
sampler
receives
the
attributes
that
were
present
at
start,
and
so,
if
you
want
attributes
to
be
considered
by
a
sampler,
they
have
to
be
present
when
the
span
is
started.
Oh
okay,
for
a
head,
sampler,
yeah,
well,
yeah,
okay,.
F
And
like
technically,
you
still
do
that.
You
know
you
just
have
to
call
set
attributes
before
you
call
end
it's
kind
of
on
the
user
to
do
that.
At
that
point,
and
maybe
that's
the
thing
in
the
future,
we
could
add
it,
but
you
know
for
the
one-hour
release.
Maybe
we
just
say
like
okay:
this
is
something
you
can't
pass
to
this.
You
just
have
to
do
it
explicitly
beforehand,
and
then
we
get
a
bunch
of
users
going
like
this
is
dumb.
C
So
aaron
would
would
you
feel
comfortable
since
you
you
said
you
were
gonna,
take
on
dealing
with
the
trace
option
overhaul.
Would
you
feel
comfortable
rolling
this
into
that
as
well,
and
splitting
out
start
and
end
span
options?
I
think
it
makes
sense
to
kind
of.
D
Yeah
I'll
try
and
slam
together
and
see,
see
what's
working
can.
Is
there
a
pr
that
that
says
these
are
the
options?
Can
we
get
a
list
of
just
what
options
need
to
be
need
to
be
present
at
the
end,
specifically.
D
F
Okay,
it's
going
to
be
a
little
bit
complex
because
the
functions
that
return
the
options
you
need
to
have
a
unified
way
to
return
timestamp
for
an
end
option,
a
start
option
an
event
option
all
three
of
those,
and
so
there
needs
to
be
this
essentially
like
that's
why
you
saw
this
lifestyle
life
cycle
option
and
that
that
needs
to
like
roll
up
into
one
of
those
things
and.
F
C
I
I
think
the
way
to
handle
that
should
be
to
have
that
function
just
return
its
concrete
type,
which
implements
all
of
the
interfaces
that
it
might
be
used
with.
I'm
robert,
I
think
you
had
mentioned
before
that
there
was
some
error
or
some
issue
with
trying
to
do
that,
or
was
that
somewhere
something
on
the
opposite
end
of
trying
to
take
a
life
cycle
option
and
extract
the
concrete
type
out
of
it.
Linters.
D
Don't
like
you
returning
unexported
types,
so
we'll
just
put
in
a
linter
yeah.
F
Right,
that's,
I
think,
if
that's
fine,
if
that's
not
the
problem
like
because
currently
right
now,
we
can
already
do
this
right,
like
we
can
return
from
with
timestamp
returns
a
lifecycle
option,
and
you
can
pass
that
to
functions
that
don't
accept
the
lifecycle
option.
They
accept
some
sub
interface,
that
is
the
composition
of
a
life
cycle
option.
F
So
right
now,
like
the
end,
accepts
a
span
option
and
you
can
pass
with
it
a
life
cycle
option
to
it,
because
it
knows
that
the
lifecycle
option
implements
a
span
option,
so
it
can
be
passed
to
that
function.
So,
if
that
that
direction
works,
it's
the
other
way
if
it
doesn't
work.
If
you
try
to.
F
Yeah,
I
think
that's
exactly
why
it
was
introduced
that
way
and
the
config
structure
is
organized
that
way,
yeah
and
for
the
linting
it
and
for
the
fact
that
there's
linting,
but
it's
also
like
there's
practicality
right,
if
you're
a
user
and
you
pass
back
this
option
and
then
you
get
some
sort
of
concrete
type
that
you
can't
interrogate
it
at
all.
Then
it's
not
really
like
it.
That
can
be
unexpected
as
well.
F
Okay
sounds
good,
should
I
assign
this
issue
to
you
then
yeah.
F
Cool
it's
issue.
1878.
C
Cool
all
right-
I
I've
allowed
us
to
run
significantly
over
and
for
that
I
apologize
next
week.
Tyler
will
be
back
steering
the
ship
properly.
I
hope
and
he'll
keep
us
on
time.