►
From YouTube: 2021-02-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
A
Hey
wait
if
he's
reinstalling
the
system
and
might
be
the
problem
with
showing
privileges
you
have
to
train
this
in
the
system.
C
Yeah,
no,
I
don't.
I
don't
have
privilege
problems,
it's
just
that
every
now
and
then
ever
since
updating
to
big
sur,
my
screen
sharing
just
freezes
halfway
through
my
share
that
happened
last
night.
Remember.
A
C
C
C
D
Yeah,
okay,
can
you
actually?
Maybe
let
me
give
you
the
link
unless
you
go
to
prs
and
search
for
pr
style
miami?
I
think
it's
this
one
right.
D
I
did
not
anticipate
how
I
would
go
first.
Yet
is
this
one?
So
I
remember
we
talked
about
this
before
but
was
some
time
ago.
So
the
gist
is
that
sdk,
sdk,
section,
sdk
environment
variables,
describes
an
environment,
variable
called
hotel
propagators
and
it's
a
comma
separated
list
of
well
names
of
propagators
and
then,
when
we
discussed
it
last
time
it
was
only
baggage,
trace,
context,
b3
and
the
aeger.
D
And
since
then
there
has
also
been
an
addition
of
x-ray
and
ot
trace
and
they
are
in
described
in
specification
now,
but
they
are
also
highlighted
as
a
third
party.
D
And
then
that's
the
default,
so
the
default
is
trace,
context,
comma
baggage,
that
hasn't
changed,
and
so
I
think
that
issue
that
valentin
mentioned
here
was
that
we
are
pulling
jaeger
from
contrib
into
core,
and
my
reasoning
behind
that
is
that
jaeger
is
part
of.
D
I
would
call
it
supported
out
of
the
box
propagators.
So
I
guess
users
can
have
an
expectation
of
like
if
I
said,
hotel,
underscore
propagators
to
say
jager.
I
would
expect
a
jager
propagator
to
be
globally
enabled.
D
But
I
don't
know
if
I
understand
it
right
so
like
if,
if
I
was
a
user-
and
I
say,
auto
propagator
is
jager,
I
would
expect
eager
propagator
to
just
work,
and
so
I
think
you
mentioned
that
core
cannot
rely
on
contrib,
and
so,
if
we
want
jager
to
just
work
in
this
scenario,
we
have
to
have
a
node
package
depend
on
jaeger
propagator
package.
D
Hence
it
is
that
you
know
that
that
pr
is
for
moving
jager
from
contributor
core,
and
then
the
discussion
was
kind
of
extended
to
also
you
know
talk
about
x-ray
and
multi-trace
the
third-party
propagators,
because
by
and
I
think,
nikita
who
is
in
specification,
I
want
to
say
or
java
hotel
sig.
He
also
told
me
that
third
party
propagators
should
not
be
in
core
or
contrib.
D
I
think
I'll
have
to
look
for
that
quote,
but
if
we
want
to
support
x-ray
or
ot
trace
values
for
hotel
underscore
propagators,
there
has
to
be
a
way
for
these
packages
to
tell
core
that
they
are
available
to
be
instantiated.
C
Yeah,
okay,
so
it
seems
to
me
that
there's
two
ways
we
can
interpret
this
one
is:
if
I
set
the
environment
variable,
then
it
should
just
work
which
seems
to
be
the
way
that
you've
interpreted
it.
The
second
is,
if
I
set
the
environment
variable
and
that
propagator
is
installed,
then
it
should
work,
in
my
opinion,
at
least
the
third
party
ones,
x-ray
and
ot
trace.
C
We
should
say
the
second
one
if
it's
if
the
environment
variable
is
set
and
the
x-ray
propagator
is
installed,
then
enable
it
because
we're
obviously
not
going
to
include
the
x-ray
propagator
in
core,
we
are
going
to
include
it
in
contrib
moving
forward.
So
I
don't
know
if
you
can
find
your
conversation
from
nikita.
C
I
would
appreciate
it,
but
I
think
this
is
the
direction
that
all
of
the
cigs
are
moving
is
allowing
them
to
be
in
contribute,
and
that's
what
will
has
been
working
on
over
the
last
two
or
three
weeks
which
we
may
hear
from
him
later
today.
D
D
I
think
I
meant
so
it
says
there
that
additional
vendor-specific
protocols,
such
as
x-ray,
must
not
be
maintained
or
distributed
as
part
of
open
telemetry
or
it's
a
score.
Okay,.
C
D
Maybe
this
has
changed
since
like
last
week,
because
I
I
distantly
remember,
ulti
trace
being
described
as
not
as
vendor
specific
and
so
to
not
be
distributed
with
open
telemetry.
So
maybe
they
added
that
core
in
the
meantime.
So,
okay,
do
you
get
from
that
document
that
jaeger
should
be
in
the
core?
Or
what
do
you
think.
C
I
mean
I
so
I
think
this
is
the
the
important
part
here
must
be
distributed
as
open,
telemetry
extension
packages.
In
my
mind,
anything
that
is
required
by
the
specification
should
be
in
core,
though
the
way
I
look
at
it
is.
If
we
deleted
the
contrib
repository
entirely,
we
should
still
be
specification
compliant,
which
means
we
need
to
move
jaeger
to
the
core.
D
Yeah
that
makes
sense
to
me:
okay,
so.
E
D
D
C
So
I
think,
moving
yeager
to
core
makes
sense
to
me,
but
ot
trace
and
x-ray
will
continue
to
live
and
contrib.
D
Okay,
can
we
can
we
make
a
note
of
that
in
the
dark?
Yes,
thank
you.
C
And
will
since
you're,
obviously
working
on
the
x-ray
contrib
like
permissions
and
deployment,
and
things
like
that.
That
sounds
reasonable
to
you
right.
E
Yeah
totally,
I
I'm
fine
with
having
the
requirement
to
install
the
propagator
as
long
as
it
grants
the
ability
to
set
up
the
environment
variable.
That's
that's
totally
cool
with
us.
Okay,.
D
And
the
second
second
thing
we
want
to
to
discuss,
I
think,
was
how
should
propagate
or
packages
interact
with.
I
think
it's
core.
I
think
it's
api,
I
placed
it
in
api
propagation.
I
don't
know
if
you
agree
with
that,
but
that's
where
I
placed
it
at
the
time
now.
The
question
is:
how
do
we
want
to
allow
propagators
to?
I
don't
know,
register
themselves
under
a
name
or
leave
that
to
the
user
or.
C
D
Can
you
take
a
look
at
my
pr
because
that's
what
I
did.
A
D
A
D
B
C
C
D
C
Any
any
propagator
that
doesn't
have
a
distribution
like
that,
I
don't
think
we
should
depend
on
the
distribution
in
order
to
call
this
register
named
propagator.
C
I'm
just
asking
in
the
general
case
when
would
register
name
propagator
be
called
if
you're
requiring
the
user
to
then
import
the
jaeger
propagator
package
and
then
call
some
function,
which
itself
will
call
register
name
propagator,
then
we're
not
providing
any.
You
know
nothing's
happening
automatically
at
that
point,
the
user
is
changing
their
code,
anyways.
C
I
think,
instead
of
having
a
registration,
we
should
just
have
a
essentially
a
list
of
well-known
names,
ones
that
are
supported.
C
So
we
just
have
a
map
from
name
yeager
to
package
name
at
open,
telemetry,
slash,
propagator,
yeager
and
declare
it
as
a
optional
peer
dependency,
and
if
it's
installed
it
will
be
used
and
then
you
can
even
have.
If
someone
tries
to
use
the
environment
variable
that's
wrong.
We
can.
You
know
log
some
error.
That
says
you
attempted
to
initialize
a
propagator
that
is
not
installed
falling
back
to
the
default
or
something
like
that.
C
C
It
doesn't
allow
ones
that
we're
not
aware
of
to
automatically
register
themselves,
but
you
know,
and
in
order
to
register
itself
something
will
have
to
be
called
in
the
code.
Anyways
there's
no,
but
did
do.
Do
you
see
what
I
mean.
D
This
self-registration
allows
just
this
one
line
to
be
added,
so
you
don't
have
to
make
any
more
changes
in
the
code,
but
I
understand
that
it's
still
a
change
in
the
code.
I
think
when
we
discussed
this
option
of
the
pure
dependencies,
we
dismissed
it
because
there
is
no
optional
pure
dependency
in
npm
unless
it
was
added
in
npm
seven,
it
was
added
and
I
think
it's
actually
backwards.
C
Compatible
to
npm
six,
somebody
else
brought
this
up
to
do
with
the
instrumentations,
but
there
is
the
let's
see
here.
D
Okay,
that
makes
sense
so
then
ot
trace
and
x-ray
becomes
okay.
So
how
does
this
handle
npm-6,
so
it
handles
npm-6
with
warnings
right
if
you
have
a
pure
dependency,
which
is
on
matt,
that's
a
warning
right
and
we
accept
it
correct.
C
Version
record
here
we
go
six,
oh
yeah,
so
there's
no
pure
dependencies
meta.
So
in
npm
six
it
would
warn
and
then
npm
seven.
It
would.
C
D
C
You
know,
because
users
will
see
those
warnings
and
say
hey,
what's
going
on,
because
not
everybody's
using
npm
seven
yet
so.
We'll
just
have
to
document
that
this
is
an
issue
with
npm
6,
but
that
it's
only.
D
C
You
can't
use
the
typical
import
statement.
You
would
have
to
do
like
import
module
equals
require
name,
you
have
to
use
the
other
syntax,
but
that's
fine.
D
Okay,
I
guess
that
that
works.
For
me,
the
list
would
be
what's
in
the
spec
and
if
we
accept
the
warnings
in
npm
six,
then.
C
Maybe
in
like
a
post
install
stage
a
post,
install
step,
we
could
log
something
like
if
you
see
peer
dependency,
warnings.
D
C
D
Right
so
and
for
node
for
node.js,
we
will
of
course
have
all
of
these
try
to
be
imported
and
for
the
web
we
will
have
those
which
makes
us
on
the
web
and
what
we
said
is
that
propagators
have
such
a
small
size
that
it
will
not
affect
bundle
size
that
much
and
we
just
always
import
them.
It's
too
difficult
to
instruct
the
bundler
of
any
kind
like
webpack
or,
whichever
to
not
add
them
to
the
package,
or
we
would
have
to
do
like
webpack
specific
stuff.
C
Much
rather
have
it
be
the
opposite
for
the
web.
I
think
we
should
avoid
unnecessarily
growing
the
bundle
size,
and
I
think
we
should
say
if
you
want
to
use
the
x-ray
propagator.
You
must
install
it
and
configure
it.
A
So
maybe
we
can
create
like
extra
package,
we'll
create
like
a
web
friendly
package
which
will
be
extended.
A
A
A
A
No,
not
for
each
propagator,
I
I
would
assume
we'll
have
just
for
the
whatever
package
will
be
importing
the
those
tracers.
Yes,
if
we
move
it
to
the
node
tracer,
then
we
don't
have
this
problem
at
all.
A
C
So
why
would
the
web
not
work
the
same
way
that
no
does
it
not
support
the
pure
dependencies?
Meta
does
webpack
not.
A
No,
I'm
talking
about
that.
You
that
you
don't
need
wait,
we're
talking
about
not
not
to
add
the
propagator
to
the
web.
Yeah.
A
Or
because
we
still
need
to
decide
where
we
want
to
some
propagating
loader
to
be
to
be
put
here
to
each
package,
yeah.
A
C
A
C
C
E
Yeah
I
mean
it's,
it
certainly
should
the
x-ray
is
not
added
yet
but
like.
I
can't
imagine
why
it
wouldn't
works
in
with
hdb
normally
as
a
in
its
current
state.
C
D
I
like,
if
you
have
a
pure
dependency
it.
Doesn't
it's
not
automatically
installed
right,
so
you
have
to
install
it
manually.
So
if
you
never.
D
There
is
nothing
to
be
bundled,
so
it
looks
like
we
are
good.
I
think
what
started
us
last
time
was
that
npm
6
warning
is
why
we
haven't
pursued
that
option
of
having
all
of
these
be
peer
dependencies.
C
I
just
don't
I'm
not
excited
about
all
of
the
npm
six
users
that
are
going
to
start
getting
these
warning
logs
and
you
know
they're
going
to
say,
what's
going
on,
I'm
getting
warning
logs
when
I
install
open,
telemetry
and
then
they're
going
to
come
open
support
tickets.
I
think
we
need
some
way
to
head
that
off.
C
D
That
makes
sense
to
me:
do
you
want
to
make
a
note
of
that
and
we
should
be
upset.
C
The
say
the
my
sequel
module,
for
instance,
includes
us
as
a
dependency,
which
is
something
that
we
hope
they
eventually
do.
C
C
C
I
just
don't,
I
think
if
we
have
these
warnings
on
the
api,
we're
we're
going
to
be
setting
ourselves
up
to
have
troubles
with
adoption
later
on.
C
Yeah.
Okay,
I
added
this
next
item
here
it
I
just
typed
this
up
off
the
top
of
my
head.
So
if
anyone
has
any
concerns
about
this
or
comments,
it's
definitely
not
set
in
stone,
but
I
just
wanted
to
make
everybody
aware
of
the
the
timeline
that
or
at
least
the
series
of
events
that
need
to
happen
before
we
can
release.
C
As
far
as
I'm
aware,
the
only
api
pr
that
we're
waiting
on
is
the
diag
logger
api,
which,
as
of
this
morning,
is
in
pretty
good
shape.
I
think
there's
only
some
minor
things
on
it
and
I
expect
it
to
be
merged
fairly
shortly.
C
C
I
hope
that
we
can
do
that
this
week,
if
at
all
possible,
after
that,
there
is
an
old
api
pr
that
I
had
opened
that
I'm
going
to
close
in
the
core
repository
and
reopen
in
the
api
repository.
C
After
that's
merged-
and
I
expect
you
know,
discussions
with
the
maintainers.
C
The
sdk
rc
is
primarily
waiting
on
the
plug-in
deprecation,
so
once
that
dot
once
that's
done,
I
expect
to
move
towards
rc
for
the
sdk
also
and
then
we'll
have
our
actual
1.0
release.
C
Does
that
seem
reasonable
to
everybody
here,
particularly
bart
and
valentine.
F
C
F
C
C
C
C
C
So
you
know
I
I'm,
I
think
the
api
will
be
most
of
the
work
done
for
the
api
repository
will
be
done
this
week.
So
then,
next
week
I
think
I'll
start
focusing
on
converting
the
rest
of
the
you
know
I'll
a
plug
in
and
convert
it
to
instrumentation,
and
I
think
we
should
just
assign
them
as
we
as
we
go
so
that
we
know
who's
working
on
what
yeah.
F
Yeah
sure
I
I
think
I
will
I
plan
to
to
migrate
both
express
and
mongodb
to
instrumentation
this
weekend,
since
I
already
wrote
them
in
the
first
place,
it
will
be
quick
and
if
I
have
time
I
try
to
do
more,
but
I'm
not
sure
I
would
just
focus
on
making
both
expressions.
C
C
After
that's
done,
I
think
we're
gonna
be
ready
for
an
sdk
rc,
so
we
need
to
also
start
doing
the
same
thing.
We're
doing
with
the
api
just
make
sure
we're
compliant
with
the
specification
and
make
sure
we're
happy
with
you
know
our
configuration
story
and
stuff
like
that.
I
expect
that
process
to
also
probably
take
a
week
or
two
you
know
just
based
on
the
fact
that
we
found
we
kept
finding
things
in
the
api.
C
C
B
C
I
don't
have
much
else
to
talk
about
today,
so
if
anyone
has
anything
that
they
would
like
to
bring
up
now
would
be
a
good
time
for
that
and,
if
not
I'll,
let
you
guys
go.
C
Okay,
well,
I
hope
everybody
has
a
good
week
and
I'll
talk
to
you
guys
next
wednesday,
thanks
here.