►
From YouTube: 2021-07-20 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
C
C
B
Hi
everybody
well,
if
nobody
else
has
an
agenda
item,
I
thought
it'd
be
worth
mentioning
the
progress
in
last
week's
sampling
sig.
I
need
to
pull
up
the
issue
I
filed
I'd
like
people
to
look
at
it.
It
is
an
issue
in
the
spec
repo.
Let
me
see
if
I
can
find
it.
B
Asking
you
all
to
consider
how
you
want
to
know
when
the
trace
is
incomplete,
the
biggest
problem
we're
having
with
sampling
is
not
that
we
don't
understand
sampling
or
probability
or
how
to
select
traces.
It's
that
we
don't
know
when
a
choice
is
complete.
Someone
has
posted
that
for
us.
I
was
going
to
put
the
notes
now.
B
C
A
For
matrix,
I
already
gave
the
update
yesterday
here
we
can
do
a
quick
recap,
so
the
matrix
api
so
far,
we've
been
running
the
experimental
state
and
the
multiple
language
six
are
doing
the
prototype
and,
and
so
far
the
feedback
has
been
positive.
We
haven't
seen
any
blocking
issue
so
we'll
continue
to
bake
the
apis
back
the
sdks
back
we're
making
slow
progress
regarding
the
multiple
pipeline
thing.
I
think
there
are
three
major
issues
number
one
is:
how
do
we
allow
people
to
specify
view
or
basically,
how
do
you
configure
the
ick?
A
If
you
don't
like
the
default
behavior,
for
example,
you
want
extra
dimension.
You
want
to
change
the
aggregation.
You
want
to
change
the
other
behavior
so
that
I
think
I
believe
we
we
almost
agreed
on
what
we
should
do.
So
I'm
I'm
trying
to
scope
down
the
pr
I
have
and
and
we'll
send
out
very
soon,
and
hopefully
that
can
conclude
the
first
thing.
The
second
thing
is
regarding
multiple
pipelines.
So
the
question
is
for
the
matrix
sdk.
We
want
to
send
data
to
different
places.
A
It
could
be
like
we
want
to
duplicate
the
data
and
send
to
both
premises
and
some
like
cloud
environment
using
the
push
model.
Then
the
question
is:
how
do
we
do
that
in
ick?
Currently,
there
are
some
debates
and-
and
the
general
idea
is
we
want-
we
want
to
give
the
freedom
to
the
sdk
because
they
won't
have
some
flexibility.
A
Another
way
of
thinking
about
multiple
pipeline
is,
you
have
some
metrics
and
there
are
critical
metrics.
You
want
to
push
at
a
much
higher
frequency
to
some
local
environment.
For
example,
you
want
to
push
the
cpu
memory
usage
to
the
local
containerized
environment
for
fast
scale
out
or
like
fill
over
and-
and
you
probably
don't
need
to
push
those
noise
to
the
cloud,
and
then
you
have
some
business
metric.
You
want
to,
for
example,
indicate
how
your
system
operates.
A
What's
the
user
access
and
those
things
push
to
the
the
cloud
so
in
this
way,
how
do
you
allow
multiple
pipelines
with
different
interests
of
the
signals
and
how
to
distribute
them?
So
that
part
is
a,
is
quite
challenging
and
and
also
the
separated
pr
split
it
from
the
the
view.
Part,
the
pr
I
have
the
the
third
thing
is
regarding:
how
do
we
specify
different
aggregation
algorithm?
A
So
the
the
question
is
what
type
of
default
aggregation
are
we
going
to
provide,
for
example,
are
going
to
provide
like
all
types
of
histogram
or
will
be
specific
about
exponential
bucket
histogram
and
for
exponential?
What
would
be
the
base
to
is
base
2
base,
10
or
something
else
or
both
or
all
of
them,
and
and
do
we
allow
mean
max
and
average
other
stuff?
Do
we
allow
unique
count?
I
I
think
currently
they're
still
discussion
and
and
josh
has
been
driving
this.
A
Hopefully
we
can
start
with
a
small
site,
so
try
to
unblock
the
isdk
and,
as
we
do
more
prototype
based
on
the
capacity
and
the
ask
we
can,
we
can
decide
whether
we
either
certainly
or
not,
but
we'll
try
to
keep
the
bar
instead
of
trying
to
open
the
flat
gate
and
and
also
the
question
regarding
when
we
do
the
aggregation
for
freedom
like
histogram,
which
sketch
are
we
going
to
use.
So
it's
it's
a
very
deep
area.
A
I
I
think
josh
had
they
asked
so
we,
the
metrics,
say
we'll
need
more
people
without
deep
understanding
about
this,
like
I'm
like
highly
encouraging
people
to
to
look
at
the
pr
or
the
issue
like
mentioned
by
josh,
so
give
us
the
feedback
as
if
you're
from
the
user
perspective.
We
want
to
know
whether
you
think
this
is
easy
to
understand
whether
it's
user
friendly,
so
that
would
help
us.
I
figured
currently
in
a
matrix.
People
are
too
familiar
with
the
concept.
A
My
word
is
they
introduce
something
that
might
make
sense
for
the
experts,
but
in
the
end,
it's
hard
for
the
user
to
understand,
and
besides
that,
I
I
I
think
that
almost
conclude
the
sdk's
back.
So
the
key
thing
I
want
you
to
take
is
will
further
delay
the
sdk
spike
experiment
hall.
We
won't
be
able
to
have
the
experimental
release
by
end
of
this
month.
According
to
the
current
progress,
I
I
think
we'll
we'll
need
at
least
two
or
three
weeks.
A
In
addition,
so
it
will
happen
in
mid-august
or
even
late
august
and
the
key
is
we
want
to
solve
this
three
prs
or
the
issues,
and
besides
that
there
are
some
smaller
issues.
I
I
think
it's
very
straightforward.
For
example,
I
see
his
back
has
to
cover
what
type
of
the
exporters
are
we're
going
to
provide
by
default.
We
all
know
like
in
tracing.
We
have
like
zip,
king
and
jager
and
otlp
so
for
matrix.
We
already
have
the
good
idea
like
we
need
the
memory
exporter
in
console.
A
We
need
premises
and
stats
d
and
otlp.
So
for
statistic.
Probably
it
is
something
that
we
can
remove
for
now,
so
that
at
least
give
us
four
exporters.
We
just
need
time
to
spec
them
out,
but
that
part
shouldn't
be
a
a
big
challenging
thing.
That's
all
from
my
side.
I
want
to
know
any
any
questions.
Do
people
have
a
reasonable
understanding
about
the
matrix
progress,
any
any
doubts
or
anything
I
haven't
covered.
B
Thank
you,
riley.
That
sums
it
up
pretty
well,
just
on
the
same
topic,
the
histogram
thing
we're
looking
for
prototypes
and
implementations,
especially
from
vendors,
but
I've
said
that
yesterday
and
I
think
you've
already
heard
that
I
also
put
a
link
to
two
open
proto
prs
that
the
metrics
group
has
been
put
together.
B
C
D
Thanks
carlos
so
yeah,
I
just
want
to
give
an
update,
so
this
is
a
doc
that
had
been
put
together.
It's
been
reviewed
by
a
smaller
audience,
but
would
welcome
you
know
any
questions
or
comments
to
it,
and
this
is
a
high
level
doc.
The
next
step
is
within
a
small
working
group,
we're
going
to
try
to
flesh
out
the
details
and
use
a
working
example
of
messaging
on
how
you
know
what
are
gonna
be
the
getting
started,
experiences
for
the
different
libraries.
How
do
we
build
out
a
backlog?
D
You
know
what
are
the
you
know?
How
do
we
look
at
it
from
you
know
where
there's
horizontal
consistency
of
like
say,
configs
or
whatnot,
so
we
still
need
to
flesh
out
all
those
details,
but
just
want
to
kind
of
share
the
document
where
it
is
here
at
a
high
level,
and
then,
in
the
you
know,
coming
weeks
we
hope
to
make
some
progress.
D
One
open
item
that
kind
of
was
raised
was
that
you
know
we
have
some
smes
internally
at
microsoft
that
are
working
on
the
messaging
spec
to
get
it
to
us
state
to
share
with
the
community.
D
But
at
the
same
time
you
know
people
are
making
some
small
changes
to
the
to
the
current
experimental
spec,
and
I
don't
know
if
that's
worth
developers
time.
I
don't
know
how
we
raise
raise
this
so
that
if
we
know
that
there's
going
to
be
a
bigger
changes
coming
on
the
messaging
side
for
the
spec,
you
know
you
know.
How
can
we
limit
like
how
do
we
limit
additional
changes
to
what's
there
already
until
we're
able
to
bring
us
something
more
concrete
to
the
full
community?
D
So
that
was
just
one
thing
that
was
raised
open
to
suggestions
on
that,
but
otherwise
that's
kind
of
where
we
are
right
now,
with
the
semantic
conventions.
D
That's
that's
correct
and
probably
you
know
maybe.net
as
well,
but
those
are
the
three
and
I
think
it's
because
you
know
obviously
from
a
language
perspective,
each
one
has
their
own
nuances
right.
They
have,
they
have
their
own
conventions
as
well.
So
we
have
to
consider
those
on
how
that
works
across
all
languages.
D
Yes,
I
think
I
don't
think
we're
ready
to
start
a
full
sick
for
the
larger
audience.
I
think
we
want
to
get
some
of
the
more
details
fleshed
out
before
we
get
there.
So,
but
yes,
eventually,
we
want
to
start
to
say
we're
just
not
ready
for
that.
Yet
I
can't
put
a
timetable
on
it.
I'm
hoping
it'll
happen
this
summer
since
we're
already
july
20th,
so
that
should
be
the
goal,
but
we're
just
not
ready
at
this
point.
C
Thank
you
so
much
for
that
as
well.
Okay
and
then
our
final
item,
spanish
status
and
http
status,.
E
Sure,
okay,
so
I
just
have
a
question
about
the
you
know:
the
instrumentation
topic.
That
michael
was
just
talking
about.
So
you
say
you
don't
haven't
started
to
sig
yet,
but
are
the
meetings
on
the
public
calendar?
I
think
that
in
open
telemetry
we
really
want
that.
All
of
these
discussions
to
be
public
and
recorded
and
on
the
public
calendar.
D
C
Perfect
so
yeah
now
going
to
the
spanish
status,
an
http
status
issue,
this
was
filled
by
nikita,
it's
an
interest
one,
probably
probably
it's
going
to
be
a
political
one.
Essentially
this
is
about
whether,
because
currently
in
the
specification,
if
you
get
any
400
or
500
code,
you
are
supposed
to
mark
your
span
as
error,
and
maybe
that's
that
doesn't
need
to
be
the
case,
at
least
for
the
server
side,
at
least
for
the
whole
400
cases.
C
It's
a
very
interesting
one,
there's
no
clear
solution.
Christian
emulator
and
nikita
have
been
discussing
there,
but
I
think
it's
important
enough
to
pay
attention
to
that,
because
it
will
affect
how
clients
interact
with
the
errors.
So
please
take
a
look
at
that
yeah.
We
really
need.
We
really
really
need
some
feedback.
There.
C
So
this
is
it
if
anybody
wants
to
race
one
more
topic
now.
This
is
your
time,
otherwise
we
can
probably
go
going
once
going.
C
Twice:
okay,
thank
you.
So
much
guys
back
to
work,
stay,
safe,
stay
cool,
see
you
next
time.