►
From YouTube: 2020-10-06 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
A
A
We
don't
have
anything
in
the
agenda
so
I'll
see
if
anyone
has
any
questions
which
requires
discussion.
Otherwise
I'll
just
share
some
updates
since
last
week
and
we
can
end
up
early.
So
if
there
are
any
and
also
we'll,
also
look
at
all
the
open
peers.
It
looks
like
we
have
quite
a
few
pending
here,
so
we
can
quickly
see
if
anything
requires
a
discussion
in
the
community
or
we
can
just
solve
it
in
the
pr
itself.
B
Yes,
cj.
I
just
wanted
to
check
in
right
quick
about
kind
of
ga
time
time
frames
so,
like
I've
been
hearing
this
rumor
that
in
the
the
broader
hotel
community
that
they've
been
talking
about
at
ga
date
earlier
in
november,
I've
been
hearing
november
9th
and
I
know
obviously,
we
wouldn't
be
able
to
ga
before
um.net
5gas.
B
But
I
did
just
want
to
check
and
see
if
there
was
any.
You
know,
indication
that
we'd
be
gaining
before
the
november
30th
deadline
or,
if
that's
still,
what
we're
targeting.
A
Yeah,
so
it's
still
the
blind
to
ga
in
november
itself,
so
it
could
be
a
number
30
or
before,
but
it
can
definitely
be
after
number
10,
because
that's
the
date
when
diagnostic
source
would
be
ga.
So
I
would
expect
some
time
between
number
10
and
number
30,
most
likely
towards
more
closer
to
the
number
30
time
frame,
but
definitely
before
december.
A
That's
the
current
plan
and
that
hasn't
changed
only
like
only
like
extra
thing,
which
we
need
to
call
out
here
is
the
matrix
will
not
be
marked
as
ga,
and
that
is
the
same
message
I'm
getting
from
the
overall
specification
as
well.
There
will
be
separate
gas
for
matrix
and
tracing
and
we'll
follow
the
same
thing
we'll
mark
our
tracing
api
as
ga
ready,
metrics
would
be
beta,
and
it
is
quite
likely
that
we'll
have
logging
or
source
g.
A
A
I
think,
like
the
logging
part,
is
where
I've
been
spending
most
energy
in
the
last
two
weeks
like
earlier,
just
to
repeat
in
case
someone
is
not
here.
So
the
metric
api
is
not
yet
closed
from
a
spec
standpoint.
However,
for
logging
the
spec
simply
says:
go
and
use
whatever
is
available
api.
If
there
is
one,
but
eventually
the
specification
would
write
a
logging
api
on
its
own,
but
so
far
there
is
no
apa
to
implement.
All
we
need
is
just
that
any
existing
one.
A
It
is
the
high
logger
api
which
we
are
accepting
as
the
logging
api,
and
the
only
thing
which
we
need
to
really
do
is
have
an
ability
to
stamp
the
two
series
and
ready
to
the
I
logger
log.
So
all
these
are
already
done.
So
we
have
work
in
progress
prs
which
would
expose
things
like
log
exporter,
basically
mimicking
whatever
we
have
for
tracers.
A
So
it's
like
mostly
ready,
but
it's
like
actively
being
worked
on.
So
I
expect
it
should
be
like
good
enough
to
use
by
end
of
this
week,
but
that's
pretty
much.
The
update
which
I
wanted
to
share
like
about
the
progress
of
vlogging
and
then
yes
back
to
any
any
other
open
questions.
C
A
So
initially
it
was
told
in
the
specification
that
we
will
allow
it
in
the
main
repo,
that's
what
the
spear
did
like
it
is
allowed
to
be
in
the
main,
like
main
repo
itself.
However,
right
after
this
was
merged,
there
is
some
discussion,
it
says
no,
it
should
not
be,
and
it's
there
is
an
open
period,
but
the
new
location
it
can
be
either
the
contribut
reports
entry
or
it
could
be
like
purely
vendor
specific.
So
that
part,
I
I
don't
know
what
was
the
yeah.
A
So
I
think
morgan
is
clarifying
that
we
can
exist,
we
can
have
it
in
the
country
repositories
or
in
the
vendor
specific
or
anywhere
else.
So
as
long
as
it's
not
in
the
main
repo,
it
looks
like
it
is
fine,
but
just
give
me
like
one.
C
The
rationale
is
that
that
maintainers
should
not
be
responsible
for
like
vendor-specific,
propagator,
okay
and
yeah,
so
for
propagator.
That
makes
sense
to
have
like
in
the
separate
contrib
repo,
but
I
think
for
the
trace
id
generator
that
that
can
go
in
the
main.
The
core
ot
report.
A
Now
let
me
see
if
there
is
anything
about
yeah.
This
is
purely
about
propagators,
but
okay,
we
have
it.
So
can
you
explain
like
what,
like
the
customers
who
use
the
custom
trace
id
generated,
would
be
always
assumed
to
be
having
an
adobe
specific
exporter
as
well
right.
C
A
Specific
exporter
right,
so
I
was
wondering
like
will
it
make
sense
to
have
it
in
the
awa
specific
package
and
not
in
the
main
repository?
I
I
mean
I
need
to
recollect
my
memory
on
what
this
pr
was,
but
it
looks
like
you
are
overrating
the
trace
id
to
be
x-ray
compatible.
A
So
this
makes
sense
if
you
are
using
like
at
a
base.
Exporter.
C
I
actually
I'll
have
to
probably
like
double
check
on
that.
If,
if
the
exporter
is
compatible
with
the
both
the
w3c
standard
of
trace
id
and
also
the
x-ray.
A
A
Help
if
you
can
also
share
your
thoughts
in
the
actual
runtime
issue,
I
think,
if
not
linked
here,
I
can
find
that
because
it's
possible
that
other
vendors
are
also
interested
in
making
that
api
exposed
in
the
container
itself.
So
if
that
happens,
if.net
decides
to
id
generators,
then
you
would
have
to
do
this.
Of
course,
you
still
need
it
for
anything
released
until
now,
because
dot
net
file
is
essentially
closed,
so
whatever
proposal
we
have
will
be
accepted
already
for
the
next
release,
which
will
get
there.
A
A
Wanting
to
do
it-
and
that's
where
I
like
found
this
issue
like
greg
from
datadog,
who
was
doing
some
experiment
for
the
auto
instrumentation
effort
faced
with
the
need
to
generate
trace
id
in
a
different
way.
So
that's
probably
what
triggered
the
whole
discussion-
and
this
looks
like
aws-
has
the
exact
same
need.
A
You
have
a
you,
have
a
desire
to,
or
you
have
a
need
to
override
the
trace
id
generation
part
so
like
separately
to
this
pr
like
this
pr
we'll
decide
whether
we
can
host
it
directly
here
or
in
the
contrib
or
in
the
aw
specific
report,
but
separately.
We
should
try
to
pursue
whether
it
should
be
made
part
of
the
runtime
itself,
and
if
you
cannot
find
the
issue,
I
think
I
linked
it
somewhere,
but
I
can.
C
I
think
eddie
eddie
posted
it
in
the
chat.
Okay,
yeah
that
should
be
cool,
yeah
yeah.
That's
something.
C
These
two
open
pr's.
No,
I
think
that
that's
everything
from
my
end
bolu,
my
teammate,
who
created
this
pr,
is
also
on
the
call
if
he
wants
to
add
something
to
it,
feel
free.
A
A
Haven't
merged
it
yet
is
I
mean
it's?
It's
just
always
like.
If
the
spec
decides
that
we
don't
want
it
in
the
main
tripod
and
we
will
have
to
just
clean
the
pad
again
move
it
somewhere
else.
So
that's
why
I'm
just
like
holding
on
to
it
until
the
final
definition
by
the
maintenance
is
formalized
in
the
spec
repo,
so
it
should
be
like
done
like
this
week.
If
not,
I
can
follow
up
with
morgan
and
carlos
who
who
oppose
the
idea
of
having
it
in
the
main
ripper.
C
Yeah,
no,
that
that
makes
sense,
at
least
for
the
propagator.
It
makes
sense.
I'm
still
like
thinking
about
the
trace
id
generator
yeah.
A
I
mean
worst
case.
I
think
this
can
be
like
in
the
contrary,
before,
depending
on
how
many
it's
like,
it's
only
like
a
couple
of
lines
of
code,
it's
relatively
easy
from
a
maintenance
perspective
and
internet
compared
to
propagator,
which
could
be
like
a
little
bit
more
important
than
that
yeah,
but
as
to
the
actual
pr,
I
did
look
at
it
like
a
few
weeks
back
but
yeah
once
I
will
get
some
more
free
time
and
I
can
take
another
look.
A
Okay,
yeah:
let's
quickly,
look
at
all
the
open
players
I'll
go
from
them
to
up
believe
this
is
the
order
in
which
they
are.
A
E
Yes,
that
pr
was
for
the
public
api
analyzer,
so
we
were
waiting
before
ga
to
double
check
the
public
api,
so
we
can
remove
or
remove.
A
Oh,
I
see
I
remember
yeah
okay,
so
I
think
I
put
the
tag,
don't
merge
because
we
were
actively
changing
public
ap,
so
this
will
be
a
pain
to
maintain.
But
let's
do
this
thing
as
soon
as
we
do
the
next
release,
which
is
expected
to
happen?
A
I
think
in
a
week
or
two
I
had
to
check
the
milestones.
When
is
the
next
release
mark
october
14
right
here,
so
once
we
done
with
that
release?
After
that
we
don't
expect
like
major
changes
to
the
api,
because
we
only
have
like
one
month
before
the
ga.
So
at
that
time
we
can
do
the
merge
this
one,
so
this
would
act
as
a
gatekeeper
to
catch
if
we
are
accidentally
changing
anything
public.
A
So
I
tag
it
for
something
after
0.7
which
should
be
0.8.
So
let
me
just
do
that
right
now,.
A
A
A
So
what
this
br
is
trying
to
do
is
automate
the
test,
basically
create
a
test,
app
use
our
instrumentation
and
run
the
w3c
test
against
it,
and
we
expect
around
ninety
percent
passes.
The
ten
percent
are
known
cases,
so
this
pr
is
just
marking
and
separating
the
machine
on
versus.
A
Like
actual
failures,
I
will
see
if
phone
can
provide
an
update
or
don't
really
look
like
what
was
the
status,
so
yeah,
no
action
here.
Let's
wait
for
sean
to.
B
Come
back,
it's
cj,
sorry,
right!
Quick
on
that
last
one.
I
had
a
question
and
actually
that
this
is
for
you,
paulo,
but
we
were
talking
about.
You
know,
trace
context
in
this
sig
meeting
last
week
for
auto
instrumentation,
and
I'm
just
wondering
if
we're
doing
anything
like
this.
You
know
similar
to
this
on
the
auto
instrumentation
side
of
things.
F
So
the
idea
that
I'm
I'm
trying
to
to
push
is
to
be
able
to
use
the
same
one
that
we
have
on
the
the
repo
the
the
manual
one.
But
we
are
still
on
dealing
with
the
prototype
about
bringing
the
the
activist
force
wrapper.
So
I
think
we're
gonna
get
to
a
resolution
for
that
later.
But
but
my
idea
at
least
is
to
try
to
bring
that
one.
A
So
it's
okay
to
be
like
little
bit
delayed
and
the
official
release,
but
it's
nice
to
have
you?
Okay.
Third,
one
is
a
top
change
trick.
D
Yeah,
hey
cj
yeah.
This
is
alan.
Sorry,
I've
missed
the
past
couple
of
sick
meetings
and
I
actually
had
space
that
this
pr
was
still
out
there.
You
know
I
had
all
those
docs
update
changes
and
I
guess
I'd
forgotten
that
this
one's
still
superseded
happening,
something
else.
No,
I
think
it's
current.
I
I
can
refresh
my
memory
since
I
actually
haven't
looked
at
this
in
a
little
bit,
but
I
think
it's
probably
good
to
go.
D
There
was
some
question
about
more
or
less
unrelated
to
this
pr,
but
something
I
noticed
from
this
pr
just
some
confusion
about
http
web
request
versus
http
client
and
the
methods
that
we
have
to
enable
those
pieces.
Yeah.
A
Yeah,
I
I
vaguely
regret
this
discussion,
because
this
is
like
somewhat
confusing
to
customers,
because
when
we
say
add
http
client
we
are
like,
underneath
we
are
doing
the
instrumentation
for
the
http
client.net
core
and
http
web
request
in
dotnet
framework.
So
that's
probably
what
this
discussion
was
all
about.
Yeah.
I
think
we
can
resolve
this
offline.
We
don't
have
to
have
everyone
in
the
code
for
that.
A
I
can
take
another
look
right
after
this
and
see
if
it
still
makes
sense
to
like
separate
the
web
request
and
http
client
for
tonight,
and.net
core
separately,
yep,
okay,
custom
property
improvements.
Yeah
this
should
be
good
to
go.
I
was
just
reviewing
it
little
earlier,
so
yeah
I
mean
there
is
no
need
of
discussion.
This
is
already
approved.
We
should
be
matching
it.
A
So
that's
that
we
already
discussed
the
two
aws
specific
peers.
This
one
is
again
found
he's
not
here,
but
I
want
to
ask
like
if
anyone
has
any
feedback
on
this,
please
go
ahead
and
share
it
here.
A
So
if
anyone
is
not
familiar
with
what
this
is
attempting
to
do
is
I
can
just
give
a
quick
overview
of
what
the
ultimate
goal
here
currently
is:
around
16
packages
being
published
and
each
package
uses
its
own
even
source
name
to
publish
its
own
logs,
like,
for
example,
if
the
asp.net
instrumentation
is
facing
an
issue,
the
general
guidance
from
open
telemetries.
A
Due
to
several
reasons,
the
approach
used
to
is
to
log
it
using
event
source.
There
was
some
discussion
about
using
I
logger,
but
due
to
the
fact
that
most
of
the
packages
support
has
to
support
dotnet
452
and
I
logger
is
not
available
until
you
are
in
dotnet
462,
we
decided
to
use
event
source,
so
all
these
packages
are
logging
using
even
source.
Now
the
question
is
something
is
going
wrong
and
you
want
to
figure
out
how
to
how
to
find
what
is
going
wrong.
A
So
you
have
two
options:
one
is
to
install
tools
like
perfume
and
listen
to
it
or
like
write
some
custom
listener
to
listen
to
even
source
and
type
it
somewhere,
either
by
logger
or
console
or
text
file.
So
what
this
br
is
attempting
to
do
is
provide
a
built-in
diagnostic
provider.
A
That's
it
that's
the
only
thing
which
this
pr
is
doing
and
if
and
it
has
the
ability
to
dynamically
read
a
configuration
either
from,
I
think
it's
only
from
involving
variable.
So
if
you
have
an
app
running
and
you
face
some
issues,
you
just
set
some
in
one
variable,
it's
going
to
just
read
it
and
start
pumping
some
data
into
the
local
file.
A
A
Okay,
yeah.
So
this
is
like
this
is
just
reacting
to
the
spectring.
So
we
had
a
fairly
big
change
in
the
specification
about
status.
It
was
originally
mapped
into
grpc
code,
then
it
was
proposed
to
be
removed,
and
since
there
was
a
lot
of
a
lot
of
lack
of
clarity
about
status,
dotnet
decided
not
to
have
status
in
the
activity.
So
as
of
today,
there
is
no
apa
in
activity
class
to
store
status,
so
we'll
be
forced
to
store
it
either
in
tags
or
custom
property.
A
A
But
this
pr
is
just
updating
our
specific
our
code
to
match
the
newspaper
we
used
to
have
a
bunch
of
canonical
codes
mapping
to
grpc,
but
now
it's
all
like
removed.
We
only
have
these
three
so
yeah,
it's
just
a
pl,
responding
to
the
specification
I
mean,
unless
it
has
any
questions
for
more
folks,
we
can
take
it
offline
and
review
it
again.
Ask
is
if
anyone
has
free
cycles.
Please
take
a
look
at
the
pr
okay,
and
this
is
brand
new.
A
Okay,
this
is
a
pure
implementation
detail.
There
is
no
ap
change,
I
think
yeah
you
can
just
go
ahead
and
review
it.
A
Yeah
michael,
is
not
here,
so
we
don't
have
to
discuss
it
right
here.
It's
just
again
calling
others.
If
you
have
any
suggestion
for
improving
performance,
please
go
ahead
and
do
it
here
or
in
a
separate
video.
We
have
been
doing
like
a
lot
of
puff
optimizations
to
the
point
where,
like
we
can
generate
like
close
three
million
activities
per
second
without
significantly
affecting
him
in
a
relatively
single
core
low
performance
machine,
so
this
would
affect
the
entire
success
of
open
telemetry.
So
please
take
a
look
review.
A
E
Sure
I
think
last
week,
github
enabled
the
code
tl
workflow,
where
it
will
analyze
your
source
code
to
check
for
vulnerabilities.
E
So
the
idea
of
this
pr
is
to
check
check
if
we
are
using,
for
example,
some
packages
that
are
vulnerable
or
secrets
in
your
source
code,
and
it
will
show
it
as
issue.
So
if
you
go
up
and
going
to
the
security
tab,
oh
yeah
here.
A
E
Yes
and
code
scanning
alerts
on
the
left,
yes,
and
if
you
see,
I
think
I
closed
it,
all
the
issues
that
were
open
because
it
was
related
to
javascript
and
things
from
our
example.
So
here
it
will
show
all
the
vulnerabilities
that
we
have
it's
not
validating
in
all
requests
it's
validating
once
a
day,
because
it
takes
a
long
time
to
run.
I
think
15
to
20
20
minutes.
A
So
that's
the
idea.
Okay,
and
if
it
detects
an
issue,
it'll
only
be
available
in
the
security
tab.
It
won't
be
available
publicly.
So
only
folks
who,
how
maintainer
or
contributor
access
will
be
able
to
see.
E
A
I
can't
research
if
it
is
an
actual
security
issue.
We
don't
want
it
to
be
like
listed
as
a
issue
publicly.
It
probably
makes
sense
to
be
only
visible
for
like
people
with
contributor
access
and
depending
on
the
severity
they
can
either
market
as
an
issue
and
make
it
public
okay
yeah.
So
thanks
for
clarifying
yeah,
I
I
will
take
a
look
at
it
and
it's
should
you
do
it
once
in
a
day
midnight,
yeah,
okay,
so
yeah,
we
have
some
backlog,
but
it
looks
like
nothing
like
really
really
scary.
A
It
should
be
like
manageable
in
a
day
or
two.
Yes,
so
that's
pretty
much
the
update
from
a
good
request.
We
don't
have
any
major
issues
as
well
yeah
I
mean
there
are
small
issues,
but
I
don't
think
we
need
to
discuss
it
in
the
submitting.
A
A
It's
like
very
straightforward,
but
the
examples
could
be
potentially
confusing
because
because
of
the
way
ilogger
is
working,
it's
not
strictly
an
issue
with
open
telemetry.net.
It
is
an
issue
with
high
logger
because,
depending
on
the
version
of
net
core,
the
way
you
do
login
is
different.
It's
different
in
2.1,
especially
but
yeah.
Please
take
a
look
and
see
if
all
the
approaches
which
we
are
doing
make
sense
yeah.
A
I
think
alan
and
michael
was
part
of
some
reviews
last
two
days
because
we
were
always
facing
one
challenge
here,
because
for
I
logger
there
is
a
well
established
pattern
of
how
do
you
create
a
logger
but
for
tracing?
We
have
an
open,
telemetry
pattern,
so
the
open
elementary
pattern
is
to
like
create
a
tracer
builder
and
obtain
traces
from
that
and
go
from
there,
but
for
I
logger
it's
completely
different
and
it's
different
for
each
version.
A
Also,
so
we
were
having
some
debate
about
which
one
we
should
align
with
so
so
far
it's
aligned
with
the
general
I
logger
api.
So
if
you
have
an
existing
app,
which
is
doing
a
logger,
so
it's
very
easy
to
integrate
it
you'll.
Just
add,
like
builder
dot,
add
open
elementary
here.
Also,
you
simply
say
builder
dot,
add
open
elementary,
so
it's
still
more
and
more
compliant
with
the
I
logger
api.
A
However,
that
puts
us
more
and
more
separate
from
the
tracing
ap,
because
if
you
look
at
trace
getting
started
way,
things
are
working
here
is
slightly
different
from
the
way
a
logo
works
like
here.
You
create
a
provider
and
you
build
it
and
from
the
provider
you
can
like
from
the
provider,
you
can
get
tracers
and
then
you
can
create
activities.
So
it's
bit
different.
A
So
if
anyone
has
strong
opinions
on
which
approach
should
we
take
whether
we
should
align
more
with
the
eye
logger
13
or
whether
we
should
align
more
with
the
open
elementary
terminologies
or
we
should
strike
a
balance,
please
feel
free
to
take
a
look
at
this
recent
years
or
the
actual
talks
and
then
share
your
thoughts.
We
are
still
actively
building
it.
So,
hopefully,
by
end
of
this
week,
we
should
have
it
done,
but
we
are
still
open
to
making
any
changes
until
we
go
ga.
A
So
please
take
a
look
at
the
logs
as
well
for
matrix
allen.
Do
you
have
any
like
updates
or
anything
to
discuss
about
metrics,
because
you
were
trying
to
do
some
materials
reporting
right.
D
No
I've
been
I've
been
wrapped
up
for
the
past
couple
weeks
with
some
other
things.
I
I
will
talk
with
you
offline
today
about
what
I
might
be
able
to
do
timeline-wise
there.
I
should
be
able
to
get
my
attention
back
on
that
here
very
shortly.
D
A
A
I
believe
it's
merry
yeah,
so
it's
not
so
we
can
like
use
this
as
a
reference
and
like
build
on
that
yeah
we
can
discuss
software,
but
if
there
are
anyone
else
who
is
interested
in
the
space,
please
look
at
the
peers
which
we
will
be
having
in
the
next
few
days.
A
F
I
think
the
status
didn't
change
much
from
from
last
week.
I
still
work
on
the
runtime
thing
and
I'll
do
the
further
updates
from
the
the
meeting
tomorrow.