►
From YouTube: 2022-03-29 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
B
The
first
point
is
that
we
will
do
we
skip
the
release
for
march,
so
I
think
we
want
to
release
on
april,
maybe
unless
there's
any
reason
to
release
today,
for
example,
I
think
we
can
just
prepare
the
release,
review
the
changelog
and
all
that
and
do
a
review.
Sorry,
I
do
a
release
very
early
friday,
so
we
try
to
keep
the
multiplications.
B
Does
that
sound
good,
observe
that,
of
course,
as
I
said
before,
we
are
doing
the
mix
metrics
sdk
part
release.
Also
logs
the
data
model
for
locks
is
stable
as
well.
B
Perfect,
of
course,
I
think
that
it
would
be
great
to
have
a
blog
post
regarding
this.
I
think
that
it's
a
milestone.
Definitely,
this
is
something
we
try
to
to
have
for
months
and
months.
So
if
anybody
wants
to
volunteer
for
this,
it
could
be
really
great.
B
Okay
next
point
set
status
clarification.
This
is
a
pr
that
recent
field,
basically
just
about
clarifying
when
you
set
the
status.
What
the
description
is
so
please
review
that
there's
a
minor
point
already
blocked
and
another
other
members
review
that,
but
we
I
just
posted
a
final
question
regarding
the
cardinality
or
potential
cardinality
of
that
one,
but
basically
it
has
been
lagging
reviews.
So
please
take
a
look
at
that.
One.
B
C
Rightly
or
german
yep
no
outstanding
topic
there
there's
one
ask
to
remove
the
histogram
like
to
remove
the
exponential
histogram
and
anything
that
mentioned
like
non-explicit,
histogram
buckets
and
there's
some
debates
that
maybe
we
should
give
that
more
time
so
follow
up
on
the
pr.
If
we
couldn't
resolve
that
in
a
week,
then
we
can
use
this
meeting.
B
B
D
B
I
don't
see
them,
maybe
you
put
them
in
the
incorrect
section.
I
may.
D
E
Yeah,
no,
I
think
it's
correct
carlos.
Do
you
have
viewing
mode
on
or
editing
mode,
because
if
you're
in
viewing
mode
it
doesn't
update,
I
am
in
edit
mode.
B
D
Actually,
sorry,
I
I
don't
know
I
mean,
maybe
I
missed
it,
but
there
was
another
pr
right
above
mine
the
set
status
clarification.
If
we
wanted
to
do
that.
First,
I
don't
know
whose
that
is.
B
Yeah,
I
already
mentioned
that
it's
a
small
one
just
need
more
eyes
yeah,
so
that
that's
fine
for
now.
D
Okay,
sorry
about
that
yeah,
so
I'll
give
a
quick,
quick
overview,
so
this
might
be
quick,
I'm
just
really
looking
for
a
clarification
here.
I've
talked
with
a
couple
of
folks,
jack
and
c
joe,
which
are
both
on
this
call.
We
have
attempted
to
implement
the
instrument
identity,
things
that
recently
changed
in
the
specification
and
in
both
java
and.
F
D
D
Should
these
conflicting
views
generate
conflicting
metric
streams?
Much
like
the
the
rules
under
the
sorry,
the
instrument,
identity,
stuff
or
would
should
these
be
ignored
and
dropped?
And
you
know
logged
by
sdks.
C
F
C
Vio
is
entirely
controlled
by
the
application
developer.
If
they
introduce
duplicates,
maybe
they
should
know
like.
The
reason
we
allow
instruments
to
have
conflict
is
because
the
user
might
be
using
different
libraries
and
each
library
owner
might
independently
develop
something
that
causes
the
ultimate
conflict.
While
the
application
owner
has
no
idea,
they
don't
have
food
control
until
they
see
the
conflict,
and
that
might
be
too
late.
View
is
a
different
story.
It's
entirely
controlled
by
the
application
developer.
C
G
Well,
I
don't
think
you
can
always
know
whether
the
view
is
going
to
cause
a
conflict
so
until
like
at
registration
time,
there's
certain
types
of
conflicts
that
you
only
know
at
runtime.
G
G
Well,
just
changes
the
name,
let's
stick
with
that
one.
So
in
that
case
you
don't
know
if
that
view
is
going
to
produce
a
conflict
until
that
wild
card
matches
more
than
one
instrument.
A
Yeah,
I
think
think
about
because
I
I
think
I
think
we
should
not
allow
having
view
configurations
that
are
not
kind
of
that
can
cause
this
problem.
H
A
But
that
that
will
cause
that
will
be
similar
with
having
two
that
will
be
the
problem
in
the
api
correct,
because
you
you
create
an
instrument
with
on
already
existing
name.
It's
the
same
problem
as
two
different
instrumentation
doing
that
versus
you.
Do
this
via
view.
I
G
Point
so
because
it
was
the
it
was
the
api
that
produced
the
identity
conflict.
Yes,
the
rules
of
you
know,
instrument,
identity,
conflict
apply
and
you
allow
conflicting
streams
to
be
produced.
Yeah,
that's
what
I
would
do
like.
D
Yeah
I
agree.
I
I
think
that
last
one
was
the
last
example
that
I
had
there.
If
you
scroll
down
a
little
ways,
I
just
want
to
confirm
that
I
understood
correctly
so
there's
one
view
the
the
instrument
counter
one
matches
that
view,
but
counter
two
does
not
it.
The
result
is
a
name
conflict
because
counter
one
gets
renamed
to
counter
two.
So
in
this
case
just
there
would
be
a
conflicting
string.
D
That's
what
that's
what
you
were
saying:
josh.
H
That's
that
sounds
right.
Yeah.
My
interpretation
of
the
spec
was
that
you
should
do
your
best
to
find
views
that
are
self-contradictory,
so
I
can
prove
you
that
this
view
will
create
conflicts
if
there's
more
than
one,
if
there's
more
than
one
instrument,
but
any
other
view,
conflict
that
comes
about
after
the
views
are
provided
or
the
meter
providers
started.
You
know
are
kind
of
unavoidable
and
I
think
allen's
question
is,
should
that
be
consistent
and
I
think
yes,
meaning
it
should
create
the
instrument.
H
A
Yeah
consistency
is
key
here
by
the
way,
because
if,
if
for
the
same
scenario,
we
have
different
behavior,
we
will
have
a
mess.
So
as
long
as
if
we
cannot
determine
the
compilation
time
or
whatever
the
start
time
that
this
is
a
problem
and
we
fail
there,
then,
after
that,
we
should
be
consistent
in
our
behavior
of
what
we
are
doing.
A
So
my
point
here
is:
if
we
can
determine
during
start
time,
construction
or
whatever
it's
the
build
time,
whatever
it's
the
terminology
in
the
language
that
this
is
a
problem
there
is
a
mis-configuration
or
or
the
viewers
will
will
generate
conflicts
or
something
like
that.
Some
something
bad
is
there.
Then
we
can
fail,
we
can
do
whatever,
because
we
can
tell
user
hey.
We
couldn't
initialize
it's
early
in
the
app
fix
this
problem.
A
G
I'm
curious
if
anyone
can
think
of
any
other
examples
where
you
could
create
this
type
of
view,
conflict
at
runtime,
because
if
we
can't
come
up
with
any
examples,
then
that
means
that
all
view
conflicts
are
created
at
initialization
time
and
any
types
of
conflicts
that
are
happening
at
runtime
would
be
like
instrument,
identity
conflicts
which
are
allowed
to
pass
through.
So
that
would
be.
That
would
be
simpler
from
an
application
logic,
standpoint
or
sdk.
A
A
G
I
think
that
would
depend
on
what
that
api
looked
like.
So
you
know,
is
it
just
like
a
method
on
the
sdk
meter
provider,
yeah.
A
G
C
H
I
just
located
that
paragraph
and
I
I'm
starting
to
see
why
it's
it's
hard
to
to
make
a
hard
rule
about
failing
on
these
situations,
and
maybe
we
should
basically
the
the
position
is
that
we
will
always
follow
the
few
configuration
and
report
how
many
conflicts
it
has
so
that
we
at
least
have
a
consistency
statement.
You
will
always
get
the
instruments
that
you've
configured
through
the
view,
and
there
are
these
essentially
warnings
that
are
created
anytime.
H
You
register
an
instrument
or
a
view,
because
if
instruments
get
registered
after
views,
then
the
problem
is
deferred
and
of
course
you
might
say,
but
you
know,
meter
providers
are
created
with
views
and
then
instruments
are
created
except
we
have
this
global.
H
H
So
that's
a
should
statement
saying
that
we
should
tell
you
when
you've
written
a
view,
that's
obviously
going
to
create
conflicts,
but
maybe
we
should
just
also
say,
and
then
we
will
continue
to
create
exactly
the
conflicts
you
just
asked
for
I.e,
be
consistent,
and
I
think
josh
would
ask
at
this
point
if
he
were
in
the
meeting.
H
I
know
he
asked
when
I
wrote
the
stuff
up
about
instrument
conflicts
in
the
first
place
that
we
have
essentially
a
strict
mode
to
allow
applications
to
voluntarily
halt
or
crash,
or
something
like
that
when
they
get
a
view
configuration
conflict
because
he
thinks
that
during
development
time
or
in
the
sort
of
happy
situation
for
a
let's
say,
google
cloud
user,
you
better
not
have
conflicts,
otherwise,
something's
really
wrong.
So
if
you're
a
developer,
you
would
set
that
strictness
mode.
H
A
G
It
seems
like
it
would
be
easier
to
start
to
publish
an
initial
metrics
sdk
specification
that
requires
strict
mode
always
and
then
loosen
it
up
later
versus.
You
know
what
you're
suggesting,
which
is
to
allow
this
kind
of
more
flexible
mode.
With
like
this
additional
option
for
to
enforce
strictness.
G
You
know
we
could
always
add
that
option
later
to
you
know,
relax
strictness,
but
the
I'm
not
sure
the
opposite
is
true.
H
So
when
would
I
ever
return
an
error
from
an
instrument
constructor
if
we're
allowing
registration
conflicts,
and
I
think
what
we
might
if
we're
trying
to
sort
of
make
some
nuance
here,
we
might
have
an
error
return.
That
says
we
constructed
the
error,
the
instrument
for
you.
H
H
The
consistency
question
is
because
the
sdk
might
be
registered
before
the
instruments.
That
error,
which
is
a
view
configuration
problem,
shows
up
when
you
create
the
instrument.
Now
what
error
should
I
return
when
I
create
an
instrument,
if
there's
a
duplicate
conflict
created
by
it,
and
the
answer
is
one
of
these
soft
errors
that
tells
you
yeah,
there's
a
there's
a
conflict
here
you
might
want
to
know
about
it,
and
that
gives
you
the
option
to
handle
it,
which
means
you
can
handle.
You
can
have
your
own
strict
mode,
which
is
even
better.
G
I'm
not
sure
I
track
100,
so
you
know
I
thought
that
I
thought
the
metric
identity
stuff
was
pretty
clear,
you're
always
going
to
when
you're
using
the
metrics
api
you're,
always
going
to
get
a
functional
instrument
back
and
you're
always
going
to
be
able
to
produce
metrics
that
get
you
know
exported
as
on
that
stream
and
if
you
request
instruments
that
like
are
in
conflict
with
each
other,
then
we'll
log,
an
error
but
you're
still
going
to
get
a
functional
instrument
back.
G
H
I'm
suggesting
that
when
you
create,
when
you
request
the
instrument
that
the
view
logic
gets
applied
at
that
point,
so
it's
not
you're
going
to
get
a
functional
instrument.
It's
going
to
do
exactly
what
the
view
is
said
to
do
it
just
might.
It
might
create
three
conflicts
and
the
the
warning
you
get
is
to
say
there
were
three
conflicts
created
because
of
views.
H
H
I
can
have
my
error
handler
receive
a
message
whenever
I
risk
registered
instrument
which
causes
registration
conflicts,
but
I
guess
the
the
point
I
was
trying
to
make
here
is
just
that:
creating
a
register,
an
instrument
may
create
conflicts,
and
it's
before
this
conversation,
I
think
we
were
thinking
about
those
conflicts
as
being
with
other
instruments,
but
now
we're
I'm
just
saying:
let's
consider
those
conflicts
to
be
with
whatever
the
output
is
that's
generated.
H
So,
technically
speaking,
the
problem
there
is
that
the
data
model
defines
points
by
data
point
kind
and
the
instrument
conflicts
are
defined
by
instrument
kind
and
there's
a
little
bit
of
mapping
that
happens
there,
but
the
same
conflicts
do
occur.
I
don't
know
if
I've
answered
any
other
questions,
but
the
consistency.
The
consistent
outcome
seems
to
be
that
you
always
get
what
you
ask
for.
We
just
tell
you.
There
are
conflicts
when
there
are.
G
So
that
was
my
interpretation
like
of
this
spec,
as
it's
currently
worded,
and
disagreement
about
that
interpretation
is
what
gave
rise
to
this
issue.
That's
how
the
java
implementation
works.
Today,
you
get
what
you
asked
for
from
a
view,
registration
standpoint.
You
can
register
views
that
are
in
conflict
and
we'll
let
you
know
about
those
conflicts,
but
you
know
that's
on
you
to
decide
to
do
something
about
them.
H
Does
that
go
for
the
the
paragraph
that
I
started
reading
out
loud,
which
was
you
know
for
the
registration
mechanism
described
above
where
a
selection
is
provided
by
configuration?
The
sdk
should
not
allow
views
with
specified
name
to
be
declared
with
instrument
selectors
that
may
select
more
than
one
instrument.
H
So
basically
saying
if
you
have
certain
wild
cards,
we're
going
to
tell
you
that
that's
wrong
at
startup,
I
would
say
yes
and
we
will
continue
with
exactly
the
views
that
you
configured,
which
are
going
to
definitely
produce
these
conflicts
when
they're
more
than
one
instrument,
which
is
what
you
asked
for,
in
other
words,
there's
nothing
special
about
the
the
warnings
that
we
print
when
views
are
configured
because
we're
gonna
also
provide
you
with
warnings
every
time.
There's
a
conflict
when
you
create
an
instrument.
G
Yeah,
I
I
don't
have
a
strong
preference
of
like
the
interpretation
on
this
no,
but
I
do
agree
with
the
sentiment
of
opening
this
issue
that
we
should
be
consistent
between
the
implementation.
So
you
know
what
you're
describing
makes
sense,
and
what
alan
and
or
riley
talks
about
also
makes
sense
to
me.
J
Can
I
just
ask
one
question
on
the
same
topic,
so
it
looks
like
the
confusion
is
from
like
where
how
the
instrument
identity,
construction,
conflict
resolution
should
apply.
So
the
example
one
is
all
about
outlet,
it's
completely
ignored,
so
the
spec
says:
if
you
have
multiple
instrument
with
the
same
identity,
then
you
should
allow
it
and
the
two
instruments
should
produce
a
single
merged
stream.
So
this
is
very
clear
in
the
spec.
There
is
another
likely
to
do
the
conflict
which
is
by
using
views.
J
So
what
riley
mentioned
at
the
beginning
of
this
meeting
is
like,
if
application
owner,
who
controls
the
view
he
introduces
conflict,
then
we
should
try
to
fail
as
early
as
possible.
If
it's
not
feasible
to
even
fail
at
the
provider
construction
time,
then
we
should
log
and
move
on.
So
that
second
part
is
not
clear
to
me.
So
do
we
did
we
intend
to
say
that
we
should
move
on
in
the
sense
like?
J
Should
we
ignore
that
instrument,
or
should
we
just
log
the
message
and
continue
to
produce
a
matrix
string
for
the
conflicting
thing.
J
Because
for
instrument
registration
conflict,
it's
very
clear
that,
like
we
try
to
avoid
possible,
but
the
like
the
net
result
is,
you
may
have
some
error
locks
in
your
like
logo
output,
but
both
instruments
would
still
produce
like
streams,
even
if
it
results
in
conflict,
but
in
case
of
view,
it's
not
clear
whether
the
idea
is
to
continue
to
produce
the
metric
stream
or
should
we
just
stop
producing
it,
because
this
is
a
application
owner
introduced
earlier,
he
should
be
allowed
to.
J
He
should
be
like
fixing
it
himself
rather
than
sdk,
trying
to
still
produce
the
duplicate
streams.
C
I
will
say
the
latter
when
you
think
about
these
problems,
I'll
always
start
from
the
higher
level
principle
like
controlled
by
the
application
owner.
You
want
them
to
know
as
early
as
possible
if
they
don't
have
control,
you
still
want
them
to
know
in
some
mild
way
and
in
the
sdk
you
want
to
do
whatever
the
best
that
you
can
help.
J
C
J
C
I'm
I'm
not
convinced
that
all
the
languages
should
follow
the
same
way,
and
this
is
exactly
why,
in
the
spike
we
we
have
some
flexibility.
We
don't
use
very
strong
wording,
because
each
language
have
their
own
philosophy
of
how
to
handle
error,
and
this
is
also
why,
in
the
error
handling,
we
only
give
principle,
we
never
say
must
so
it
seems
like
you
were
expecting.
The
spike
is
written
in
a
way
that
you
can
literally
translate
the
spec
into
your
own
language,
which
is
not
the
intention
of
this
fact.
J
Yeah,
I'm
I'm
fine
with
that,
but
I
mean
as
long
as
everyone
is
having
the
same
understanding
it's
fine.
I
I'm
not
asking
that
like
java,
should
do
exactly
as
dotnet.net
should
do
exactly
as
go
or
anything
else.
J
So
it's
possible
that,
like,
let's,
like
even
the
example
which
is
shared
in
the
screen,
it
is
possible
that,
like
one
language
used
to
handle
the
conflict
in
one
way
and
another
language
could
choose
to
handle
it
in
a
different
way.
There
could
be
a
language
which
can
detect
determine
that
this
is
going
to
introduce
a
future
conflict
and
fail
at
startup
itself.
So
these
are
all
like
allowed.
As
per
the
spec.
J
It's
really
up
to
the
language's
capability
of
determining
ahead
of
time,
whether
it's
going
to
introduce
a
feature
code,
fit
and
crash
it
right
there
or
like
allow
it
log
it
and
move
on
and
locate
and
ignore
the
instrument.
So
these
are
like
all
possible,
depending
on
how
the
individual
languages
decide
to
handle
the
conflicting
views.
C
H
So
I
don't
know
when
you
are
incapable
of
knowing
that
the
view
is
an
error
enough
that,
because
the
user
specified
it
for
you
that
you
should
somehow
do
something
like
something
serious
about
it.
But
maybe
that's
because
I'm
stuck
in
the
going
friend
of
mine
and
that's
okay.
K
I
I
do
think
we
we
take
the
pattern
of
like
in
general
of
not
crashing
or
throwing
exceptions
and
just
informing
the
user
and
then
taking
some
default
action
right
like
in
general.
We
don't
even
want
to
return
errors
like
I
wouldn't
even
return
in
her
in
this
case,
because
that's
implying
the
end
user
needs
to
write
some
code
to
handle
that,
as
their
program
is
executing.
G
J
J
J
If
that's
the
case
like
I'm
fine
with
that
like
if
the
expectation
is
different,
like
it's
expectation,
is
that
every
language
should
handle
the
v
conflict
the
exact
same
way,
then
the
current
wording
is
not
strong
enough
to
enforce
that.
It
allows
that
possibility
of
different
languages
dealing
with
conflicts
in
different
way.
In
the
view
case,.
C
H
G
So
that's
reducing
the
number
of
possible
outcomes
from
three
to
two.
So
currently
there's
three
interpretations.
You
can
fail
fast
with
an
exception
and
you
know
force
the
user
to
handle
it.
G
You
can,
you
know,
fail
fast
with
like
a
lot
or
you
can
fail
with
a
log
and
ignore
the
view
that's
in
conflict
or
you
can
fail
with
like
a
log
and
you
know
continue
to
output
the
view
that's
in
conflict,
and
so
what
you're
suggesting
josh
is
reduce
that
from
three
to
two
and
the
two
would
be
fail
fast
with
an
exception
or
fail
with
a
log
and
continue
to
adhere
to
the
view,
and
you
know,
output
the
view
that's
in
conflict.
F
Yes,
what
I
wanted
to
say
is
that
error
handling
allows
fail
fast
on
initialization.
It
is
so.
Unless
this
view
configuration
is
considered
initial
execution,
it
doesn't
allow
that
to
happen,
error
handling
is
actually
not
that
flexible.
It's
pretty
strict
and
uses
must
for
the
second
and
third
well.
Also,
the
second
principle:
isn't
configuring
views
part
of
initialization?
F
I
F
G
But
so
let's
say
that
it's
not
con
or
okay.
So
let's
say
you
don't
fail
fast,
so
you
views
are
part
of
initialization
and
you
don't
fail
fast.
You
log,
the
spec
still
isn't
completely
clear
about
what
should
happen
in
this
case
of
you
know:
bad
configuration
you're
not
gonna,
fail
fast
you're
gonna
log,
but
should
you
just
drop
the
output
or
the
you
know
the
desired
view?
Or
should
you
adhere
to
it
and
you
know
produce
these?
You
know
the
views
that
are
in
conflict
on
export,
so
that.
F
Yeah
the
that
posterior
action
that
you
do
for
reviews
is,
I
think,
outside
of
scope
of
basic
error
handling,
because
pretty
much
error
handling
the
the
only
thing.
F
G
Well,
I,
like
josh's
point
of
view
so
that
you
know
the
summary
is
that
you
consider
views
part
of
initialization.
An
sdk
can
fail
fast
with
an
exception
because
they're
part
of
initialization,
but
if
they
choose
not
to
fail
fast,
then
they
have
to
adhere
to
the
view.
J
J
Given
the
clarification,
I
don't
think
we
need
any
change,
but
I
I
was
curious,
like
if
you
think
any
better
wedding
would
like
avoid
this
issue
even
being
brought
up
in
the
first
place.
D
A
if
you
could
scroll
down
just
a
little
ways.
This
may
not
be
relevant
anymore,
but
just
fun.
To
look
at
further
comment
down.
D
Regarding
this,
the
this
clearly
says
to
log,
but
it
doesn't
say
anything
about
any
of
the
failure
options
that
we've
discussed.
Do
folks,
think
that
that
would
help
I
feel
like
it
might.
J
I
think
it
goes
yeah.
The
second
statement
is
what
you
are
referring
to
right:
the
following
words
mentioned
conflicts
and
recurs
sdk
to
law,
but
does
not
state
to
ignore
that
stream.
So
what
josh
basically
was
saying
that
like
do
not
ignore
it
continue
to
produce
it,
but
that
part
is
unspecified.
H
H
We
should
add
something
just
to
clarify
this.
I
do,
but
so
it
would
stay
say
essentially
unconditionally
the
view
configuration
will
be
applied.
You'll
get
warnings
about
how
many
conflicts
there
were
and
individual
languages,
as
per
some
other
section,
may.
H
H
Because
if
the
view
got
registered
first
and
now,
I'm
creating
the
instrument,
I'm
initializing,
something,
but
I
don't
think
of
it
as
initialization,
and
I
don't
think
failing
fast
when
I
construct
an
instrument.
Is.
H
Well
again,
it's
it's
my
language
frame
of
mind.
I
don't
think
that's
a
good
thing,
but
but
someone
else
might
decide
to
do
it.
C
H
So
I
guess
that's
why
the
spec
currently
has
exactly
what
it
has,
which
is
that
there's
only
a
few
types
of
error
that
you
can
detect
before
any
instruments
are
registered
and
which
brings
us
back
to
just
do
what
the
view
says:
register
all
the
instruments
and
and
file
some
warnings
for
the
number
of
conflicts.
H
C
E
C
D
Yeah,
I
can
take
a
stab
at
the
words
here.
I
mean
it
sounds
I'm
I'm
I'm,
okay
with
everything
that's
been
discussed,
so
I
think
the
words
that
I'd
add
here
would
mainly
just
speak
to
the
flexibility
that
we've
discussed
when
this
conflict
arises.
Log,
that's
that's
expected,
but
that,
depending
on
the
language.
G
Yeah
I
I
agree,
so
I
thought
the
clarification
was
fail
fast
if
you
can
and
if
you're
interested
in
doing
it.
But
if
you're
not
going
to
fail
fast-
and
there
is
a
view
conflict
that
is
detected
at
at
run
time,
then
you
know
log
and
continue
to
produce
the
views
that
are
in
conflict.
D
Okay,
thank
you
for
that
clarification.
So
so
this
part
of
the
spec
is
actually
not
the
this
sentence
that
I
quoted
is
not
at
initialization
time.
It's
it's
the
it's
in
like
this
for
each
statement
of
the
specification
that,
as
instruments
are
created,
v
and
views
are
being
applied.
What
do
you
do
so?
Okay?
So
then
I
guess
in
that
case
then
maybe
we
don't
need
a
clarification
I
if,
if
the
if
this
jack
that
sounds
like,
then
our
original
interpretation
of
things
seems
to
be
about
what
people
think.
Would
you.
G
Agree,
I
think
so
and
there's
just
I
guess
this.
This
implication
that
if
sdks
are,
are
free
to
detect,
viewed
conflicts
at
registration
time
and
and
fail
fast
and
that's,
I
guess
already
available.
So
maybe
that
doesn't
need
clarification.
H
J
I
mean
it
looks
like
there
is
still
some
confusion,
maybe
like
I
could
state
my
view
and
see,
if
that's
same
as
what
others
think.
So
what
we
are
essentially
saying
is
it
doesn't
matter
how
you
handle
your
error
like
whether
it's
startup
like
you
can
crash
your
app
or
you
determine
it
at
runtime.
You
should
still
produce
the
stream,
even
if
it's
conflicting,
the
sdks
are
prohibited
from
dropping
it.
J
Is
that
the
clarification
which
we
want
to
add,
because
my
understanding
was
based
on
what
riley
said
in
the
beginning
was
view
is
a
thing
which
application
owner
added.
So
if
he
introduced
conflicts
and
just
let's
just
let's
just
punish
them,
don't
produce
the
three
log.
The
error
don't
produce
it,
but
if
the
intention
is
to
still
produce
the
stream
and
log,
then
there
are
like
two
ways
and
if
we
are
okay
with
different
languages,
taking
different
approach,
we
don't
need
any
clarification.
J
But
if
the
intention
is
to
prohibit
any
languages
from
dropping
the
measurements
from
a
particular
instrument,
then
I
think
that
should
be
like
very
explicitly
clarified
in
the
same
part
of
the
spec
which
allen
has
quoted
it
says:
if
there
is
a
conflict,
it
simply
says
provide
a
way
to
let
the
user
know.
So
if
the
intention
is
to
continue
to
produce
a
stream
then
say
provide
a
way
to
let
the
user
know
but
continue
to
produce
the
stream,
even
if
it
results
in
conflicts.
G
I
I
can,
I
think
that
we
should
make
that
small
clarification
cjo.
We
should
adjust
this
sentence
to
say
something
to
the
effect
of
you
know.
If
there
is
an
error,
conflict
provide
a
way
to
let
the
user
know
and
continue
to
produce
the
the
view
that's
in
conflict
with
the
the
other,
okay,
okay.
So.
J
Views
are
introduced
and
created
by
the
application
owner.
They
can
still
produce
conflicts.
If
we
had
the
opportunity
to
like
catch
it
at
the
very
beginning,
then
we
should.
But
if
we
did
not,
then
the
application
is
started.
I
mean
the
provider
is
successfully
initialized
after
that
we
no
longer
have
the
opportunity
to
like
throw
an
error,
so
we
should
just
log
but
still
produce
the
matrix.
J
B
Perfect
now
we
will.
Let's
then
go
to
the
last
item
because
okay.
K
Is
that
you
yeah
yeah?
That's
that's
me
something
an
idea.
We've
been
kicking
around
as
a
kind
of
a
a
follow-up
to,
rather
than
having
like
tc
sponsors
for
stuff
another
way
of
helping
to
manage
the
spec
backlog
and
kind
of
like
provide.
Maybe
some
more
focus
and
clarity
to
the
community
would
be
generate,
creating
like
a
project
board
for
the
main
spec
working
group.
We've
created
project
boards
and
burned
down
boards
for
various.
You
know
sub
projects
like
metrics
api
and
things
like
that.
K
But
I'd
like
to
propose
that
we
we
try
to
do
something
like
that
for
this
main
body
of
spec
work,
where
we
create
a
project
board
and
try
to
organize
it,
possibly
as
something
like
a
monthly
sprint
or
have
some
kind
of
you
know
triaging
process
where
stuff
gets
added
to
it,
so
that
we
have
like
more
clarity
about
kind
of
like
what
our
spec
goals
are
for
that
month
and
on
the
one
hand,
that
might
give
us
a
better
focus
for
being
able
to
process
those
items
faster,
because
everyone
could
see
what
what
was
on
the
menu
for
that
month,
and
it
would
also
provide
clarity
for
people
for
all
of
the
issues
that
we
know
we
can't
get
to.
K
Since
we
we
know
for
a
fact.
We
can't
we
can't
solve
every
spec
problem.
At
the
same
time,
it
would
be
a
good
way
to
provide
clarity
to
people
to
understand
like
why
we're
not
getting
to
their
issue
this
month,
because
we're
we're
working
through
this
other
backlog.
K
So
so
I
don't
have
a
specific
proposal
beyond
that,
and
credit
goes
to
daniel
dayla
for
for
making
this
proposal
initially.
So
I
wanted
to
bring
that
up
with
this
group
to
see
how
people
feel
about
something
like
that.
And
if
anyone
has
any
more
concrete
suggestions
for
how
we
could
use
something
like
project
boards
and
like
a
triage
process
to
help
provide
a
little
more
focus
and
clarity.
K
B
K
I
I
I
would
propose
that
you
know
the
tc
are
effectively
the
the
maintainers
of
the
spec
repo
right,
like
that's,
that's
more
or
less
a
big
part
of
being
on
the
tc.
So
yes,
the
tc
would
definitely
have
final
say
about
you
know,
what's
what's
on
the
agenda
for
that
month
and
and
would
guide
it
and
would
be
involved
in
the
triaging,
but
like,
like
other
backlogs,
that
we
have.
I
don't.
K
I
don't
see
any
problem
with
giving
you
know
effectively
like
triage
permissions
to
to
other
people
in
the
community
who
are
interested
in
helping
to
just
maintain
the
project
board.
There's
definitely
a
bit
of
that
work.
That
has
to
be
done
just
because
github
there's
like
a
beta
for
automating
the
stuff
more,
but
at
this
time
github
doesn't
actually
fully
automate
these
project
boards.
So
there
is
a
certain
amount
of
keeping
them
up
to
date.
K
That
has
to
happen,
which
is
why
we
should
only
create
project
boards
in
situations
where
you
know
it's
important
enough,
that
we
develop
a
process
for
keeping
them
in
charge,
but
it
would
be
the
tc
and
we
would
use.
K
We
would
be
looking
at
that
project
board,
essentially
in
this
meeting
and
either
in
this
meeting
or
at
some
point
maybe
on
you
know,
just
like
we've
done
with
other
project
boards
like
once
a
month
or
once
a
week
have
like
a
triage
session,
so
part
of
the
triage
would
occur
just
naturally
in
this
meeting
we
would
just
kind
of
be
trying
to
move
over
to
using
that
project
board
to
guide
what
we're
talking
about
in
this
meeting
to
a
certain
degree
and
then
the
aspect
of
trying
to
figure
out.
K
What's
what's
on
the
agenda
for
for
the
next
sprint,
we
would
probably
want
to
take
some
extra
time
at
some
point
to
do
that,
but
that
would
probably
be
good
because
that's,
I
think,
actually
part
of
the
process
that
that
we
don't
have
we
just
kind
of
like
chew
through
whatever's
in
front
of
us
until
it's
done
right
now,
but
we
don't
have
as
much
of
a
process
of
saying
we
think
we
can
solve.
K
We
think
we
can
like
get
through
this
stuff
this
month
or
we're
going
to
try-
and
you
know
once
we've
gotten
through
that
stuff.
What's
the
next
most
important
set
of
stuff
that
that
we
want
to
focus
on,
so
I
think
that
that
would
be
the
the
clarity
that
this
process
would
add,
and
a
project
board
is
a
good
way
to
to
capture
that
information
in
public,
where
everyone
can
go.
Look
at
it.
I
K
We
got
a
couple
other
tc
members
on
the
call
bogdan
and
josh
and
riley.
What
do
you
all
think
about
about
something
like
this?
I
think
another.
A
I
would
like
to
to
first
say
something
about
the
proposal.
I
think
the
proposal
will
only
work
if
we
have
a
program
manager
program
and
whatever
is
the
terminology.
Sorry,
I
I'm
so
happy
knowing.
I
think
it's
program
manager,
the
the
person
who's
supposed
to
to
do
this
or
the
tpm
in
google
or
whatever
it's
called,
but
anyway
we
need
somebody
a
scrum
master
or
something
that
comes
and
pushes
us
at
the
beginning
of
the
month
to
refresh
the
list
mark
things
in
the
board
and
stuff
like
that.
A
So
we
need
somebody
like
we
had
andrew
before
or
somebody
to
to
help
us
drive
this.
That's
that's
one
thing
and
I
think
we
will
fail
otherwise
totally
to
do
this.
The
the
other
comment
here
is
about
other
work.
I
think
the
other
work
should
be
treated
more
or
less
best
effort
and
the
people
that
are
interested
in
that
work
should
understand
that
it's
the
best
effort
to
work.
K
Yeah
yeah,
exactly
like
one
of
the
things
I've
I've
noticed.
I've
been
looking
at
kind
of
like
our
spec
process
and
where,
where
it
can
improve,
is
the
way
things
often
work
is.
There
is
a
group
who
cares
about
some
issue
or
some
aspect
of
spec
and
they're
working
on
it,
and
I
would
ever
say,
like
don't
do
that.
People
should
should
work
on
this
stuff
if
they're
interested.
K
But
what
happens
is
there's
a
certain
point
where,
because
this
is
a
big
community
effort,
whatever
work
is
being
done
by
some
small
group
then
has
to
like
actually
get
reviewed
and
approved
by
the
larger
spec
community,
and
you
know
in
particular
like
the
tc
and
spec
approvers
have
to
give
them
feedback
and
then
eventually
approve
it,
and
that
part
of
the
process,
I
think,
is
confusing
for
people
right
now,
because
what
happens
is
they
get
to
the
point
where
they're
they
want
to
review
right
now?
K
But
you
know
this
group
is
like
really
busy
and
has
a
lot
of
stuff
on
their
plate,
and
so
I
think
the
main
purpose
of
this
board
would
be
kind
of
like
clarifying
that
step.
Like
what
is
the,
what
are
the
tc
members
and
spec
approvers
and,
like
you
know,
like
this
group
here,
essentially
focusing
on
which
is
the
stuff
that's
like
in
the
state
where
it's
it's
ready
to
go
into
the
spec
or
you
know
it.
K
B
Sorry
we're
on
time
and
people
are
leaving
so
I,
but
I
guess
that
for
for
people
staying
one
more
minute,
I
guess
the
question
is:
where
can
we
find
such
person
like
pm
or
tpm
or
tpl
whatever?
So
that's,
let's
first
try
to
get
that
such
person.
They
can
play
that
all
okay
and
after
that
I
can
imagine
like
doing
triaging
like
I
don't
know
whether
weekly
or
monthly
but
yeah.
So
let's
shall
we
post
that,
in
isla
in
the
open,
telemetry
channel,
montana's
channel.
K
Yes,
yeah
posted
in
the
channel.
If
anyone
is
interested
in
that
role,
just
send,
you
know
on
the
call
right
now,
just
send
me
a
dm
yeah
would
be
interesting.
A
Ted
to
start
building
redundancy
and
maybe
look
for
two
people
on
because
he
was
such
great
with
andrew
and
then
everything
disappeared
because
we
didn't
have
continuity
yeah.
So,
let's,
let's
from
the
beginning,
I
mean
we
can
start
with
one
person.
But
let's
actively
looking
to
end
up
into
a
situation
where
we
have
two
people
over
this
in
this
position,
yeah
and
then
because
one
may
take
vacation,
one
may
leave
the
project
and
so
on
and
so
forth,
holidays,
yeah.
K
Okay,
that's
great
awesome
I'll
start
looking
around
if
anyone's
interested
in
in
helping
guide
the
spec
in
this
manner.
Definitely
let
me
know
stay
safe.
Thank
you.
So
much
ciao.