►
From YouTube: 2021-06-17 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
B
Yeah
static
types
have
spoiled
me
compiled
binaries
have
spoiled
me
yeah.
That's
like
I
said.
All
I
used
to
write
was
python
and
then
I
just
like
I
switched
to
go
like
full
time
and
I
had
to
go
back
and
you're
just
like
wait.
A
Well,
I
have
to
say,
like
I'm,
dealing
with
artifactory's
query
language,
which
is
interesting
at
best.
So
I'm
like,
I
love
the
dynamic
typing
there,
but
everything
else.
B
Yeah,
it
is
kind
of
fun
going
back
to
python.
Sometimes
it's
just
it's
such
a
different
language,
but
I
don't
know
it's
also
fun
going
to
rust,
sometimes
because
that's
also
a
very
different
language.
B
C
Rust
is
fun
once
you
get
past
the
initial
troubles,
with
a
borrow
checker.
I
I
think
I've
largely
got
through
that.
I
managed
to
do
all
of
this
year's
adventive
code
and
rust
and
most
of
the
way
through
last
year,
but
last
year
I
got
like
two
problems
and
I
was
like
nope.
This
is
just
not
happening.
B
It's
a
it's
a
pretty
awesome
language.
It's
got
its
own
set
of
issues,
but
yeah.
B
David,
do
you
actually
work
much
in
java
and
c,
plus,
plus
over
there,
google.
D
D
Yep
I've
avoided
the
other
other
googly
languages,
yeah.
B
I
mean
there's
definitely
something
addicting
about
the
c
plus
plus
world,
where
you
can
just
like
hyper
optimize
things,
but
man
there
is
just
boilerplate
right
out
the
out
the
nose
and
don't
even
get
me
started
on
like
which
boost
library
you're
allowed
to
use
or
not
or
which
one
you
are
using
that
you
don't
realize
you're
using
yeah,
all
fun
things
cool.
I
think
this
might
be
it
for
the
day.
We
only
have
six
people
on,
but
we're
four
minutes
in
so
we
could
probably
get
started.
B
I
think
it's
kind
of
a
light
agenda,
so
let
me
start
sharing
my
screen.
We
can
go
into
things
cool.
I
think
everyone
wants
to
hear
from
56
yeah.
Everyone
seems
to
have
signed
in
thanks
for
doing
that.
If
you
have
anything
else,
you
do
actually
want
to
talk
to
or
bring
up
as
a
topic
for
the
conversation.
Please
add
it
to
the
agenda
here.
B
Otherwise,
we'll
just
jump
in
there's
the
other
century
rc,
which
I
think
is
going
to
eventually
get
down
to
here,
but
just
a
really
quick
recap:
there's
two
issues
in
progress,
still,
one
of
which
is
this
development.
Implement
a
plan
to
extend
interface,
which
is
mine
and
gustavo,
is
the
remove
unstable
metrics
dependency
from
the
otlp
exporter
anthony,
and
I
were
talking
a
little
bit
yesterday.
B
As
we
talked
last
week
in
the
sig
meeting,
we
had
a
pr
for
this
to
get
metric
support
into
its
own
module
and
it
was
merged,
and
I
think
that
that's
sufficient,
as
we've
kind
of
talked
about
to
get
the
1.0
release
candidate
out
the
http
otlp
metrics
are
not
there
yet,
but
I
think
that
could
be
added
in
a
experimental,
minor
release.
If
we
wanted
to
do
that,
I
think
we've
completely
taken
away
the
otp
exporter
itself,
there's
refactors
that
can
be
done
here.
B
In
fact,
this
transform
package,
I
think,
is
an
open
question
as
to
like
how
we
want
to
do
that
and
how
we
want
to
expose
that.
Maybe-
and
I
think
that
we've
done
the
examples-
that's
an
interesting
one.
Well,
I
think
that
also
has
to
do
with
like
or
each
one
of
our
examples
is
its
own
module.
B
So
we
may
just
not
be
releasing
some
of
these
examples
in
the
100
release,
which
I
think
is
perfectly
fine,
not
only
anybody's
going
to
be
complaining
about
stable
examples
not
being
released
with
the
1-0,
so
we
could
definitely,
I
think,
punt
on
that
and
then
docs
update,
but
I
don't
think
that's
a
requirement
for
this
rc
specifically,
so
I
think
that
this
is
something
that
we
could
probably
say
is
not
blocking
anymore
for
the
rc
and
in
the
same
vein,
I
think
that
this
development
implement
a
plan
for
to
extend
the
interfaces,
is,
I
don't
think
blocking
anymore?
B
I
do
want
to
talk
about
this
a
little
bit
with
the
group.
That's
here
I
put
a
little
time
towards
this.
I
have
been
putting
a
little
time
towards
this
for
a
little
while
and
the
idea
that
I
came
out
with
well
just
for
recap
for
people
that
are
not
familiar
with
the
issue.
B
The
problem
that
we
have
right
now
is
that
we
have
exported
interfaces
anything
from
the
api
down
to
options
to
things
like
the
detector
or
the
error
handler
parts
of
the
the
code
base
and
as
the
go
language
is
designed,
you
cannot
add,
remove
or
change
any
part
of
the
interface
with
the
interface
methods,
without
it
being
in
breaking
change,
meaning
that
if
somebody
was
using
that
interface
downstream
implementing
that
interface
downstream
using
it
in
a
way
like
it
could
break
them
by
changing
it,
which
is
a
problem
because
the
open
telemetry
api
is
at
specification
level
stated
that
it
will
be
adding.
B
But
it
is,
it
is
reserving
the
right
to
add
functionality
in
the
future
and
that
can
be
functionality
for
types
or
or
things
that
it
already
has
defined
so
say,
like
a
span,
has
added
functionality
to
it.
We
need
to
be
able
to
support
that,
which
means
that
we
would
need
to
add
a
method
to
the
span
interface
or
to
another
one
of
these
interfaces,
which
is
in
conflict
with
the
stability
guarantees
of
go
so
in.
There
are
definitely
a
few
different
ways
that
we
can
handle.
This
and
we've
explored
some
in
the
past.
B
Some
of
them
involved
embedding
structures
embedding
the
interface
itself
and
others
are
making
it
clear
which
interfaces
this
is
going
to
affect,
and
given
the
fact
that
these
interfaces
are
only
ever
going
to
affect
interfaces
that
sdks
will
be
implementing
or
are
expected
to
implement,
make
sure
it's
very
clear
that
that's
an
exception
to
the
rule
in
documentation
in
where
they're
they're
listed
and
tell
sdk
developers
that
they
have
the
added
responsibility
that
they
will
need
to
update
interface,
implementations
for
added
methods.
B
That
being
said,
we
do
not
plan
to
remove
or
change
existing
methods.
So
that's
an
important
point
to
keep
in
mind
that
the
interfaces
that
we
are
going
to
export
they,
if
you
know
this,
is
I
think
why
we
spent
so
much
time
on
these
sort
of
things.
If
we
got
this
wrong
and
set
status
now
needs
to
include
something
else.
That
means
we
need
to
add
a
method.
B
We
can't
change
this
method
anymore,
you
know,
is
recording
me
needs
to
change
something
else
like
it
needs
to
be
a
new
method
to
encapsulate
it,
and
you
can't
remove
this.
B
B
Some
of
them,
I
think,
might
have
changed
that
might
be
in
the
metrics
package.
Maybe
this
actually
is
accurate,
but
there
was
an
inventory
that
I
did
and
we
found
all
the
exported
interfaces
and
I
really
came
up
with
three
different
classes
of
what
these
interfaces
are
and
I'm
not
too
sure
these
classes
are
the
best
classification
yet.
But
the
idea
is
is
that
there
are
interfaces
that
we
expect
end
users
to
implement
and
call.
This
is
kind
of
what
I
was
talking
about
at
the
beginning.
B
These
are
things
like
the
detector,
the
span
exporter,
sampler,
spin,
processor,
id
generator,
textback
carrier
text,
micropropagator
error
handler,
and
this
otlb
trace
client,
which
we've
probably
talked
about
as
well,
and
these
need
to
be
stable
like
these,
these
need
to
conform
to
the
classic.
Go
stability,
guarantees
that
they
they're
not
going
to
change.
I
can
have
methods
added
to
them,
then
I
could
have
methods
changed
on
them.
That's
just
going
to
be
stable
for
that.
We
need
to
have
a
plan
for
how
to
extend
them.
B
If
we
need
to
go,
has
a
you
know,
outlines
things
that
you
can
do
to
extend
these
interfaces
and
I
think,
there's
they're
highlighted
here
so
say
you
have
some
sort
of
exporter
and
down
the
road.
We
wanted
to
add
some
sort
of
close
method
to
this.
What
we
can
do
is,
we
can
explicitly
add
a
new
interface
called
closer
and
we
can
check
to
see
if
say
the
past
exporter
satisfied
that
and
then
we
can
call
that
method.
So
that's
one
way
to
extend
it.
B
B
I
in
this
I'm
still
writing
some
of
the
docs
in
the
pr
that
I'm
actually
opens,
but
it
says
we
probably
want
to
prefer
this
method
instead
of
the
superset
just
because
it
limits
the
functionality
that
you
can
impose.
However,
sometimes
if
you're
going
to
be
passing
the
type
it
needs
the
unified
type,
this
does
make
sense.
So
listening
as
an
option
is
important,
and
these
are
all
ways
to
extend
like
these
end
user,
implement
and
call
interfaces.
B
The
next
class
that
I
come
up
with
is
like
this
internal
only
implementation,
or
I
might
just
rename
this
to
be
all
of
the
options,
because
that's
all
they
are
and
all
of
these
options
look
very
similar
to
this,
which
is
they
have
some
unexported
private
method
and
that's
it.
They
don't
have
any
other
any
other
public
methods
exported
and
they
probably
never
will
in
theory.
B
I
guess
we
could
add
a
public
method
as
we
go
down
the
road,
because
nothing
should
be
implementing
this,
but
I
don't
ever
anticipate
that,
and
so
I
kind
of
just
left
these
as
a
a
very
terse
statement
saying
essentially
it's
not
perfect.
Things
could
get
around
this
with
the
compiler,
but
the
idea
is
these
will
never
actually
be
extended
either,
but
they
they're
regarded
from
the
users
using
them
and
then
the
last
one
is
this
class
of
interfaces
that
we
kind
of
talked
about.
B
This
is
the
tricky
wicket
here
the
interfaces
that
we
plan
to
extend
and
they're
really
not
too
many,
except
for
these
two
outliers,
which
kind
of
talk
about-
and
it
mostly
is
just
the
trace
package
and
the
trace
api.
So
spam,
the
tracer
and
the
tracer
provider
are
the
three
interfaces,
and
on
top
of
that
we
have
these
two
other
packages.
B
Here
the
read
only
span
and
the
read
write
span,
so
the
read
write
span
is
inherited
from
this
trace
fan,
so
it
is
going
to,
I
think,
by
composition,
inherit
this
concept.
That
needs
to
be
able
to
have
the
ability
to
extend
it,
and
the
read-only
span
is
also
listed.
This
way-
and
the
reason
I
did
this
is
this-
is
a
type
that
we
are
going
to
be
passing
in
the
exporter
interface,
so
the
span
exporter
itself
is
going
to
be
using
these
read-only
spans,
as
well
as
spam.
B
Processors
we'll
also
use
these,
but
these
are
things
that
we
may
need
to
extend
because
there
may
be
concepts
or
functionality.
That's
coming
from
the
api
that
is
net
new
and
we
can't
encapsulate
that
functionality
into
any
one
of
these
already
existing
method
calls
it's
also
one
of
the
tricky
wickets,
because
it
has
this
private
method,
meaning
that
we
aren't
expecting
anyone
outside
of
the
project
to
be
implementing
this
method
either.
B
So
it's
it
is
a
little
bit
of
an
odd
ball
out
on
this
one
and
I'm
open
to
admit
that,
and
I'm
also
open
to
think
if
somebody
has
different
ideas
as
to
what
that
should
look
like
we
can.
We
can
address
that,
but
with
regard
to
the
ticket
in
the
progress
on
it
for
the
rc
that's
exciting,
we
have.
B
I
have
this
prototype
draft
pr
which
does
not
have
to
land
before
the
rc
given
kind
of
what
we
just
talked
about
like
there's,
really
no
functional
code
change,
that's
going
to
be
included
in
this.
It's
entirely
all
documentation.
It's
outlining
the
interface
stability
from
the
developer's
perspective,
giving
context
there.
B
It's
updating
the
versioning
policy
talking
about
like
there
is
an
exception
to
the
senver
ii,
and
that's
that
some
of
these
interface
methods
may
have
added
methods
making
sure
that,
like
you,
can
always
identify
them
by
including
this
or
finding
this
in
their
public
documentation,
which
is
added
to
the
the
interfaces
that
were
kind
of
identified
before
and
then
for
all
of
the
other
ones.
I
added
documentation
pretty
much
screaming
at
you
in
your
face
that
you
should
not
be
changing
these
methods
once
once
the
1-0
has
happened.
B
So
there's
really.
No,
I
don't
know
justification
once
you
change
them
like
these
things
should
not
actually
be
changed.
The
way
I
added
it
also
is
in
a
way
that
this
does
not
show
up
in
the
public
exported
documentation.
So
it's
just
a
developer
comment
here,
but
yeah.
I
think
if
there's
an
open
pr,
I
probably
it's
really
close
to
just
getting
out
I'm
still
just
reading
through
it
multiple
times,
but
it's
probably
going
to
get
out
today
and
hopefully
we
can
resolve
that
so
yeah.
B
B
Talking
about
an
rc1
which
I
can
only
imagine,
this
is
gonna,
be
a
really
long
chain
set
yeah.
There's
there's
a
few
changes
since
we
last
released
yeah
just
a
few
okay
cool.
I
think
I.
C
Have
already,
however,
realized
that
I've
forgotten
something
I
forgot
to
update
the
website.
Docs
so
I'll
have
an
additional
change
for
this,
but
I
just
wanted
to
get
this
out
there
and
get
people
to
start
looking
at
it
to
ensure
that
there
isn't
anything
else,
I'm
also
forgetting
I
think
I've
covered
all
of
the
bases
I
used
the
releasing
tool
that
eddie
has
been
working
on
to
update
gomod
to
100rc1
and
to
v21
for
all
of
the
rest
of
the
modules.
C
I
have
updated
the
change
log.
I
have
updated
the
documentation,
the
the
doc.go
file
for
all
of
the
modules
that
are
now
in
rc
to
update
from
there
currently
in
free
ga
to
their
currently
in
release
candidate.
We
expect
them
to
be
stable,
but
changes
may
still
happen,
and
so
I
think
we've
covered
all
of
the
bases,
but
eyes
always
need
eyes.
B
C
I'm
not
sure
if
it's
part
of
the
semantic
inventions
or
not
it's
certainly
a
me
thing.
I
think
I
don't.
I
don't
know
if
it
matters,
if
that's
capitalized
or
not.
A
C
Sort
of
I
think,
there's
anything
after
a
dash
after
the
patch
is
there's
a
term
for
it's
not
build
metadata,
pre-release
version,
yeah,
section
nine
there,
so
you've
got
a
hyphen
and
then
some
segments-
and
it
looks
like
it
can
be
upper
or
lower
case.
We
can
have
it
lower
case.
If
you
want,
we
can
have
it
uppercase.
I
don't
think
it
matters.
C
The
important
thing
is
that
that
sorts
prior
to
100
when
sorting
versions
and
then
there's
the
the
the
other
one,
which
is
the
build
metadata
which
comes
after
a
plus
sign,
which
is
not
supported
by
gomod
and
we
won't
use
it
all.
B
Right,
okay,
building,
pre-release
identity,
alpha
america,
identifier,
oh
man,
yeah
right!
This
is
upper
and.
B
Lower
sorry
where's
the
back
our
bike
shopping
here,
yeah.
No,
I'm
just
making
sure
that
we're
conforming.
I
honestly,
I
would
have
used
lowercase,
but
do
not
care.
B
B
This
naming
is,
I
think,
as
long
as
we
agree
on
it,
I
don't
care
this
is
this
is
great
yeah
and
I
think
anthony's
correct,
like
it
can
be
whatever.
So,
let's
just
let's
just
leave
it,
I
don't
wanna.
I
do
not
want
to
cause
any
consternation.
C
B
I
think
it's
gonna
be
my
birthday
too
yeah.
I
think,
if
that's
achievable,
I
think
that
that's
totally
achievable.
I
don't
know
if
anybody
else
on
the
call
has
differing
opinions
on
that
one.
F
B
Oh,
this
is
lining
up
really
well
actually
yeah,
okay,
yeah,
I
think
that's.
This
looks
great.
I
want
to
put
a
little
more
thought
into
reviewing
it
and
I
would
appreciate
everyone
on
the
call
to
do
the
same
anthony.
What
are
your
thoughts
on
closing
this
board
when
we
make
that
release?
A
E
C
Our
next
target
is
1.0.
If
we
have
to
have
an
rc2,
we
have
an
rc2,
but
that's
not
something
we're
driving
towards
it's
a
milestone
on
the
way
between
rc1
and
1.0.
A
C
On
on
the
topic
of
user
feedback
and
kind
of
related
to
the
the
interface
discussion
that
we
were
just
having
as
well
tyler-
and
I
met
with
someone
from
the
build
kit
project
yesterday,
who
had
been
integrating
open,
telemetry
and
had
some
concerns
with
the
the
ability
to
create
spans
on
a
trace
export
pipeline
without
having
to
be
pre-configured
with
a
tracer
and
coming
out
of
that
conversation,
we
we
came
to
the
conclusion
that,
having
removed
the
tracer
method
off
of
span,
which
was
kind
of
a
holdover
from
open
tracing,
was
the
right
thing
to
do,
because
the
tracer
is
not
the
thing
that
the
people
actually
want,
but
that
capability
of
being
able
to
say
I've
got
a
span.
C
Now,
let
me
create
a
new
span.
That's
on
the
same
export
pipeline
is
still
an
important
use
case,
and
so
we
added
the
tracer
provider
method
to
the
span,
which
enables
the
user
to
get
the
tracer
provider
that
they
can
create
a
tracer
from
that
they
can
then
create
a
span
from,
and
we
will
bring
that
up
to
the
spec
for
inclusion
in
the
span
interface
in
the
future.
C
B
F
C
E
One
I
understood
I'll
say
that
hi
everybody
I
haven't
been
here
in
a
while
welcome
back
wow
yeah,
hey
how's,
it
going
good.
I
remember
there
was
once
in
the
very
early
stages
of
open
census
or
actually
open
tracing
the
ability.
E
To
get
a
tracer,
and
this
is
how
this
kind
of
merged
I
I've-
never
liked
that
I
wish
a
span
would
give
you
its
context,
but
I-
and
I
wish
there
was
a
way
to
get
from
context
to
like
active
tracer
or
tracer
provider,
but
that's
just
my
own
personal
private
wish.
C
C
So
I
think
there's
definitely
improvements
to
be
made
there
and
I
agree
that
it
might
be
better
to
to
say:
hey.
I've
got
a
span
context,
something
give
me
a
tracer
provider
for
this.
I
think
that
gets
back
to
global
values
and
and
registries,
and
things
like
that.
That
would
make
the
the
build
kit
people
uncomfortable
because
they
they
dislike
the
idea
of
a
global
tracer
provider
as
well.
So
there
would
be
a
lot
of
stuff
to
work
through
with
you
know.
C
How
do
we
define
that,
and
I
think
this
is
the
straightforward
path
of
least
resistance.
It's
clear
to
understand:
what's
happening,
it's
clear
that
it
needs
to
be
an
optional
method
on
in
in
the
spec
right.
I
can't
think
of
an
implementation
that
wouldn't
be
able
to
get
from
a
span
to
its
tracer
provider,
but
it's
possible
and
I
don't
think
it
should
be
required.
But
if
it's,
if
it's
possible
to
provide
it,
I
think
it
should
be
provided
it's
a
nice
convenience.
B
Yeah-
and
I
think
I
think
what
josh
was
talking
about-
I
was
kind
of
considering
as
well
yesterday
in
that
conversation
is
to
like
so
right
now
we
have
the
tracer
provider.
You
know
return
function,
hanging
off
the
span
but
like
we
also
have
these
context
aware
functions
where
you
can
get
like
the
current
span
from
a
context
or
something
like
that
like
there
may
just
be
a
use
like
in
the
api.
B
Just
to
say
like
give
me
the
current
tracer
provider
for
this
context,
and
if
doesn't
one
doesn't
exist,
you
get
a
no
op
but
yeah.
I
think
that,
as
anthony
kind
of
said,
as
well
that,
like
since
the
open
tracing
kind
of
already
decided
on
that
api,
there's
our
users
that
expect
it
to
be
there
and
so
much
so
that
they
were
like.
Why
did
you
get
rid
of
this
tracer
api
on
the
span?
B
We
need
this
and
we
go
like
well
actually,
like
the
concept
of
a
tracer,
has
changed
from
open
tracing
to
open
telemetry.
So,
like,
let's
provide,
I
think,
what
they're
expecting,
which
is
going
to
be
a
tracer
provider.
So
then
they
could
scope.
It
with
a
tracer
but
josh
one
important
thing
is,
like
you
have
been
a
part
of
this
conversation
as
well
for
a
long
time-
and
I
kind
of
remember
this
in
the
specification
that
this
is
a
really
important
thing
for
multiple
tracer
providers.
B
So
if
you
have
a
tracy
provider
with
different
span
limits
or
sampling
or
something
else
like
using,
a
global
doesn't
actually
solve
the
problem
like
unless
you
have
like
like
anthony's
thing,
maybe
a
registry
or
something
because
like
if
you
want
to
like,
send
it
from
one
export
pipeline
to
another.
You
can
do
it
with
like
a
spam
processor,
but
the
sampling
is
above
the
span
processor.
The
span
limits
are
above
so
you
would
have
to
essentially
like
re-implement
this
entire
concept
in
your
own
span
processor.
B
So
I
think
this
is
a
really
positive
change.
Where
say
something
like
a
span
is
coming
down
the
pipeline
from
one
tracer
provider
and
you
can
do
something
with
it
and
then
it's
coming
down
the
pipeline
from
another
tracer
provider.
It
can
do
you
know
no
problem
it
can
handle
both
of
those,
I
think,
is
kind
of
an
important
use
case
that
we
are
seeing
in
this.
E
Trying
to,
I
feel,
like
I
somehow
missed
the
connection
and
I'm
sorry
I
think
I'm
a
little
out
of
context
right
now
with
some
of
the
stuff
that
you
are
all
talking
about.
I,
I
guess
the
reasons
that
I'm
familiar
with
for
wanting
to
know
your
own
tracer
provider
are
like
you're
working
in
a
multi-tenant
environment
and
someone's
going
to
start
a
span
and
then
you're
going
to
like
make
some
child
spans
from
that
and
you,
the
person
doing,
that
want
to
create
a
span
in
the
same
tracer
or
something
like
that.
E
Tracer
a
tracer
from
the
same
sdk
concept,
but
that's
like
not
a
very
well
established
concept
on
its
own.
I
think-
and
that's
probably
what
the
reason
why
I
got
confused
by
what
you
said,
but
I
think
you're
we're
talking
about
the
same
stuff,
yeah.
B
E
B
Are
same
thing
yeah,
and
exactly
also
it
was
a
really
interesting
use
case
that
they
showed
in
the
build
kit
for
moby.
B
It
was
where
this
was
coming
from
and
they're
doing,
like
tracing
through
test
builds,
so
they're
running
like
in
docker,
the
docker
api
is
calling
out
to
some
cloud
system
and
that
cloud
system
is
calling
it
to
something
else,
and
so
it's
like
traversing
all
of
this,
like
docker
api
interfaces,
just
you
know
by
using
the
build
kit
stuff
and
then
returning
to
a
single
instance
of
they
were
using
jager.
I
think
yesterday,
but
it
was
like
it
was
really
cool
to
see
that
entire
span
set
up
so
yeah,
really
cool.
C
Yeah,
I
think
that
gets
the
the
question
of
the
otlp
transform
and
the
interesting
use
case.
They
had
there
where
what
they
were
doing
was
they
were
using
a
reversal
of
the
otlp
transform
and
our
sdk
as
effectively
a
mini
collector.
C
So
a
big
piece
of
their
pipeline
is
instrumented.
Has
an
otlp
exporter
that
ships
to
build
kit
d,
which
receives
the
protobuf,
transforms
that
back
into
a
span
and
then
that
build
kit
d
is
what
actually
has
the
connection
to
the
desired
exporter,
whether
that's
otlp
or
jager,
or
reception,
or
something
like
that
and
it
after
transforming
the
protobuf
trades
into
an
sdk,
trace,
hands
that
to
the
actually
configured
exporter
and
sends
it
along.
So
the
the
thing
inside
of
the
container,
that's
that's
being
built.
C
The
docker
file
processing
has
no
connection,
has
no
idea
where
it's
actually
shipping
it
just
knows.
I
can
talk
to
this
build
kit
d
and
provide
it
this
data
and
it
ends
up
being
shipped
to
the
right
place,
which
was
very
cool
to
see,
and
I
I
think
it's
something
that
the
collector
may
be
able
to
better
support
if
it
were
set
up.
More
as
a
library
than
as
an
application,
but
ours
was
with
the
implementation
of
this
small
reverse:
transform
from
htlp
to
span
data
able
to
fill
the
function
quite.
C
B
Cool
I'm
trying
to
short
this
project
board.
I
think
one
thing
I
can
do
for,
I
think
maybe
we
already
kind
of
talked
about
this
project
board
idea.
I
am
moving
on
the
topic
from
this.
I
think
everyone
on
the
call,
if
you
can
review
the
releasing
pr
that
anthony's
got
out
that'd
be
great,
but
I
think
we
could
probably
I
just
want
to
jump
back
in
here
and
see
what
people's
thoughts
on
this
are.
B
There's
this
ticket
right
here,
I'm
thinking
we
just
close
this
and
take
the
remaining
task-
should
be
moved
to
a
new
issue.
Does
everyone
probably
say
good
on
that?
I
can
create
the
issue
afterwards.
B
C
A
C
C
A
Yeah,
so
just
any
documentation,
that's
left
outstanding
is
the
only
thing,
that's
probably
blocking
1.0.
If
that's
not
already
done.
B
The
website
docs
need
to
be
updated.
Oh,
are
you
going
to
include
that
in.
C
In
the
pre-release
vr,
though,
for
rc1,
because
there's
stuff,
that's
there
that
references
vo20
that
needs
to
be
updated
explicitly
and
just
have
passed
to
make
sure
that
the
example's
there,
because
they're,
not
buildable
examples.
The
compiler
won't
catch
them
in
our
tests.
So
you
need
to
make
sure
that
they're
actually
current
and
then
probably
also
figure
out
who's
dealing
with
the
website,
while
austin
is
taking
care
of
tiny,
tiny
human.
B
Is
a
million
dollar
question?
I
thought
that
you
were
supposed
to
manually,
resync
it,
and
then
I
was
told
explicitly
that
you're
not
so
I
don't
have
no
idea
what
that
pipeline
looks
like
these
days
but
yeah.
I
agree.
We
should
probably
figure
that
out.
B
B
Okay,
I
think
we
need
to
create
an
issue
about
that
one
as
well,
because
we
need
to
be.
I
think
we
talked
about
this
in
a
previous
sig,
but
we
probably
want
to
track
sending
out
and
explicitly
asking
for
feedback.
I
think
was
a
good
idea.
B
I
don't
know
if
josh
is
still
here.
Did
he
he
just.
B
B
Okay,
well,
anthony's
been
a
really
good
boy
this
year,
so
you
should
give
him
a
good
birthday
present.
That's
all
I'm
saying
how.
A
About
any
use
cases
other
than
the
build
kit
that
you
already
gave,
which
sounds.
B
Pretty
neat
yeah.
I
would
love
to
answer
that
question.
That
was
the
only
one
I
know,
but
yes,
if
anybody
else
does
any
of
this
david,
any
update
on,
like
I'm
sorry
guys.
D
So
I
do
actually
have
an
update,
although
it's
not
like
complete,
so
I've
been
waiting
like
eight
or
ten
months
now
for
kubernetes
to
resolve
their
protobuf
and
grpc
dependency
problems,
and
they
seem
to
have
implemented
some
hack
work
around
specific
for
kubernetes
but
they're
past
it
at
least
so
now,
I'm
no
longer
blocked
by
that.
B
B
D
B
C
B
I
don't
have
to
say
what
year
I
mean:
that's
that's!
How
open
cemeteries
was
founded.
We
were
going
to
release
a
stable
sdk
in
winter,
so
we're
still
we're
still
on
track.
C
On
the
on
the
use
case
front,
I
have
a
meeting
tomorrow
with
someone
here
at
amazon
who
is
working
on
instrumenting
container
d
as
well,
so
it
will
be
cool
to
see
what
they're
working
on,
and
I
think
they
already
had
a
couple
pr's
that
have
started
to
flow
through
what
they
need.
Ttrpc
support.
C
D
B
I
I
feel
guilty
because
you
said
that-
and
I'm
just
reminded
in
the
back
of
my
head
on
my
stack
of
things
to
do
is
review
that
pr
for
ttrp
support.
We
have
in
the
repo,
so
understood
message
received
yeah,
okay
cool.
Well,
I
don't
want
to
take
up
too
much
more
of
your
time.
It
sounds
like
we've
got
some
really
good
use
cases
today,
and
hopefully
some
really
exciting
news
tomorrow.
So
yeah
thanks
everyone-
and
I
will
see
you
all
virtually
next
week.