►
From YouTube: 2021-06-09 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).
B
A
A
A
A
So
probably
don't
expect
too
quick
of
a
response
on
friday
this
week,
it's
a
friday
anyway,
so
it
is
what
it
is,
but
next
week
bart
will
be
gone
the
whole
time.
What
I
wanted
to
talk
about
is
when
we
have
maintainers
on
vacation
for
a
week.
How
do
we
want
to.
A
A
This
is
really
more
of
a
question
for
bart
than
anyone
else.
What
what's
the
expectation
here?
What
do
you
think
we
should
do.
B
A
There
will
be
two
maintainers
here:
if
a
pr
is
small
or
not
high
impact,
then
maybe
we
can
merge
with
just
one
but
we'll
see.
Hopefully
it's
just
not
a
problem.
B
A
An
issue
was
created
yesterday
requesting
a
change
in
the
api.
This
is
not
required
by
specification.
It's
just
a
consistency
thing.
Do
we
change
the
span
context,
call
to
be
named
span
context.
Do
we
want
to
do
the
same
thing
with
a
link?
A
If
so
this
blocks
the
1.0
until
we
can
get
it
merged
or
if
not,
we
can
just
say
it's
unfortunate
that
we
missed
this
and
close
it.
Personally.
I
would
vote
for
just
closing
this,
since
it's
not
causing
problems
and
I'd
like
to.
D
B
B
F
You
have
three
seconds
to
speak
up
yeah.
I
opened
this
one
and
I
I
kind
of
agree
as
well.
It's
it's
minor,
maybe
is
there
like.
Do
you
guys
want
to
backlog
this
until,
like
the
next
major
release,
or
just
close
it
or
whatever?
I
kind
of
just
wanted
to
call
it
out
so
that
it
wouldn't
get
lost
at
all.
D
A
F
Sorry,
I
was
going
to
say
in
the
python
set
we've
also
like
you
know,
we
could
make
the
rename
and
then
mark
this
one
as
deprecated.
So
just
so,
it's
like
tracked,
but
without
actually
creating
a
breakage
or
whatever
just
like
a
few
options.
E
Yeah,
I
was
about
to
suggest
the
same
thing.
Sort
of
add
a
second
one
and
mark
this
as
deprecated.
A
C
E
C
I
do
understand
us
not
wanting
to
you
know,
push
the
release,
release
forward
like
by
small
increments,
and
do
it
like
forever,
but,
on
the
other
hand
like
it,
will
likely
stay
like
this
for
years
to
come
so
where's
the
hurry
in
that
sense,
with
the
1.0
release
like
let's
like
solve
the
small
inconsistencies
and-
and
you
know,
push
the
release
forward,
it's
like
or
like
do
we
have
a
time
pressure
in
that
sense
or
right.
What's
the
pro
side,
basically,
what
I'm
asking.
A
The
time
pressure
that
I'm
thinking
of
honestly
is
that
bart
goes
on
vacation
tomorrow
for
10
days,
and
I
will
be
on
vacation
friday.
So
if
we
can't
get
this
merged
and
released
today,
it's
pushed
for
a
significant
amount
of
time.
A
B
Fart
you're,
okay
with
that
yeah,
definitely
I
mean
it
never
be
perfect.
Honestly,
I
know
it's
like
always
in
the
end,
people
want
to
think
you
know:
okay,
one
more
thing,
one
more
thing,
one
more
thing,
and
after
one
month
you
realize
okay,
there's
one
more
thing:
it's
like
in
a
joke.
You
know
you're
asking
how
far
is
going
to
be,
and
then
someone
tells
you
hey.
You
see
that
rock
yeah,
so
after
this
log
just
a
bit
a
little
bit
further,
so
it's
like.
B
E
I
guess
the
other
way
is
like
in
app
insights.
I've
effectively
tagged,
I
don't
know,
probably
a
couple
of
dozen
of
api
functions
as
deprecated,
but
we
have
zero
plans
to
remove
it.
They're
only
tagged
for
tree
checking
capabilities
so
effectively.
We
rather
than
being
in
you
know,
names
based
on
a
utils
function.
We've
got
them
as
root
names
so
that
as
long
as
you
don't
use
it
you
end
up
with,
like
you
know,
10k
smaller.
E
A
Okay,
I
did
also
create
a
release
proposal
for
the
core
repository
to
release
version
21,
which
uses
version
21
of
the
api.
I
don't
really
have
much
to
say
here
other
than
please
review
it.
A
We
will
create
a
contrib
release
immediately
following
I
actually
already
made
the
pr,
but
it
fails
because
no
21s
have
been
released
yet
from
core.
I
don't
expect
anything
to
be
a
problem,
so
once
the
once
the
core
emerges,
I
will
re-trigger
the
build
on
this
and
it
should
be
okay.
A
A
Okay,
I
noticed.
A
Yes,
20
api,
21
and
api
1.0
are
practically
the
same.
The
only
difference,
I
believe,
is
a
ts.
Config
change,
there's
very
little
yeah,
so
we
enabled
the
no
implicit
override,
which
requires
you
to
add
the
override
keyword
and
made
a
documentation
change
so
other
than
that
the
code
is
functionally
identical.
A
A
Tests
this
pull
request
I
put
in
here
because
we
had
already
brought
it
up
last
week
and
it's
still
not
merged
the
reason
that
I
was
waiting
on
this
because
there's
a
few
open
discussions
here-
and
I
just
wanted
to
hear
from
from
the
people
that
were
involved
in
these
discussions-
is
there
any
anything
in
here?
That's
currently
blocking
the
pr
or
do
we
still
think
that
this
is
good
to
go
in
its
current
state?
I'm
not
that
familiar
with
the
with
browser
events.
So
I'm
not.
A
E
Yeah,
my
comment
was
really
about
which
considered
the
other
ones.
It
wasn't
a
blocking
comment
and
I
haven't
done
any
ie
testing,
but
I
have
concerns
that
ie
works
at
all
for
open
telemetry.
At
this
point,.
E
E
Yeah,
I
think
I
think
it's
a
three-year
timeline,
which
we
we've
already
for
app
insights.
We've
already
started
the
calendar
to
say
in
three
years
we're
not
going
to
support
ie
at
all,
so
this
comes
back
to,
I
think
our
open
question
ages
ago
about
what
is
our
browser
metrics
support,
which
I
don't
think
we
fully
defined.
A
There
are
a
couple
of
packages
like
the
api,
the
semantic
conventions
package,
various
ones
like
that
which
we
have
compiled
for
older
node
targets
as
well.
That
should
be
compatible
with
the
high
e,
but
for
the
actual
like
tracing
itself,
you
know
that
the
the
sdk
itself,
I
think,
ie
support-
is
most
likely
lacking
and
has
not
been
a
real
priority.
B
A
So
one
quick
question
in
the
current
state
of
this
pr:
will
it
break
ie
11
or
will
this
feature
just
not
work
on
it.
E
The
the
standard
issue
that
we've
got
yeah
well,
I
do
point
out
there.
There
is
another
issue
which
we
found
recently
in
app
insights:
that
people
who
hook
the
events
after
the
sdk.
If
they
want
to
send
telemetry,
we
probably
want
a
flag
so
that
we
don't
go
batch
it
we
want
to
make
it
a
flush
through.
B
E
Yeah,
it
really
is
an
edge
common
case,
like
we
had
sites
like
msn
and
that
wanting
to
hook
and
send
their
own
telemetry
in
terms
of
unload,
and
previously
we
told
them
to
hook
the
event
before
they
initialize
us,
but
we
can't
guarantee
that
in
all
cases,
so
it
is
an
edge
case.
It's
a
it's
a
corner
issue.
A
B
A
Now
last
week
you
mentioned
that
you
would
maybe
look
into
tooling
yeah.
E
A
B
Who
added
this
last
yeah?
I
had
it
because
it's
pretty
informal
reason,
I
don't
understand
why
it's
breaking.
A
A
C
A
D
A
A
A
Other
than
that,
anyone
have
anything
that
they
would
like
to
talk
about.
F
A
So
we've
already
done
sort
of
a
spec
review
and
I
think
we're
actually
good.
What
we
need
to
do
is
solidify
our
release
and
versioning
story.
So,
like
the
the
independent
versioning
like,
we
don't
want
to
release
metrics
with
a
1.0
version
number.
We
don't
want
to
release
the
metrics
api
with
a
1.0
version
number
and
things
like
that.
So,
with
our
current
release
process,
we
actually
can't
release
1.0
on
the
sdk,
but
I
believe
that's
currently
the
only
blocker.
A
I
would
say
whenever
that
blocker
is
done,
we
will
also
at
least
wait
until
bart
gets
back
from
vacation,
and
I
started
looking
into
this
morning.
Browser
stack
and
I
would
like
to
have
that
before
we
release
1.0
also
so,
hopefully,
by
the
time
park
gets
back.
We'll
have
something
to
review
for
that.