►
From YouTube: 2022-03-11 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
B
D
B
First,
I
have
a
question
for
everyone.
We
we
have
some
issues
that
were
created,
maybe
like
a
few
weeks
ago
or
a
month
ago,
and
we
haven't
tried
all
of
them.
So
there's
some
nice
to
have
things.
Do
you
think
we
should
try
all
of
them
or
not?
My
proposal
would
be.
We
only
attracted
the
issue
since
last
week
and
if
some
issue
is
really
important,
I
expect
people
to
bring
this
to
the
triage
meeting.
B
B
B
A
B
What
I've
normally
see
permits
is
like
if
people
want
to
do
some
like
local
site,
normally
they
just
protect
that
with
a
username
password,
it's
not
for
production
for
production.
B
They
would
need
to
integrate
that
with
some
other
system,
but
normally
what
people
would
do
is
they
have
the
permissive
exposure
listening
on
a
certain
port
under
a
framework
instead
of
they
open
their
own,
like
hdb,
hosting
or
whatever?
So
in
this
way,
the
overall
hdb
framework
is
in
charge
of
the
authentication
and
ddos
all
kinds
of
things.
This
is
the
essential
task
in
order
to
open
any
http
endpoint.
A
So
that's
still
possible
in
this
case,
if
you
put
like
a
proxy
in
front
of
it,
then
yeah
do
the
authentication
through
there
yeah.
So
I
think,
if,
if
it's
like
a
thing,
that's
really
important
to
them,
then
that's
a
way
of
doing
it,
but
I
I
agree
that
this
is
not
something
that
we
need
to
focus
right
now,
yeah,
so
I
tend
to
put
it
as
allowed
for
ga.
B
B
So
as
a
quick
summary,
I
think,
josh,
you
have
a
proposal
that
you
want
to
remove
the
preferred
temporarily
at
all
and
then
only
ship,
the
cumulative
for
otlp
and
and
later
we
can
revisit
it,
and
I
think,
based
on
what
had
heard
from
from
like
ireland
and
other
like
vendors,
it's
even
worse
for
them,
they
would
rather
have
something
as
is
or
if
we
can
add
another
flag,
saying:
hey,
there's
a
like
a
balance
temporarily,
which
you
use,
like
you
use
delta
in
most
of
the
cases,
but
for
the
asynchronous
counter,
isn't
as
I've
done
counter,
you
can
change
that
to
a
gauge
or
something.
B
So
my
proposal
is
either
single
flags,
yet
another
flag,
saying
something
in
between
like
it.
It
looks
like
delta,
but
for
the
up
down
counter
it
has
a
different
behavior.
It
will
simply
convert
things
to
a
gauge
or
something
that
would
meet
your
requirement
as
well.
So
do
you
think
that's
a
good
balance.
D
I
think
that
the
pr
that's
open
now
is
the
right
balance
there.
There
were
a
couple
open
questions,
and
clarifications
pointed
out
by
people
on
the
call
here
right
now.
D
I'm
my
position
is
that
we
aren't
adding
new
flags
and
we're
just
removing
this.
This
ambiguity
that
was
kind
of,
like
you
know
the
statement
there
saying
something's
idiomatic
that
that
there's
not
really
a
place
for
something
to
be
idiomatic.
Here
we
haven't
just
haven't,
said
what
the
sdk
will
do.
D
So
after
the
feedback
from
this
week,
I
updated
the
pr
again,
there's
still
one
environment
variable
that
would
control
temporality
and
the
the
new
argument
that
surfaced
through
this
conversation
here
is
that
we
have
perhaps
a
first
principle
on
which
we
can
say
up
down.
Counters
should
always
be
cumulative,
and
if
we
accept
that
argument,
which
I
think
is
pretty
acceptable,
then
the
the
number
of
choices
becomes
far
fewer,
at
which
point
the
justification
I've
been
giving
for
having
one
environment
variable
appears
to
pass
past
muster.
D
So
my
position
is
that
we
simply
have
not
been
clear
enough
about
what
the
sdk
should
be
doing,
and
we
haven't
been
clear
about
what
the
otlp
exporter
should
be
doing
and
that
this
solves
both
of
those
problems
in
ways
that
ought
to
be
acceptable
to
anyone
and
but
are
particularly
acceptable
to
the
people
who
want
delta.
D
And
this
is
also
not
a,
I
think,
not
a
breaking
change.
The
only
the
only
thing
that
we
will
be
asking
well
that
we
would
be
asking
sdk
authors
to
do
is
to.
B
Yeah
so
my
second
bad
question:
this
is
not
related
to
technical,
it's
more
about
logistics.
This
is
allowed
for
ga,
which
means
we're
not
going
to
wait
for
this.
If
it's
going
to
take
another
three
weeks,
then
it
will
not
be
part
of
the
stable
release.
So
my
question
for
you
is:
do
you
think
you
will
be
able
to
get
people
aligned
and
get
this
merged
before
the
stable
release
timeline
or
you
think?
Currently
it's
a
floating
target.
We
don't
know.
D
I
don't
know
riley.
Can
I
convince
you
right
now
to
accept
this
change,
because
I
I
do
feel
that
we
can.
I
just
I
I
I
want
us
to
like
agree
and
commit
not
wait.
B
So
if
I
propose
this
like
for
folks
who
are
here
like
island
guild
and
carlos
and
me
if
we
can
take
a
look
and
if
all
of
us
think
we
can
quickly
like
approve
this,
then
it's
highly
likely
that
it
makes
sense
for
most
of
the
nurse.
D
D
Own
protocols,
which
is
fine
but
we're
talking
about
otlp,
and
I
think
the
thing
that
the
clarity
that
I
feel
was
missing
and
I
think,
will
be
welcomed
when
the
larger
group
reads
through
this
is
that
is
that
the
metric
reader,
the
methods
were
spelled
out,
but
the
the
constructor
was
never
given,
and
I
think
that
is
a
a
shortcoming.
It's
not
an
incorrectness,
it's
just
a
like.
D
There
was
something
missing
that
that
people
weren't
quite
getting,
and
it
was
all
between
the
lines,
and
I
tried
to
put
something:
that's
left
between
the
lines
here
together
and
now
there
came
a
question
about
this.
This
thing
I
wrote,
which
I
realized
was
buried
in
there,
but
not
quite
clear,
like
called
default
enabled,
but
I
feel
like
in
the
group
we
had
said
the
sdk
author
can
like
the
vendor
can
decide
what
the
defaults
will
be,
and
the
question
is:
okay,
no
view
matched
my
instrument.
D
D
So
I
feel
that
this
this
is
broadly
going
to
improve
people's
understanding
as
well.
In
addition
to
fixing
the
thing
that
was
broken
for
the
vendors
that
want
delta
temporality.
D
D
We
can
allow
it,
but
I,
but
I
want
to
make
sure
that
in
viewing
it
as
a
non-breaking
change,
we
get
it
to
the
point
so
quickly
that,
like
we
aren't
releasing
sdks
that
haven't
gotten
our
fix,
at
which
point
like
is,
is
it
breaking
or
not?
I
don't
care,
I
just
want
to
get
it
fixed
before
I
start
telling
my
customers
to
try
to
use
it
anyway.
I
do
think
we
can
agree
quickly.
B
C
That's
specific
for
this
issue.
That
is
what
I
would
like
riley,
the
the
suggestion
that
you've
made
in
the
past.
It's
acceptable,
though
I
just
don't
think
I
mean
putting
my
like
open,
telemetry
hat
on
and
advocating
for
open
telemetry
customers.
I
just
don't
feel
like
the
the
path
to
then
at
make
an
additive
change.
C
C
I
really
do
like
the
in
addition
to
resolving
this
issue.
Josh
has
also
the
the
clarifications
he
has
brought
with
this
pr
are
great
in
my
opinion,
and
so
just
just
to
respond
to
your
question
a
minute
ago.
Riley
where
he
asked
do
you
think
we
can
get
aligned,
I'm
I'm
there
with
with
josh.
I
have
a
couple
of
clarifying
questions,
there's
a
few
more
clarifying
questions
from
george,
and
so
I
guess
I
guess
my
question
to
you
is:
who
else
do
we
need
alignment
from
to
be
able
to?
B
My
question
is:
there's
a
lot
of
discussion
and-
and
I
don't
see
approval-
that's
my
problem,
so
you
think
you
support
this
and
you
can
work
with
scouts
to
fix
all
your
concerns,
and
you
approve
this
and
if
I
say
like
many
folks
could
approve
this,
then
I
think
we're
in
good
condition.
The
problem
is
this:
this
pr
has
a
lot
of
comments.
People
are
talking
about
different
things
and
there's
no
enough
approval.
D
Well,
there
aren't
really
enough
reviewers
either.
So
that's
my
like
long-standing
problem
that
hotel
has
yeah
here's
just
just
to
summarize
what
I
think
actually
changes,
rather
than
clarifications.
D
What
I
actually
think
is
changing
that
it
cuts
that
an
existing
sdk
sdk
is
going
to
have
to
adapt
to
is
very
little
if
they
were
already
doing
what
I
think
they
were
doing
right,
but
it
would
be
make
sure
that
all
the
configuration
is
going
through
the
metric
reader,
but
you
should
have
had
all
that
configuration
already
and
then,
if
your
configuration
was
as
simple
as
having
a
single
preference
for
temporality,
it
now
is
be
becoming
a
five-way
by
instrument
preference
which
doesn't
sound
like
a
great
big
distinction
and
then
and
then
there's
this
other
potential
way
of
framing
this
problem
that
calls
it.
D
This
is
a
data
model
bug.
If
we
fix
the
data
model,
bug
we're
not
even
having
to
fix
the
the
sdk
much
that
makes
it
less
breaking
if
we
call
it
a
data
model
bug
for
the
sdk.
Yes,
I
think
I
can
get
approval,
but
no
one
cares.
That's
why
no
one's
reviewing
this?
It's
not
a
big
deal,
it's
my
opinion.
B
B
About
exactly
so,
my
ask
is,
if
you
from
a
vendor
you
care
about
this,
then
you
should
either
block
this
pr
or
approve
this
or,
if
you
think
you
still
have
questions
then
work
with
josh
to
sort
that
out.
It
seems
you're
telling
me
you
care
about
this,
but
I'm
not
saying
you
give
a
strong
opinion.
You're
making
comments
here
and-
and
this
is
where
we're
not
making
progress.
C
D
D
So
let's
suppose
that
we
do
this.
D
I
sit
down
and
respond
this
morning
to
the
latest
round
of
questions
which
I
think
is
all
confirmatory
like
I'm
just
saying
yes
and
I'm
adding
more
words
to
help,
but
I
don't
know:
what's
going
to
confuse
people
until
people
ask
those
questions,
but
I
think
we've
reached
essentially
support
within
the
vendors,
the
three
vendors
who
have
a
stake
here
and
then
later
in
the
day,
once
I
have
answered
alan's
questions,
we're
going
to
approve
it,
like
george,
is
going
to
approve
it
allen's
going
to
approve
it
I'll
get
another
lightstepper
carlos
is
on
the
call.
D
I
think,
to
do
that
and
and
we'll
just
bring
a
strong
case
to
the
tuesday
meeting.
You
know
we
have
so
many
people
who
are
out
like
josh
s
is
not
revealing
bogen's,
not
in
right.
Now
I
like,
we
don't
have
a
lot
of
approvers.
That's
part
of
our
problem.
B
A
I
just
want
to
second
that
opinion
that
josh
and
ellen
put
forward
just
now.
I
think
we
are
also
very
much
good
with
this.
With
this,
I
just
added
a
few
clarifying
questions
as
well
and
as
soon
as
those
are
addressed,
I'm
also
willing
to
to
put
in
my
my
check
mark
there,
and
I
can
also
reach
out
to
daniel
dyla
and
yeah.
Then
we
can
potentially
get
enough
reviews
in
and
enough
approvals
and
to
actually
get
this
get
this
moving
or
yeah
moved.
I
guess:
okay
thanks,
so
so
I'll.
E
B
So
the
next
issue
clarify
how
the
ic
has
involved
invoke
the
async
callback.
So
this
is
basically
saying
hey.
If
I
have
multiple
readers,
the
ick
is
not
saying:
should
the
multiple
readers
call
in
it
and
make
sure
they
call
the
callback
just
once
and
share
the
results
or
they
should
call
it
independently?
B
I
think
this
is
more
like
implementation
question.
The
fact
is
not
trying
to
be
super
specific.
My
analogy
is
this
is
very
similar
to
sampler.
If
you
call
the
sample
once
or
twice,
the
ic
can
never
ask
you
to
do
it.
It's
if
you're
smart.
You
can
implement
that
in
a
more
efficient
way,
but
if
not,
it
wouldn't
harm
a
lot.
If
you
call
it
multiple
times,
because
the
data
would
be
the
same,
so
I
treated
it
as
a
nice
suggestion,
but
not
necessarily
something
that
spike
has
to
clarify.
D
B
B
B
B
B
Yeah
my
position
is
like,
like
he
has
a
strong
position.
He
believes
exemplar
should
be
enabled
by
default
in
the
in
the
ultimate
spike,
but
currently
exemplar.
I
I
think
that
part
is
moving
slowly,
a
lot
of
people,
they
have
questions
and
it's
not
being
well
prototyped
across
languages.
That's
why
we
decided
to
make
it
I'll
have
scope
for
now,
so
it
will
mark
be
marked
as
feature
freeze
but
not
stable.
This
is
why
we
try
to
put
the
sdk
spike
has
mixed.
B
This
is
the
only
odd
ball
here
and
in
this
way
the
spike
cannot
say,
example
must
be
enabled
by
default,
because
it
has
a
dependency
right.
So
I
tend
to
say
in
the
spec
example
should
not
be
enabled
by
default.
In
this
way,
we
can
shape
that
part
as
stable
or
leaving
the
example
as
a
non-stable
version
and
later.
B
If
we
want
to
change
the
word,
we're
saying
oh
matrix
and
traces
correlation
is
becoming
important
and
this
it
should
be
the
the
default
by
changing
the
spec
word
from
should
not
to
shoot
is,
isn't
a
loud
thing.
It's
not
a
breaking
change,
but
if
we
change
something
from
a
master
node
to
mast,
then
it's
a
breaking
change
so.
B
D
C
B
So
if,
if
I
can
quickly
solve
this
eq
and
if
josh
you
can
you
can
drive
the
temporarity
issue,
yeah,
I
think
that's
and
if
we
can
merge
this
meter
reader
like
like
metric
reader
to
meet
a
provider
magazine.
B
And
another
question
for
carlos,
so
this
pr
I
got
a
reasonable
number
of
approvals.
I
thought
your
comments.
Like
I
replied,
maybe
you
can
you
can
take
a
quick
look
and
see
if
you
can
get
your
approval.
E
B
So
if
that's
the
case,
I
I
hope
I
can
merge
the
pr
next
before
next
tuesday.
Oh
definitely
yeah
actually.
E
B
Just
go
there
now
yeah,
then
it
seems
like
we're
in
good
shape,
like
I'll
work
with
you
offline
on
the
apr,
and
I
I
think
that
that
got
all
the
blogging
issues
covered
and
if
you
do
see
any
any
other
thing
that
you
think
is
concerning
will
block
any
issue
just
ping
me
offline,
like
we
need
to
get
them
tracked
so
far.
I
I
think
our
understanding
is.
These
are
the
only
blocking
issues.