►
From YouTube: 2020-11-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).
A
A
A
I
think
we
should
probably
start.
I
asked
him
on
getter
if
he's.
B
B
Let
me
see,
we've
hit
a
milestone
where
the
trace
api
has
been
frozen.
Officially,
with
a
git
tag
and
the
status
of
the
remaining
p1
issues.
Almost
all
of
them
are
metrics.
B
A
A
A
There
it
is
oh,
oh
right,
I
resolved
that
and
opened
a
new
issue
wherever
that
one
went
this
one
yeah,
so
maybe
that
was
yeah.
This.
A
B
So
it's
it's
going,
and
this
is
just
p1
that
I've
highlighted
there
are
also
other
p2s
p3s,
but
the
p1
are
the
ones
that
we
really
need
to
get
done
for
the
gta.
B
Let
me
see
I
have
a
couple
other
items
that
I've
put
on
the
list
as
well.
Next
one
is
related
to
metrics
api
and
sdk.
I
noticed
at
the
tc
meeting
the
other
day.
That's
what
yesterday
it
was
mentioned,
specifically
aiming
for
the
end
of
january
for
the
metrics
spec
freeze
at
this
point
right
here.
A
Yeah
that
was
made
up
the
the
group
was
basically
discussed
it
and
we
thought
that
if
we
all
really
put
our
minds
to
it,
we
could
get
this
done
and
I
think
it's
a
stretch,
but
I'm
willing
to
try.
B
Okay,
so
that
so
we
can
work
backwards
and
see
how
things
track
from
there
like.
There's,
not
that
many
weeks
left
in
this
november
or
december,
of
course,
because
of
the
holidays
and
then
january.
A
A
Get
this
done
by
january.
We,
I
think,
like
some
serious
planning
is
gonna
have
to
take
place
to
sort
of
sequence
like
there's
too
much
work
that
gets
kind
of
like
slow,
like
open,
pr's
end
up
lingering
and,
for
example,
I
have
two
right
now
on
the
spec
that
I'm
having
trouble
just
like
refreshing,
my
memory
about
because
they're
two
weeks
old
and
so
there's
somehow.
We
need
to
like
free
cycles
for
people
to
write,
specs
more
and
I
think
that'll
that's
possible.
But
it's
going
to
require
some
careful
organization.
A
We
might
have
a
pr
pressure
on
to
get
the
metrics
sdks
finished,
but
that
there
is
this
tension,
because
some
of
them
already
work
at
some
level
or
partially
work
and
can
be
tempting
to
just
say:
okay,
let's
go
with
what
we've
got
partially
working
and
then
you
know
like
no
one's
working
on
spec.
D
Have
we
done
any
sort
of
man?
I
sound
like
a
pm
at
this
point,
some
sort
of
like
retrospective
or
something
like
that
on
the
tracing
side
of
things
like
could
we
have
learned?
You
know
how
to
approach
things
better
because
of
that
like
because
I
kind
of
wonder
of
that
approach
of
trying
to
get
perspective
and
then
the
implementations,
because
it
seems
like
we
had
some
thrash.
C
D
In
there,
just
because,
like
some
implementations
were
saying,
like
you
know,
oh
by
the
way
like
in
this
language,
that
makes
absolutely
no
sense,
which
may
be
inevitable.
But
I'm
just
kind
of
wondering,
like
I'm,
posing
the
question,
just
wondering.
If
we've
done
something
to
try
to
learn
from
that.
A
We
mean
we
have
been
implementing
these
sdks,
so
we've
got
the
go
reference
implementation,
but,
and
one
of
the
reasons
that
I've
been
like
a
little
bit
distracted
from
like
working
on
hotel
right
now
is
that
a
lot
of
the
light
stuff
engineers
are
like
asking
me
questions
every
day
saying
we
tried
to
use
this
code
and
it
turns
out
it's
not
quite
working
and
then
please
explain
and
I
end
up
spending
a
lot
of
time
explaining
that
to
them,
because
we
do
want
it
to
work
and
we
actually
have
some
people
working
on
getting
it
to
work,
but
they're
working
off
of
like
me,
directing
them
rather
than
me,
writing
a
spec
to
direct
them.
A
And
it's
that's.
Why,
like
I
can't
decide,
I
can't
figure
out
what's
the
right
use
of
time,
so
I
I
think
I
take
it.
Your
point,
tyler's
is
good.
We
we
are
also
working
on
sdks,
but
I
just
didn't
want
to
kind
of
promise
them
like
until
after
the
spec
is
finished,
which
is
contradictory.
As
I
see
you
point
out,.
D
Okay,
yeah,
that
makes
sense
yeah.
I
think
that
trying
to
optimize
the
amount
of
like
time
that
you
spend
doing
things
that
are
going
to
be
multipliers
is
a
really
good
idea
and
kind
of
like
john's
comments.
I
think
on
your
sdk,
your
latest
pr,
one
of
your
latest
pr's
was
just
you
know
like
this
is
really
good.
I
think
john
was
going
through
and
just
like
green
fielding
a
little
bit
of
a
new
sdk
so
like.
D
I
think
that
your
time
spent
on
the
specification
is
extremely
valuable,
also
putting
words
into
john's
mouth,
where
I
think
it's
on
the
call.
So
thank.
A
E
To
follow
on
from
what
tyler
said
at
the
java
sig
meeting
yesterday
well,
actually,
two
weeks
ago,
I
I
created
an
issue
in
the
java
implementation,
repo,
basically
saying.
I
think
we
need
to
rewrite
the
spec
or
rewrite
the
sdk,
not
the
spec,
the
sdk,
because
what
is
in
java
works,
but
it
does
not
really
bear
any
relation
to
what
the
spec
looks
like,
and
this
brought
up
and
andrew.
E
E
What
does
it
mean
to
be
compliant
to
a
specification
on
the
sdk
side,
especially,
and
what
are
the
requirements
to
being
able
to
say
that
an
implementation
is
spec
compliant,
because
if
we're
super
loose
a
goosey
and
the
java
sdk
doesn't
have
to
look
anything
like
the
the
implementation
yeah,
we
can
release
something,
but
I
think
it's
going
to
be
very
difficult
to
have
a
coherent
discussion
about
implementation
details
without
having
all
the
implementations,
at
least
at
least
structurally
match.
A
Yes-
and
I
think
you
earlier
john,
had
asked:
could
we
just
write
requirements
in
that
sdk
spec
and
I
think
you
were
worried
about
the
sort
of
model
implementation
parts
that
I
had
been
writing
and
then
I'm
not
sure
how
you
feel
now
about
that.
Well,
so
what
I
feel
now.
E
E
A
E
A
Yeah
I
like
it,
I
do
have
two
open
pr's
with
spec
wording
in
them
and
I
and
I
knew-
and
I
was
looking
over
them
earlier
today
and
I
realized
that
you've.
Given
me
some
feedback
and
and
then
I
dropped
the
ball
and
now
I'm
going
to
get
back
to
that.
So
I'm
going
to
look
to
you
to
help
me
review
these.
E
E
That'd
be
great,
so
I
think
the
the
one
thing
that
I'd
love
out
of
this
sig
is
a
little,
maybe
a
little
bit
of
support
on
my
desire
to
rewrite
what
we
have
in
java,
so
that
I
can
get
the
first
pr
merged.
That
is
my
working
like
super
super
basic
work
in
progress
of
the
new
module.
That
is
the
rewrite,
because
right
now
I
feel,
like
I
put
this,
I
put
logged
the
issue
in
java
and
essentially
got
nobody
responding
whatsoever
and
carlos.
E
And
I
think,
if
carlos
just
kind
of
gave
even
gave
that
issue
a
thumbs
up
just
bare
minimum,
just
give
the
issue
a
thumbs
up
I'll
put
in
the
pr
with
my
very
first
steel
thread.
That
goes.
Has
one
instrument
end
to
end
working
unoptimized
and
just
get
that
pr
and
get
things
get
the
ball
rolling
great.
F
F
E
F
A
I
also
do
think
carlos
is
trying
to
get
in
there
too.
So
we'll
and
I'll
mention
that.
E
A
B
You
so
we
move
on
to
the
next
topic,
which
is
a
bit
of
logistics.
I
was
looking
for
the
inflection
point,
as
I
mentioned
earlier,
we've
arrived
at
it.
B
This
trace
back
frozen
I'd
like
to
propose
to
this
group
that
we
consider
perhaps
canceling
this
metric
spec
meeting
in
new
of
the
specsic
meeting,
because,
as
you
guys
all
know,
this
is
the
smartest
best
group
of
people
related
towards
metrics
and
hotel
sitting
right
here,
and
we
also
have
another
group
of
the
spec
sig
that
has
other
people
who
would
also
participate
and
get
the
specs
to
a
level
that
would
be
suitable
for
ga
and
I'm
thinking
this
could
be
an
opportunity
to
reduce
the
number
of
meetings
in
our
week
and
also
make
sure
that
we
have
the
audience
of
everyone
related
and
just
have
this
metrics
issues
at
the
forefront
of
all
the
things
that
we
talked
about
for
until
matrices.
B
That's
my
pitch
now
of
the
meetings
that
we
have
for
the
metrics
sick.
I
see
that
there
are
some
over.
We
got
europeans.
We've
got
asian
folks,
asia,
pacific
time
zone.
Folks
right
so
we
have.
Let
me
see
at
the
beginning
and
here
11
a.m
and
4
p.m.
B
For
this
metric
sig
on
thursdays
and
the
spec
sig
has
8
a.m
and
4
p.m,
meeting
times,
actually
every
tuesday
at
the
8
a.m
and
then,
in
addition
on
every
other
tuesday,
the
4
pm
for
the
for
the
asia
pacific
time
zones.
B
So
that's
how
those
would
line
up
if
it
is
okay
with
this
group.
I'd
also
then
proceed
to
bring
this
to
the
specs,
it
being
saying:
hey
we're
going
to
be
concentrating
on
the
metrics
issues
on
the
specsic,
meaning.
A
So
I
know,
are
we
actually
changing
the
spec
meeting
to
alternate
tuesdays
and
mornings
and
afternoons?
It's
it's
been
both.
A
I
was
wondering
if
that's
already
happened,
but
but
I'm
not
sure
it
has
so
in
your
cursor
here
it
says
the
8
am
would
be
every
tuesday
every
oh,
it
does
say
every
every
other
tuesday
afternoon,
okay,
so
every
other
week
we
do.
Two
meetings
is
what
you're
saying?
Yes,
okay,
I'm
sorry!
I
got
confused.
A
I
think
this
is
okay,
but
it
doesn't
make
me
think
that
we
should
probably
invest
some
serious
time
and
like
issue
triage
and
just
making
sure
that,
like
I
kind
of
want
there
to
be
a
complete
set
of
issues-
and
I
I'm
I'm
like
wondering
what's
missing
right
now
as
and
I
don't
know
I
when
I
think
of
what
are
the
big
issues,
it's
labels
versus
attributes,
it's
histogram
beta
types
and
that's
kind
of
it.
I
don't
know,
I'm
sure
there
are
lots
of
other
little
ones,
but
those
are
the
ones.
D
A
D
I
mean
like
I,
I
don't.
I
want
to
get
a
ga
yeah.
You
know
like
yeah,
that's
pretty
important.
So
just
as
long
as
we
have
like
an
understanding
across
the
group
as
to
like
what
that's
gonna
entail.
A
A
You
know
cumulative
to
delta
or,
like
you,
can
choose
your
exporter
and
you
can
choose
certain
memory
behaviors
for
prometheus
or
not
and
so
on,
but
that,
like
a
grand
configuration
approach
or
some
sort
of
like
is
beyond
our
like
means
right
now,
and
I
don't
think
we
should
try
and
do
something
fancy
so
that
if
otel
is
just
a
as
an
sdk
toolkit
with
one
default
behavior
that
works
at
ga,
that's
good
enough
and
those
that
the
tools
can
be
kind
of
turned
into
more
later.
E
A
Yeah,
I
think
that
we
want
that.
We
just
there's
this
question
about
the
protocol.
That's
still
up
and
then
I
there's
some
question
about.
E
I
have
I
have.
I
have
some
serious
concerns
about
the
viability
of
dd
sketch
after
tyler
natalyan,
the
other
tyler
from
datadog
put
in
a
pr
into
the
java
repo
for
it,
because
it's
not
thread
safe,
which
means
that
every
recording
has
to
be
has
to
have
a
lock
on
it
before
it
can
be
recorded,
and
I'm
very
worried
that
it's
not
going
to
be
able
to
keep
up
with
this.
A
So,
as
far
as
I
mean,
is
there
an
hdr
histogram,
that's
concurrent
and
dynamic,
because
that's
a
better
option.
If
you
have
that
and
that
might
be
the
way
to
go,
I
don't
know
I.
I
think
this
is
actually
one
of
the
reasons
why
I
was
hoping
we
could
just
say
any
histogram
and
that
I
think
yuka's
protocol
proposal
in
the
proto-repo
is
is
very
flexible
so
that
we
could
drop
in
any
of
the
histogram
algorithms.
So
if
you
have
one
that
has
good
concurrency,
maybe
you'll
choose
that.
A
Yeah
I
get
I'm
just
referring
to
how
even
for
a
trivial
histogram
you
can
make
the
individual
bucket
like
increment,
be
atomic
and
not
need
concurrency.
But
then
there's
been
some
question
in
the
past
about
whether,
when
you
export
a
histogram,
whether
you're
required
to
get
like.
A
Whether
the
buckets
should
be
a
consistent
snapshot
or
if
you
can
walk
through
the
buckets
one
at
a
time
and
like
I
don't
think
it.
We
haven't
really
discussed
at
this
level
of
detail
what
the
spec
should
be.
But
we
did.
I,
as
I
recall
early
on,
have
some
discussions
about
whether,
if
you
were
exporting
this
so-called
min
max
some
count,
whether
you
were
ever
allowed
to
get
a
inconsistent
view
where
you
get
like,
say
the
min
and
the
max,
but
not
the
sum
of
the
count,
and
that
that
could
happen.
A
F
A
A
It's
like
a
hot
cold
bit
and
there's
like
two
sets
and-
and
it
actually
makes
sure
that
your
histogram
is
consistent
and
it,
but
it
requires
this
extra
synchronization
and
we
decided
to
just
use
a
mutex,
but
we
could
go
the
direction
that
you
said
that
this
is
a
spec
question.
You're
right.
E
I
mean
there's
a
there's
another
option
that
I've
been
considering,
which
is
so
in
the
in
the
the
prototype
java,
ddk
dd,
sketch
pr
there's
they
put
a.
We
put
a
cue
in
between
this,
the
sketch
and
the
reporter,
and
the
sketch
is
being
recorded
on
a
different
on
a
different
thread,
but
the
then.
If
we
took
that
strategy,
you
need
to
at
least
specify
what
the
behavior
should
be.
If
the
queue
gets
full
yeah.
Could
you
drop?
Should
you
block
and
flush
it
all
out
or
what
what
the
behavior
should
be?
This.
A
Reminds
me
of
an
implementation
that
bogdan
described
for
district
for
getting
the
baggage
or
the
distributed
context
field,
because
that's
an
expensive
operation
where
you
actually
have
to
walk
through
the
baggage
items.
Looking
for
keys
that
you
might
want
to
attach
as
labels,
and
he
has
described
to
me
a
cue
to
do
that-
asynchronously,
which
just
raises
complexity.
A
I
don't
know
I.
I
don't
really
know
how
much
like,
because
hotel
is
gonna
sort
of
have
so
many
users
like.
I
can
imagine
that
there's
a
small
number
of
users
who
really
do
care
about
this
type
of
concurrency-
and
I
think,
like
one
good
answer-
is
that
you
can
always
decide
to
drop
in
a
better
approach
later.
So
if
we
can
find
a
concurrent
histogram
and
then
we
can
swap
it
in.
E
A
Spec
does
say
very
clearly
that
that
the
accumulator
must
not
take
a
lock
to
make
sure
that
an
aggregator
that
doesn't
take
a
lock
gets
that
benefit.
So
it
is,
it
has
been
pushed
into
the
aggregator
at
least.
B
Josh
back
to
your
original
point
of,
like
you
desire
a
triage
of
issues
in
order
to
be
able
to
get
a
landscape
of
the
kind.
B
On
fridays,
like
fridays,
30
to
9
o'clock
a.m,
it's
a
half
hour!
So
that's
where
I
got
the
audience
of
like
bogdan
tigran
and
it's
dedicated
for
spectriage
and
such
so.
I
can
set
an
agenda
there
in
order
to
be
able
to
do
something.
What
what
was
that
you
want
to
do.
A
A
E
Issue
about
that
one
at
least
yeah
ken
finnegan
and
I
are
working.
I
tagged
you
by
the
way
on
a
java
pr
josh
to
take
a
look
at
an
idea
for
a
new
shape
of
api,
for
that.
That
might
make
it
easier
to
understand
that
if
you're,
okay,
with
we'll
write
up
a
spec
for
it.
A
I'll
take
a
look,
definitely
my
email,
I'm
not
sure
it's
like
falling
behind
on
email,
but
I'll.
Look
great!
No,
no
worries.
B
B
B
Okay,
okay,
okay,
so
you're
looking
for
in
order
to
accomplish
that
before
just
merging
the
meetings
together.
A
I'll
I'll
come
to
one
tomorrow
and
then
I'm
not
going
to
be
at
the
spec
meeting
on
next
week.
I
think
I'm
going
to
be
away
from
town
and
then
maybe
by
the
following
tuesday,
we
should
expect
to
have
a
full-on
metrics
discussion.
Respect
me,
spexig.
B
Okay:
okay,
thanks
that
helps
with
cleaning
the
timeline.
I
will
also
be
out
of
town
on
the
road
next
week,
but
I
I
will
host
the
triage
meeting
tomorrow
and
I'll
put
something
in
the
github
channel
in
order
to
get
bogged
in
and
into
green's
attention
on
it.
B
B
All
right
next
agenda
item
is
openmetrics
how
to
release.
A
So
I
see
richie
has
put
in
a
note
saying
he
couldn't
make
it,
but
he
wanted
to
discuss
it
and
he's
offering
some
times
for
me
and
bogdan
to
to
have
a
one-on-one,
which
is
fine.
I
do
would
prefer
that
we
as
a
group
could
talk
about
it.
Perhaps
so.
A
There
are-
and
I
don't
know
that
we
should
just
do
it
right
here
and
now.
Perhaps
this
should
be
a
an
issue
discussion
or
something
like
that.
But
but
if
you
look
at
this,
the
open
metrics
there
are
sort
of
some
standard
stuff
like
counters
and
gauges
and
and
histograms,
and
those
are
the
ones
that
we
are
like
very
much
need
to
understand
and
get
compatibility
for
and
then.
A
Other
types
that
I
I
feel
are
useful
to
talk
about
and
may
be
useful
for
the
future
that
we
can
do,
but
I
don't
think
matter
that
much
and
that
we
don't
need
to
worry
about
very
much
so
there's
something
called
you
know.
Well,
gage
histogram
has
a
ticket
about
and
we
are
discussing
that
bogdan
and
I
have
been
back
and
forth
with
one
of
the
other
contributors
and
then
summary
has
been
discussed.
We
have
a
protocol
change
for
that
and
but
state
set
and
info
and
unknown.
Oh,
I
don't
know
who
cares.
A
Now
for
the
rest
of
those
types,
we
need
to
talk
about
whether
we
want
to
transform
them
into
otlp
or
whether
we
want
to
add
a
new
type
in
otlp,
and
I
I
just
don't
know
how
important
I
just
don't
have
a
sense
for
which
clients
might
be
generating
these
data
and
how
how
people
expect
to
use
these.
I
haven't
seen
the
apis
that
let
you
write
a
state
state
full
set
or
whatever
it's.
D
I
have
kind
of
an
open
question
about
how
much
of
a
priority
is
it
that
we
could
set
up
a
pipeline
that
receives
open,
telemetry
and
emits
open
telemetry
without
mutating
it
at
all.
A
A
Yeah
yeah,
so
can
we
pass
open
metrics
straight
through
an
otlp
pipeline
and
end
up
with
openmetrics?
I
guess.
A
Well,
I
think,
for
for
histograms
and
some
like
all
the
standard
data
types.
I
think
the
answer
should
be
yes,
absolutely
and
then
I
think
maybe
you're
thinking
about
questions
about
like
underscores
and
like
syntactic
stuff.
I
don't
know,
but
as
far
as
the
data
data
models,
I
think
that
they
line
up.
A
D
Yeah,
I
wasn't
so
much
thinking
about
the
naming.
I
guess
I
had
been,
assuming
that
we
would
accept
the
open
metrics
naming
we.
D
Naming
and
then
we
admit
them
in
the
same
way
and
for
counters
gauges
and
histograms,
I
think
yeah,
that's
easier.
I
guess
I
was
kind
of
questioning
about
these
other
data
formats,
data
structures
and
whether
we
want
to
support
those.
A
Yeah
I
wish
somebody
from
other
metrics
were
here
to
talk
about
how
they
think
those
are
very
important
since
I
I
just
don't
know
like
I
don't
know,
there's
prometheus,
I
feel
like
I
know
very
well
and
I'm
understanding
their
client
libraries,
but
then
openmetrics
are
there
libraries
that
I
haven't
seen
that
generate
these
things.
That's
what
I
want
to
know,
but
I
think
we
ought
to
be
able
to
do
a
bidirectional
transform
either
with
a
new
type
or
with
some
sort
of
conventions.
A
I
don't
know
like
an
example
of
the
the
state
set
thing,
or
these
in
nums
is
that
you
could
represent.
Instead
of
having
booleans,
you
could
have
a
label
just
ordinary
labels
with
a
one
or
a
zero.
So
that's
one
way
you
could
represent
state
sets
and
then
I've
definitely
had
experience
with
systems
that
have
string
valued
gauges.
I
know
john
you've
mentioned
it
about
at
some
point
in
the
past
and
this
these
enums
are
sort
of
like
that,
and
you
could
you
can.
A
E
A
A
C
Yeah,
so
the
thing
is,
we
need
a
way
to
rename
our
metric
labels,
but
we
we.
We
have
a
problem
here
like
we
cannot
get
our
metric
levels
until
we
raise
the
exporter,
because
our
metric
levels
are
basically
being
generated
from
our
resource
attributes
using
the
exporter
helper
module
with
a
new
option,
we
added,
so
we
need
something
to
rename
our
resource
attribute.
So
I
had
a
little
discussion
on
twitter.
We
take
on
right
now
we
can
do
it,
but
we
need
two
actions.
One
is
like
we
can
generate.
C
A
new
attribute,
then
delete
the
previous
one.
That's
why
I
was
planning
to
propose
writing
something.
A
new
action
may
be
in
the
attribute
processor,
just
quality
name
visual
in
the
new
existing
activator,
rather
than
using
two
actions.
So
I
just
want
to
get
a
thought
here.
So
if
it
looks
good,
maybe
I
can
start
the
implementation.
A
The
only
thing
this
makes
me
think
of
is
that
prometheus
has
us
like
a
precedent
for
how
to
to
like
express
these
relabelings
and
they
have
actions
the
standard
action
names
already
so,
and
I
don't
remember
them
off
the
top
of
my
head.
I
I
wonder
if
we
can
be
closer
to
this
prometheus
world,
but
I
and
I
thought
that
there
was
already
something
like
that
in
the
collector.
B
A
Okay,
I
don't
feel
like
I
have
enough
understanding
of
collector's
actual
code
to
help
here.
A
Okay,
so
the
standard
relabel
action
field
in
a
prometheus
relabeling
rule
can
be
one
of
replace,
keep
drop,
hash,
mod
label
map
label
drop
and
label
key
and
with
those
actions
you're
able
to
implement
a
variety
of
re-labelings,
I
would
feel
it
might
be
beneficial
to
use
those
same
concepts,
and
I
suspect
that
there's
already
an
existence
of
something
somewhere
somewhere
in
the
collector,
and
that's
where
I
don't
know
where.
C
A
A
A
C
A
A
Yep
we
need
logan
to
come
to
these
meetings,
so
I'm
going
to
harass
him
a
little
bit
about
that.