►
From YouTube: 2021-04-20 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
C
B
B
D
C
A
Yeah
we
got,
we
got
an
apartment
with
a
patio
in
in
november
so
because,
like
we
were
like
oh
it's
a
winter
during
a
pandemic
like
let's
not
try
to
live
in
the
smallest
apartment
possible.
A
So
when
the
weather
is
nice,
it's
getting
to
use
it
and
yeah
patio
and
stuff.
It's
very
nice.
B
E
F
B
I
really
like
portland
the
last
time
I
went.
Oh,
I
guess
it's
hard
to
keep
track
of
time,
maybe
in
2018
I
went
there
for
a
week
or
so
and
did
a
week
and
a
half
into
some
of
the
areas
around
it
really
yeah
great
city,
good,
the
food.
I've
never
eaten
so
much
food
in
my
life.
B
Yeah,
it's
crazy,
so
is
that
all
west
of
the
river
they're,
like
I
don't
know
whatever
political
stuff.
F
No,
I
feel
like
it's
it
spans.
Both
sides
of
the
river,
but
just
I
think,
generally
stuff
that
has
been
shut
down,
has
caused
a
lot
of
these
great
places
to
eat
to
no
longer
exist,
because
nobody
was
even
there
and
right
yeah
and
then
just
general
other
things.
I'm
sure
cities
are
going
through
this
to
some
some
extent.
It's
like
if
we
ever
come
out
of
this,
we'll
see
what
remains,
but.
F
All
right
on
that
note,
it
seems
like
it's
about
the
usual
time
with
the
usual
folks,
so
I
will.
G
B
F
I
think
there
will
be
plenty
of
time,
so
I
guess
we'll
get
on
with
the
specific.
B
Yeah
I
have
no
burning
questions.
It
would
be.
Let's
would
be
good
to
do
a
sink
on
where
our
first
rc
stands.
I
have
some
work.
I
may
want
to
schedule
my
end
around
after
that's
done
so,
but
not
burning
cool.
D
F
G
Folks
to
take
a
look
at.
F
Well,
I
guess
this
is
a
little
newer
than
I
thought
there
was.
There
has
been
something
around
for
a
while
about
this,
but.
G
F
Between
versions,
you
can
have
a
way
for
things
to
change
and
hopefully
a
wave
to
accommodate
those
changes
without
breaking.
So
I
would
have
to
read
it
into
this.
F
F
Produces
conforms
to
a
version
number
and
sending
a
version
number,
as
I
say
that
it
probably
is
way
more
simple
to
say
than
it
is
to
do,
but
I
think
the
other
side
of
this
is
on,
like
the
the
tracing
back
inside,
like
consuming
that
version
and
being
able
to
make
sure
that
anybody
sending
you
your
data
will
continue
to
have
the
same
experience
as
things
are
upgraded.
So
I
think
that
that's
me
sounds
like
the
slightly
harder
problem.
It's
like
on
the
on
the
ingest
side.
F
F
D
F
F
What
you
just
said,
andrew
is,
is
correct,
like
the
the
goal
of
this
thing
is
to
help
preserve
community
as
potentially
the
output
of
of
the
telemetry
changes.
F
How
to
handle
synthetic
requests
in
telemetry
and
if
there,
if
there
needs
to
be
any
thing,
decided
kind
of
like
at
a
spec
level
or
any
sort
of
I
don't
know
ways
to
maybe
handle
this
in
a
multi-vendor
situation,
etc.
F
It's
pretty
open-ended.
But
really
the
question
is
synthetics.
I
don't
know
who's
familiar
with
this
term,
but
sometimes
like
you
will
you
will
script,
it's
kind
of
like
a
scripted
user
that
will
come
to
your
website
and
like
do
something
and
usually
like
it's
nice
to
capture
a
trace
and
be
able
to
kind
of
a
make
sure
that
that
thing
succeeded.
F
Situations
where
there's
like
sampling
involved,
like
you,
usually
want
a
priority
to
like
a
synthetic
synthetic
request,
for
example.
So
that's
kind
of
the
backdrop.
I
think
there
really
is.
No.
There
is
nothing
in
open
telemetry
so
far
to
kind
of
to
support
this,
although
they're
likely.
F
F
F
F
F
The
w3c
context,
propagation
format,
so
state
is
a
spot
for
an
individual
vendor
or
user.
I
use
the
term
vendor
lightly
to
kind
of
put
an
entry
with
some
custom
information
that
should
propagate
to
the
next
propagate
through
multiple
tracing
vendors.
F
So
this
should
be
something
that
that
lasts
between
requests
and
if
somebody
didn't
want
to
implement
synthetic
support,.
F
Usually
this
starts
by
setting
a
header
on
the
request
that
comes
from
your
kind
of
scripted
user,
so
I
think
it
would
really
kind
of
entail
a
a
custom
propagator.
You
could
probably
just
subclass
our
our
w3c
propagator
to
kind
of
preserve
that
state
from
that
original
request.
That
asynthetics
request
stick
something
in
trace
state
and
then
read
and
attach
that
attribute
as
needed.
F
F
I
don't
know
I
ramble
about
that
a
little
bit
any
any
questions
or
comments
here.
Is
anybody
thinking
about
synthetics.
B
Yeah,
I
think
it's
it's
popped
up
for
me
because
we
have
a
pretty
large
synthetics
product.
I
think
tri-state
is
like
the
right
place
for
this,
but,
to
be
honest,
I
actually
really
strongly
dislike
open
telemetry,
really
like
having
any
explicit,
like
quote
synthetic
support,
because
it's
like
a
very
vendor
like
it's
a
vendor
term.
It's
not
like
if,
if
open
telemetry
doesn't
have
synthetic
support
within
the
ecosystem,
like
it's
a
little
bit
ridiculous
to
suddenly
have
like
first
class
support
for,
what's
essentially
just
vendor
products,
and
it's
like
you
know.
B
If,
if
aws
wants
to
donate
the
synthetics,
you
know
repo
they
stole
from
checkly
or
whatever
like
they
can
do
that
I
don't
know,
but
I
don't
love
that
like
it's
going
like,
I
I
think
in
general,
like
it
would
be
nice
to
support
synthetics
without
explicitly
saying
like
this
is
for
synthetics.
Just
saying
like
this
is
how
you
pass
in
a
generated
trace
id
and
some
sort
of
indic
like
a
data
dog.
It's
just
some
sort
of
it's
another
header
that
says
like
just
make
sure
we
keep
sample
this
trace.
B
B
I
think
it's
a
it's
a
little
crazy
to
me
to
say,
like
to
explicitly
use
some
of
the
terminology.
That's
otherwise
not
even
really
like
part
of
open
telemetry,
it's
a
weird,
but
it
helps
me
okay.
So
those
are
my.
Those
are
my
thoughts,
I'm
not
sure
whether
trace
what
what
the
keys
would
be
in
trace
date,
but
it
feels
like
tri-state's
the
right
place.
F
Yeah,
I
think
I
think,
they'll,
probably
summarize
a
little
better.
What
I
was
trying
to
say
there
is
that
there
are
definitely
the
hooks
there
to
do
this.
This
is
something
that
you're
interested
in
so.
H
If
you
have
to
do
something
like,
I
guess,
the
question
is:
if
you've
got
a
behavior
that
is
dependent
on
the
trace
state,
do
like
is
our
instrumentation
set
up
in
such
a
way
that
you
could
kind
of
hook
in
what
you
need
transparently
right
so
is,
is
the
is
the
mechanism
there
to
add
the
policy
that
you
need,
and
I
don't
know
if
it
is
at
this
point.
H
Yeah
exactly
it's
like:
you
need
to
map
that
somehow
to
a
sampling
decision,
so
does
the
sampler
get
access
to
the
trace
state?
I
can't
remember
offhand.
B
I'm
blanking
as
well
yeah,
I
don't
know
if
our
tool,
I
don't
know
if
the
repos
like
actually
have
convenience
hooks
or
anything
like
that,
makes
us
a
practical
solution,
but
just
in
terms
of
architecture,
it
probably
ought
to
live
in.
I
feel
like
this
is
the
intention
of
trace
at
least
the
the
guts.
Are
there.
F
F
I
feel
like
you
could
somehow
sneak
something
into
the
context
and
through
that,
be
able
to
get
it
in
these
endpoints.
So,
whether
or
not
like
something
is
physically
passed
to
the
sampler,
I
think
we
would
be
able
to
see
into
the
context
and
if
you
had
a
custom,
sampler
read
it
back
out.
For
example,
this
might
be
not
ideal
situations.
F
Those
are
things
that
I
was
kind
of
thinking
and
alluding
to
extension
points
and
the
fact
that
the
the
hooks
are
probably
there
having
not
tried
to
do
this,
though
it
it
is
something
that
might
that
there
might
be
things
that
we
can
add
in
that
make
it
a
little
bit
easier.
So
I
think
pochemic
is
going
to
at
least
open
up
some
issues
for
discussion
on
this
and
see
where
they.
F
F
F
There
was
a
fact
change
that
apparently
allowed
a
null
pass-through
from
tracer
provider
git
tracer,
and
it
is
something
that
turns
out
to
be
a
pretty
big
problem.
I
guess
like
in
java.
Specifically,
I
could
see
this
being
a
problem
in
any
other
language
where,
where
you
might
expect
a
type,
instead
of
a
null.
F
I
took
like
a
quick
look
at
what
we
have
ruby
and,
I
think
fine,
because
we
default
name
to
an
empty
string.
Even
if
you,
if
you
get
a
tracer
with
no
arguments,
we
get
an
a
name
as
an
empty
string.
I
think
that
was
one
of
the
yeah
that
was
kind
of
the
the
decision
here
was,
instead
of
a
null
just
making
an
empty
string
and
everything
kind
of
works.
F
It's
not
the
best
value,
probably,
but
I
think
it's
unlikely
that
anything
from
or
probably
like
a
bug
if
our
sdk
was
producing
anything
with
the
empty
string.
It's
kind
of
like
the
user
has
full
control
over
this.
If
they
don't
like
that,
they
can't
pass
an
argument
to
get
tracer,
but
an
empty
string
is
a
lot
better
empty
value
for
typed
languages
in.
G
F
I
think
there
were
kind
of
two
conversations
that
were
going
as
a
result
of
this,
and
one
is
probably.
F
One
is
probably
more
contentious
than
the
other,
the
the
lesser
interest.
One
was
that
we.
F
Or
in
ruby
we
probably
don't
have
a
ton
yet,
but
we
may
have
a
ton
and
we
it's
an
extension
point.
So
it's
up
to
the
user,
how
many
they
have,
but
you
have
multiple
resource
detectors
and
they
kind
of
like
run
in
some
kind
of
sequence
and
values.
F
For
the
most
part,
it's
fine,
but
in
some
situations
some
of
these
resource
detectors
could
be
detecting
the
same.
The
same
attribute,
name,
same
keys
and
like
it
becomes
a
little
bit
undefined
and
possibly
a
little
bit
convenient
inconvenient
depending
on,
like
which
one
takes
precedence.
F
So
I
guess
there
are
some
situations
where
this
does
matter
in
the
real
world.
Today
I
guess
like
gke
versus
gce.
I
think,
like
one
is
a
more
specific
version
of
the
other
and
you
would
like
the
more
specific
version
to
take
precedence.
F
So
that
was
one
discussion.
It's
like
how
to
kind
of
define
ordering
and
how
to
like,
make
sure
that
there
is
like
some
knobs
for
for
ordering
of
the
resource
detectors
for
those
situations.
D
Yeah,
I
think
for
me,
like
the
case
of
the
environment
variable
and
the
precedence
it
should
have,
or
should
not
have
over
explicitly
configure
things
in
the
code
that
case
to
me,
isn't
actually
all
that
confusing.
I
in
my
mind
at
least
I
would
say
you
know
the
things
provided
by
the
sdk
have
the
lowest
precedence
and
then
the
environment
variable
wins
over
that.
And
then,
if
you
configured
something
in
your
code,
then
maybe
that
wins
but
but
that's
also
sort
of
just
an
opinion.
D
For
me,
the
more
interesting
thing
would
be
like
within
resource
detectors
provided
by
the
sdk,
which
one
should
win
like
what
should
the
precedence
order
there
be
if
multiple
detect
the
same
attributes
that
that
to
me
is
more
interesting
but
it'll
be
good
to
know
which
way
you
know
in
general.
I
guess.
F
So
I
think
that
is
interesting.
You
touched
on
the
more
controversial
topic,
though,
and
I
think
it
is
slightly
more
controversial.
F
If
you
get
a
big
enough
group
of
people
about,
like
does,
does
anybody
configuration
take
precedence
over
an
environment
variable
or
vice
versa,
and.
F
F
D
Oh,
I
was
just
gonna
switch
topics
slightly
and
ask
what
what
the
ruby
sdk
does
today,
because
we
actually
started
implementing
in-house
resource
detectors
and
we
only
have
the
one
at
the
moment.
So
it
doesn't
matter,
but
we're
gonna
have
the
two
or
the
three
very
soon,
and
so
I'm
actually
curious.
What
have
have
we
decided
anything
on
this.
D
I
mean
like
everyone
on
the
call,
I
guess,
is
the
ruby
sdk
made
a
decision
on
this,
or
is
it
sort
of
up
in
the
air
still.
H
All
right,
yeah
robert,
might
have
some
context.
I
know
he
did
some
work
on
the
the
resource
detection.
H
This
question
came
up
on
the
slack
as
well
are
a
related
question
on
slack
right
now
we
just
have
the
one
resource
detector
in
like
in
the
open
telemetry
project,
which
is
the
google
resource
detector
and
that
I
believe,
is
currently
kind
of
embedded
in
the
resource
detectors.
Gem
really.
I
think
that
should
be
extracted
into
its
own
gym
and
we
should
just
have
the
mechanism
for
resource
detection
in
the
resource
detector's
gym,
and
then
you
should
be
able
to
explicitly
pull
in
whichever
resource
detectors
you
want.
H
So
if
you
want
the
aws
one,
you
pull
that
in,
but
you
don't
need
the
gcp
one,
because
you're
not
running
in
gcp.
I'd
have
to
look
at
the
code
to
recall
the
precedence.
C
I
don't,
I
think,
because,
right
now,
I
think
there's
only
one.
We
only
have
the
auto
detector
and
the
one
gcp.
So
I
think
the
merge
order
is
just
it
doesn't
like
have
one,
because
it's
just
fun
right.
That's
what
we're
talking
about
so
and
yeah.
C
Because
of
how
we
pass
in
resources,
so
I
think
I'd
have
to
double
check,
but
I
think
because
it
happens
with
the
sdk
kind
of
implicitly
it'll
pull
from
the
environment.
C
C
D
Okay
cool,
I
was
to
relate
it
back
to
the
pr
at
hand
or
the
the
issue
at
hand.
I
was
wondering,
maybe
if
we
could
chime
in
there
with
how
we're
doing
it
today
and
say
here's
you
know
here's
what
we've
decided,
but.
H
F
Yeah,
I
don't
know,
as
this
conversation
goes
on,
I
kind
of
feel
like
I
feel
like
the
environment
variable.
The
detector
should
probably
take
precedence
over
the
other
detectors
and
then
I
think
it's
a
toss-up.
F
D
Yeah,
maybe
we
maybe
we
open
an
issue
about
it
and
think
about
it
and
discuss
a
little
bit
there
see
if
anyone
else
that
follows
the
repo
might
have
a
have
a
thought
on
it.
B
F
B
B
B
This
is
where,
like
in
in
practice,
our
users
will
often
be
devops
practitioners
or
sres
and
infrequently
or
or
not
infrequently,
not
as
frequently
as
companies
would
like
will
be
like
the
developer
like
who
just
can
ship
a
change
in
in
the
application
code,
and
so
yeah,
it's
easier
time
to
value
or
whatever
for
the
now,
I'm
really
getting
like
data
dog
speak
for
our
champions.
B
I
Chiming
is
another
vendor
and
channeling
my
experience
at
chef,
it's
generally
the
precedence,
if
you
put
yourself
in
the
shoes
of
the
person
running
this
thing
developers
unless
they're
running
the
thing,
don't
really
know
all
the
operational
issues
so
like
you
can
put
stuff
into
code,
but
in
general
you
want
to
let
like
the
at
the
last
moment
you
can
put
in
something
else
so
with
command
line,
switches,
override
environment
variables,
which
override
code
is,
has
been
the
precedence
that
has
served
me
well
for
like
a
decade.
I
H
Right
the
way
the
code
is
set
up
right
now,
the
environment
variable
has
the
lowest
precedence,
so
the
environment
variable
takes
precedence
over
telemetry,
sdk
and
things
like
that.
But
any
code
anything
explicitly
set
in
the
code
will
take
precedence
over
the
environment
and
then
it's
up
to
the
developer,
whether
they
stick
those
explicit
code,
like
sorry
explicit
resource
things
from
code
in
front
of
the
resource
detectors
are
after
the
resource
detectors,
but
yeah
environment
variable
loses.
I
I
would
I
would
recommend
that
it
not
but
yeah
from
my
experience
in
different
worlds,
not
necessarily
here
in
open
source.
E
But
so
not
that
they
get
not
to
dig
into
the
weeds,
because
I
haven't
read
this
yet,
but
the
there's
a
single
resource
attribute
and
is
there
anything
that
is
explicit
about
when
to
exclude
a
specific
resource
detector?
If
those
attributes
are
present
or
is
it
saying
that
there
should
be
merging
with
whatever's
auto
detected
as
well.
H
Well,
you
could
override
it.
The
order
right
now
is
that
we
set
the
the
the
default
telemetry
sdk
stuff
first
and
then
the
environment
overrides
that
and
then
anything
you
set
explicitly
and
you
get
to
choose
whether
you
set
sort
of
explicit,
attribute
or
explicit
resource
attributes
first
and
then
the
resource,
auto
detector,
stuff
or
whether
you
do
the
resource,
auto
detectors
first
and
then
do
the
the
explicit
attributes,
but
it
sounds
like
we
should
have
a
way
for
the
environment
to
override
everything
else.
H
H
And
then
you
do
the
overrides.
I
think
we
would
need
to
split
that
out
where
you
have
default,
then
you
have
all
the
auto
detection
and
explicit
things,
and
then
you
have
environment
overrides
at
the
end,.
B
Oh,
I
actually
just
a
little
account
if
I
I
misspoke
datadog
def.
The
preference
order
is
in
code,
if
you
explicitly
configure
it
in
code,
we'll
take
in
precedence
over
environment
variable.
I
was
totally
mistaken,
but
there's
a
big
push
to
make
everything
configurable
for
by
environment
variable.
For
the
reasons
we
talked
about,
yeah.
H
Yeah
sorry
just
want
to
try
sorry
in
our
in
shopify's
kind
of
rapper
gem.
For
this
we
have
had
to
jump
through
hoops
in
a
couple
of
places
to
allow
like
we
set
some
stuff
explicitly
because
we
have
some
defaults
that
apply
across
the
organization,
but
we
also
want
to
allow
environment
variables
to
take
precedence.
H
H
I
don't
know
how
we
could
set
up
the
code,
so
we
didn't
have
to
do
that.
I
imagine
other
people
might
have
the
same
pain.
C
I
B
F
F
There
is
this
paradigm
that
people
are
very
used
to
where
you
can
always
override
things
with
an
environment
variable-
and
I
know
I
know
this
appeals
a
lot
to
this
is
where
you
have
people
who
are
more
in
the
devops
role,
or
they
don't
they
aren't
in
the
code
base.
They
might
even
have
access
to
the
code
base,
but
they
want
to
be
able
to
kind
of
like
toggle
some
switches
and
that's
very
useful
for
them.
F
I
feel
bad
for
people
in
that
position,
but
yeah
then
there's,
I
think
the
12
factor
route,
which
yeah
the
12
factorists,
will
tell
you.
If
you
want
that,
you
should
just
leave
the
you
should
have
no
encode
configurations,
but.
F
I
don't
know,
maybe
the
12
factorists
are
not
running,
are
not
part
of
observability
teams
and
running
this
kind
of
software.
Maybe
it
makes
a
little
bit
more
sense
in
some
other
scenarios,
I'm
not
really
sure.
F
Think
the
main
thing
here
is,
if
you
have
opinions
and
if
you
have
scenarios
and
if
you
want
your
voice
heard,
I
think
this
is
like
a
good,
a
good
issue
to
comment
on
and
participate
in
and
whatever
we
come
up
with
like
open.
Telemetry
should
like
adopt
this.
You
know
and
standardize
it
between
the
projects
so
that
we
don't
have
everybody
crazy.
H
Yeah,
I
I
would
just
say
like
we
have
also
fought
battles
against
12
factorists
within
the
org.
It's
it's
challenging,
because
when
you're
part
of
an
observability
team
for
an
entire
organization,
you
want
certain
configuration
to
be
standardized
across
the
entire
org,
and
you
want
people
to
just
be
able
to
pull
in
the
auto
instrumentation.
They
get
all
the
defaults
set
up
for
them
and
they
kind
of
don't
have
to
mess
with
anything,
because
if
they
mess
with
something
they're,
probably
going
to
break
it.
I
That's
is
that
not
still
available
to
them
when,
if
you,
if
you
provide
a
wrapper
around
open
telemetry
for
your
organization-
and
it
sets
some
things
in
code,
you
would
you
would
tell
the
consumers
of
that
wrapper.
Don't
set
these
environment
variables
or
or
your
training
wheels
have
come
off
and
you're
responsible
for
the
consequences.
H
Yeah
yeah,
we
can
do
that.
It's
just
a
question
of
whether
we
should
then
allow
them
to
set
the
environment
variable
or
not
right,
it's
like
if
we
want
to
enforce
the
configuration
then
and
tell
them
like
I'm
sorry,
you
can
set
the
environment
variable
all
you
like.
It's
just
not
going
to
have
any
effect.
H
That's
that's
true,
yeah
yeah,
so
we
we
need
to
figure
out
all
that
sort
of
stuff
right.
It's
like
right,
yeah,.
I
I
And-
and
I
have
my
opinion
about
precedence,
cli
switches,
environment
variables
and
then
config
and
code,
but
as
long
as
there's
a
documented
precedence
I'll,
you
know
I
can
move
with
anything
as
long
as
it's
consistent,
yeah.
H
Cool,
do
we
want
to
move
to
prs
and
issues
or
yeah.
F
Other
topics
we
should
this
has
been
a
lively
discussion.
It's
been
good,
I
think
we've
discussed
it
more
than
we
did
in
this
exam,
so
yeah
further
thoughts
should
probably
go
on
this
issue
and
I'm
sure
we'll
watch
in
coming
meetings.
H
H
I've
done
the
easy
part
of
that
this
morning,
which
is
using
process
clock
at
time
for
timeouts.
So
all
the
places
where
we're
specifying
timeouts
the
hard
part
of
it,
which
I
think
eric
alluded
to
a
few
months
back-
is
using
monotonic
clocks
and
the
real-time
clock
for
all
the
different.
Well,
it's
basically
for
span
start
time
and
time
and
event
time
where
it
gets
really
messy
is
when
users
can
pass
in
explicit
time
stamps
to
those
apis
and
you
kind
of
need
to
deal
with.
H
Like
am
I
a
local
route?
Am
I
a
local
route
with
an
explicit
start
time?
Is
my
parent?
Does
my
parent
have
an
explicit
start
time,
or
does
it
have
a?
Is
it
a
local
route
with
a
default
start
time,
so
I
can
use
an
offset
from
its
start
time
as
my
start
time,
all
these
sort
of
scenarios,
so
it
gets
really
weird
and
interesting.
H
I
rub
a
doctor,
a
bunch
of
this
stuff
with
robert
this
morning
and
I'll
write
up
some
notes
for
that
on
the
issue,
but
there's
this
and
then
there's
an
associated
kind
of
work
in
progress
issue
as
well.
Talking
about
some
of
this
stuff.
B
So
I'll
I'll
update
the
issue
probably
review
it.
Since
I
was
the
person
clamoring
for
this
yeah.
H
Robert
jumped
on
this
right
away
as
soon
as
I
pushed
it
up
and
approved
it,
and
I
was
like
wait,
wait
I'm
not
done
yet.
I
hope
it's
just
the
first
easy,
but
I
thought.
B
All
right
I'll
review
the
thoughts
again
I'll,
provide
thoughts,
cool
thanks.
H
H
I
guess
in
terms
of
this
pr,
though
one
question
is:
do
we
want
to
do
the
minimal
thing
where
we
just
replace
time
now
with
process
clock,
get
time
for
whatever
the
real
time
clock
and
not
do
all
the
offset
dance
just
so
that
we
have
the
apis
set
up
the
way
we
want
so
the
time
stamps
are
the
timestamps
are
exported
in
the
right
format,
and
then
we
can
do
the
internal
cleanup
later
or
do
we
want
to
do
the
whole
thing
in
this
pr
because
it
might
be
like
we
might
be
able
to
get
it
done
faster
if
we
just
focus
on
the
api,
visible.
F
H
The
handle
the
offsets,
so
we
just
like.
Ultimately,
we
just
need
to
handle
the
offsets
internally
in
the
sdk
span
class,
maybe
the
event
class,
but
I
think
it's
mostly
just
in
the
span
class
and
maybe
tracer
so
it's
sort
of
internal
stuff
in
the
sdk
and
then
the
change,
the
user,
visible
change
would
be.
Exporters
would
get
time
stamps
as.
H
Some
offset
from
epoc,
so
it
would
be.
We
have
to
make
a
decision
about
whether
that's
nanosecond
since
epoch,
which
is
what
otlp
expects
or
microseconds
since
epoch,
which
is
what
jager
expects
or
milliseconds
since
epoch,
which
is,
I
think,
the
what
we
get
from
like
windows
or
afloat.
H
We
can
discuss
it
on
the
issue.
I
think
the
the
thing
that
I
really
want
to
get
resolved
is:
do
we
want
to
try
to
handle
all
the
complexity
right
now
in
this
pr
or
do
we
want
to
just
focus
on
things
that
affect
the
the
use
of
user-visible
data,
basically,
like
the
readable
span,.
I
I
C
I
Today
would
be
yep
would
make
sense
and
as
a
new
person,
I
I
think
as
much
as
the
opinion
matters.
I
think
doing
it
in
two
swipes
one
to
settle
the
api
and
what?
How
does
using
it
look.
And
what
do
you
get
out
of
it
defined
and
then
follow
up
prs
for
resolving
the
internal
behavior
to
make
it
match
that.
H
Right:
okay,
in
that
case,
I
can
do
just
in
this
pr.
I
can
make
all
the
changes
to
use
process
clock
at
times,
so
we
can
decide
on
the
units
and
so
forth,
I'll
update
all
the
exporters
so
that
they're
doing
the
right
thing,
and
then
we
can
do
a
follow-up
even
after
the
rc,
we
can
do
a
follow-up
where
we
actually,
you
know,
be
a
little
bit
more
precise
in
our
handling
of
time.
Internally,.
H
H
For
jager
right,
the.
A
H
Caveat
there
is
that
we're
going
to
run
out
of
bits
in
a
63-bit
number
faster
with
nanoseconds
than
microseconds.
So
that's
that's
really.
The
only
issue.
F
G
F
Have
we
covered
cover
the
main
issues?
I
know
eric
wanted
to
ask
a
little
bit
about
our
rc
plans.
I
think
at
least
I'm
recalling
this
the
beginning
of
the
meeting
yep.
H
B
Okay,
cool,
I
think,
that's
reasonable.
I.
B
I'm
not
I
I
have
to
catch
up
on
the
in
span
thing.
I
know
that
was
from
last
week,
I'm
blanking,
but
yeah.
I,
the
only
reason
I
was
asking
is
because
I
was
going
to
update
some
packages
that
datadog
publishes
once
there's
an
rco,
but
I
was
only
do
it
this
week,
but
I
figure
it's
dumb
to
do
it
before
in
rc,
because
I'll
just
have
to
do
it
again.
B
I
Win
this,
I'm
not
sure,
is
he
like
getting
a
bunch
of
consistent
numbers
across
all
the
things
that
I
bring
in,
but
other
than
that,
instead
of
instead
of
a
bunch
of
little
points,
moving
yep.
H
Okay,
well,
if
yeah,
if
robert
lauren
really
really
cares
about
having
a
release,
I
will
probably
do
a
release
for
him
and
then
we'll
that
that
should
hopefully
happen
today
or
tomorrow,
I
think,
depends
how
much
she
pressures
me.
B
I
So
I
I
had
my
thrashing
yesterday
with
not
knowing
what
update
I
needed
to
make
to
my
code
config
to
get
the
batch
spam
process
to
get
the
exporter
configured
right,
because
I
missed
that
breaking
change
and
I
guess
I
have
a
question
about
whether
the
oh,
what
is
it?
What
are
they?
I
What's
the
commit
spec
the
conventional
commits
conventional
commits
is
that
does
the
tooling
there
have
a
way
to
include
not
just
like
detect,
fixed,
bang
or
or
feature
bang,
and
then
include
that
commit
message
and
the
change
log,
but
like
particularly
for
the
bang
ones
like
a
message
that
would
come
with
it.
That
would
say:
here's
what's
broken
and
here's
the
change
that
you
need
to
make
consumer
of
this
library.
H
So
I
don't
think
it
does.
It's
really
reliant,
like
the
maintainers,
of
course,
cannot
modify
the
change
log
yeah,
so
the
the
change
log
that
is
put
together
in
the
pr
by
the
conventional
commit
tooling.
You
know
it
is
nice
as
a
summary,
but
you
know
if
you
had
really
good
maintainers.
H
Those
maintainers
might
go
in
and
actually
edit
the
change
log
and
make
it
more
consumable.
So
you
should
definitely
try
to
vote
for
a
maintainer
that
goes
the
extra
mile
yeah
I
I
will
try
to
do
a
better
job
of
that.
This
was
not
critiquing.
A
human.
H
No,
I
I
think
for
us
it's
a
totally
valid.
It's
a
totally
valid
criticism.
I
think
the
tooling
only
goes
so
far,
and
you
know
sometimes
we
find
that
you
know
we
forget
to
use
conventional,
commit
messages
and
then
I
need
to
go
in
and
dig
out
that
commit
and
add
the
information
to
the
changelog.
H
So
I
think
we
need
to
get
a
little
bit
more.
I
H
Yeah,
so
I
mean
pr:
the
change.
Log
is
one
thing,
but
also
the
release
process
creates
a
pr
which
we
then
have
to
modify
like.
I
already
have
to
do
a
bunch
of
work
there
to
update
all
the
dependencies
between
the
gems
and
tweak
the
change
log.
If
we've
missed
a
conventional
commit
message,
I
think
we
should
make
the
review
process
for
that
release
a
little
bit
more
onerous
and
have
they
have
people
requesting
hey?
Could
you
add
this
information
to
the
change
log?
Because
you
know
it
matters
to
consumers?
H
I
It
could
even
help
if
in
as
much
as
we
can
control
the
committer
put
making
a
a
longer
commit
message
that,
whenever
you
put
encourage
that,
whenever
you
put
a
bang
in
your
conventional
commit
prefix
that
it's
not
just
one
of
the
one-liners
but
like
include
in
the
message
body
of
the
commit
message
that
like
what
what
is
breaking
about
this
and
what
would
a
consumer
have
to
change
about?
The.
I
C
Go
ahead,
oh,
I
was
going
to
say
like
that's
like
I
was
going
to
say.
The
other
side,
too,
is
like
I'm
not
always
the
best
at
putting
in
like
proper
commits
when
something
breaks
or
change,
something
so
like
as
much
as
the
responsibility
is
sort
of
on
the
maintainer.
It
is
also
should
be
on
us
that
are
like
contributing
to
the
repo
to
make
sure
that
we're
actually
capturing
the
information
and
submitting
good
commit
messages.
I
But
the
prolific
committers
add
like
try
to
try
to
add
notes
to
the
commit
messages
and
then,
when
something
has
a
bang
in
it,
when
the
maintainer
comes
to
like
flesh
out
the
release,
notes
they're
at
least
commit
messages
to
refer
back
to,
to
lift
and
and
then
wordsmith
for
end
users,
which
again
I'm
I'm
happy
to
help
with.
If
that's.
C
I
But
that's
maybe
something
that
in
reviewing
pr's
that
are
backwards,
breaking
at
least
have
the
submitter
or
somebody
write
in
the
pr
in
a
comment
or
update
the
description
with
here's.
The
release
notes
that
here's
the
blurb
that
you
get
included
in
release,
notes
or
the
change
log
about
what
how
do
end
users
adjust
to
this
change.
F
Yeah,
I
will
add,
I
think,
js
has
this
like
upgrade
guide
it's
in
addition
to
the
change
log,
where
it'll
kind
of
mention
things
that
if
there
was
a
big
enough
change
that
you
will
have
to
modify
your
code,
what
you
need
to
do,
I'm
just
throwing
it
out
there
as
a
possibility.
F
I
H
I
H
B
Yeah
I.
F
Will
I
think
we
need
to
find
a
way
forward
on
tracer
in
span?
I
did
mention
it
in
the
in
a
couple
of
the
slack
channels
and
that's
the
feedback,
but
maybe
we
can
on
on
the
issue
and
follow
up
on
it
next
week.
I
think
the
the
general
consensus
is
what
we're
currently
doing
is
confusing,
and
I
think
I
think
that's
pretty
clear.
I
think
the
the
two
options
would
be
for.
F
F
From
the
past
in
context
or
just
avoid
that
situation
by
not
even
allowing
somebody
to
pass
in
a
context
and
then
you're
kind
of
always
using
the
implicit
one,
so
maybe
we
can
make
a
point.
I
guess
to
make
a
decision
on
this
for
for
next
time,
and
I
can
link
to
maybe
the
conversation
that
was
in
in
slack.
There's
not
a
whole
lot
of
talk
there,
but
one
of
the
js
maintainers
chimed
in.
H
Yeah
thanks,
I
think,
be
helpful
to
have
that
context.
Probably
in
the
discussion
like
we've
got
the
tracking
issue,
but
that
just
points
to
the
discussion,
the
github
discussions.
So
if
you
want
to
post
sort
of
a
link
to
the
slack
discussion
there
that'd
be
helpful
yeah,
I
think
the
I
think
where
we
got
to
was.
H
Maybe
we
want
to
pull
out
the
in
span
api
to
somewhere
else,
some
external
gem
and,
at
the
very
least,
get
rid
of
the
explicit
contact,
explicit
parent
context,
option
for
that,
like
it's
easy
for
us
to
add
in
the
option
later
on,
it's
hard
for
us
to
take
it
out
later
on.
So
let's
take
it
out
now
and
for
the
cases
where
people
have
to
do
explicit
context,
manipulation
they'll
need
to
do
that.
F
Explicitly
yeah,
I
think
that
makes
sense.
I
guess
of
this
milestone.
This
is
the
one
that
is
probably
still
most
up
in
the
air,
so
I
guess
this
is
probably
the
thing
that
we
should
probably
try
to
get
some
direction.
C
F
This
week,
so
that
we
can
wrap
that
up
and
then
I
think,
as
always,
I'm
trying
to
go
through
the
api
with
a
fine-tooth
comb
and
just
make
sure
that
there
isn't
anything
else.
That.
H
F
Cool
we've
got
a
little
over,
so
maybe
I'll.
Let
everybody
get
back
to
work
and
see
you
next
week
thanks.
Everyone.