►
From YouTube: 2020-10-16 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
B
The
current
status
of
open
p1-
yes
sure
I
mean.
B
Right
so
these
are
p
ones.
I
put
an
update
in
getter
yesterday,
but
we
have
two
p1s.
B
We
actually
have
three,
the
third
one
is
tracked
only
because
it's
got
a
metrics
label
and
this
trace
label
attached
to
it.
So
it's
not
showing
up
on
this
dashboard,
but
we
have
these
two.
We've
got
owners
for
them,
but
nothing's
in
progress
for
them.
We
can
actually
dive
into
it.
The
third
one,
let
me
bring
it
up,
see
it's
this
one
labels
versus
attributes,
so
those
are
the
three
p
ones
that
we
have.
Thank
you.
D
This
one's
assigned
to
me
and
it's
I'm
gonna
close
it.
We,
I
think
we're
gonna,
keep
attributes.
I
think
that's
the
the
obvious
choice.
I
think
we
just
had
to
go
through
this.
This
conversation
did
anyone
disagree.
C
C
So
I
think,
even
if
you
want
to
go
with
attributes,
there
is
a
discussion
about,
should
metrics
use
the
same
attributes.
Maybe
should
packages
use
the
same
attributes
and
I
think
I
think
I
think
there
are
two
parts
here:
first
clarify
the
difference
between
labels
and
attributes
and
mention
that
they
are
not
signal.
Specific
then
second
thing
is:
where
do
we
use
one
versus?
Where
do
you
use
the
other?
But
anyway
I
I
will
pause
my
comment
after
this.
I
I
started
to
like
ten
minutes.
Okay,
I'm
gonna.
D
I'm
gonna
state
my
opinion.
I
think
this
is
gonna,
get
discussed
again
at
the
top
of
the
spec
sig
call
next
week,
I'm
leaning
towards
suggesting
that
we
try
and
use
a
single
word
and
keep
this
distinction
of
type
restriction
with
a
single
word.
In
other
words,
you
can
have
signal
specific
restrictions
on
attributes,
but.
E
D
I
take
your
approach.
Yours
was,
let's
keep
the
distinction
and
by
by
having
two
words,
that's
that's
the
table
but-
and
I
I
personally
have
opinions
about
which
is
best,
but
I
don't
care
enough
just
to
slow
us
down.
So
tag
is
good
enough
attribute
label
whatever.
C
Yeah
yeah
anyway,
let's
discuss
there.
I
I
think
I
think
this
one
can
we
go
back
to
the
dashboard
and
I
I
don't
know
what
the
heck
is,
this
one
p1
and
required
for
g.
These
are
some
some
semantic
conventions
that
we
define
with
the
old
status.
I
do
agree
that
we
need
to
clean
up,
but
I
think
we
can
do
it
a
bit
later.
Maybe
I'm
wrong,
but.
B
Okay,
this
was
from
an
issue
triage
from
one
week
ago
last
week.
B
B
We
just
oh,
no,
that's
forgotten
that
this
one
doesn't
have
open
pr.
None
of
the
three
have
open
pr's.
C
I
don't
know
how
everyone
feel
about
this
being
blocker.
I
don't
think
this
is
a
blocker.
This
is
again
this
is.
We
have
a
document
where
to
map.
G
B
B
C
C
A
G
A
Yeah
effectively,
yes,
that's
the
outcome,
I
mean
that's
the
result
yeah
of
this,
but
you
could
also,
even
if,
like
api
people
can
do
instrumentation
and
test
that
instrumentation
without
an
sdk
or
any
kind
of
test
harness
as
well
without
propagation
being
necessarily
the
consideration.
So
so
would
you.
A
Well,
I
think
I
haven't
seen
anyone
say
that
it
shouldn't
just
be
a
100
in
the
api
at
this
point,
so
my
call
I
did
make
a
call
a
couple
days
ago
is
like
does
anyone
think
this
should
be
sdk
implement
implemented
only
in
the
sdk
and
nobody
responded
with
a
positive,
so
I
could
put
a
poll,
but
I
think
that
that
comment
already
fulfilled
that
need.
I
think.
D
C
C
A
C
C
Okay,
so
we
are
done
with
the
we
went
to
with
a.
C
C
Perfect,
we
are
done
with
a
critical
thing,
so
let's
go
to
metrics
today
correct!
That's
what
we.
B
Discussed
we
got
two
things.
Sorry
I
had
to
take
a
screenshot
in
order
to
make
sure
I
say
thank
you
to
a
number
of
people.
We
got
a
lot
of
people
on
call
today,
but
two
things
we
have
new
issues
like
about
seven
or
eight
of
them
that
we
need
to
triage.
Do
we
do
the
three
hours
during
specs
meeting
or
here
we
do
it
both
here
and
also
specs
meetings.
So
that
way
everything
is
up
to
date.
C
C
C
C
A
D
Yeah,
I
agree
and
it
shouldn't
be
too
hard.
It
hasn't
been
a
big
priority.
A
John,
would
you
take
that
I
can't
make
any
promises
about
time
frame
of
being
able
to
write
anything
up
at
this
point.
Well,.
F
D
A
Is
it
been
assigned
to
me
I
I
don't
know
that
I
have
all
the
context
for
it.
That's
that's
the
other
consideration.
D
Questions
that
fall
out
of
it
like
yeah,
like
how
do
I
know
what
what
instruments
are
getting
you
know
used
at
which
intervals
and
and
then
it's
related
to
the
question
of
using
synchronous
instruments
during
asynchronous
callbacks,
and
it's
oh
yeah,
related
to
the
views.
It's
like
related
kind
of
everything.
I
E
I
A
There
is
a
I
mean,
I
think
there
is
the
distinction.
Is
it
bundled
with
your
api
artifact
or
is
it
something
that's
an
additional
artifact
with
the
fall
propagators
in
it?
I
think
there's
there
is
that
there
is
a
little
bit
of
a
distinction
there,
like
in
java,
there's
been
a
proposal
to
move
all
the
propagators
to
their
own
to
their
own,
distributed
artifact.
D
A
I
think
this
is
whether
we,
whether
the
api
needs
to
bundle
the
propagators
in
with
it
by
for
all
languages,
rather
than
whether
the
api
needs
to
some
propagation
needs
to
function
with
the
api.
Only
what.
A
Has
to
be
there?
No!
No!
No!
No!
No!
No!
No!
No!
If
I
have
an
api,
I've
installed
an
api,
I
don't
have
any
sdk.
Can
I
say
with
no
other
artifact
or
nothing
else,
just
be
a
configuration
turn
on
w3c
trace
context,
propagation
or
do
I
need
to
add
another
artifact
which
which
also
uses
the
api
to
implement
it
and
then
turn
that.
C
That
just
having
the
api
propagation
will
work,
then
we
cannot
have
a
separated
artifact.
I
do
understand
your
proposal
and
I
do
understand
the
option
of
having
a
separate
artifact.
That
does
not
require
an
sdk
implementation,
which
is
also
achieving
this,
but
I
think
I
think
we
should
clarify
if
just
the
api
artifact.
A
It
has
to
be
in
the
api,
yeah
agreed.
I
don't,
and
it's
not
my
proposal.
I
think
carlos
is
the
one
who
proposed
it.
I
think
it
should
be
bundled
in
the
api
itself,
but
I
don't
think
it's
clear
in
the
spec
and
I
totally
agree
with
the
issue
being
something
we
need
to
resolve.
C
If
you
said
carlos,
do
you
think
he
can
be
assigned?
We
need
to
assign
it's
a
p1
andrew
correct?
Is
it
a
big
change?
Is
a
small
change,
small
change,
but
we
still
need
to
assign.
B
Okay,
yeah:
I
can
throw
it
over
to
him
at
least
to
start
with,
I'm
not
sure
about
his
vacation
time
and
stuff
like
that
he's
moving.
So,
okay.
C
Okay,
just
put
a
comment
there
that
he,
if
he
doesn't
have
time,
just
be
assigned
to
him
and
we'll
figure
out
tuesday,
another
assignee.
C
Okay,
this
is
just
a
rewrite
of
the
things.
It's
not
changing
the
the
thing
I
would
put
p
two
and
allowed
for
g.
I
These
are
probably
pretty
low
priority.
Yeah
sounds
good.
B
So,
okay,
let
me
set
some
context.
These
were
prioritized
long
time.
Some
of
the
older
ones
like
on
page
two
were
prioritized
a
long
time
ago,
even
maybe
one
down
here
since
then,
we've
kind
of
changed
meaning
of
p1
p2
p3,
so
p1
means
it's
like
api
breaking.
We
really
really
must
get
it
in
and
it's
going
to
be
required
for
ga,
p2
and
p3
are
editorial
changes
allowed
for
ga
and
make
some
changes
if
they're
not
closed
by
the
time.
All
the
p1's
are
closed.
B
Then
it's
no
big
deal
we're
just
going
to
cut
without
it
we're
going
to
make
a
release
of
a
freeze
of
the
metrics
api.
Without
so
that's
the
context,
I'm
looking
for
in
terms
of
reevaluating
whether
these
are
p1
p2s
p3s,
because
there
are
some
older
ones
that
don't
adhere
to
that
same
meaning
because
we
made
the
change.
I
don't
know
maybe
two
months
ago
or
something
okay,
so
we
can
start
from
maybe
the
end
and
move
backwards.
A
D
Also,
it
looks
like
some
of
these
are
just
protocol
issues
which
don't
really
impact
api
stability,
like
our
api
spec,
hasn't
moved
a
lot
in
the
last
five
months
and
those
questions
about
batch
observer.
Those
are
the
type
of
questions
that
are
remaining
with
the
api.
Most
of
our
questions
are
about
protocol
support
for
certain
options,
which
are
sdk
specific
behaviors
that
we
still
want
to
specify
out,
but
as
for
the
metric
api,
we're
we're
pretty
stable.
E
B
B
C
Wait
wait,
wait,
wait.
This
is
a
semantic
community.
D
D
C
Also
very
important
if
we
have
a
push
protocol
in
order
to
there
is
a
problem
that
prometheus
resolves
by
having
a
poor
protocol,
which
is
the
determining
the
up
of
of
the
process
by
by
pulling.
But
when
you
do
a
push,
it's
kind
of
becoming
more
important.
So
I
would
I
would
like
to
transform
and
put
approximately
before
g
and
if,
if
we
decide
not
to
let's
decide
next
week,
but
let's
give
a
week
for
people
to
focus
on
that.
I.
D
Know
I
know
the
team
at
new
relic
has
got
someone
working
on
it.
Chris,
I
believe,
is
the
name
I
haven't
reviewed
anything
yet
so
yeah.
Let's.
D
And
unless,
unless
you
all
disagree,
I
agree
with
that
statement.
I
Yes,
and
there
was
even
a
spec
pr
and
eventually
I
closed
it,
because
I
felt
like
it
really
went
off
the
rails.
My
plan
now
is
really
just
to
kind
of
revive
that
or
rewrite
that
pr
and
try
again.
D
G
D
D
I
think
that
this
can
be
done
quickly.
Therefore,
I'm
going
to
say
required
for
gi.
B
D
I
I
have
no
strong
feeling.
I
do
think
that
yeah,
I
think
a
lot
is
sufficient.
I
think
justin's,
probably
gonna,
knock
us
out
of
the
park
and
have
it
done
in
probably
two
days
right.
Justin.
C
Fate,
you
have
in
me
yeah
always
define
making
semantics
for
rpc
same
rule.
P2
allow
for
g.
C
This
is
for
messaging
system.
This
may
even
be
p3.
In
my
opinion,
I
I
think
if
timing
and
and
rpcs
are
very,
very
important,
this
may
be
a
big
tree.
H
C
C
B
C
I
There
were
some
extra
requests,
actually
that
came
from
bogdan
when
graham
was
putting
together
this
original
spec
and
rather
than
delay
the
pr
for
the
original
http
spec.
We
decided
to
split
it
out
into
a
new
vr.
D
B
So
leaving
them
bring
it
to
p2
or
leave
it
on
p3.
D
Yeah
when
I
found
this
I
mean
obviously
this
is
ages
ago.
I
think
we've
made
tremendous
progress.
All
those
p3
allow
for
gas
that
we
just
went
through
are
the
ones
that
resulted
from
this.
I
almost
want
to
disclose
this
right
now,
because
it's
substantial
progress-
and
we
have
some
issues
now.
D
Good
question:
there
is
pieces
and
fragments
of
text
floating
around,
and
I
think
this
is
something
I
tried
to
load
upon
justin
to
to
be
the
sort
of
owner
of
that
question.
D
D
G
C
Can
you
can
we
just
close
this
one
and
file
a
new
issue?
I
will
file
a
new
issue
that
we
need
a
standardization
for
how
to
to
name
things,
how
to
and
stuff
like
that
make.
C
D
I
D
Yeah,
I
think
so
it's
gonna
especially
questions
about,
underscores
and
prometheus
when
it
comes
to
metrics
that
are
kind
of
thorny
and
we
should
we
should
have
a.
D
Was
also
like
a
really
a
really
snarky
type
of
issue,
comment
from
somebody
outside
the
community
about
dots
and
names
and
established
protocols
that
we
were
ignoring,
especially
the
http
header
or
syntax
rules.
Did
you
remember
that
one
I?
It
was
somebody
who
was
kind
of
being
offensive,
but
also
had
a
lot
of
important
things
to
say.
D
D
Seems
related
at
least,
but
this
of
course
crosses
tracing
and
metrics.
This
is
a
project
life
concern
that
you
just
gave
about
dots,
and
you
know
names
and
things
like
that.
I
It
seems
as
though
we
have
settled
on
an
like
an
unwritten
convention
of
using
dots.
D
It's
pretty
standard
in
the
statsy
world,
it's
pretty
standard
in
hotel.
I
think
it
came
from
open
tracing
as
well.
I
don't
know
bogan
did
the
open
census
also
start
this
in
this
spot
yeah
we
we
use
dots
as
well.
So
that's
why
I'm
going
to
go,
find
this
snarky
email
or
could
have
issue.
I
G
C
Think
it's
almost
the
same
as
the
issue
bogey
was
going
to
file.
I
think
yes,
I'm
not
going
to
file.
This
is
more
I'm
just
going
to
publish
a
bit
the
text
here
and
whatever,
but
I'm
going
to
put
this
as
the
original
thing,
and
this
should
be
required
for
g
in
my
opinion,
because
we
need
to
have
just
this
before
g
and
any
other
standard
semantic
convention.
I
I
D
E
C
I
think
a
p2
after
for
ga.
I
think
this
is
should
be
closed,
because
I
I
will
close
this
as
a
duplicate
of
the
other
one
correct.
K
G
C
D
I
have
to
run,
but
I
have
more
time
maybe
this
afternoon,
but
more
likely,
that's
monday
or
tuesday.