►
From YouTube: 2020-11-06 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).
A
Yeah
welcome
everyone.
Please
open
up
the
attach
agenda
as
well
and
add
yourself
to
the
attendees
list
and
I'll
wait
to
add
myself.
So
there's
one
less.
I
guess
person
clashing.
I
guess
I'm
directly
contradicting
what
I
just
said
to
do.
A
If
you
have
any
issues
you
wanted
to
talk
about
today,
please
make
sure
you
add
them
to
the
agenda.
Add
them
to
the
bottom,
if
possible,
if
you
think
they're
higher
enough
priority,
adam
higher
up
in
the
list
should
be
pretty
self-evident
and
just
kind
of
start
it
off.
I
can
figure
out
how
to
share
my
screen.
A
Cool
yeah,
we'll
just
kind
of
dive
into
it,
talk
a
little
bit
about
the
high
level
statistics,
at
least
at
the
start,
and
then
hopefully,
maybe
ted
shows
up
or
oh
in
absentia.
So
I
will
cover
that
as
well,
yeah,
so
kind
of
to
start
it
off.
We
usually
take
a
look
at
the
high
level
go
project
board.
A
This
is
a
recap
of
that
board
and
just
to
see
some
sort
of
the
status
of
our
project
going
forward
a
little
bit
of
a
slower
progress
in
the
past
two
weeks,
but
still
progress
going
forward.
Our
to-do
issues,
I
think,
are
rising
faster
than
we
can
resolve
them,
but
we
are
still
making
progress.
A
Going
forward,
probably
touch
on
a
little
bit
more
of
this
going
forward
later
in
the
meeting
kind
of
want
to
talk
a
little
bit
about
some
timing
of
our
release
candidate
in
more
detail,
but
that'll,
be,
I
think,
related
to
strategy
afterwards,
so
yeah
gonna
just
dive
into
what
ted
left
for
us
and
my
understanding
of
it
and
people
who
have
better
understandings
on
the
call
or
understand
that
I'm
making
a
mistake.
A
Please
jump
in
and
correct
me
at
any
time,
but
the
idea
here
is
that
ted
made
this
really
great
doc
on
user
research
for
our
apis,
and
the
idea
is
that
you
should
be
able
to
go
through
this
form
and
just
perform
a
bunch
of
actions
to
validate
the
apis
and
implementation
of
the
open,
telemetry
specification,
the
important
parts,
if
I'm
not
mistaken,
this
is
confined
to
the
tracing
and
the
context
propagation
parts
of
the
specification
alone.
A
One
thing
to
note
is
that
there's
also
been
this
form,
which
you
can
submit
feedback
and
then
should
be
able
to
use
that
to
validate
the
apis
and
get
you
know,
hopefully
some
really
great
user
feedback.
The
idea
is,
we
would
like
to
have
this
sent
out
to
more
than
just
probably
people
on
the
call,
mostly
just
because
people
on
the
call
are
contributing
to
the
project
and
your
your
input
is
very
valid
as
well.
A
The
idea
is,
we
probably
want
more
than
just
this,
but
let
me
pause
because
the
thing
that
also
note
is
that
there's
no
listing
of
go
here,
and
that
was
because
I
explicitly
asked
to
get
that
taken
off
as
we're
going
into
maybe
the
second
part
of
the
agenda,
but
I
think
that
maybe
in
a
week
or
two,
hopefully
we'll
talk
about
that
in
a
second.
This
would
like
some
involvement
on
this
and
to
get
some
feedback
from
other
people.
A
I
think
ted
is
asking
here
to
list
versions,
yep
run
through
the
research.
I
think
the
important
thing
is
to
please
recruit
one
or
two
other
people.
Each
is
probably
something
to
be
asked.
This
might
be
a
little
bit
early
in
the
game
because
I
think
we
kind
of
want
to
get
some
things
to
land
before
we
have
this
evaluation
done.
A
But
if
you
have
the
cycles
and
our
understanding
of
some
of
the
direction
we're
taking
the
api,
then
I
think
this
is
a
great
time
to
start
evaluating
and
asking
people
as
well.
But
I
think
I'm
looking
for
a
bigger
push
of
this
in
a
week
or
two
once
we
have
the
trace
api
move
to
the
trace
package
and
some
of
the
context,
propagation
move
to
the
contact
package
probably
don't
need
the
full
scope
of
the
next
issue
resolved.
A
Cool
that
makes
sense,
I
think,
then,
without
further
ado,
we
can
kind
of
just
jump
into
some
of
the
action
items.
I
kind
of
wanted
to
touch
on
one
of
the
bigger
issues
we
discussed
we've
been
discussing
for
two
months
now,
I
think,
is
api
refactoring,
definitely
something
that
has
been
involving
a
lot
of
our
time
at
a
lot
of
our
discussion.
A
Encapsulation,
I
guess,
is
the
way
I
used
the
word
to
re-encapsulate
portions
of
the
api
and
that
ended
up
ultimately
producing
this
issue
that
I
was
able
to
draft
up.
If
you
haven't
taken
a
look
at
this,
I
would
love
more
eyes
on
it.
We've
already
started
work
on
it,
but,
as
is
you
know,
kind
of
my
mo
better
late
than
never
is
is
totally
fine.
I
would
rather
hear
any
sort
of
comments
or
ideas
that
kind
of
come
to
mind
when
you
do
some
sort
of
revision
of
this.
A
The
goal
here
is
is
just
directly
re-encapsulate
and
achieve
some
of
our
bigger
issues
that
we
kind
of
identified
in
the
last
meeting,
mostly
trying
to
keep
the
usability
at
a
high
level,
so
that
users
should
be
able
to
still
discover
it
not
going
back
into
an
api
package
is
one
of
the
things
that
kind
of
came
out
of
that,
but
at
the
same
time
also
splitting
up
the
the
large
surface
area
that
currently
exists
in
the
hotel.
A
It
was
intended
to
make
it
easier
to
discover,
and
I
think
that
it
is
it's
much
easier
to
see.
It's
also
too
easy
to
see.
That's
extremely
overwhelming,
when
you
take
a
look
at
the
current
hotel
godox
for
a
new
user,
maybe
even
for
a
tenured
user,
it's
a
little
bit
hard
to
to
wade
through.
A
So
I
think,
if
that's
really
good
feedback,
it's
again,
not
really
the
a
little
late
in
the
game,
but
I'd
rather
get
this
right
than
release
something
and
have
a
lot
of
flip-flopping
in
multiple
releases,
and
so
this
is
also
something
that
delayed
our
release
last
week
of
some
other
code
base
and
so
we're
waiting
to
get
some
of
this
stuff
done
before
we
actually
make
a
release
of
the
telemetry
go
project.
A
So
your
eyes
on
that,
and
even
just
a
thumbs
up
or
some
sort
of
emoji
reaction
pick.
Your
favorite
would
be
great
on
this
or
a
comments
you
know
providing
suggestions.
If
it's
definitely
something
really
critical.
I
really
would
love
to
hear
your
feedback
in
this
meeting
or
in
the
issue.
If
it's
some
just
you
know
a
good
idea,
I
really
value
the
diversity
of
this,
this
cig
and
so
like
any
sort
of
ideas
or
don't
feel
limited
to
not
brainstorm
with
this
one.
A
So
I
love
that
kind
of
feedback,
so
I
I
would
encourage
that
if
you,
if
you
have
ideas,
definitely
x-sam
was
able
to
provide
some
some
great
context,
renaming
ideas.
I
don't
think
we're
probably
gonna
hit
them
in
this
issue,
but
I
think
if
these
are
really
good
things
to
maybe
in
a
follow-on
issue
address
so
yeah,
I
I
really
value
all
of
this
stuff.
So
love
love
the
idea
or
I
love
the
feedback
on
that.
A
That
being
said,
kesmir
krezmir,
yeah
jody's
on
the
call
she
can
laugh
at
me
for
mispronouncing
kresna's
name
he's
a
contractor
that
has
already
worked
on
the
project
in
the
past.
He
works
with
kim
voke.
Out
of
I
think,
they're
out
of
eu
and
new
relic
has
hired
them
on
as
a
contractor
to
contribute
to
this
project
plus
a
you
know.
Just
the
progress
of
telemetry
really
tried
to
get
this
over
the
end.
Ga
dates
and
hit
some
targets,
and
so
he's
back
on
the
project.
A
He's
he's
working
on
this
issue
actively
and
he
has
already
opened
up
one
of
the
issues
that
is
going
to
be
the
most
important
as
I've
identified
is
that
the
trace
api,
because
that's
the
thing
we're
trying
to
ga
so
pretty
critical
that
in
the
context
stuff,
so
hopefully
getting
that
moved
in
first.
So
then
we
can
start
that
evaluation
process.
Like
I
said
this
is
all
feeding
back
to
that
original
ask
by
ted.
This
is
a
pretty
critical
one.
A
I
would
love
to
get
some
eyes
on
sooner
rather
than
later,
as
as
we
get
the
rest
of
this
migration
of
the
api,
I
think,
is
it's
still
critical.
It's
still
extremely
blocking,
but
this
one
is
like
a
really
top
priority,
so
I'd
love
to
get
some
eyes
on
sooner
rather
than
later.
If
you
have
cycles,
I'd
really
appreciate
it,
but
it's
also
really
straightforward.
As
again
like,
we
did
a
lot
of
the
work
when
we
moved
it
into
the
hotel
package.
A
Moving
it
back
is
just
forgoing
a
name
change
and
then
re-breaking
up
an
instrumentation
option.
Otherwise,
just
a
big
brain
naming
so
realizing
I'm
doing
a
lot
of
talking
on
this
for
probably
a
pretty
simple
thing,
but
it's
more
just
a
plea
for
some
help
on
this
one,
so
I
would
appreciate
it
yeah
and
speaking
of
talking
a
lot,
I
was
wondering
if
maybe
somebody
else
had
something
they
wanted
to
talk
about
this
or,
if
maybe
they've,
had
any
initial
reactions
that
they
have
taken
a
look
at
it.
D
So
I
haven't
had
a
chance
to
look
at
the
pr
yet,
but
I
have
looked
over
the
comments
on
the
issue
and
it
does
seem
like
a
good
organization
in
line
with
what
we
talked
about
last
week.
D
You
guys
are
working
through
and
it
seems
like
you're
coming
to
the
right
decisions
on
them.
So
I'm
good.
A
Cool,
that's
good
to
hear
yeah
for
contacts
on
some
of
the
naming
things.
Christmas
pointed
out
that
there's
gonna
be
some
naming
conflicts
between
the
number,
the
new
number
package,
which
was
also
something
we
talked
about
last
week
and
the
trace.
I
also
found
some
in
the
baggage.
A
I
think
the
baggage
one
we
could
be
more
comprehensive.
The
number
ones
are
pretty
straightforward.
This
is
pretty
common,
go
idioms
here,
so
we're
probably
just
going
to
drop
another
kind.
The
tracing
one
is
the
choice
id,
and
this
is
something
that
has.
I
know
in
the
past
been
extremely
controversial
and
differing
opinions
on
this
one.
I
would
like
to
just
get
this
moved.
A
I
think
this
is
kind
of
what
anthony's
kind
of
saying
is
like
if
we
can
get
this
movement,
there's
really
strong
opinions
that
we
want
to
remove
the
trace
from
the
trace
id.
I'm
happy
to
have
that
conversation,
because
it's
it's
going
to
be
an
api
breaking
change,
but
I
think
that's
something
we
can
encapsulate.
While
we
have
people
evaluated
it's
a
smaller
change
as
well,
so
just
for
context
what's
happening
there,
cool
well,
yeah,
thanks
anthony.
A
I
I
imagine
everyone's
more
than
busy
as
I
I
could
definitely
feel
for
you
on
that
one
or
have
a
lot
of
other
things
on
the
plate
right
now
at
this
time
of
year.
So
I
understand
and
appreciate
it.
A
I
kind
of
wonder:
if
sean
are
you
on
the
call?
Maybe
we
should
oh
you're
right
there
like
that's
been
working,
so
I
can
actually
see
it.
I
kind
of
wonder
if
maybe
we
can
kind
of
talk
about
this
and
then
you
can
break
up
the
monotony
of
hearing
my
voice
drone
on
so
that
was
also
a
benefit
and
then
we
can
just
go
into
it.
So
yeah,
maybe
I'll.
Let
you
kind
of
take
the
stage
and
talk
a
little
bit
about.
A
E
Yeah
I
had
to
discuss
my
work
for
my
work
vpn.
I
had
a
disconnect.
It's
been
stuttering
all
day,
so
there's
been
a
couple
of
solutions
proposed
here
and
I
guess
my
open
question
is
the
last
one
was
the
there's
a
library
out
there
by
is
it's
j2gogs
j2
ggos?
He
has
yeah.
He
has
his
own
otc
ot
sql
package
and
the
question
was:
does
he
want
to
contribute
that
into
the
contrib
repository?
Is
it
gonna
or
is
it
gonna
stay
in
its
own
private?
E
Are
we
gonna
have
one
it
can
trip
we're
implementing
this
at
care
right
now
and
so
either
I'm
gonna
have
to
go
build
my
own,
my
own
package
for
database
sql
or
I've
been
kind
of
just
deferring
hoping
that
one
of
these
was
gonna
drop,
and
so
that's
the
decision
point
I'm
at
right
now
is.
Do
I
build
my
own
and
then
can
I
I'll
contribute
that
to
your
guys's
project
or
are
we
gonna
take
one
of
these
two
solutions
that
other
people
have
already
offered
before?
I
do
that
work.
D
Yeah
and
I
think,
there's
potentially
a
third
alternative
on
the
table
as
well.
Liz
from
honeycomb
the
other
day
was
just
lamenting
the
lack
of
an
equivalent
to
their
sequel
bee
line
and
expressed
an
interest
in
getting
that
into
hotel
go.
I
can
reconnect
with
her
to
see
what
the
mechanics
of
that
might
be,
but
yeah.
We
we
brought.
D
Conversation
that
I
think
comes
up
every
time
we
talk
about
this
package,
which
is
at
what
level
do
we
need
to
support
all
of
the
interfaces
versus?
What's
an
mvp
and
good
enough
and
liz
was
definitely
the
opinion
that
the
the
stuff
that
was
in
the
b
line
was
good
enough
to
to
work
with
people
have
been
using
it
for
a
while
there
may
be.
You
know
further
that
you
could
go
with
it,
but
that
was
a
good
start.
D
So
let
me
touch
base
with
her
to
see
how
the
mechanics
of
getting
that
from
honeycomb
over
to
hotel
might
work
or
if
there
are
others
that
we
we
think
are
also
good
enough.
I
don't
know
that
there
necessarily
has
to
be
just
one
right.
We've
got
multiple
http
middleware
implementations
for
different
for
different
routers
and
handlers,
and
things
like
that.
So
maybe
we
end
up
with
multiple
sql
instrumentation
implementations,
maybe
not
all
of
them
live
forever.
Maybe
we
do
decide.
A
A
A
really
great
solution
is
to
include
multiple
instrumentation
packages
in
in
maybe
an
experimental
directory
or
something
that
could
then
be
graduated
to
a
final
solution.
There
may
also
just
not
be
a
final
solution
like
that,
may
actually
need
to
be
multiple
forms
of
this
instrumentation.
A
I'll,
be
honest,
I
don't
I
this
is.
I
try
to
pay
attention,
but
it's
not
that
I
haven't.
This
is
obviously
I'm
not
working
on
this,
so
I
don't
have
the
most
information
and
context
here
but
yeah.
I
really
like
that
idea.
Anthony.
Is
this
something
that
you
or
liz
could
could
take
on
and
lead,
or
is
this
something
that
is,
we
need
to
find
a
you
know
a
more
suitable
owner
for
it.
D
So
I'd
say:
if
we're
going
to
consider
bringing
in
multiple
implementations
into
experimental,
maybe
sean
can
take
on
one
of
these,
these
other
two
and
I'll
get
with
liz
and
see
if
either
she
or
someone
at
honeycomb
has
the
bandwidth
to
try
porting
theirs
and
if
not,
I
don't
know
if
I'm
going
to
have
the
bandwidth
in
the
near
term
or
if,
if
any
bandwidth
I
have
should
be
more
directed
towards
the
the
p1
ga
issues,
because
I
don't
think
this
is
necessary
for
ga.
Is
it
really
no.
A
It's
not,
and
that's
also
why
it's
not
a
high
priority
for
it's
not
something
of
my
focus
as
well,
but
I
mean
you
know.
I
say
that
and
then
I'm
also
hearing
things
from
people
like
sean
who's,
a
customer
and
who
is
trying
to
use
these
sort
of
things
and
it.
It
motivates
me
to
try
to
be
more
focused
on
this.
I
really
want
to
find
some
way
to
get
a
solution
here,
but
at
the
same
time
I
also
want
to
release.
D
Right
right
and
by
saying
that
this
isn't
necessary
for
ga,
I'm
not
at
all
saying
it's
not
important.
I
absolutely
agree.
It's
an
important
thing
that
people
are
going
to
need
to
be
able
to
instrument
their
applications,
I'm
just
trying
to
figure
out
where
my
time
needs
to
be
spent,
and
if
that
is
on
the
things
that
get
us
to
a
ga
or
if
that's
on
the
things
that
make
the
library
useful
and
that's
kind
of
a
balancing
act,
we'll
have
to
figure
out.
E
I'd
be
happy
to
test
the
honeycomb
solution.
If
we
want
to
focus
efforts,
if
you
guys
want
to
make
it
available,
I'm
happy
to
test
it
with
the
our
services
that
we're
deploying
at
care,
and
you
know,
provide
feedback
and
prs
if
necessary
around
that
versus,
like
I
really
I've
been
delaying
trying
to
implement
this
myself,
because
I'd
just
rather
use
some
something
that's
already
out
there
and,
if
something's
been
written,
then
that's
going
to
save
me
time,
because
I
have
a
lot
of
other
a
lot
of
other
things
around
open
telemetry.
D
C
A
Okay,
there's
no
way
I
can.
I
always
really
think
it
typing
the
conversation,
but
let
me
let
me
try
to
encapsulate
this.
The
conversation
in
that
issue.
A
Afterwards,
and
then
just
to
kind
of
make
it
clear
is
the
is
the
consensus
that
we
kind
of
wanted
ads
an
experimental
directory
and
adds
all
three
possibly.
A
Two
solutions
there
to
have
them.
A
Evaluated
sorry,
I
probably
just
read
exactly
what
I'm
typing
anyways.
D
A
Okay,
sorry
wait
a
minute
dropping
one
of
those
into
the.
D
Okay,
this
is
the
one
we
want
to
go
forward
with
and
the
others
are.
You
know
either
going
to
go
to
the
bed
bucket
or
you
know,
just
be
left
for
people
to
come
along
and
maybe
update.
Maybe
we
get
them
all
to
1.0
and
they
never
have
to
be
updated
again.
Yeah
fingers
crossed.
F
Hi,
this
is
rich,
I'm
from
the
relic,
I'm
a
newbie
to
open
till
on
that
tree.
But
have
we
considered
this
is
a
cool
idea
with
the
experimental
directory
have
we
looked
at
other
agents,
other
open
telemetry
agents
who
may
have
been
dealing
with
this
issue,
seeing
what
they've
done,
especially
in
that
the
idea
where
we
promote
one
and
don't
promote
others?
Is
there
a
voting
system
or
is
there
just
a
usage
criteria.
D
Yeah,
I
don't
know
that
any
of
the
other
cigs
have
done
that.
I
I
thought
I
recalled
tyler.
Was
there
some
discussion
of
experimental
directories
in
instrumentations
at
maintainers
a
while
back,
so
I
think
there
might
be
other
sigs
that
are
that
have
experimental
things,
but
I
don't
know
if
there's
been
any
discussion
of
how
it's
promoted.
A
Yeah
that
sounds
correct
to
me.
I
thought
the
collector
was
one,
but
it's
not
I'm
not
seeing
it
yeah.
I
don't
think
there
was
a
really
clear
definition
of
what
the
promotion
was
other
than
just
like
the
maintainers
would
kind
of
like
see
how
users
were
feeling
about
things
see
what
sort
of
like
you
know
once
people
got
their
hands
dirty
with
like
what
they're
actually
experiencing.
Like
you
know,
one
of
the
things
is
like
implementing
all
these
interfaces
for
the
database
sql
packages
like
we
identified
that
as
an
important
thing.
A
A
30
000
lines
of
code
then
nobody's
really
using
it,
or
nobody
really
needs
that
functionality.
Then
maybe
it's
pretty
obvious,
like
don't
promote
that
one
versus
the
one
that,
like
you
know,
we
see
more
people
using
that.
I
think
it's
also
something
in
go
or
kind
of
use
where
you
can
see
like,
especially
in
the
open
source
world,
all
of
use
cases
of
any
sort
of
instrumentation,
because
that
package
will
be
referenced
in
godot
somewhere.
A
So
we
should
be
able
to
see
some
sort
of
metrics
there
but
yeah
to
answer
rich.
I
don't.
I
don't
have
a
really
good
way.
If
you
would
like
to
come
up
with
one
and
propose
it,
I
would
love
that
contribution,
but
yeah.
No,
I
don't.
I
think
it's
more
just
a
feel.
A
Yeah,
no
good
deed
goes
upon
a
straight
yeah.
No,
I
I
would
love.
I.
I
think
that
we
we,
I
would
love
to
have
it
more
formalized
and
that
may
just
eventually
turn
into
like
you
know,
after
a
few
months
after
the
rc
or
the
ga
specification
date,
and
we
see
a
lot
of
people
using
these
things
open
an
issue
and
say
like
hey,
how
does
everyone
feel
about
this
like
what
maturity
level
do?
A
What
do
we
want
to
do,
or
something
like
that,
because
I
think
that
there
are
probably
some
some
ways
we
could
engage
the
community
at
a
at
a
later
point
after
we've,
given
the
opportunity
for
people
to
to
explore
it.
You
know-
I
also
you
know,
maybe
I'm
a
little
bit
with
a
sparkle
in
my
eyes,
hoping
that
there's
just
gonna
be
floods
of
blog
posts,
talking
about
how
to
use
open,
telemetry
and
look
at
this
really
great
database
package.
A
A
But
that's
I
don't
know,
that's
the
reality
I
like
to
live
in,
we'll
see
we'll
see
if
that
happens,
but
yeah.
I
think
that
kind
of
answers
the
solution.
I
think
this
is
a
really
good
way
to
progress
that
issue,
because
it's
kind
of
become
it's
extremely
wanted,
but
it's
also
there's
not
really
active
work
being
done
on
it,
and
so
I
think
this
is
a
helpful
way
to
try
to
evaluate
that
work
that
people
are.
A
Proposing,
okay
cool,
we
can
continue
to
move
on.
So
this
is
the
point
in
the
meeting
where
I
start
to
ask.
The
hard
question
is
on
monday
maintainers
meeting
the
goal
is
to
start
the
maintainers
meeting
by
asking
the
sigs
when
we
think
that
our
ga
or
a
ga
release
candidate
could
be
cut
for
the
specification.
I
was
taking
a
look
at
the
and
I'm
looking
for
all
of
your
input
on
this.
Obviously
it's
it's
definitely
choose
your
favorite
number
kind
of
thing,
but
hopefully
it's
a
choose.
A
Your
favorite
number,
that's
kind
of
close
is
kind
of
the
goal
here.
These
are
all
the
p1
issues.
A
These
are
the
issues
that
to
be
fair,
I
I
mostly
classify
so
they
may
not
all
be
the
most
accurate
if
you
want,
but
it
was
my
best
guess,
but
p1
being
the
definition,
we
need
this
for
ga
like
these
are
critical
to
have
done
for
ga,
and
so
some
of
these
may
need
to
just
be
reclassified
to
be
lower
that
we
don't
actually
need,
but
it
also
shows
you
a
little
bit
of
like
a
cross-section
of
what
work
needs
to
actually
be
done.
A
There's
20
things
that
have
not
been
started
yet,
there's
six
that
are
actively
in
progress.
They
have
owners.
Some
of
these
have
been
in
progress
for
a
little
while,
if
I'm
being
fair,
oh
okay,
yeah
sorry
getting
distracted,
but
these
20
over
here
I've
also
been
here
for
a
little
while
some
of
them
are
pretty
big
changes
as
well.
That
probably
need
to
get
staged
after
this
api
work.
A
So,
like
there's,
some
sort
of
serialization
ordering
here
for
the
project
managers
on
the
call
like
you'll
quickly
find
that
I
am
not
the
best
project
manager
and
I'm
doing
my
best.
So
if
you
have
suggestions
on
how
to
like
get
a
better
understanding
of
like
gauge
the
timeline
on
this,
I
would
love
to
understand
that.
That
being
said,
I'd
love
to
get
some
sort
of.
A
Like
estimate
on
this,
I
think
that
the
specific
or
the
project
as
a
whole
is
expecting
some
sort
of
release
candidate
within
the
the
next
two
to
four
weeks.
The
four
weeks
sounds
reasonable
to
me.
The
two
weeks
sounds
ambitious,
maybe
even
unrealistic,
but
I
I
think
ambitious
is
the
right
word.
I
think
that,
four
weeks,
if
there's
a
lot
of
active
work,
we
could
we
could
try
to
accomplish
this.
A
The
thing
I
am
worried
about
is
releasing
something
that
is
not
fully
vetted,
and
I
think
we've
talked
a
lot
about
this
in
this
meeting
and
making
sure
that
we
understand
that
the
release
candidate
needs
to
be
something
that
is
going
to
potentially
become
the
ga
release
and
it's
something
that
we're
proud
of
standing
by
and
that
it
is
going
to
be
something
that,
if
only
there
is
you
know,
through
user
feedback
or
through
you
know,
really
unforeseen
events,
issues
that
we
come
up
with
after
the
fact,
then
we'll
make
a
release
candidate,
two
or
some
sort
of
changes
or
or
bug
fixes,
obviously,
like
those
could
predicate
the
release,
change
revision
as
well,
but
the
goal
is
to
have
what
we
do
really
hasn't
really
scanned.
A
It
potentially
be.
The
ga,
I
think,
is
the
idea
so
yeah
I
would
love
to
get
people's
feedback.
Maybe
even
got
reactions
as
to
what
they
think
timeline
wise.
You
know.
Obviously,
people.
A
D
A
D
Be
I
don't
know
if
that
works,
I
think
area
metrics
is
the
label
it's
not
quite
on
all
of
them,
but
it's
on
most
of
them.
A
Yeah,
okay,
14
results.
Let's
look
for
traces
directly
now
that
I
again
back
to
the
whole
thing,
I'm
not
really
great.
At
the
whole
project
management.
A
Or
even
github,
it
looks
like
so
five
five
done
on
the
to-do
one
active
in
progress.
29
done
this
seems
more
tractable,
let's,
let's
kind
of
just
kind
of
walk
through
it
really
quick,
too
many
trace
packages.
I
think,
with
our
recent
revision
to
the
api
I've
been
thinking
about
this
one
we
could
probably
just
close
it.
This
is
asking
for
renames
of
the
sdk
trace
package
and
the
export
truce
package.
A
Well,
there's
also
been
three
plus
ones.
One
of
those
is
mine.
I'm
gonna
take
that
away.
At
this
point,
I
don't
think
it's
a
plus
one
for
me
anymore,
yeah.
We
discussed
this
previously
in
the
sig.
I
don't.
I
wasn't
actually
there
for
that
discussion,
but
it
seems
like
the
using
the
import
names
was:
that's
what
go
is
there
for
maybe
I
could
we
could
circle
around
with
bob
did
on
this
one,
but.
A
A
A
We
also
don't
have
a
owner
of
this
one.
It's
also
a
super
old
issue.
That's
been
around
for
a
while.
That's
not
accurate
november
19th!
Okay,
I
guess
it's
only
a
year
old,
it's
a
little
old,
so
that's
about
a
week.
I'd
see
there
and
work
the
span
contract
unclear.
I
was
looking
at
this
one
as
well.
This
is,
if
I'm
not
mistaken,
yeah.
This
is
the
ending.
Also
doesn't
actually
stop
you
from
setting
things.
This
is
a
this
is
a
rabbit
hole
looking
into
this
one.
A
So
I
think
that
we
should
probably
I
would
love
some
opinions
on
this
one
as
well
or
if
you
can
comment
in
the
issue,
but
anthony's
also
kind
of
jumped
in
here.
The
specification
pretty
much
says
like
you
shouldn't,
be
able
to
set
any
sort
of
things.
After
the
fact
that
the
span
has
been
finalized,
but
that
I
mean
it's
been
ended,
which
kind
of
makes
sense,
because
once
it's
been
ended,
it's
sent
down
some
sort
of
span
processing
pipeline
and
that
span
processing
pipeline
may
be
doing
batching.
A
So
I
think
if
that
is
an
inconsistency,
I
think
a
specification
if
I'm
not
mistaken,
anthony
and
jana
had
correctly
shown
that
it
probably
meant
to
not
allow
this.
So
I
think
we
should
change
that.
I'm
pretty
sure
it
only
means
in
this
resolution
is
to
change
this
comment,
because
then
it's
on
to
the
sdk,
to
just
ensure
that
that's
that's,
that
behavior
is
enforced
so
that
it
could
be
kind
of
small
if
we
scope
it
that
way.
Looking
into
the
sdk
there's
some
issues
with
the
sdk
right
now.
A
I
also
noticed
there's
locking
issues
that
are
kind
of
obscure.
I
still
have
yet
to
open
an
issue
on
it
and
just
the
end.
Options
itself
probably
need
some
better
concurrency
patterns
and
somebody
to
go
through
that.
So
look
for
an
issue
on
that
one.
I
think
this
one
could
probably
get
resolved
somewhat.
Quick.
D
Yeah,
I
think
if
we
just
adjust
that
comment,
then
anything
else
that
falls
out
of
the
sdk
can
probably
be
treated
as
a
bug
fix
and
doesn't
necessarily
need
to
be
done.
Pre-Ga
because
it
won't
break
anything
okay,
yeah.
If
it
does
break
anything,
it
was
undefined
behavior
that
shouldn't
have
been
relied
on
in
the
first
place,
you're.
A
I
did
yes,
okay,
I
am
the
only
thing
left
on
the
agent.
I
just
want
to
make
sure
I
didn't
gain
time
to
somebody
else
wanted
to
talk
about
something
add
parent
context
parameter
to
the
spam
processor.
On
start,
oh,
this
is
kind
of
a
newer
one,
I'm
not
mistaken
yeah
three
days
ago,
it
looks
like
this
was
just
added
to
the
specification
as
well,
so
this
just
needs
to
get
done.
I
don't
think
this
is
actually
too
hard.
I'm
just
gonna
add
this
label.
A
I
haven't
looked
too
deep
into
it
either,
but
yeah.
I
imagine
this
is
only
a
day
or
two
of
well
reviewing,
mostly
so
that
looks
good,
add,
trace
state
to
state
context,
also
a
newer
one.
This
is
also,
I
think,
something
that
was
recently
added
to
the
specification
again.
I
think
this
is
something
we
could
think
through
really
quick
and
get
done
in
a
day
and
then
review
in
a
few
days
so
yeah,
I
think,
that's
again,
not
too
hard.
A
It
will
almost
always
conflict
with
the
the
current
api
move.
So
that's
why
I
think
it's
really
critical
to
get
that
trace
package
moved,
but
once
that's
actually
moved.
I
I
see
this
taking
a
week
or
two
to
get
all
the
p1
issues
resolved
and
then
it's
going
into
the
p2
and
p3s
after
that,
so
yeah.
I
think
that
that
four
week
timeline
is
is
a
reasonable
timeline.
So
far
from
just
kind
of
that
high
level
view
love
to
hear
what
you
all.
A
D
Yeah,
I
think
there
are
a
couple
propagation
related
issues
that
aren't
marcus
area
trace,
that
we
might
also
need
to
deal
with
before
jay,
but
I
think
the
total
number
is
less
than
the
20.
We
were
starting
to
look
at
so
okay
reason
to
be.
A
Optimistic
cool,
yes,
cool
and
yeah.
This
is
actually
there's
only
two
more
issues
to
do
from
the
high
level
that
aren't
p1,
investigate
record
exceptions
like
method
yeah,
this
one,
I
just
need
to
look
at
it
again.
I
opened
it.
A
D
I
think
we're
in
line
with
the
spec
here,
even
if
we've
got
a
different
name
for
this
function
and
we
use
it
slightly
differently.
The
spec
anticipates
that
there's
going
to
be
some
variance
per
language
and
since
go
doesn't
really
do
exceptions.
I,
I
think
we're
probably
good.
A
A
Cool,
I
think
that
should
be
one
more
in
here,
but
oh
here
it
is
update,
name.
A
Yeah,
okay,
I
was
just
looking
at
the
specification
on
this
one
as
well
today.
This
is
another
kind
of
a
bigger
one,
long-standing
as
well
over
a
year
now
as
well.
Yeah
just
need
somebody
to
tackle
this
with
this
one.
I
think
again,
it's
probably
another
week
or
two
which,
if
we
were
able
to
get
some
some
help
on
or
even
if
we
serialize.
I
think
we
should
be
able
to
get
this
done
in
four
weeks,
but
just
need
to
kind
of
dig
into
it.
A
I
think
it
really
is
just
somebody
needs
to
go
back
and
read
the
specification
to
make
sure
that
we're
handling
the
specification
and
reevaluate
this
problem
pablo
hasn't
been
on
the
project
for
six
months
now.
So
I
think
just
somebody
needs
to
onboard
some
thought
onto
this
and
take
a
look
at
the
current
state
of
things
and
fix
it.
D
I
I
think,
we're
okay
on
this,
but,
as
you
say,
we
want
to
go
back
to
the
spec
and
double
check,
but
my
recollection
is
the
spec
eventually
got
updated
to
say.
Basically,
if
you
change
the
name
after
we
decided
not
to
sample
a
span,
there's
nothing.
We
can
do
the
really.
The
only
point
where
sampling
decisions
can
be
made
is
at
the
beginning
or
at
the
end
of
a
recorded
span.
A
Yeah,
this
is
reminding
me,
I
think
david.
Did
you
open
that
pr
for
the
shin
for
the
census?
Yes
set
it
yeah,
so
this
is
kind
of
related
to
your
question
as
well
around
like
the
span
sampling
decision?
Well,
I
guess
it's
not
quite
how
we
don't
accept
that
an
open
slide
opens
on
the
tree,
but
yeah.
I
think
that
it's
kind
of
the
same
same
vein,
sorry
that
was
maybe
just
more
of
a
stream
of
conscious
thing.
I.
A
David
for
opening
up
to
that
pr,
that
was
super
helpful
for
that.
If
people
haven't
actually
taken
a
look
at
it,
yet
there's
a
a
great
pr
to
address
evan
census
tracing
bridge,
which
is
a
great
stock,
launching
point
for
the
open
census,
users
that
are
currently
like
trying
to
migrate
to
open
telemetry.
It
only
touches
on
some
of
the
span,
our
tracing
stuff
right
now,
which
is
kind
of
waiting
on
the
metric
side
of
things
to
solidify
or
compatibility
issues.
A
I
think
as
well,
but
yeah
it's
it's
pretty
straightforward
500
lines
for
most
of
it
is
riff
raff.
It's
you
should
be
able
to
rip
through
this,
but
yeah.
Also
the
incompatibilities
david,
I
think
really
good
idea
on
just
erroring
on
them
and
then,
if
that
does
change
in
the
future,
we
can
address
it
at
that
point
makes
sense.
G
I'm
actually
talking
with
morgan
and
I
might
try
and
do
a
blog
post
about
how
one
would
potentially
migrate
using
this
package
so
stay
tuned.
This
morning,
yeah.
A
A
A
Yeah
good,
I'm
pretty,
I
would
agree,
I'm
a
little
scared,
but
that's
kind
of
normal.
No.
A
Well,
cool,
I
think
that's
actually,
oh
no!
I
did
have
one
more
issue,
so
one
of
the
other
things
that
I
wanted
to
jump
into.
If
we
wanted
to
move
on,
I
can
only
see
four
people.
A
I
don't
know
if
I'm
also
really
bad
at
zoom,
so
I'm
just
gonna
flat
out
say
that
if
anybody
just
had
anything
more
saying
about
that
issue
for
a
week,
cool
yeah,
the
thing
that
I
found
in
the
past
a
few
weeks
we've
we've
did
we've
been
doing
some
api
refactoring
and
that's
been
breaking
things
downstream.
A
And
I
think
this
is
going
to
continually
happen
throughout
the
project's
life
cycle,
mostly
based
on
the
fact
that,
while
we
say
we're
using
modules-
and
we
have
reiterated
to
use
modules
and
make
sure
that,
like
you're
using
modules,
if
you're
going
to
use
open,
telemetry
people
don't
and
they
just
pull
for
master
and
so
there's
breaking
changes
on
master
that
are
commonly
going
to
be
there.
A
Just
as
we're
especially
iterating
on
this
that'll,
hopefully
not
be
the
case
after
the
ga
like
the
goal
is
to
remain
backwards
compatible
and
I
imagine
the
master
branch
is
going
to
be
so
the
main
default.
But
I
was
kind
of
wondering
if
we
needed
a
more
sophisticated
git
flow
situation
here.
I
was
going
to
find
a
link
and
I
never
did.
A
But
the
idea
is
essentially
is
you
have
a
development
branch
and
that
development
branch
is
where
all
active
changes
are
done
and
then
from
the
development
branch
to
a
base
branch
you
make
a
release,
pull
request
essentially
or
release
branch
from
one
to
the
other,
and
you
pull
back
in
those
developments
so
essentially
like
the
the
main
branch
is
always
at
a
stable
buildable
state
is
kind
of
the
goal
and
the
backers
compatibility
is
insured
that
way
that
if
people
are
voting
for
master
like
they'll
get
the
olds
released
anyways
because
there
hasn't
been
any
more
releases,
so
it'll
just
be
consistent
for
them
and
we
wouldn't
be
feeling
as
many
issues.
A
It
also
means
that
allowing
feature
branches-
it
probably
is
going
to
be
more
common
as
we
go
into
ga
to
like
have
more
feature
branching
and
not
work
so
much
into
the
master
branch,
and
the
thing
that
I
keep
wanting
to
say
is.
It
would
give
us
an
opportunity
if
we
did
want
to
do
this
to
rename
the
master
branch.
I
know
this
has
been
a
topic
throughout
github
as
if
we
wanted
to
rename
master
at
some
point.
A
Like
probably
want
to
do
that
before
ga,
I
don't
think
it's
like
the
most
critical
like
we
could.
We
could
make
this
happen
after
ga,
given
the
fact
that
we
are
doing
releases
like
you
shouldn't
be
following
master
but
like
it
might
be
less
disruptive
if
we
do
it
at
this
point
in
time,
so
these
are
kind
of
I
just
wanted
to
propose
it
see
what
other
people
thought
about
it
to.
D
Sign,
well,
I'm
not
sure
I'm
100,
either
in
favor
or
opposed
to
it.
I've
I've
done
the
development
branch
and
then
you
you
go
to
the
trunk
at
a
release
before
and
it's
worked.
I
also
think
we've
been
pretty
good
about
ensuring
that
we.
C
D
Stable
trunk,
our
unit
tests,
and
at
least
in
contrib
we've
got
integration
tests
as
well.
We're
pretty
good
about
ensuring
that
I
think
the.
As
you
say,
the
the
only
reason
why
it
would
be
useful
is
for
consumers
who
are
not
using
go
modules,
and
I
don't
know
what
to
what
extent
we
expect
that
to
continue
or
to
rapidly
fall
off
as
adoption
of
go
modules
picks
up.
E
I
would
say,
as
a
consumer
that
we
use
go
modules
like
you
know,
I've
been
doing
active
work
against
these
libraries
for
the
last
three
or
four
months,
and
we
just
we
follow
whatever
your
latest
version
is
right
now,
we're
using
you
know:
zero
through
15.0
for
our
own
go
libraries.
E
We
use
semantic
release
so
based
on
your
release,
based
on
your
commit
messages,
you
know
we
we
bump
this
portion
of
the
sum
version,
that's
appropriate,
but
our
master
is
always
because
it's
absurd
there's
a
pr's,
merge
master
is
going
to
be
whatever
the
latest
releases
and
for
me,
that's
always
worked
well.
You
know
we
still
go
and
use
versioned
releases,
but
it's
not.
We
don't
build
a
release
based
on
many
pr's
of
being
already
merged.
It's
like
every
pr
is
going
to
increment
that
version
by
a
patch
of
minor
or
major.
A
Yeah
I
looked
at
the
semantic
release.
Versioning
thing,
it
looked
very
node,
js
centric.
I
didn't
I'd
love
to
understand
how
you
got
that
workflow
to
work
because
I
was
kind
of
jealous.
I
thought
that
was
a
really
cool
thing.
One
of
the
things
that
I've
also
realized
is,
as
we
go
to
the
ga
it's
going
to
be
the
1.0
release
of
this.
A
An
important
thing
for
the
next
iteration
afterwards
is
the
v2
release
and
there
are
some
really
important
things
I
found
actually
looking
at
a
pr
in
the
contrib
repo
around
how
go
handles
the
v2
version
in
the
go
modules,
and
that's
that
it
doesn't.
It
tells
you
that's
not
a
valid
version.
You
need
to
go
to
a
different
path
and
that
different
path
should
end
in
v2
and
so
yeah.
That's
a
that's
an
interesting
one
as
well.
I
I
love.
Do
you
in
the
semantic
versions
that
you
set
up?
E
They
will
but
we're
not
doing
any
well
yeah.
I
guess
we're
pretty
good
about
our
libraries,
not
breaking
backwards
compatibility,
so
I
mean
we
haven't
hit
that,
but
I
guess,
if
we
do,
I
should
probably
now
test
that
we
just
built
it
into
jenkins,
maybe
six
weeks
ago,
and
we
just
use
the
node
portion
to
check
the
commit
messages,
we're
not
using
it
to.
Actually
we
had
to
write
some
custom
code
to
actually
go
through
and
bump
our
modules
and
tag
the
git
repos
and
everything.
E
D
Right,
I
think
there's
some
tooling
that
can
help
once
you're
at
version
two
going
from
v2
to
v3
and
rewriting
all
of
those
I'll
see.
If
I
can
take
up
a
link
to
that,
but
going
from
v1
to
v2
is,
I
think,
the
biggest
change
when
you've
got
a
module
and
you
get
to
that.
Second
major
version.
A
I'd
love
to
read
about
that
as
well,
because
I
I
love
automating
these
kinds
of
things
and
building
git
workflows
as
well.
Yes,
anthony.
I
think
that
you
make
some
good
points.
Maybe
we
just
hold
off
on
the
git
flow.
I've
also
done
it,
and
I've
also
kind
of
like
been
there's
added
bureaucratic
load
to
having
multiple
branches
like
this
and
like
it's
kind
of
a
pain.
A
In
that
sense,
I
think
what
I'm
hearing
is
that,
like
people
aren't
doing
what
we've
told
them
and
suggested
in
in
the
guidelines
of
how
to
work
at
the
project,
that's
kind
of
just
a
part
of
the
project
and
we're
going
to
need
to
communicate
that
repeatedly
when
they
ask
about
this
sort
of
thing,
which
is
fine,
I'm
okay
with
that
answer
as
well,
I
just
wanted
to
bring
it
up.
That
being
said,
did
we
actually
want
to
address
the
the
master
branch?
A
A
A
Well,
I
don't
know
if
anybody
was
saying
something,
but
I
yeah
I'm
I'm
not
looking
for
more
work
either.
So
we
can
delay
that
decision
as
well.
A
Cool,
I
think
that's
it.
I
think
we've
hit
the
end
of
the
time
tomorrow,
new
work.
Where
have
I
seen
that
name
before
awesome,
I'm
looking
at
the
link
that
anthony's
putting
in
the
doc
sorry.
A
Okay,
that's
right!
Okay,
I
was
like
that's
a
very
familiar
name:
cool
yeah,
thanks
I'll,
take
a
look
at
that.
I'm
interested
in
that
and
in
conjunction
with
the
semantic
version
of
the
tool,
anyways
but
cool
awesome,
I
think.
Does
anybody
else
have
something
else
they
wanted
to
ask
leave
the
chat.
A
Going
once
going
twice:
okay,
I
think
everyone
gets
their
12
minutes
back.
Please
be
sure
if
you
have
some
time
check
out
the
metrics
inc
in
a
little
bit,
we'd
love
to
have
people
collaborate
on
that
one
as
well,
but
until
then
I
will
see
you
all
next
week
and
thanks
for
joining
thanks
a
lot.