►
From YouTube: 2020-10-21 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).
C
C
C
C
C
C
Nikita
I
saw
that
there's
attacks
on
our
election
integrity
coming
from
estonia,
you
wouldn't
know
anything
about
that.
Would
you.
B
B
C
All
right
well
give
another
minute
or
so
to
see
if
anybody
else
shows
up,
hey,
there's
carlos.
D
Flats,
yes
still
in
still
in
prague,
though
yeah
yeah
yeah,
but
I
got
kicked
out
of
my
flat,
so
I
will
move
the
temporary
flat
and
then
I
will
go
to
mexico.
After
for
christmas
or
winter
yeah
yeah,
let's
see
how
things
go
well,
yeah.
C
All
right
again,
carlos
and
jason-
add
yourself
to
the
edge.
Oh,
we
got
ken
also
good
to
see
you
again.
Agenda
is
pretty
lean,
so
people
have
things
they
want
to
talk
about.
Please
go
ahead
and
add
them
to
the
agenda.
I'll
give
my
usual
ga
burndown
update.
C
We
finished
10
items
in
the
last
week,
which
is
good.
We've
got
four
in
progress.
I
think
those
are.
They
may
be
kind
of
stalled
at
the
moment.
So
if
you
have
something
that
you're
working
on
carlos
take
a
look
at
it
and
there's
nine
p2
issues,
which
is
two
less
than
last
week,
I
just
added
another
one.
This
morning
report
the
jaeger
example
isn't
working.
C
Although
the
eager
exporter
is
working
so
not
super
critical,
but
something
to
look
at
we're
making
just
kind
of
as
an
update
anurag
and
I
have
been
working
very
hard
with
everyone
else's
assistance
in
review
about
getting
the
apis
really
tightened
up,
pre
ga
tracing
apis,
mostly
in
context
apis.
C
I
think
we're
getting
getting
pretty
close
to
having
something
really
solid
and
great.
I
just
put
a
put
a
note.
Second
agenda
item.
That's
a
pretty
significant
change
to
make
open,
telemetry
an
interface
with
an
implementation
rather
than
just
being
much.
C
C
But
yeah
and
he
and
there's
a
there's,
a
follow-on
pr
already
created
that
fixes
the
naming
so
perfect
yep.
C
So
I
think
that's
going
to
be
good
to
go.
If
people
could
just
take
a
look
and
throw
an
approval
on
it,
that
would
be
great
all
right.
Well,
that's
all
I
have
anybody
else.
Have
anything.
D
Yeah,
I
guess
that
I
know
I
promise
the
jager
propagator
part,
which
is
part
of
the
getter
keys
change.
It's
it's
in
my
it's
locally.
It's
working.
I
just
need
to
do
more
cleanup
for
the
testing
part
and
thanks
to
your
lately
latest
changes
john,
I
will
just
have
to
use
the
api
for
the
baggage
portion
so
yeah.
I
hope
that
I
can
have
a
pr
by
the
end
of
the
day
today,.
D
C
That
was
a
that's
an
issue
right
yeah.
We
need
to
make
a
decision
on
that
before
ga,
because
after
ga
is
definitely
going
to
be
too
late
there
doesn't,
I
didn't
see
any
incredibly
strong
opinions
on
done.
It
either
way.
B
C
Yeah,
I
know
I
know,
there's
opinions,
I
didn't
I
just
what
I
was
saying.
I
don't
think
there's
strong
opinions
like,
I
don't
think
it's
gonna,
it's
not
a
life
and
death
issue.
If
it's
the
other
way,
but
I
also
haven't
seen
any
real,
I
think,
did
christian
have
an
opinion.
The
other
way
his
opinion
was
the
other
way
right.
C
Yeah
I
mean
I'm
I'm
as
I
said,
I'm
fine
with
it.
I
don't
have
a
lot
of
strong
opinion
on
that.
So
oh.
D
I
guess
that
I
just
prefer
the
way
it
is
now.
So
it's
a
matter
of
personal
taste
and
I
guess
in
general
I
don't
like
changes
that
are
like
mostly
just
for
it's
like
a
personal
taste,
which
is
probably
an
irony,
but
anyway.
E
D
Just
wasting
that,
but
I
am
perfectly
fine
with
it,
especially
given
the
reasons
presented.
B
Well,
that
season
not
only
about
personal,
personal
taste,
it's
it's
about
some
simplification
for
auto
instrumentation.
F
F
That
thing
where,
where
you
have
specific
packages,
shipped
by
specific
artifacts
and
so
on-
and
I
don't
know
how
that
plays
with
the
current
thing-
and
that
may
help
make
a
good
decision
here-
I
mean
it-
may
having
it
under
that
api
may
help
with
that
as
well.
But
I
don't
know
exactly
the
story
and
I've
never
used
those.
G
I'm
also
not
super
familiar
with
modules,
but
we
had
this
come
up
recently
on
one
of
our
projects
and
we're
still
struggling
with
it.
But
the
fact
is
that
separate
modules
cannot
export
the
same
package
name
that
was
new
to
me
and
so
by
keeping
it
flat,
you
can
strain
other
modules
in
the
future
from
ever
using
that
namespace.
F
C
C
F
C
F
C
F
E
Just
for
some
color
around
gpms
from
a
red
hat
perspective,
we
tend
not
to
use
it
in
our
projects,
even
when
we're
using
java,
11
and
beyond.
F
E
Right,
I'm
just
saying
like
taking,
if
we're
talking
about
taking
the
jump
to
including
jpms
modules
and
structure,
that
that
will
have
other
implications.
That
may
not
always
be
good,
but
I'm
also
like
switching
the
package
name,
it's
itself
to
facilitate
that,
but
not
necessarily
taking
the
next
step.
If
that
makes
sense,.
C
But
if
someone
does
want
to
use
the
packaging
system
module
system,
we
shouldn't
stop
it
cool.
Well,
thanks
for
the
feedback
on
that,
somebody
put
a
comment
about
moving
moving
the
meeting.
D
Yeah,
that's
me
sorry
bogdan,
you
didn't
make
it
to
the
pc
call,
but
it
has
been
very
hard
to
find
a
common
time
for
everybody
to
meet.
So
it
seems
that
meeting
every
two
wednesdays
for
the
tc,
eight
and
a
half
pacific
time
will
be
a
good
time.
D
D
C
So
so,
basically
so
you're
considering
moving
it.
I
I'm
totally
fine
with
9
30.,
especially
since
I
have
a
10
to
11
p.m.
Meeting
on
tuesday
night,
if
I
could
sleep
in
a
little
bit
more
on
wednesday
morning,
that
would
not.
C
All
right,
I
will
post
I'll
I'll
well
yeah.
I
will
post
something
action,
all
the
next
one
and
post
something
in
get
her
just
to
see.
If
anybody
will
yell
and
scream
about
it.
I
guess
the
only
people
who
would
affect
mostly
is
people
in
europe,
because
it
would
mean
it's
another.
This
half
hour
later
european
time,
yeah
nikita.
B
C
C
D
Yeah
exactly
yeah,
okay,
given
that
I
will
confirm
with
the
dc
that
this
is
possible,
so.
C
D
C
All
right
any
thing
else
that
anyone
wants
to
talk
about
we're
getting
really
close.
I
mean,
I
know
that
there's
still
a
few
lingering
trace
spec
issues,
but
I
think
we're
actually
getting
really
close
to
having
something
that
we
can
start
to
call
release
candidate.
Oh,
I
guess
one
thing
just
to
note:
onroad
has
been
working
hard
to
move
all
of
our
builds
to
github
actions,
which
is
great
because
it's
like
the
builds
are
like
five
times
faster,
which
is
fantastic.
C
Having
some
trouble,
we
just
merged
the
thing
to
try
to
publish
snapshots
last
night
and
it's
not
working
so
I
think
donald
about
it,
but
we
may
need
some.
We
may
need
some
support,
but
we
probably
have
everything
we
need
to
figure
it
out.
I
just
want
to
let
you
know.
Snapshots
are
not
publishing
at
the
moment,
but
we'll
get
it.
C
If
anyone
was
working
on
the
rapidly
evolving
snapshot,
picture,
they're-
probably
feeling
a
lot
of
pain
anyway,
so
slowing
it
down
for
a
couple
days,
probably
all
right,
that
should
be
fine
yeah
I
mean
it
would
be.
It
would
affect
the
instrumentation
project
more
than
anyone,
since
they
and.
C
There's
a
couple
small
there's,
a
couple:
small
follow-ons
around
putting
static
methods
on
the
span
to
get
rid
of
the
public
usage
of
tracing
context
details.
C
D
C
Of
attention
but
monorock
had
a
super
clever
idea
about
how
to
make
it,
so
the
context
can
context
can
have
items
added
to
it
without
having
to
know
their
types
via
an
interface
that
those
types
can
implement.
So
the
key
is
the
key.
The
context
is
not
known
to
the.
The
key
is
not
known
to
the
context,
and
the
type
is
not
known
to
the
context
of
just
an
interface
that
the
types
can
implement.
So
our
span
currently
implements
this
the
new
interface
so
that
you
can
directly
stick
it
onto
the
context.
C
Yeah,
let
me
I
can
just
I
cannot.
I
can
pull
it
up
that
one
got
merged
yesterday.
It's
a
very
clever
idea:
yeah.
H
Nice,
where.
F
Why
am
I
not
seeing
18
20
18
27.
yeah
there.
C
So
the
way
what
it
boils
down
to
is,
there's
a
new
interface
called
implicit
context,
keyed
that
you
can
then
extend
and
provide
a
method
that
will
allow
the
context
essentially
to
store
you
so
that
the
key
is
not
known
to
the
context.
The
type
is
not
known
in
the
context.
Just
the
implicit
keying
is,
is
a
interface
that
the
context
can
use.
F
C
So
the
benefit
is
then
we
can
make.
We
can
use
the
api
that
looks
like
this,
so
you
can
attach
the
like
add
the
span
to
the
context
without
the
context
having
to
know
anything
about
tracing
in
particular
or
about
baggage.
We'll
do
this
with
baggage
also,
so
it
allows
a
very
easy
to
use
api
on
the
contents.
F
F
You
expose
this,
which
means
which
means
hear
me
a
second
which
means
you
if,
if,
for
example,
for
v2,
you
want
to
declare
a
new
interface
for
spam,
okay,
you
will
not
be
able
to
store
that
interface
in
the
context
and
do
a
wrapping
whenever
people
call
into
v1
api
so
to
make
an
exercise
of
this
and
to
give
a
try
to
see
if
this
is
beneficial
for
you,
for
this
think
about
coming
up
with
another
spam
interface
and
build
a
transition
path
for
that.
H
F
Don't
have
anywhere
where
you
can
execute
some.
So
in
this
scenario
here
you
don't
have
a
place
where,
for
example,
even
if
you
store
a
different
thing
in
into
the
context,
you
can
wrap
that
thing
to
look
like
a
v1
span.
C
F
F
It
is
a
problem
for
a
transition
perspective.
If
you
have
a
static
function
or
something
like
that,
you
can,
you
can
change
that
static
function
to
do
the
wrapping,
even
though
you
you
put
a
v2
span
into
the
context
anytime,
when
you
retrieve
v1,
you
will
actually
wrap
v2
into
a
v1
and
make
it
look
like
a.
F
C
F
You
you
have
a
static
method.
Tyler
you
have.
You
have
a
place
where
you
can
put
some
code
that
does
the
wrapping.
H
C
A
So
probably
the
the
more
important
side
is
on
the
retrieval
of
this
right.
Yes,
so
what
does
it
look
like
to
pull
that
span
out
of
the
context.
C
F
C
Mean
tracing
context,
utils
is
still
there
like.
It
hasn't
gone
away.
It's
just
no,
no
longer
public.
In
this
case,
it's
something!
That's
an
implementation
detail
of
the
way
that
things
are
stored
and
retrieved
anyway,.
F
C
G
C
A
Components,
I
I
think
the
thing
that's
weird
to
me
is
just
the
fact
that,
yes,
it's
a
little
bit
nicer
on
the
right
side,
but
on
the
retrieval
side,
it's
still
a
little
awkward.
Well,
the
retrieval
side.
C
I
think
is
still
using
tracing
context
details
and
I
think,
if
I
recall
honorary,
was
saying
that
there's
another
there's
a
follow-on
pr
that
he's
working
on
to
on
the
retrieval.
F
F
It
is,
it
is
open.
I
I
found
it
it's
open
now.
F
C
Okay,
so
here
yeah
yeah
yeah
this
so
this
is
this-
is
the
retrieve
the
first
part
of
the
retrieval
there's
another
one.
Maybe
the
scope,
one
is
the
one
I'm
thinking
of
I
haven't
taken
a
look
at
hey.
I
haven't.
I
don't
remember.
I
also
haven't
gotten
a
lot
of
sleep
but
yeah.
So
it
looks
like
the
retrieval
here.
You
can
get
it
with
span.current
if
you
want
it
out
of
the
current
context
or
from
context
with
a
given
context.
C
So
if
you
had,
for
example,
a
v2
span
here
that
implemented
from
context,
it
could
extract
itself
or
extract
itself
and
wrap
it
into
another
into
a
v1
span
or
cover
any
work.
I
believe.
C
H
A
A
F
I
mean
it's:
is
it
not
already
generic
in
some
sort.
H
H
C
F
F
C
Or
it
can
be
well
the
context.
The
context
needs
to.
F
Be
but
the
context
is
in
the
same
package
with
with
the
implicit
context
key,
so
they
can
call
a
package
protected
method
on
these,
but
you
spam
can't
implement
it.
If
it's
not
public.
C
What
no,
no
you
can
implement?
You
can
overwrite
even
a
private
label.
You
can't
implement
the
interface
if
it's
not
public.
If
it's
an
interface.
B
F
C
C
Yeah,
we
actually
had
some
debate
and
couldn't
necessarily
come
up
with
the
best
name.
For
this
there
was
a
lot
of
on
the
original
pr.
There
were
well
this
vr
here
that
I'm
looking
at
there
were
many
many
options
suggested,
and
I
don't
think
anything
rose
to
the
surface
and
we
kind
of
agreed
that
if
we
could
find
a
better
name,
we'd
be
happy
to
change
it.
C
A
C
F
F
E
F
That's
the
the
thing
that
worries
me
is
the
the
method,
the
method
name
here
and
the
method
not
being
public.
That's
what
I
was
mentioning
like.
I
would
like
that
method
to
not
be
public
if
possible,
because
that
may
that
may
not
expose
this
to
the
to
the
user
if
we
believe
it's
useful
to
have
it
exposed
to
the
user
as
expand
that
store
in
context.
C
Anyway,
I
think
so
just
off
the
top
of
my
head,
my
thoughts
are
open.
Telemetry
has
become
so
intensely
context,
oriented
rather
than
span
oriented
that
having
these
methods
that
make
it
super
clear
and
super
obvious
and
super
easy
to
interact
with
the
context
feels
like
a
feels
like
a
good
thing.
Yeah,
but
again,
maybe
name
just
in.
F
A
F
A
F
And
again,
I
would
not
design
necessary
an
api
with
that
first
goal.
My
first
goal
would
be
visibility
for
the
user.
If,
if
this
confuses
user,
I
would
trade
off
mocking
for
for
that,
but
it
doesn't
seem
to
be
the
case.
We
can
find
a.
We
can
find
a
trade-off
between
both,
but
if
I
would
have
to
choose
any
day
between
users
being
less
confused
and
ability
to
mock,
I
will
choose
the
user
being
less
confused.
I.
C
C
Yeah
and
the
the
big
one
big
thing
that's
nice
about
this-
is
that
we,
this
this
method,
that
honorable
cooked
up
doesn't
tie
the
context
to
tracing,
which,
I
think
is
what
we
really
wanted
to
avoid
and
make
sure
the
context
wasn't
aware
of
tracing
now.
It's
just
aware
of
this
kind
of
of
the
something
that
has
a
key
or
something
that
knows
how
to
store
itself,
which
is
a
good.
I
think,
a
good,
an
elegant
way
to
to
allow
the
context
to
interact
with
spans
directly
without
having
to
make
it
know
about
tracing.
F
Then
then
we
don't
have
to
create.
Let's
say
we
have
three
four
propagators:
we
don't
have
to
create
four
contexts
because
context
has
to
be
immutable
for
for
good
reasons
to
be
able
to
be
shared
between
threads
and
stuff.
So
right
now,
every
time
we
call
a
propagator,
we
create
a
new
context,
which
makes
we
make
another
copy
of
that.
F
If
we
return
this
thing
and
then
we
have
a
method
to
say
with
list
of
implicit
keys,
it
may
be
an
optimization
there
to
to
avoid
creating
too
many
context,
objects.
Yeah.
No
that's.
C
B
And
we
and
we
even
have
the
exact
same
problem
in
instrumentation
repo
when
we
actually
want
to
put
like
the
same
span
under
two
different
keys
for
different
reasons,
and
one
is
like
hidden
because
it's
exactly
this,
like
the
usual
way
to
put
span
into
context.
And
the
other
is
like
our
key.
And
now
we
use
like
trace
to
kill
context
spawn
with
current
contacts.
And
then
they
add
the
same
span
under
our
key.
F
B
C
There
was
a
discussion
about
this
very
specific
use
case
yesterday
on
this
late
night,
spec
meeting
or
the
afternoon
spec,
meaning.
I
think
about
reasons
why
span
context
in
several
implementations
has
its
own
key,
because
you
know
if
you
get
a
span,
context
context
of
the
wire
that
you
can
put
into
the
context
as
a
separate
key
and
know
that
there
that
there
is
a
like,
even
if
you're
down
way
down
in
the
guts
of
your
service,
that
there's
a
there's
a
remote
span
that
started
things.
F
C
D
Two
things:
first,
we
are
going
to
create
a
pr
to
rename
spam
reference
back
to
spam
context
and
the
second
one
is
very
valid.
Yeah
you're
gonna
hit
it
even
more
and
that's
why
we
wanted
you
there
it's
about.
Having
is
removing
the
concept
of
propagated
spam.
So
now
we
will
have
spam
context
and
hispanic
context.
D
You
will
have
what
a
spam
context
and
spam
in
context
like
no
not
propagated
spam.
Why
why?
Why
do
you
do
that
during?
What's
against
that?
It
says
that
it's
complicates
things
well,
you
can
check
out
the
notes,
but-
and
actually
we
need
to
discuss
that
more.
C
B
Anyway,
our
reason
in
instrumentation
is
even
simpler.
For
example,
we
have
we
want
to
prevent
two
client
spams
from
happening.
You
have
like
jax
rest
library
which,
under
the
hood,
uses
like
apache
http
client.
We
have
both
instrumentations,
but
we
don't
want
to
build.
Two
clients
span
nested
inside
each
other
and
in
general
you
can
have
as
many
layers
between
them
as
you
can.
So
we
we
want
to
know.
There
is
somewhere
client
span
already
present
in
this
context,
trace
what
not.
So
we.
B
That
answering
bogdan's
question:
why
do
I
put
the
same
thing
under
two
keys
and
span
key?
It
can
change.
I
don't
know
well,
not
no,
no,
not
in
the
client
case,
but
in
server
case
you
can.
I
can
have
servers
and
internal
internal
internal
and
then
one
more
instrumentation
which
may
want
to
create
server
spam
in
some
cases.