►
From YouTube: 2021-02-18 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
Well,
it's
it's
close
enough
that
if
the
weather
is
nasty
here,
it's
probably
also
nasty
there.
C
Yeah,
it's
not
so
bad
here.
I
guess
it
was
one
monday
night
tuesday
we
got
maybe
six
or
eight
inches
of
snow.
It's
been
low,
20s,
but
pretty
clear.
Since
then,.
A
A
Yeah,
you
guys
are
a
lot
closer
together
than
I
am
over
here
on
the
west
coast
in
portland
oregon.
So.
A
Pretty
bad,
I
think
you
guys
probably
had
like
technically
more
severe
weather
than
us,
but
our
infrastructure
for
dealing
with
that
kind
of
stuff
is
non-existent.
So
it's
been
pretty
bad.
There's
been
some
really
big,
severe
power,
outages
yeah!
It's
not
great!
I
think.
A
A
Yeah
no
portland
oregon
so
rich
and
I
are
up
here
yeah.
E
Rich,
did
you
lose
power
at
all?
I
did
not,
which
is
really
weird.
We
had
to
evacuate
my
mom
out
of
her
house
removed
refrigerators.
It's
been
pretty
crazy,
although
one
of
my
co-workers,
she
lives
in
texas
and
she
she's
getting
more
snow
this
morning,
yeah
we
are,
she
showed
a
picture
of
this
line
of
people
that
went
off
onto
the
horizon.
It
was
evidently
the
line
to
the
grocery
store
yeah,
which
you
couldn't
see.
D
Also,
like
most
of
texas,
doesn't
have
any
kind
of
snow
plows
or
maybe
like
one
or
two
salt
trucks.
So,
and
we
have
a
lot
of
like
bridges
like.
Apparently
we
decided
that
building
up
in
the
air
was
a
good
way
to
get
everything
out
of
the
way.
D
So
it's
it's
a
real
bad
mess
to
get
anywhere
by
car
like
I
was
lucky
and
prepared
for
this
right,
I'm
like
oh
bad
weather
for
a
couple
days
in
a
row.
Let's
get
some
groceries.
Let's
you
know
put
some.
F
D
Out
right,
but
half
of
my
neighborhood
hasn't
had
power
for
three
days:
water
outages
all
across
the
city,
gas,
outages,
power,
outages,
it's
it's
bad!
It's
like!
Oh,
almost
like
mad
max
type.
It
feels
like.
A
Yeah,
that's
definitely
how
it
feels
sometimes
going
through
portland,
but
I
think
it's
just
insult
to
injury
at
this
point
for
how
tough
things
have
been,
but
yeah
right
well,
yeah.
Sorry
to
hear
that
I'm
glad
you're
able
to
make
it
though
yeah
definitely
definitely
some
tough.
D
Stuff,
I
mean
on
a
good
note
like
since
we've
had
power
since
we've
had
you
know
heat
and
whatnot
we've
been
inviting
neighbors
over
to
come,
you
know
charge
their
phones
warm
up.
A
Yeah,
that's
really
kind
of
you.
Yeah
yeah
well
cool
a
little
bit
of
a
sad
note
to
bring
off
the
meeting,
but
we
can
kind
of
jump
into
it
here.
Let's
see,
I
can
start
sharing
my
screen
thanks
everyone
for
joining,
as
always,
please
be
sure
to
add
yourself
to
the
attendees
list,
and
if
you
have
any
agenda
item
topics,
please
add
them
in
we
met
on
tuesday
wow.
A
It's
been
a
long
week
to
talk
a
little
bit
about
the
triaging
of
our
rc
and
our
milestone
to
try
to
prioritize
things
and
get
some
momentum
going
thanks
again
to
everyone
who
showed
up
for
that
punya
and
anthony.
I
definitely
value
a
lot
of
that
collaboration,
but
the
goal
here.
A
I
think
we
wanted
to
start
off
the
meeting
with
about
30
minutes
of
continuing
that
work,
it
wasn't
actually
finished
the
the
goal
here
is
to
continue
through
the
rc
and
the
milestone
itself
and
make
sure
that
we
have
any
sort
of
pruning.
We
need
to
do
and
then
try
to
get
issues
assigned
to
people
if
they're.
Actually,
this
is
probably
a
really
great
forum,
so
if
anyone's
interested
to
get
some
issues
assigned
to
everyone.
A
Additionally,
thanks
again
for
getting
into
your
and
blocking
my
screen
updating
the
project
board
as
well.
This
is
now
kind
of
more
of
a
I'm
gonna
mess
this
up,
but
I
think
it's
a
kanban-
or
maybe
it's
a-
I
don't
know-
maybe
maybe
there's
some
other
pm
term
here-
for
how
we're
gonna
actually
do
this
so
really
helpful.
It's
definitely
nice
and
pruned
looks
really
good,
really
value
it.
A
I
think
it's
a
really
great
way
to
communicate
to
the
rest
of
the
community,
and
so
I
think
we
can
kind
of
just
stop
and
jump
in
here
to
the
rc
itself.
Go
through
the
the
final
stages
of
this
we're
already
making
some
really
good
progress
system
this
week
alone,
just
to
start
off,
I
think
we
have
like
some
really
good
progress.
There
might
even
be
another
one
added
here.
A
I
just
merged
pr
from
anthony
resolving
one
of
these
issues
so
definitely
making
some
good
progress
definitely
have
a
little
bit
of
place
to
go.
So
we
can
kind
of
just
dive
in
here
and
maybe
after
that,
we
can
talk
a
little
bit
more
about
some
of
the
issues
with
whether
we
want
to
track
this
in
a
milestone
or
in
a
project
is,
I
think,
an
open
question
is
as
well,
but
we
can
contact
that
in
a
second
yeah.
A
So
let
me
just
open
some
things
up
here:
cool
too
many
trace
packages.
This
is
an
open
one.
I
think
that
there's
been
a
lot
of
consensus,
that
this
is
maybe
just
something
that
okay
handling
and
moving
on.
A
I
kind
of
wonder
if
we
should
just
close
this,
I
think,
is
a
good
question.
I'd
love
to
hear
other
people's
opinion
on
that.
C
I
I
think,
other
than
potentially
the
sdk
export
trace
moving
we've
talked
separately,
I
think
about
moving
the
export
trace
and
export
metrics
to
trace
export
and
metrics
export,
but
other
than
that.
I
think
these
are
probably
fine,
they're,
typically
not
going
to
be
used
together
or
if
they
are
they're
they're,
just
in
in
the
the
main
initialization
routine
of
an
application
where
an
operator
uses
them.
F
A
A
All
right,
fine,
yeah
yeah,
I'm
trying
to
think,
might
be
helpful
to
look
at
the
package.
Documentation
actually
metric
plug-in
resource
stats.
That
was
definitely
not
it.
I
don't
think
so.
I
don't
think
they
had
this
problem
just
because
I
don't
think
they
had
that
that
separation
between
the
api
and
the
sdk
got.
D
A
Yeah,
I
think
that's
where
that's
coming
from.
I
can't
I
mean
I
totally
agree.
I
think
that
this
is
the
one
that
kind
of
like
is
mucking
it
up
a
little
bit.
These
two
things
have
really
good
package
demarcations
and
you're
like
anthony
just
kind
of
pointed
out,
like
there's
a
really.
You
know
only
in
the
one
case
where
you're,
like
kind
of
just
building
a
really
simple
ad
hoc
instrumentation,
like
example,
you're
gonna,
have
both
these
packages
imported.
A
Otherwise,
it's
not
a
big
deal
and,
as
it's
kind
of
pointed
out,
like
that's
kind
of
what
import
names
are
there
for
to
try
to
make
this
demarcation
there.
So
I
don't
know
if
it's
that
really
that
big
of
an
issue
it
was
made
of
p1
just
because
if
we
do
want
to
actually
make
this
change
like
we
need
to
make
this
change,
but
I
think
we
could
probably
close
this
yeah
all
the
from
the
interest
of
moving
on.
I'm
gonna
sign
this
to
me
and
then.
E
F
I
think
that's
true,
but
I
feel
like
tracing
initialization
is
somehow
worse
than
all
the
other
flavors
that
I've
seen
because
of
the
cross
cuts.
Anyways,
sorry
kind
of
off
topic.
A
No,
that's
fine.
I
agree
same
thing.
I
was
looking
at
this
issue
yesterday.
I
actually
don't
know
what
to
do
here,
because
I
saw
when
you
commented
on
this
week.
I'm
not
exactly
sure
I
understand
the
content
of
this
issue.
A
Feel,
like
somebody,
I
think
somebody
needs
to
just
kind
of
like
dig
into
this
one.
I
do
think
that
we
do
need
to
get
the
context
propagation
correct
for
ga.
This
is
definitely
also
related.
There's
a
link
issue
here.
This
is
why
puny
was
asking
about
the
resolution
between
labels
and
attributes,
because
ghana
created
this
other
related
issue,
which
is
closed,
but
it's
superseded
by
another
issue,
so
it
actually
is
resolved
in
a
later
issue.
Wow.
This
is,
I
don't
remember,
reading
that
many
comments,
but
yeah.
A
I
think
this
is
the
one
that
is
actually
dealing
with
that
resolution
yeah.
I
think
that
we
need
to
just
have
some
somebody
take
a
look
at
this
and
kind
of
dig
further
into
that.
I
don't
know
if
there's
anybody
out
there
who's
interested
in
doing
that,
I
can.
I
can
put
my
name
in
the
in
the
hat
if
nobody
else
is
interested,
so
I'm
still
not
sure
which
context
key
she's.
Referring
to
here,
I
that's.
A
I
agree
and
I
think,
if
that's
kind
of
what
is
needed
here,
because
I'm
not
exactly
sure
what
is
the
problem,
so
we
probably
need
to
just
dig
into
it.
I
was
thinking.
F
I'm
gonna
I'm
gonna
tag
her
maybe
just
tag
her
in
the
comment
and
say:
could
you
expand
a
little
bit
more
we'd
like
to
work
on
this,
but
we're
not
sure
I
mean
I
can.
I
can
ping
her
on
slack
and,
like
I
don't
know,
five
bajillion
github
emails,
so
I'll
ping
her
on
slack,
so
she
only
gets
two
kajillion.
C
Yeah
so
like
I'm,
not
sure
if
this
relates
to
the
context
keys
for
remote
spans
versus
local
spans,
which
I
think
is
also
kind
of
related
to
the
span
context
issue,
I
was
looking
into
where
we've
kind
of
drifted
from
the
spec
there.
I
think
that
expects
the
span
context
to
know
whether
it's
remote
or
local,
whereas
we
store
that
in
the
go
context,
we
store
s-band
context
in
a
different
location,
depending
on
whether
it
was
remote
or
local.
C
G
A
Might
be
related,
but
I
don't
know
so
as
for
assignees,
our
goal
here
was
to
try
to
have
all
these
assigned.
Is
there
anyone?
I
didn't
hear
anyone,
so
maybe
I
should
just
oh.
A
All
right
cool:
we
have
each
protocol
support
for
otlp
yeah.
Maybe
you
won't
take
this
next
one
this
one
I
thought
had.
Oh
okay,.
F
F
A
A
C
Yeah-
and
I
was
just
looking
at
the
same
protocol-
exporter
spec-
that
puny
just
linked-
and
I
don't
see
anywhere
where
it
says
what
protocols
must
be
supported.
A
F
This
go
ahead.
I
can
be
assigned
to
it
with
a
with
a
with
a
bias
towards
trying
to
differ.
F
A
Yeah,
I
think,
okay,
if
that's
the
case
punya,
if
you
do
find
out
that
it
like
is
needed
or
deferred,
then
you
can
categorize
it
and
then,
if
you
want
aaron,
you
can
pick
it
up
afterwards
and
like
having
it
assigned.
Doesn't
you
know
we.
A
This
is
a
monster.
This
is
something
I
was
hoping
to
have
krezmir
start
on.
This
is
something
I
need
to
get
assigned
to
I'm
getting
a
lot
of
things
assigned
to
me,
but
I
think
if
this
is
something
that
I
kind
of
had
a
passion
for
the
idea
is,
is
that
our
all
over
our
apis
and
sdks?
We
we
tried
to
unify
in
a
single
configuration
style.
A
In
fact,
we
actually
captured
it
in
this
developing
or
contributing
style
guide,
and
I
think
it's
just
going
through
and
making
sure
that
we
actually
unify
on
this,
I
think,
is
really
critical.
A
No
and
I
I
looked
into
building
that
it
becomes
really
hard
yeah.
I
know
I
thought
about
that
exact
same
thing.
I
was
like
this
is
a
really
good
idea
for
doing
something
like
that,
but
yeah.
It
becomes
really
hard
when
you
have
like
these,
it's
based
on
like
the
type
and
so
then
how
you
actually
want
to.
F
A
That
up
as
the
option
was
like
just
the
hard
part
I
couldn't
quite
figure
out.
I
imagine
if
I
was
like
dave
cheney
I'd
be
like
yeah
there's
no
way.
I'm
writing
all
this
stuff.
I'll
just
do
a
stringer,
but
I
couldn't
quite
figure
it
out.
Yeah,
fair.
A
A
Yeah,
I
think
that
the
my
favorite
was
when
I
first
came
onto
the
project
in
in
2019.
The
inception
was
in
2018
and
they
said
that
they
were
going
to
be
releasing
by
the
fall,
but
they
didn't
give
a
year.
So
it's
been
perpetually
correct,
yeah.
A
They
worked
for
pearl
six,
they
released
on
christmas,
yeah.
Okay,
I
think
this
just
looks
like
it
needs
to
get
resolved.
Is
there
any
takers
on
somebody
going
in
here?
I
don't
I
don't
know
the
current
state.
It
would
just
need
somebody
to
kind
of
like
dig
through
the
history
and
yeah.
A
Cool
yeah
here
we
go.
A
This
is
waiting
on
yeah,
so
it
looks
like
I
have
failed
to
review
something
I
can.
I
can
take
this
sort
of
all
I
feel
like.
I
owe
this
one
to
kasmir
to
try
to
get
it
over
the
finish
line.
He
did
a
lot
of
really
good
work
and
just
had
to
dump
it
at
the
end,
but
yeah.
I
think
that
this
is
something
I
can
I
could
take
cool.
I
think
that
means
that
this
has
everything
assigned
awesome
cool.
A
The
next
thing
was
the
contrib
repo
I
just
went
through
this
morning
and
pruned
a
bunch
of
issues
out
of
this
milestone
and
removed
them
from
the
project
as
well,
because
they
dealt
with
a
lot
of
instrumentation
and
or
metrics,
and
I
think
that
they're
really
cool
and
really
nice
issues
just
that
they're
not
needed
for
a
1.0
of
trace.
So
I
pulled
everything
out.
A
This
is
kind
of
what
I
came
up
with
as
like
the
remaining
things
that
actually
need
to
get
resolved
hotel
memcache,
just
because
this
is
misusing
this
is
actually
just
a
misuse
of
our
status
message.
So
I
think
this
can
get
resolved
eddie
j.
I
think
has
been
on
this
for
a
little
while,
so
it
may
need
some
help
getting
over
the
finish
line.
Yeah
there's,
there's
a
okay,
so
I'm
guessing
this
just
hasn't
been
reviewed.
A
A
A
Cool
awesome,
I
appreciate
it
thanks
anthony
and
then,
when
should
instrumentation
library
set
a
service
name
attribute?
This
is
a
pretty
important
one,
because
we
need
to
have
clear,
like
communication
on
this,
going
forward
for
instrumentation
going
out
of
the
ga
as
to
like
how
that's
actually
gonna
relate
to
the
tracer.
I
think
that
this
just
needs
somebody
with
experience
and
domain
knowledge
in
the
hotel
project
to
respond
to
it.
Anthony
looks
like
you're
responding
here.
Maybe
you
can.
Let
me
know
if
this
is
actually
good
to
go.
G
Point
so
yeah.
This
is
the
fact
that
I
think
currently
we
have
specific
apis
to
set
the
service
name
for
these
exporters
right
and
apparently
the
spec
now
says
you
should
take
it
only
from
the
resource
service,
dot
name
and
not
take
it,
but
it
doesn't
say
it
should
not
take
an
option
to
set
it,
but
it
says
you
should
take
it
from
the
from
the
service.
Now
I
think
shuttle
must.
I
can't
remember.
A
Yeah,
I
okay,
I'm
with
you
now
that's
a
really
good
point.
Actually.
G
G
Well,
if
you
go
to
no
resource
and
then
I
think
it's
you
know,
it
must
be
under
trace.
I
think
on
the
trace,
trace
and
then
sdk
exporters.
Oh.
C
Must
be
populated,
yes,
jaeger
absolutely
depends
on
service
name
being
populated.
It
will
not
accept
traces
if
that's
missing
and
certain
as
well.
I
understand-
and
it
does
seem
kind
of
weird,
that
the
instrumentation
would
provide
it
rather
than
the
application,
because
I
think
that's
intended
to
be
an
application
level
service
name,
so
it
would
make
much
more
sense
to
have
it
come
out
of
the
resource.
C
A
If
you
remember
correctly,
a
lot
of
the
service
name
is
passed
on
instantiation
of
the
exporter
so,
like
I
think
the
instrumenter
could
get
around
not
having
it
but
you're
right
like
ideally,
it
came
from
the
instrument.
I
think
I
think
I've
seen
this
resolved
in
a
few
different
places.
Rich
may
be
able
to
correct
me.
I
knew
relic.
A
I
think
we
did
this
as
well,
where
like
it's,
if
it's
in
the
resource
that
takes
precedence
and
then
if
the
exporter
has
a
concept
that
will
be
a
secondary
backup
or
something
like
that
with
maybe
like
a
sync
defaults,
I
can't
quite
remember
I
will
have
to
double
check
that.
G
A
G
If
you
don't
have
anything
set,
it
should
populate
the
default
resource,
but
I
don't
think
it.
It
won't
currently
do
anything
to
send
it
over
to
canola
jagers.
None
of
that
code
has
changed
here,
for
example,.
A
A
Awesome,
I
think
that
I
think
we're
close
on
this
one.
I
appreciate
help
cool.
We
have
six
minutes
left
in
the
time
box
gone
through
all
of
the
rc's,
I'm
not
seeing
puny,
jumping
up
and
down
with
excitement
yet,
but
you
know
yeah
there
you
go,
there's
an
excitement.
B
A
A
Number
five
yeah
number:
five,
it's
a
good
one
yeah!
I
I'm
not
kind
of
in
the
camp
of
saying
like.
I
don't
think
anybody
on
this
call
should
be
focusing
effort
on
this.
Obviously,
some
of
you
are
paid
by
employers
that
they
want
you
to
be
focusing
effort
on
this.
This
is
a
really
big
hairy
issue.
I
know
that
my
employer
also
wants
this
issue
resolved.
A
F
A
I
don't
think
it
should
be
included
in
the
rc.
I
do
think
that
like
if
you
know
we
talk
about
prioritization
of
instrumentation
after
the
rc
like
this
would
be
high
on
the
list,
if
not
the
highest.
So
I
know
that
helps
steve
yeah.
C
Yeah,
I
think,
for
contrib.
We
should
be
focused
on
intrigue
that
we
keep
it
up
to
date,
with
whatever
we've
changed
in
the
main,
repo
and
fixing
bugs.
C
B
A
Yeah,
that
was,
I
think,
my
bad.
I
don't
think
I
communicated
as
as
needed
for
the
getting
reviews
of
that
vr17
release
out,
but
yeah.
I
think
that's
just
something.
That's
naturally
gonna
happen
based
on
the
fact
that
there's
two
repositories,
we
should
try
to
do
a
better
job.
I
think
in
the
future,
keeping
those
tighter
and
closer
together.
C
B
F
Yeah
also,
unfortunately,
until
everything
is
1.0,
we
will
continue
to
have
bc
breaks
in
metrics
and
wherever
else.
So
I
have
a
question
I
think
at
the
bottom
of
the
agenda,
for
how
we
can
try
to
speed
up
the
feedback
loop
on
that.
But
I
think
bottom
of
the
agenda
is
the
right
place
for
it.
A
Okay,
yeah
yeah.
This
is
another
good
question.
I
was
just
kind
of
like
hinting
and
flirting
with
as
well
before
the
meeting,
but
we
can
kind
of.
I
think
the
rest
of
this
should
be
somewhat
straightforward.
This
is
an
issue
that
was
questions
on
tuesday.
Should
we
clear
reviews
for
additional
commits
come
into
a
pr?
So
if
you
review
something
and
then
something
else
is
committed
to
the
pr,
does
that
like
clear
your
review?
A
I
think
this
makes
a
lot
of
sense,
because
if
you
review
something
and
then
somebody
after
the
fact
pushes
something
that
you
don't
actually
approve
of,
like
your
approval,
might
need
to
actually
be
removed.
But
I
did
remember
that
this
also
includes
merging
in
master
so
like,
if
somebody
had
to
update
the
branch
back
up
to
master.
All
of
the
previous
reviews
are
also
then
cleared,
and
everything
has
to
be
re-reviewed,
which
is
not
really
ideal,
especially
for
non-substantive
like
changes,
it
seems.
Maybe
maybe
we
shouldn't
do
that.
A
We
could
also
try
to
be
a
little
more
proactive
in
if
you
do
make
some
substantive
changes
to
your
pr.
Just
to
clear
the
reviews
manually
was
kind
of
my
thought
on
that
one
or
have
maintainers
or
recruiters
clear
their
reviews
directly.
C
For
us,
but
if
that's
going
to
cause
problems,
then
let's
try
doing
it
manually.
F
I
agree
with
that
and
I'd
also
add
in
a
there
are
other
other
projects
where
the
norm
is.
Once
you
have
all
the
approvals
you
need,
then
things
get
merged
automatically
in
that
world.
I
would
support
this
kind
of
thing
in
our
world
where
we
have
a
maintainer.
F
I
think
it
as
a
way
to
keep
our
velocity.
I
would
I
would
advocate
for
approvers
saying
I
approve
like
in
a
comment
I
approve
and
you
don't
need
to
get
another
approval
or
I
approve,
but
dear
maintainer,
don't
accept
this
if
there's
any
edits
afterwards.
So
I
think
that
pushes
the
burden
a
little
bit
to
maintainers,
which
is
fine,
it
still
to
me,
it
seems
crisp
and
clear
what
an
approver
intends
from
for
out
of
their
approval
right,
like
as
a
maintainer.
C
It
yeah-
and
I
know
occasionally
as
well-
I
do
something
like
I'll
approve,
make
a
comment
with
a
suggestion
for
a
minor
change,
hoping
that
that
will
be
made,
but
I
would
take
it
with
or
without,
and
I
would
kind
of
hate
for
that
change
being
accepted
than
to
cause
me
to
have
to
come
back
and
approve
again.
So.
D
So
in
that
world,
what's
the
default
like
if
somebody
just
says
I
approve,
does
it
default
to
the
I
approve
at
this
point
and
anything
beyond
that
or.
A
That's
a
good
question.
I
definitely
like
in
the
same
thing
as
like
kind
of
what
anthony's
saying
like
when
I
approve
sometimes
I'll,
also
like
make
suggestions
for
changes
and
if
I've
approved
and
made
suggestions,
if
you
don't
accept
those
changes,
and
you
still
want
to
merge
it,
like
that's
fine
by
me,
you
know,
or
or
if
they're,
the
minor
changes
that
are
included
because
of
the
suggestions,
that's
also
fine
by
me
just
to
keep
going.
I
I
think
this
is
something
this
is
a
really
hard
question.
A
It's
been
pretty
easy
up
to
now,
because
I
think
that
I've
kind
of
had
like
a
perception
of
like
who
the
people
are
behind
the
reviews,
and
so
I'm
kind
of
like
I.
I
don't
think
that
anthony
would
be
okay
with
like
accepting
this
after
things
changed
so
dramatically
versus,
like
you
know,
josh
I'm,
like
oh
he'd,
be
fine
like
he
just
wants
us
to
merge,
like
he's
really
like
he's
avoid
the
fact
that
she's
merged
you
know,
and
so
like.
A
I,
I
think
that
there's
a
little
bit
of
a
hand
holding
there,
but
that's
not
gonna
scale.
You
know
as
this
project
grows,
or
you
know
more
people
just
start
to
get
involved
in
the
project.
So
I
think
that's
a
really
good
point
and
we
should
definitely
try
to
document
whatever
this
decision
is.
A
I
think
that
by
default
like
if
you're,
making
substantive
changes
or
the
the
pr
takes
a
different
direction,
just
review
should
be
cleared
and
I
think
we
should
just
document
that
as
the
default
unless,
like
the
approver
has
said
something
specific
like
I
I
I
like
this
like
just
keep
going
and
I
prove
indefinitely
or
something
like
that.
C
F
C
F
Yeah
right
sorry
steve,
I
don't
know
if
some
people
rebase
maine
instead
of
merging
main
even
during
the
pr-
and
I
think
that
could
be
that
could
potentially
cause
confusion
for.
C
This
that
may
be
something
we
want
to
put
in
the
contributing
doc.
Then,
if
we
don't
already
address
it,
there.
A
Yeah,
I
I
think,
if
that's
I've
added
an
action
item
here,
but
that
needs
to
get
done,
I'm
gonna
at
least
open
an
issue
for
it
after
this
meeting.
I
think
this
is
a
good
idea.
A
Talk
about
next
yeah
right,
let's
I
want
to
keep
this
moving
exactly.
Should
we
switch
to
slack
for
official
communication
channel,
I
see
a
lot
of
funds
up
already
yeah.
I
don't
really
see
a
reason
why
we
should
stick
with
gitter.
A
lot
of
people
are
already
communicating
over
in
the
slack
channel
that
we
have
created
in
case
people
are
not
aware
of.
What's
going
on
yeah.
A
The
idea
is
that
since
we
have
the
one
over,
the
specification,
slack
is
not
available
for
the
cncf
and
so
like
it's
kind
of
just
supported
at
that
point.
So
we've
moved
over
to
the
hotel
dash
go
channel
in
the
cncf.
A
Workspace
so
yeah.
I
think
that
I
don't
know
it
seems
like
we
should
just
move
when
he's
already
moved
this
over.
I
I
would
support
this
change.
I
haven't
even
looked
at
the
differences
here,
but
this
is
one
of
those
ones
where
I'd
approve
and
definitely
improve,
so
I'm
in
favor.
I
see
a
lot
of
hands
going
up.
Let's
do
that.
I
think
we
need
to
communicate
it
correctly.
A
I
think,
if
that's
the
only
thing
make
sure
that,
like
the
there's,
a
lot
of
documentation
out
there
that
points
together
but
we'll
just
have
to
go
through
and
make
sure
that
we
clean
it
all
up.
I
think
it's.
The
idea.
B
I
had
held
off
on
a
cncf
slack
member
enrolling
there,
but
I'll
take
care
of
it.
Wait
you
didn't
go
to
kubecon.
No,
I
mean
I,
I
have
plenty,
but
oh
you
mean
this
here.
C
Yeah,
so
this
is
something
that
I
noticed
while
looking
at
the
trace
flags
issue,
that's
assigned
to
me,
and
it
seems
that
the
the
spec
expects
the
span
context
type
to
be
immutable
and
ours
is
not,
as
it
has
exported
fields,
so
anybody
can
reach
in
and
change
the
trace
id
span
id
or
any
of
these
fields.
C
So
I
I
expect
we
have
to
address
this
right.
The
question
probably,
then,
is
how
I
think
all
of
these
accessors
are
probably
fine
to
leave
as
is
do
we
then
create
a
new
constructor
that
expects
all
of
these
values
to
be
provided
initially,
and
that's
the
only
way
to
set
values
in
one
or
do
we
provide
the
ability
to
much
like
a
go
context.
C
Add
in
a
value
that
then
returns.
You
know
copies
and
and
makes
a
new
span
context
that
it
returns
to
you.
A
Yeah,
that's
a
good
question,
I
kind
of
just
assumed
and
maybe
incorrectly
so
that,
since
the
span
context
is
never
actually
referenced
as
a
reference,
it's
it's
a
just
a
struct
value
itself.
A
The
idea
is,
is
that
you
can
change
the
value
all
you
want,
but
like
it's
not
going
to
change,
the
upstream
span
context
values
that
were
handed
to
you.
So
things
like
this
method.
Here,
I
think,
is
what
I've
just
kind
of
assumed
that
you
would
get
a
copy
of
the
stand
context
whether
you
actually
do.
I
don't
know,
if
that's
the
case,
and
I
think,
if
that's
kind
of
skirting
around
the
line
of
immutability,
I
don't
know
that's
just
my
thoughts.
C
That's
true,
it's
definitely
true
all
right,
so
I
I
will
create
an
issue
and
outline
some
potential
apis
for
having
a
fully
immutable
span
context
and
try
to
see
if
there's
any
gotchas
hanging
out,
but
I
yeah-
I
just
noticed
this
last
night,
so
I
thought
it
was
maybe
something
we
could
discuss
here
in
case.
Anybody
has
any
ideas
about
how
it
should
be
handled.
C
That's
kind
of
my
first
thought
as
well:
an
interface
for
just
retrieving
the
values.
F
F
A
Yeah,
I
I
think
we
could
do
that.
Switching
this
to
an
interface,
you
could
have
a
constructor
where
this
you
know
in
the
news
world
like
this
span
context
is
not
exported,
but
the
constructor
will
return
like
a
an
exported
interface
type
that
just
has
accessors
to
that
and
the
unexplored
type.
You
know
you
could
handle
the
fields
that
way.
That
being
said,
like,
we
also
have
like
been
critiqued
on
the
fact
that
we've
had
way
too
many
interfaces.
A
So
I'd
love
to
see
if,
like
some
different
proposals
here
and
kind
of
go
through
the
ideas,
I
imagine
anthony
digging
into
this
you'll
have
some
good
context
about
your
design.
Choice
on
this.
C
Yeah
yeah,
I
think,
keeping
the
the
concrete
type
and
on
exporting
the
fields
is
probably
the
way
I
would
recommend
going,
but
I'm
I'll
need
to
spend
some
time
thinking
about
how
that's
going
to
change,
how
propagators
interact
with
it,
and
things
like
that.
I
think
those
are
the
primary
places
where
mutation
of
the
span
context
happens.
The
place
at
which
it's
constructed.
D
A
Okay
yeah,
I
I
like
the
idea
of
keeping
it
as
a
struct
as
well
in
some
ways,
because
the
interface
is
extremely
static,
as
going
forward
like
adding
to
an
interface
is
just
not
something
you
can
do
well
unless
we
put
some
guards
in
there
but
yeah
for
just
the
long
term
maintainability,
but
I
think
we're
on
the
same
page,
I'm
looking
forward
to
the
proposal.
A
I
think
that
also
like
you're
correct,
it
probably
should
get
added
as
something
we
need
to
address
prior
to
the
release
so
yeah,
something
we
should
get
done.
Hopefully
in
the
next
week
or
two
cool
moving.
C
On
anthony
you're,
the
next
yeah,
the
next
one,
so
someone
someone
opened
an
issue
this
morning
where
they
had
tried
to
update
a
project
and
thrift
has
released
a
new
miner
version
that
has
bc
breaking
changes
because
they're
also
pre
1.0.
So
we
we
specify
thrift
0.13
but
go
hopefully
says
hey.
This
is
just
a
minor
version
change.
I
can
go
ahead
and
bump
this
up
to
the
next
minor
version
without
paying
attention
to
the
fact
that
v0
offers
no
stability
guarantees.
A
Right,
I
feel,
like
thrift
is
a
pretty
important
requirement
for
that
jager
exporter.
That's
a
good
question.
C
F
To
explode,
so
people
may
hate
this,
but
could
be
vendor
thrift.
F
Like
is
there
any
reason
why
people
would
need
to
use
vendored
this
vendor
thing,
like
the
reason
why
you
wouldn't
want
to
render
things
is
that
people
want
to
do
type
assertions
across
the
vendored
and
unvended
types.
Is
that
ever
important
for
us.
C
I
don't
think
so.
I
I
think
in
fact
it's
only
referenced
in
this
internal
yeah
generated
package,
so
it's
probably
safe
to
generate
this
package
and
vendor
the
the
version
of
thrift
that
it
was
generated
with
that
need
to
go
through
the
generated
package
and
rename
all
of
the
imports
on
it.
But
that
can
be
obviously.
F
C
F
C
C
Okay
yeah,
then,
then
we
could
vendor
it
in
the
jaeger
exporter
yeah,
I'm
fine
with
that.
F
Can
take
that
if,
if
no
one
else
is
excited
about
learning
about
rendering.
C
A
C
E
A
Yeah
I
mean
I
think
that
that
sounds
reasonable,
especially
if
so,
if
you're
vendoring
it
right
like
even
in
that
upgrade,
it
shouldn't
be
too
much
of
a
problem
if
you're
trying
to
pull
in
some
security
patches,
because
nothing
could
really
be
depending
on
it
anyways,
because
we
that's
right
for
priority
here.
What
would
you
do
you
think
this
is
something
we
should
try
to
get
done
for
the
ga,
because
it's
going
to
be
breaking
what
we're,
depending
on.
C
A
C
F
Think
so,
okay,
by
the
way
that
that
means
that
we
were
planning
to
make
the
exporter
have
a
1.0
version.
A
I
don't,
I
think,
I
think
it
is
required
by
the
project
or
by
the
specification
as
something
that's
a
part
of
their
one-on-one.
A
F
C
A
The
thing
is,
though,
I
think
this
might
also
include
things
that
are
not
necessarily
included
in
the
right,
but
that
first
column
should
indicate
whether
it's
optional
or
not.
Oh,
okay,
yep.
What
do
you
remember?
What
x
versus
star
means.
C
Okay,
well
I
oh
okay,
okay,
so
we
have
to
have
one
of
them,
I
mean
so
we
could
say
we're
doing
protobuf
over
grpc
and
toss
thrift
entirely,
but
we've
got
a
working
implementation
and
we
think
we
have
a
way
to
get
to
reasonable
stability.
So
yeah,
okay,
let's
see
yes,
okay,.
A
Yeah
cool
all
right,
I
think
this
is
all
set.
Then
I
think
this
is
also
okay.
A
Thanks
for
bringing
that
up,
anthony
yeah
turns
out
important
issue,
and
I
think
this.
G
Is
your
next
one
yeah?
I
was
just
seeking
clarification
here
as
to
who
is
responsible
or
what
the
process
is
for
in
cases
where
the
specification
has
changed,
since
somebody
wrote
code
that
we're
actually
going
back
and
validating
that
we
still
meet
the
spec
and
when
it's
changed
the
reason
I've
noticed
this
is
that
I
follow
the
java
one
as
well,
and
I
see
lots
of
things
going
through
there
that
I
realize.
Oh,
we
haven't
done
that
in
the
go
one
yeah.
C
G
C
Think
that's
like
the
the
second
step
of
what
we
need
to
do.
We've
gone
through
the
first
step
here,
which
is
going
through
all
the
things
we
know
we
still
have
outstanding
and
getting
those
prioritized
and
assigned
the
next
step
is
we
also
need
to
go
through
and
figure
out.
What
have
we
missed?
What's
changed
in
the
specs
since
we've
implemented
some
of
these
things?
Where
have
we
deviated
like
the
the
span
context
being
immutable?
C
Perhaps
when
that
was
implemented,
it
wasn't
specified
as
immutable
and
now
it's
changed
and
we
need
to
deal
with
that.
So
yeah,
I
think,
having
one
or
more
people
go
through
that
spec
compliance
matrix,
probably
is
the
place
to
start
going
through
that
and
saying:
okay,
let's
take
a.
F
F
That
makes
sense.
I
have
a
because
somewhat
somewhat
pipe
dream
idea.
I
don't
know
how
I
don't
know
if
we
could
get
there,
but
writing
a
conformance
test
for
the
spec.
Obviously,
that's
not
a
thing.
You
can
write
in
a
cross-language
fashion
right,
but
if
you
can
write
like
imagine
a
cucumber
test
where
you're
saying
given
blah
blah
blah
english
prose,
then
blah
blah
blah
english
prose
and
this
cucumber
spec
gets
an
implementation
in
every
language
that
you
know
you
you
really
can
say
in
in
unambiguous
terms.
You've
met
it.
C
E
We
have
something
about
that
new
relic.
It's
a
series
of
json
files
that
describe
behaviors
and
output,
and
every
agent
team
implements
some
sort
of
subset
of
that.
But
even
within
that,
there's
a
subset
of
what
you
really
can't
contain
in
a
programmatic
sort
of
test
for
spec
compliance.
So
it'll
always
be
a
subset,
but
it
is
extremely
useful
and
it
does
catch
problems.
F
And
even
knowing
what
the
sub,
knowing
what
the
hard
to
capture
subset
is,
helps
to
focus
discussion
right
because,
right
now
we
don't
know
we
could
be
things
like
immutability.
Are
you
know?
Yes,
it's
hard
to
it's
hard
to
verify
a
negative.
The
following
code
does
not
compile.
Okay,
that's
that's
silly,
but
other
things
could
be
written.
A
Yeah,
I
think,
if
that's
a
really
good
point,
I
think
anthony
was
also
hinting
that
there's
this
idea
of
an
end-to-end
test
that
was
going
to
be
generic.
That
was
proposed
for
the
release.
I
think
ted
was
working
on
that
with
venue
from
new
relic
as
well
at
some
point,
but
it
kind
of
just
fell
flat.
If
I
remember
correctly,
I
think
you
also
brought
up
in
tuesday's
spec
meeting
as
to
like.
A
What's
the
you
know
currently
right
now,
it's
kind
of
like
a
pull
model
where
maintainers
and
other
specifications
like
cigs
or
our
language
zigs
have
to
kind
of
like
understand.
What's
going
on
the
spec,
but
like
is
there
any
chance
to
switch
like
a
push
model
is
also
kind
of
another
question
for
both
release.
Timing,
as
well
as,
like
you
know,
change
it
to
the
spec
yeah.
F
F
Okay,
yeah,
so
so
that's
not
necessarily
saying
the
press.
Release
will
say,
go
is
fully
compliant,
it
might
say:
okay,
go
doesn't
want
to
be
in
the
press
release
or
it
might
be.
There
will
be
a
release
timed
with
the
spec
release.
That
has
these
things
for
go
right
and
it's
up
to
us
as
go
to
decide
like
it's
just
committing
ahead
of
time
and
then
meeting
that
commitment
right
right.
So
yeah,
it's
still
very
much
up
to
us,
but
there
is
a
forcing
function
to
say:
well
we're
going
to
have
a
press
release.
A
Yeah,
okay,
yeah.
I
think
I
misinterpreted
or
misrepresented
your
idea,
but
yeah
thanks
for
clarifying
but
yeah
back
to
evan's
comment.
I
think
that's
these
are.
This
is
really
good
work
to
be
done
in
the
the
interim
there's
a
lot
of
work
that
we've
already
identified,
but
there
still
needs
to
be.
A
I
think,
like
a
an
audit
just
to
go
through
and
make
sure
that
we're
conforming
to
the
specification-
and
I
don't
think
it
necessarily
needs
to
be
a
maintainer
or
even
direct
approvers,
obviously
doesn't
need
to
be
direct
movers
there's
but
like
anyone
on
the
call
is
welcome
if
they
find
incompatibility
with
specification
or
non-compliance
issues
with
specification
open
them,
even
if
they're
not
for
the
1.0
tracing.
You
know
they
can
just
be
prioritized
differently,
but
especially
if
they
are
for
the
1.0
tracing.
A
G
A
A
Yeah,
thank
you
appreciate
it
so
cool.
I
just
wanna
move
on
to
punya's
last
two
items
here.
I
think
it
this
this
one
is
really
important.
I
think
this
also
kind
of
calls
out
like
what
is
our
roadmap
after
this
1.0
release,
or
just
you
know,
rc
release
like
what.
How
are
we
prioritizing
our
time
after
the
fact
I
have
ideas,
and
I
guess
maybe,
with
the
title
of
maintainer,
I
might
have
some-
I
don't
know
responsibility.
A
I
definitely
have
some
responsibility
to
have
ideas,
but
I
don't
think
I
have
the
authority
to
say
definitively
what
the
project
should
do.
I'd
love
to
hear
input
from
all
of
you
and
like
the
group,
what
we
think
our
priorities
should
be
going
forward.
So
I'd
love
to
hear
like
what
your
ideas
are.
A
I
guess
I
can
start
us
off.
I
definitely
know
there's
a
backlog
of
bugs
that
probably
want
to
resolve,
and
I
think
that
was
kind
of
what
I
wanted
to
look
at.
A
I
know
that
the
specification
has
a
priority
to
try
to
get
the
metrics
portion
of
the
api
and
sdk
and
the
data
model
all
resolved
so
that
that
can
be
released
as
a
1.0.
So
I
feel
like
we
should
try
to
remain
in
some
sort
of
lockstep
with
what
they're
trying
to
do.
There,
I
think,
is
a
really
good
priority.
A
Additionally,
there's
a
lot
of
ask
for
instrumentation
and
I
think,
if
you
have
a
1.0
release
of
the
tracing
side
of
things,
the
other
side
of
things
in
the
contrib
and
making
sure
that
we
have
a
valid
instrumentation,
and
maybe
that
is
necessarily
like
those
instrumentation
packages.
I
think
we
kind
of
talked
about
this
are
split
from
the
versioning,
so
they
may
need
to
be
like
prioritized
as
some
sort
of
release
candidates
there.
Things
like
the
net
http
library
things
like
the
grpc
library.
A
These
sort
of
things
like
those
may
be
next
on
our
agenda
as
top
priorities
to
get
released
as
well,
but
I
don't
know
necessarily
like
what
the
community
itself
is
particularly
looking
for.
A
Yep
yeah,
so,
oh
okay,
so
I
just
kind
of
assumed
the
one
I
know
you're
talking
about
like
we
have
gone
through
our
release
candidate
process
but
like
yeah
to
get
into
the
1.0
process.
I
guess
that's.
Another
question
is
so
like
how
long
do
we
let
this
soak
is.
Maybe
the
answer.
A
F
C
Yeah
yeah,
so
I
think
bugs
always
are
on
the
table.
I'm
never
happy
releasing
software
with
known
defects
in
it.
So
if
we
know
about
a
bug,
we
should
fix
it
regardless
when
or
where
and
then
between
rcn
1.0.
I
think
we
should
be
focused
on
things
that
require
backwards
and
compatible
changes
to
address
or
things
that
are
out
of
conformance
with
the
spec
1.0
should
be
we're
comfortable.
Supporting
this.
We
don't
believe
we're
going
to
make
any
backwards.
Incompatible
changes
we're
in
line
with
the
spec
and
we've
addressed
all
known,
defects.
C
After
that,
I
think
the
things
that
tyler
laid
out
are
good
places
to
focus
getting
metrics
going
once
the
spec
starts
to
solidify
around
that
improving
the
instrumentation,
getting
those
all
up
to
a
place
where
we're
comfortable
calling
them
1.0,
which
I
think
a
lot
of
the
instrumentation,
is
already
fairly
close,
but
dealing
with
whatever
has
changed
between
now
and
that
point
we'll
address
those
and
then
looking
at
new
instrumentations,
like
the
the
sql
instrumentation
that
we
mentioned
at
the
top
of
the
hour
right
see
if
we
can
start
expanding
the
scope
of
the
instrumentation.
B
Yeah
one
one
thing
that
came
to
mind:
I
don't
know
if
it
counts
as
significant,
but
there's
an
issue
or
two
about
the
the
sort
of
hairy
initialization
of
the
sdk,
and
when
you
write
that
stuff,
you
wind
up
mentioning
a
whole
bunch
of
types
and
functions
that
I
suppose
that
as
long
as
they're
exposed
right
now,
we
won't
be
able
to
remove
them
in
the
future
like
if
we
wanted
to
wrap
it
up
in
more
succinct,
initialization,
maybe
with
more
options,
you
could
pass
in
how
that
that
kind
of
semantic
compression
that
could
go
on
there.
B
C
That
may
not
be
such
a
bad
thing,
though
I
mean
as
long
as
we
you
know.
If
we
were
to
try
to
do
that
sort
of
compression.
As
long
as
we
make
it
significantly
easier
and
more
attractive
to
use
the
newer
functions,
people
will
drift
towards
them
and
they'll
probably
be
implemented
in
terms
of
the
existing
ones.
Anyways.
B
Yeah,
I'm
not
saying
I
don't
know
of
anything,
I'm
looking
at
the
time
because
I
gotta
drop
very
soon.
I
don't
know
of
anything,
that's
like
some
sort
of
an
abstraction
leak
or
something
that
looks
like
a
mistake
that
it
should
have
never
been
exported.
It's
just
more
about
the
desire
to
reduce
the
surface
area
of
the
the
library
but
I'll
keep
an
eye
on
it,
but
I'm
sorry.
I
have
wrong.
A
Yep
so
cool,
I'm
just
going
to
end
it.
So
yes,
if
you
have
to
take
off
I'm
just
going
to
say
thanks
everyone
for
joining
pune.
I
see
your
final
issue
in
here
I'll,
try
to
respond.
Asynchronously
to
that
and
see
you
all
on
slack,
because
that's
now
our
official
channel
has
decided
here.
If
you
have
any
more
questions,
just
go
ahead
and
raise
them
there
and
we
can
keep
the
discussion
going.
Otherwise
I'll
see
you
all
online
or
next
week
at
the
meeting,
bye.