►
From YouTube: 2021-01-13 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
I'm
very
confused
by
why
zoom
decides
to
put
its
things
on
various
screens.
Can
you
all
see
the
the
my
screen
share
of
the
agenda?
B
B
Tyler,
how
are
things
in
the
state
of
florida?
C
B
B
All
right
well
looks
like
we
have
a
relatively
small
crew.
Today
I
was
going
to
be
very
excited
and
announced
that
we
released
0.14
and
we
did
accept
that
the
bomb
was
mispublished,
so
we
had
to
do
a
patch
release
I'll
be
working
on
that
today.
B
B
We've
got
a
few
more
sdk,
tweaks,
cleanups,
etc.
To
do.
B
But
we're
getting
super
close,
so
plan
is
still
kind
of
have
odot
15
released
by
the
end
of
the
month
and
have
it
be
our
1.0
release.
B
Gameplay
or
whether
we'll
just
declare
it
we'll
see,
let's
figure
that
out
ga
burned
down.
I
should
I
actually
wanted
I
wanted.
I
was
thinking
about
creating
a
1.0
milestone
in
github,
so
I
could
actually
track
what
we
actually
need
to
get
done
for
1.0
before
we
can
declare
it
released,
but
I
haven't
done
that
yet.
So,
if
I
have
time
I
will
try
to
get
to
that,
there's
not
very
much.
I
think
it's
mostly
documentation
plus
a
couple
sdk
issues.
B
B
Hope,
yeah
and
for
people
who
are
interested
in
metrics
there's
a
six
hour
meeting
on
friday,
which
anyone
is
welcome
to
join
in
we're
gonna
try
to
do
try
to
burn
down
some
metrics
sdk
api.
I
don't
know
spec
issues
see
how
that
goes.
It's
on
the
community
calendar.
B
D
Yeah
erin
mentioned
the
other
day
that
she
might
jump
on
onto
that.
If
I
don't
get
back
to
it
before
she
needs
it.
For
some
micrometer
stuff
cool.
B
B
Yeah
yeah,
I
mean
I've.
I
have
been
keeping
up
as
best
I
could
he
and
I
talked
offline,
a
bunch
about
it
also.
So
this
is
all
kind
of
in
lieu
of
doing
a
rewrite
of
the
sdk
to
match
the
spec
he's
been
working
really
hard
to
get
it
more
in
line
with
the
way
the
sdk
specification
is
currently
written,
and
then
just
uncovering
lots
of
cleanups
and
other
stuff
that
can
happen
there,
hey
josh
good,
to
see
you
glad
you
could
make
it.
E
Yeah
sorry,
I
had
a
meeting
run
way
over,
as
is
normally
yeah.
Is
that
how
it
works
at
google
yeah?
You
know
you
have
like
so
so.
Normally
you
would
be
walking
to
the
next
meeting
room
and
be
like
sorry,
we're
late.
This
meeting
room
is
really
far
away
now,
we're
just
like
sorry
we're
late.
You
know.
E
B
Cool
josh
did
you
have
any
topics
you
wanted
to
talk
about
because
everyone
seems
content
to
not
discuss
things
in
detail
this
morning.
E
The
only
question
I
missed
the
spec
meeting
yesterday,
so
the
open
census,
migration
shim
some
places
it's
marked
as
required
for
ga
in
some
places
it
is
not
marked
as
required
for
ga.
I
just
want
to
know
if
it
is
because
if
it
is,
I
will
finish
it
and
make
sure
ga
gets
out
the
door
if
it's
not
required
for
ga.
Maybe
it's
worth
having
more
discussion
on
some
of
it.
That's
that's
the
only
question
I
if
you
don't
know,
that's
fine.
I
have.
B
Assumed
that,
for
whatever
ga
means
I
mean
this,
was
actually
discussed.
What
is
ga
that
it
is
necessary
before
we
can
declare
open
telemetry
to
be
ga
that
doesn't
mean
1.0,
because
1.0
doesn't
have
metrics,
so
complete,
open
census,
shim
until
metrics
are
done.
Obviously,
right,
yeah.
B
The
door
yeah
yeah,
I
mean,
I
think,
the
way
we
are
way
things
are
right.
Now
we
have
the
open
sensor
stuff
tagged
as
dash
alpha
and
when
it's
ready
we
can
remove
the
dash
alpha
and
have
it
be
something
that's
long
term
supported
and
that's
really
that's
it's
kind
of
our
call
okay,
so
it
is
required
for
ga,
which
is
really
a
marketing
term
rather
than
a
technical
term.
B
At
this
point,
but
not
something
that
you
have
to
do
there
for
1.0,
because
1.0
is
whatever
we
decide,
is
stable
and
when
we
remove
the
dash
alpha.
E
Okay,
so
two
things
for
everyone
here,
then
one
is:
we
actually
changed:
the
implementation
of
open
census,
okay,
so
the
latest
release
of
open
senses
will
look
for
the
and
override
its
internals
to
use
the
shim
instead
of
its
own
internals,
when
it
exists
reflectively
via
class
path.
E
We
specifically
do
that,
because
open
census
is
a
little
less
configurable
than
I
had
realized
in
its
internals,
so
we
thought
that
was
the
best
solution
that
is
in
the
spec.
I
I
put
a
lot
of
implementation
details
in
the
spec,
so
there's
a
proposal
for
the
open
census,
ships
for
all
the
languages
and
unlike
open
tracing,
we
have
avoided
saying
that
there
won't
be
a
change
to
open
census
to
make
the
shim
work
better,
because
we
think
it's
just
going
to
be
better
for
the
users.
E
If
we
can,
you
know
line
these
things
up
a
little
bit
better.
The
the
second
thing
is:
there
are
unspecified
behaviors
in
open
senses
that
are
specified
in
open,
telemetry
and
actually
break
real
applications,
which
is
fun.
E
I
don't
know
how,
if
you
see
one
of
these
get
reported
as
a
bug
against
the
open
census.
Shim
feel
free
to
say
sorry,
because
I
really
don't
know
how
we
handle
that
it's
lit,
it's
unspecified
behavior
right
and
open
telemetry
specified
it,
for
example,
adding
parents
at
any
point
in
time
in
a
span's
life
cycle
versus
straight
in
the
beginning,
as
the
only
option
that
was
unspecified
in
open
census
and
is
allowed,
it
is
not
allowed
in
open
telemetry.
E
I
don't
think
we
just
allow
it
for
the
shin
right,
so
I
just
wanted
to
confirm
and
make
sure
that's,
okay
with
everyone
here
and
have
a
little
mini
java
discussion
around
that.
B
Seems
fine
to
me,
can
you
not
add
them
as
links
instead
of
like
as
strict
parents
would
mean
this.
E
I
there
was
an
issue
with
links
to.
Let
me
take
a
look
at
what
I
wrote
you
might
be
able
to
that
might
be
a
decent
solution.
B
Take
a
look
anyway.
This
seems
fine.
I
think
it
might
be
really
good
to
in
the
maybe
in
the
open.
I
don't
know
if
people
will
ever
read
it,
but
maybe
have
a
read
me
in
the
open
census,
shin
module
that
just
kind
of
explains
the
current
known
issues.
E
I
think
if
it's
not
already
there,
it
was
documented
internally,
and
I
put
it
into
the
I
put
it
into
the
proposal
for
the
spec,
but
I
can
throw
in
a
readme
there
as
well.
The
thing
to
remember,
though,
is
we
cannot
change
the
package
names
of
anything
in
the
shim,
because
it's
reflectively
instantiated.
B
E
B
11
or
whatever,
yeah
okay,
I
forgot
about
that.
Yeah.
The
module
system
can't
have
two
modules
loaded
in
the
same
vm
that
share
a
pack
an
exported
package,
so
that
which
one
of
the
reasons
why
we
took
our
apis
when
we,
when
we
sold
them
apart
and
repackaged
everything
into
sub
packages.
B
So
this
is
it's
a
yeah
java
module
system.
E
Limitation,
so
the
the
only
one
that
would
have
to
change,
I
think,
is
the
metrics
one
I'll
tell
you
what
I'll
I'll
put
together
a
proposal
that
hopefully
doesn't
look
like
crap,
but
I
don't
want
to
have
to
release
another
major
version
of
open
senses
for
this,
because
we
already
have
a
version
that
theoretically
supports
this
that
was
released
before
I
took
over.
So
okay
cool
thanks.
That's
that's
all
I
had.
B
E
B
Yeah,
we
definitely
have
no
no
goal,
no
plans
at
all.
I
mean
right
now,
that's
part
of
the
api
and
all
that
packaging
is
basically
locked
in
place,
so
we're
not
planning
on
doing
any
repackaging
any
repackages
we'd
be
doing
would
be
in
sdks
or
extensions
at
the
moment,
but
context
racing
main
metrics
who
knows,
but
that
stuff
is
all
in
locked
in
place.
Now.
E
Oh,
I
did.
I
did
have
one
other
thing
to
ask
about,
so
the
propagators
text
map
propagators
that
are
registered
right
now.
The
open
census
shim
is
hard
coded
to
only
do
w3c
header
propagation
in
text
map,
not
the
configured
one
from
the
sdk
okay.
E
Should
I
make
it
be
the
configured
one
from
the
sdk
opencensus,
never
supported
baggage
previously,
but
I
from
what
I
understand,
of
the
implementations
and
from
what
I've
seen
and
tested.
If
I
just
start
using
the
sdk
contributed
propagators,
a
user
using
the
open,
telemetry
shim
could
get
open
senses
to
start
propagating
baggage
and
whatever
propagation
that
they
configure
in
open
telemetry.
Is
it
worthwhile
to
do
that.
B
I
guess
is:
is
there
harm?
I
guess
I
don't
know
enough
about
open
census
to
know.
E
Here's
here's
the
scenario,
so
I'm
using
say:
grpc
java,
that's
instrumented
with
opencensus.
I
use
open
telemetry
in
my
application
and
configure
the
sdk
and
the
shim,
and
I
configure
my
text
map
propagators
and
they
don't
work
right
right.
What's
my
expectation
as
a
user,
my
thinking
is
they
assume
that
the
shim
should
be
working
and
that
grpc
would
be
propagating
baggage
right
from
an
open
sense
standpoint:
it's
invisible
to
everything,
because
you
can
only
access
baggage
via
the
open,
telemetry
api.
E
B
Yeah,
that's
interesting,
I
mean
baggage.
Is
in
such
a
w3c
baggage.
Is
in
such
a
nascent
state.
It's
I
mean
it's
barely
specified.
The
spec
is
not
complete.
It's
not
marked
as
final,
so
I
mean
my
gut
would
be
if
my
gut
says
that
if
there's
a
user
ex
who
wants
to
configure
the
baggage
property
when
it's
not
working
with
grpc
in
the
open
census
gym
I
mean
I
think
I
mean
two
options
either
we
just
say
this
is
not
currently
supported,
sorry
or
and
and
because
the
the
spec's
not
complete
yeah.
B
I
don't
know,
I
don't
know,
I
don't
know
the
right
answer
there.
It's
users,
I
don't
know
what
users
are
going
to
do
if
they're
really
going
to
think
like
if
our
open
census
user
is
going
to
expect
every
feature
of
open
telemetry
to
work.
I
mean
we
already
know
that
that
won't
be
the
case
right.
There's
going
to
be.
E
B
D
B
Doesn't
include
the
parent
thing
you
mentioned,
but
we
can
add
that
obviously,
but
I
think
it's
probably
worth
just
unless
you
want
to
make
it
work
and
implement
it
just
document
the
unsupported
future.
So
it's
literally
a
one-line
change
to
make
it
work.
I
mean
it's
your
call:
you're
the
you're,
the
open
census
boss.
Here,
oh.
E
E
Happen
anyway:
okay,
okay,
if
no
one,
if
no
one
has
any
like
known
issues
or
concerns,
I
might
just
make
it
work
for
the
sake
of,
I
think
that
might
be
better
for
people
in
the
long
run.
I
really
don't
want
this
open
census
bridge
to
last
longer
than
a
few
years,
but
you
know
how
long
it
takes
enterprise
to
move
so
yeah.
B
Stable
it
was
like
like
pulling
teeth
to
even
get
everyone
to
agree.
We
didn't
have
to
support
java
7
anymore,
so
yeah
wait
really
oh
yeah.
That
was
well,
I
mean
initially,
it
was
grpc
that
was
blocking
it.
So
I
have
nothing
to
do
with
that.
I
promise
anyway,
yeah
that
took
a
year
of
negotiation
and
wrangling
to
finally
get
all
the
vendors
to
agree.
We
didn't
need
to
support
java
7.
B
so,
which
is
one
of
the
reasons.
I
think
why
it's
taking
us
so
long
to
get
everything
stable,
because
when
we
finally
were
able
to
push
to
java
8,
we
could
actually
use
java
8
features
in
our
apis
and
there
was
a
whole
bunch
of
rework.
We
wanted
to
do
right
then,
like
we
could
put
static
methods
in
our
interfaces
and
we
could
do
all
sorts
of
things
that
are
super
useful
from
an
api
perspective,
so
yeah.
I
think
it
actually
slowed
the
java
project
down,
probably
by
six
months,
that
whole
debate.
Unfortunately,.
D
B
It's
done
cool
yeah,
they're,
putting
that
bag
of
sport
in
there
is
total.
That's
totally
fine,
I've
absolutely
no
problem
with
it
at
all.
I
mean
right
now
at
this
point,
josh
all
the
open
senses,
stuff
you're.
The
only
expert
I
mean
I'm
sure
bogdan
is
around
and
knows
a
lot
of
that
since
he,
I
think,
wrote
a
lot
of
it.
But
since
he's
not
at
google
anymore,
it's
not
something
he's
focusing
much
on
so.
E
Yeah
yeah,
that's
cool,
so
the
only
other
thing
around
open
census
that
we've
been
dealing
with
is
a
lot
of
observability
of
open
senses
itself.
Being
a
problem
like
when
telemetry
goes
down
from
open
census.
How
easy
is
it
for
users
to
find
and
fix
that,
and
that
sort
of
thing
I
noticed
in
the
c-plus
plus
sigs
that
I've
been
attending
that
I,
as
the
implementations
roll
in,
because
you
know
c
plus
plus,
is
well
ahead
of
everyone
else.
E
The
most
loved
language
in
the
whole
ecosystem,
the
as
implementations,
roll
in
that's
a
concern
that
keeps
getting
deferred
right.
I'm
not
sure.
If
that's
the
case
in
java,
I
suspect
it
is
just
because
that's
how
I
roll
with
gambling
and
people,
so
I'm
kind
of
curious
how
you
think
the
failure
scenarios
are
for
java
are
like
if
I'm
a
user
things
aren't
working.
How
hard
is
it
for
me
to
figure
this
out?
E
You
know
I've
been
in
the
I
finally
been
able
to
pay
attention
to
getter,
even
though
that
ui
is
awful.
Now
I
don't
know
what
happened
to
2010,
but
it
was
way
better
back
then
or
whatever
2015.
Maybe
anyway,
I've
been
paying
attention
to
that
and
I've
been
seeing
some
some
questions
show
up
with.
Like
you
know.
Why
is
this
not
working,
and
you
know
john's
easily
able
to
answer
some
of
these
things
but
like
how
does
someone
who's
new
to
it
actually
discover
what's
wrong,
how
to
fix
it?
E
Those
kinds
of
error
messages.
You
know
the
other
80
of
development
right
of
feature
complete,
and
how
can
I
help
here
is
kind
of
one
of
my
questions,
because
what
in
open
census,
that's
like
all
the
bugs
I'm
getting
that
we
need
to
solve
and
fix
that
our
p
zeros
are
effectively
around
telemetry,
disappeared
completely
right.
B
B
I
think
the
answer
is.
Whenever
we
come
up
with
one
of
these
cases,
we
should
figure
out.
If
there's
a
way,
we
can
log
information
that
would
highlight
it
and
make
it
easy
to
easier
to
to
debug
or
let
people
self-debug,
because
I
mean
I
think
we
all
know
we're
not
going
to
be
able
to
guess
what
all
of
the
crazy
things
that
customers
users
are
going
to
do,
because
they'll
always
be
able
to
think
up
something
crazier.
B
So
I
think
that
the
and
I
think,
a
lot
of
the
issues
that
I've
run
into
that
I've
heard
people
talking
about
on
getter
and
discussions
et
cetera,
are
interactions
with
the
agent
when
you
have
the
agent
and
you're
trying
to
do
things,
and
things
aren't
working
right
with
the
agent
rather
than
the
sdk
itself,
because
the
sdk
itself
is
pretty
dumb.
There's
not
that
much
going
on.
B
Most
of
the
issues
with
the
sdk
itself
are
revolved
around
misconfiguration
of
the
collector
or
the
exporter,
pointing
at
the
wrong
port
or
that
kind
of
stuff,
and
the
exporters
tend
to
yell
pretty
loudly
when
things
are
broken,
but
they
don't
necessarily
know
precisely.
Why,
like
all
they
can
say,
is
I
can't
talk
to
this
thing?
They
can't
know
that
people
have
misconfigured
their
ports
or
whatever.
B
B
Work
right
now:
okay,
I've
done
a
bunch
of
there's
actually
a
project.
There's
a
module
in
the
project
called
perf
harness,
which
is
probably
it's
not
it's
a
terrible
name
for
it,
but
there's
a
in
there
is
basically
just
a
kind
of
a
rough
setup
for
doing
this
kind
of
testing
like
what
happens
when
the
collector
goes
down
and
it
uses
toxoproxy
right
now,
which
is
not
perfect,
but
at
least
we'll
can
do
coarse,
green
things
just
to
verify
what
happens
when
the
back
end
or
when
the.
B
When
the
exporters
can't
talk
to
the
collector,
for
example,
I
use
it
mostly
to
verify
that
it
would
that
it
wouldn't
cause
memory
leaks.
I
haven't,
and
I,
but
I
do
know
that
it
re
it
reconnects.
Just
fine,
I
mean
it's
uses
grpc
and
all
of
those
normal
grpc
stuff
work
work.
The
way
they're
supposed
to.
B
E
Well,
yeah,
that's
that's
like
a
different
mode
of
failure,
but
yeah
that's
awesome
is
it
do
we
have
any
of
that
in
the
spec
either
and.
B
Is
it
worth
it?
I
think
it's
not
in
the
spec.
This
was
just
something
I
did
because
I
actually
was
funny
when
I
was
interviewing
with
splunk
they're
like
if
you
could
do
one
thing
to
make
sure
that
this
was
successful.
What
would
it
be
and
like
we
need
to
write
some
things
to
show
what
happens
when
things
go
bad,
so
that
was
like
my
first.
The
first
thing
I
did
once
I
joined
the
company
so
nice.
No,
I
don't
think
any
of
that's
been
specced.
B
I
think
it
would
be
really
good
to
at
least
have
something
in
the
spec
about
you
know:
failure
modes
and
how
things
how
things
should
respond,
but
yeah,
I
don't
think,
there's
anything
there
right
now.
Okay,.
E
Yeah
yeah
yeah,
that's
that's
good.
We
yeah,
short-term
buffering
is
also
fun.
I
think
the
expectation
of
having
a
local
agent
is
going
to
be
an
awesome
thing.
If
the
community
adopts
it
wholesale.
B
For
sure
it's
definitely
the
model
that
splunk
is
trying
to
push
as
much
as
possible
yeah,
and
that
is
the
one
thing
the
buffering
of
data
is.
I
have
we
have.
You
know
the
spam
processor
is
configurable
with
how
much
it
will
buffer
and
what
the
limit
of
the
buffer
size
before
it
drops
and
that's
the
kind
of
stuff.
I
was
worried
that
making
sure
it
worked
the
way
it
was
supposed
to
and
it
will
start
dropping
data
when
its
queue
gets
full,
and
you
know
that's
the
for
when
you're
running
something
in
process.
B
B
I
haven't,
I
think,
the
baggage
apis
right
now
do
they.
I
don't
actually
don't
remember
what
that
looks
like.
We
do
have
some
fuzz
testing
on
baggage
propagators
to
make
sure
that
if
you
send,
if
someone
sends
garbage
in
over
the
wire
that
we
don't
misbehave,
but
I
don't
know,
I
don't
know
how
we
deal
with
like
super
large
buffers.
I
haven't.
I
don't
just
don't
remember.
E
That's
literally
the
only
api
I
can
think
of
that's
not
protected
by
something
else
that
has
protections.
So
that's
why
I
was
curious.
B
Yeah,
I
don't
remember
precisely
whether
the
baggage
api
limits
sizes
right
now
I
mean
at
some
point,
there's
nothing
you
can
do
if
somebody
does
something
super
malicious
and
just
opens
up,
opens
up
a
connection
and
starts
streaming
data
at
you,
you're
dependent
on
your
app
server
right,
not
something
something
we're
in
control
of,
but
well.