►
From YouTube: 2021-06-15 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
Back
from
two
weeks
of
not
being
here
so
I'm
catching
up,
but
I'm
glad
to
be
back.
Are
you
in
the.
B
I
am,
this
is
a
new
location,
mendocino
county,
also
noting
that
now
that
I'm
back
I've
added
the
go
sig
meeting
back
to
my
calendar,
so
I
can
get
involved
in
metrics
in
the
grow
sig.
D
A
You
know
you
should
get
a
background
filter.
That's
your
old
house.
C
A
A
No
zoom
just
really
likes
the
color
red.
I
guess
red
is
faster.
Gotta
go
soon,
all
right
so
for
folks
joining
feel
free.
To
add
your
name
to
the
notes
and
add
agenda
items
that
you
want
to
talk
about.
We
didn't
actually
have
anything.
I
felt
the
need
to
add
in
the
discussions
outside
of
like
things
that
people
want
to
discuss
for
this
particular
meeting,
and
then
we
have
one
issue
from
last
time
that
I
think
is
worth
hashing
out,
maybe
spending
a
little
bit
more
time
on.
A
A
B
E
Yeah
sure
do
you
want
to
since
you're
sharing
screen.
You
want
to
just
click
on
the
link
there.
I
am.
E
And
then,
if
you
go
to
the
yeah
and
when
you
get
there,
there's
a
issue
309
I
put
up
posted,
I
put
a
post
there
and
we
could
discuss
that.
First.
All
right
give
me
a
sec
because.
A
I
have
to
move
this
all
to
a
separate,
zoom
tab
and
share
that,
because
it's
not
letting
me
switch
tabs
and
zoom
all
right
shoes
window,
open,
telemetry,
sig.
Okay,
now
do
you
see
my
entire
chrome
window
this
time.
E
If
you
go
to
the
first
link,
there
number
309,
okay.
So
let's
go
to
the
bottom
of
this
thing,
so
I
tried
this
week
to
add
the
non-negative
value
keys.
So
I
have
a
comment
on
what
we
could
do
regarding
backward
compatibility
per
se.
E
So
I'll
just
start
off
by
saying
I
think,
last
week
we
said
that
you
know
introduce
the
flag,
no
recorded
value
on
the
bottom,
and
my
expectation
for
backward
compatibility
is
that
the
count
field,
as
well
as
the
sum
field,
as
well
as
the
bucket
count
field,
would
by
default,
be
zero.
E
So
if
you
were
implementing
the
old
spec,
it
would
allow
for
count
of
zero.
So
presumably
it
would
just
be
the
benign
code
if
you
were
to
just
send
that
over
with
count
of
zero.
I
have
not
verified
this
with
a
collector
anything.
You
know
regarding
that,
so
this
is
purely
just
from
spec
perspective.
E
So
continuing
on
that,
based
on
that,
I
tried
to
introduce
the
flag,
non-negative
values.
Naming
is
problems
so
please,
you
know
please
inform
me
what
the
naming
should
be,
but
but
right
now
I
called
it
a
non-flag
for
non-negative
values,
and
the
intention
here
is
to
say
that
this
particular
time
period
for
this
histogram-
and
this
is
in
the
scope
of
within
a
histogram
that
there
are
the
there
are.
E
Not
all
the
values
being
considered
for
this
histogram
are
all
non-negative,
that's
zero
and
positive
numbers,
okay,
and
to
try
and
get
that
working
for
backward
compatibility.
We
have
a
complication
with
how
we
currently
do
the
sum
in
which
we
have
a
note
in
our
spec.
That
says
that
if
you
do
count
negative
numbers,
you
should
not
provide
the
sum
field.
However,
in
proto
buff
three,
I
don't
know
that
older
code
can
distinguish
between
a
sum
not
being
set
versus
a
sum
just
being
equal
to
zero
okay.
E
So
I
did
some
google
search
around
that
and
I
don't
think
in
prototype
protocol
protobuf
3.
You
really
could
tell
that
different,
so
we
needed
something
else
to
kind
of
designate
that
and-
and
the
best
I
could
come
up
with
at
this
point
is
to
say
that
I
need
to
deprecate
the
count
and
sum
field,
those
two
fields
and
introduce
two
new
fields,
which
is
basically
the
same
as
population
count
and
population
sum,
but
population
count
population
sum
you
know,
because
it's
new
code
will
then
know
to
honor.
E
Also
this
flag,
that
says,
know
the
the
non-negative
values.
So
if
you
are
running
o
code
and
you
encounter
someone
introducing
this
new
stuff,
your
count
and
sum
will
still
be
zero,
which
will
leave
you
being
benign.
E
But
if
you
are
aware
of
the
new
code,
you
will
look
at
the
population
count
and
the
population
sum,
and
then
you
know
that
it's
new
code,
so
you
could
then
check
the
flag
for
the
non-negative
values.
To
know
that
you
know
to
know
to
know
that
this
particular
histogram
is
all
non-negative
and
then
you
could
then
have
prometheus
support
per
se
now.
At
the
same
time,
I
think
that
the
the
population
sum
I
think,
regardless
of
whether
you
have
negative,
not
non-negative,
I
think
that
should
still
be
just
counted.
E
A
A
That's
not
it
here,
it
is
inside
of
histogram.
There
is
a
count
and
there
is
a
sum
and
for
open
metrics.
They
want
to
be
able
to
export
some
as
an
open,
metrics
sum
right,
which
means
that
it
has
to
be
non-monotonic.
A
And
similarly,
I
think
count
is
the
number
of
values
and
count.
I
don't
know
if
we
need
to.
I
don't
know
if
count
can
go
negative,
that's
just
the
number
of
values
in
the
population.
Right
sum.
D
A
Sum
is
the
problematic
one
here
where
some
could
have.
If
we
have
negative
measurements,
we
can't
guarantee
that
this
is
strictly
an
open
metric
sum,
so
we'd
have
to
export
it
as
either
a
gauge
or
we'd
have
to
export
it
as
a
sum.
If
we
know
that
the
values
are
not
negative,
so
what
victor's
proposing
here
is
actually
we
create
this
flag
that
tells
us
whether
or
not
the
values
are
all
non-negative.
A
So
whether
or
not
the
sum
can
be
a
prometheus
sum
and
we
move
to
a
new
field
where
it's
absolutely
clear
that
the
values
could
be
negative
or
not,
and
we
look
at
this
flag
and
the
reason
is
because
if
we
were
to
just
introduce
the
flag
without
changing
this
protocol
buffer
at
all,
it
means
that
some
has
a
new
meaning
that
would
break
prometheus
exporters
where
they
might
be
exporting
a
sum
that
is
completely
broken,
that
they
actually
shouldn't
be
exporting
at
all.
A
B
A
F
E
B
A
E
Right
so
I
needed
the
count,
because
if
you
were
to,
if
you're
running
newer
code
and
your
account
does
include
negative,
that
means
your
account
would
be
higher
than
what
you
normally
would
have.
If
you
were
not
so
the
code
would
then
you
know
you
could
still
make
it
work,
but
it
was
just
disambiguate.
A
E
G
The
other
thing
is
usually
you
in
protobufs
the
the
way
to
do
it
is
because
the
id
is
the
one
that
is
backwards
incompatible
on
the
wire
I
I've
seen
actually,
instead
of
coming
up
with
a
new
name
for
the
new
value,
rename
that
one
with
deprecated
underscore
sum
or
something
like
that,
the
number
five
and
add
the
number
12
to
to
be
called
sum.
This
is
more
or
less
something
that
I've
seen
in
protobuf
work.
A
Okay,
so
I
want
to
ask
two
questions
here:
if
that's
okay-
and
this
is
this-
is
for
consensus
across
the
group,
one
is:
do
we
think
that
we
need
so?
Is
the
behavior
of
accidentally
exporting
a
sum
of
a
histogram
to
prometheus
as
a
sum
when
we
shouldn't?
Is
that
bad
enough
to
merit
doing
this
kind
of
a
hook
to
try
to
resolve
it
like
if
that's
broken
from
version
a
to
version
b?
A
That's
so
that's
question
number
one
is
like,
but
now
that
we
see
a
solution
because
because
by
the
way
I
think
this
this
is
what
a
solution
is
likely
to
look
like
it
might
have
an
extra
field.
But
I
think
this
is
what
backwards
incompatibility
would
mean
with
open
metrics
to
solve
that?
Do
we
think
it's
worth?
It
is
like
question
number
one,
or
are
we
willing
to
break
open,
metrics
compatibility
for
a
point,
release
versus
open,
telemetry
compatibility,
because
I
think
from
an
open,
telemetry
standpoint,
it
would
be
okay.
B
G
I
also
think
it's
fine.
I
also
think
we
haven't
really
exposed
open
metrics,
so
I
think
it
should
be
good.
A
Okay,
so
the
last
question
is:
do
we
think
if
we
change
so
so
effectively?
If
you
look
in
here,
let
me
hold
on.
Let
me
find
the
window
again.
My
computer
is
like
toast,
okay,
so
this
bit
here
where
the
sum
of
all
values
in
the
population
population
counts,
0
in
this
field
must
be
0..
It
removes
this
thing
about.
Some
should
only
be
filled
out
when
measuring
non-negative,
discrete
events,
so
at
one
point
in
time
sum
would
not
be
filled
out,
which
means
you
get
zero
and
then
going
forward.
A
A
Correct
somewhere
there
will
be
a
flag,
but
what
we're
talking
about
is
an
old
consumer
of
histograms
suddenly
see
sums,
they
don't
know
to
look
for
the
flag
where
they
didn't
see
sums
before.
Do
we
and
and
sums
involve
non-negative
measurements
in
open
telemetry?
Do
we
consider
that
a
breaking
change
to
the
protocol.
B
H
E
G
A
A
A
Is
this
just
a
bug
fix
just
allowing
negative
values
and
adding
in
the
thing
we
could
consider
that
a
bug
fix?
That's
that's
fair.
I
I'm
of
the
opinion.
So
so
my
opinion
is
that
this
this
is
like
on
the
edge
of
a
breaking
change
and
I
think
the
policy
that
we
have
going
forward
really
kind
of
kind
of
matters
in
terms
of
how
we're
going
to
treat
this
protocol.
A
So
if
we
think
that
this
is
unlikely
to
break
90
percent
of
users
and
that's
okay,
to
make
this
flip,
that's
actually
a
good,
pragmatic
definition
of
a
breaking
change
right.
So
I
I
I
think
that
that's
okay,
like
I
personally,
would
would
I
don't
want
to
tell
you
where
I'm
going
to
vote.
A
What
I
want
to
do
is
have
us
hash
it
out
and
kind
of
get
an
idea
of
how
people
feel
and
if
anyone
feels
strongly
about,
like
the
need
to
to
go
as
far
as
making
sure
it
absolutely
is
100
compatible,
because
I
think
what
victor
outlines
here
is
is
how
we
make
this
100
compatible
and
outlines
all
the
details
for
that
going
forward
right.
A
So
if
we
think
that
this
is
unlikely
to
break
most
otlp
usage
and
we're
okay
to
make
this
change,
and-
and
we
want
to
have
some
way
of
denoting
this
right
in
the
release-
notes
to
say
this
is
a
change
that
breaks
a
thing
which
we
never
declared
would
keep
stable.
That's!
Okay,
but
I
I
just
want
to
make
sure
that
we're
aware
of
like
that
nuance
and
that
that
edgary,
that
we're
doing
here
right.
D
A
G
It's
exciting,
they
are
adding
it
back.
You
know
they
approved
an
rfc,
so
they're,
adding
it
back
with
the
keyword
optional
or
something
I
don't
remember,
adding
it
back.
G
A
G
Or
a
nand
value,
but
but
we
never
specify
any
non
value
or
anything
so
by
default
by
not
setting
anything
the
way
how
we
say
it
will
mean
zero.
G
A
G
B
While
you're
typing,
I
want
to
add
that
there's
some
speculation,
at
least
by
me,
about
what
the
gauge
histogram
might
one
day
look
like,
and
it
has
to
do
in
my
opinion,
with
whether
counts
the
same.
It
has
the
same
treatment
for
accounts.
Whether
counts
can
be
negative
and
positive
or
not,
and.
B
B
B
Of
the
flag
negative
values-
well,
I
I
actually
was
imagining
like
kind
of
an
enum
to
tell
you
which
kind
of
histogram
you
were
staring
at,
but
but
that
could
be
done
compatibly
in
the
future.
With
this
as
well,
okay,.
A
So,
let's,
let's,
let's,
let's
stick
to
what
we
have
here.
So,
let's,
let's
say
this
effectively
for
no
recorded
value
and
for
non-negative
values
we
might
have
bug
and
that
bug
is
that
proto
3
doesn't
work.
The
way
proto2
does
and
the
wording
that
we
have
here
is
totally
based
on
proto2.
B
A
So
with
that
said,
I
think
adding
the
field
to
account,
for
the
bug
makes
a
hell
of
a
lot
of
sense
for
proto3
and
then
the
question
is:
what
do
we
recommend
for
proto2
clients?
Are
we
going
to
provide
any
kind
of
compatibility
like
guarantees
here?
I
guess
I
guess
no,
there's
literally
just
a
bug
for
proto3
users,
but
proto2
would
be
okay.
G
G
Yes,
so
so
maybe
maybe
what
we
need
to
do-
and
this
is
good
thing-
is
to
document
that
we
are
not
proto2
compatible.
H
G
Unless
you
change
them
correct
because
it
says
it
says
at
the
the
top
of
the
file,
it
says
proto3
syntax
and
I
think
the
compiler
does
not
let
you
compile
proto2,
we
don't
have
the
keywords
optional
or
or
required
anyway.
G
E
G
A
A
B
I
want
to
come
back
to
this
question
I
had.
I
don't
think
I
said
it
very
clearly,
I'm
trying
once
more
so
we've
been
talking
about
the
meaning
of
the
sum
field
in
a
histogram.
I
think
there
are
three
cases:
it's
not
meaningful.
It's
monotonic
and
it's
not
monotonic.
B
I
think
we
need
two
bits
of
information
to
talk
about
the
meaning
of
a
sum
field,
and
I'm
not
sure
we
have
that
yet
is
the
sum
meaningful
is
the
sum
monotonic
or
is
it
non-monotonic
and
to
me
it
corresponds
to
the
three
primitive
instruments.
B
I
I'm
hoping
that
we
can
use
two
bits
and
consider
this
essentially
a
num
that
tells
you
how
to
interpret
the
sum
field,
and
the
thing
I
was
trying
to
say
earlier
is
that
there's
another
issue
open
about
the
count
field
where
all
the
same
discussion
can
happen
is
the
count
meaningful
is
the
count
monotonic
and
I'm?
I
know
I'm
off
in
a
real
corner
here,
but
gauge
gauge
histogram
can
may
be
modeled
as
a
histogram
with
a
non-monotonic
count.
That's
that's
all.
B
F
A
B
I
B
Input
could
have
gone
to
a
synchronous
counter,
it's
a
non-negative
instrument,
it's
non-negative
input,
and
so
the
sum
is
going
to
be
not
monotonic.
If
it's,
if
the,
if
the
primitive
instrument
were
a
gauge,
we're
saying
that
the
sum
is
not
meaningful.
Otherwise,
you
would
have
chosen
up
down
counter
and
if
the
primitive
instrument
isn't
up
on
counter,
then
that
some
maybe
not
monotonic,
because
the
values
can
be
negative.
G
Okay,
so
so
josh,
I
hear
I
hear
your
proposal
about
trying
to
put
the
gauge
histogram
in
open
metrics
in
these
in
the
same
histogram
here
that
we
have.
That
may
not
be
okay
for
two
reasons:
one
in
the
message
that
includes
these
we
do
have
the
temporality,
which
does
not
apply
to
a
gauge
histogram.
What
temporality
would
you
use?
We
can
debate
that.
A
Yeah,
I
I
want,
let's
take
all
the
discussion
against
histogram
offline.
Let's,
let's
make
progress
on
specifically
this
issue,
so
I'm
sorry
for
getting
horrified
at
my
proto3
mistakes
because
yeah,
I
think
you
can
implicitly
tell
my
opinions
on
proto3
the
to
make
to
make
progress
here.
We
have
a
bug
and
we
need
to
fix
the
bug.
A
I
am
supportive
of
taking
what
victor
proposed
and
saying
okay
going
forward
when
we
don't
have
an
absolute
known
bug
with
the
way
we've
described,
how
to
use
a
field,
we
should
not
make
any
breaking
change,
but
this
actually
isn't
a
breaking
change
because
we
actually
have
broken
instructions,
so
we're
going
to
fix
those
instructions
where
it's
actually,
it's
literally
impossible
to
use
the
instructions
we
have
today,
which
means
all
sums
are
confusing
to
users
today.
So
let's
fix
that-
and
I
think
this
flag
proposal
is
probably
the
best
proposal
out
there.
A
A
Okay,
so
can
someone
I
mean
I
can
do
this
too.
Can
someone
open
a
bug
around
the
the
way
we
describe
the
field
and
proto3
victor?
You
might
be
the
ideal
person
to
to
open
this
bug
because
you're,
the
one
who
caught
it
and
told
us
about
it
that
we're
relying
on
proto2
has
behavior
for
our
descriptions.
A
If
you
open
the
bug,
I
can
look
through
and
try
to
find
other
instances
where
we've
done,
that
in
the
data
model,
kind
of
fix
them
or
at
least
open
bugs
for
each
one
and
then
for
this
pull
request.
We'll
give
it
another
two
minutes
of
allowing
people
to
violently
disagree.
But
if
nobody
else
disagrees,
let's
just
add
the
flags
as
a
bug
fix
for
this
proto-3
issue,
like
with
the
current
description.
So
you
can
you
don't
have
to
add
new
fields.
A
D
C
B
B
B
And
so,
when
we
talk
about
cue
sizes
and
heap
sizes
and
all
those
other
things
that
are
sizes,
you
add
them
up.
The
sum
is
meaningful,
but
if
it's
a
histogram
of
latencies,
a
histogram
of
temperatures,
a
histogram
of
voltages,
it's
just
not
meaningful
to
add
those
up,
the
same
way,
understood
and
and
that's
so
so
that's.
B
A
Okay,
but
it's
kind
of
okay:
let's
not
debate
that,
yet
that's
a
fun!
Well
that'll
be
a
fun
discussion.
B
G
But
again
that
may
be,
since
we
have
a
sum,
we
can
say
that
this
is
a
some
histogram
or
whatever
you
say
that
additive
histogram
and
we
add
a
gauge
histogram.
I
still
believe
that
that's
to
have
equivalence,
you
have
a
gauge
and
a
gauge
histogram.
You
have
a
sum
and
a
histogram
or
some
histogram,
because
we
don't
have
only
one
thing
that
is
called
value
that
can
be
histogram,
monotonic
sum
or
non-monotonic
sum.
We
have
actually
two
different
things.
One
is
called
gauge
and
the
sum
that
is
monotonic
or
not.
G
B
And
that
this
is
some
histogram
and
you
have
a
gauge
histogram,
that
is
the
equivalent.
B
G
Definitely,
let's
take
a
look
because
because
I
may
be
misinformed
there
so.
A
Let's
take
a
little
break
and
add
that
to
the
discussions
because
we
have,
we
have
some
other
things
discussed,
I'm
going
to
get
to
riley's
topic,
because
I
think
it's
super
highly
reveling.
Okay,
so
in
terms
of
action
items.
G
Josh
only
one
last
comment
about
that:
have
we
thought
if
the
mo
is
monotonic
or
this
property
about
the
sun
belongs
in
the
point
or
in
the
in
the
metric
metadata?
So
we
do
have
in
the
metric
metadata.
We
do
have
the
aggregation
temporality.
G
Should
this
be
around
the
same
place
with
temporality,
or
is
this
separate
just
something
for
for
people
to
think
about,
because
I
saw
right
now
is
at
every
point.
I
G
Data
yeah
there
may
be
two
flags
josh
you're
right.
The
missing
data
is
a
point
with
missing
data
which
has
a
meaning
for
for
stainless
and
and
stuff
like
that,
but
but
for
for
the
for
the
sum
in
monotonic,
I
think
it
belongs
to
the
higher
level
anyway.
We
can
discuss
about
this,
but
I
want
everyone
to
know
about
this
thing
and
think
about
until
we
we
see
the
pr.
A
Yes,
yeah,
I
totally
agree
so
I
would
also
emphasize
my
my
own
opinion
that
the
the
whether
or
not
values
are
recorded
or
negative
is
a
property.
The
instrument
which
is
this
level,
whether
or
not
the
value
is
missing,
is
a
property
of
the
metric
stream,
which
is,
at
this
level
exactly.
G
A
Yep
yeah,
I
totally
agree
very
good
point.
Let's,
let's
account
for
that
in
the
pr.
Let's
make
our
updates
of
opening
a
bug
and
then,
let's,
let's
update,
victor's
pr
to
address
it,
and
we
can
all
comment
in
the
pr.
But
I
think
we
have
a
path
forward
of
how
we
want
to
deal
with
this
and
thanks
again
victor
for
raising
the
fact
that
when
I
made
that
change
to
the
the
sum
I
wasn't,
accounting
for
proto3,
okay.
E
Well,
one
last
comment
really
quick
comment.
There
is
a,
I
think,
just
a
bug
in
the
in
the
description
for
how
we
do
the
bounce
explicit,
so
for
the
last
for
the
last
bucket.
That
is
the
current
value
to
infinity.
I
think
the
that's
just
a
bug
that
that
says
it's
using
the
current
value,
but
there's
no
current
value.
So
it's
really
just
a
minus
one.
The
previous
value,
just
fyi.
A
Sure,
okay,
that's
pretty
good;
okay
cool
all
right!
So
now,
riley's
asking
is
metrics
data
model
done
and
the
project
board
does
show
as
past
due
I
can
pull
it.
I
just
checked
it's
it's.
A
Someone
fixed
that,
oh,
oh,
that
was
that
was
I
when
I
set
it
up.
I
figured
we'd
be
done
by
june
with
getting
the
metrics
data
model
marked
to
stable.
What
I
think
is
true,
though,
is:
if
you
look
at
the
stuff,
we
have
to
do.
There's
a
bit
of
data
modeling
around
prometheus
compatibility
that
we
want
to
figure
out
well
hold
on.
Let
me
let
me
just
write
this
in
notes,
so.
A
We
have,
we
have
a
few
big
ticket
items
that
we
need
to
address
and
the
question
is:
do
we
focus
our
attention
on
the
now
or
do
we
focus
on
the
met
the
other
metrics
api?
Meaning?
I
think
that's,
but
let
me
before
we
have
this
discussion
I'll
talk
about
high-level
things
that
I
know
are
on
our
radar.
One
is
gauge
histogram,
oh
god
come
on
histogram
and
this
is
again
an
open,
metrics
compatibility
question.
We
have
the
news
and
what
are
they
called
stateful
sets.
A
A
From
openmetrics,
and
then
we
have
what
was
it
exponential
bucket
for
histograms?
This
would
be
just
us
and
then
what
was
the
last
one?
Oh
multivariate,
metrics
time
series.
These
are
all
so
this
I
know
there's
work
going
on.
This
is
an
otep
with
a
whole
bunch
of
approvals
and
some
some
to
do's,
and
then
these
are
two
things
that
we've
had
some
teaser
discussions
about,
but
I
think
actually
deserve
a
little
bit
more
attention.
A
So
with
that
said
riley
do
you
want
to
kick
off
your
your
concerns
and
ideas
here
which
what
you
wanted
to
say
yeah?
So
if.
C
You
look
at
the
the
project
board
on
the
description
we
communicated
update
april
the
30th,
which
I
believe
there
there
is
a
bit
delay,
but
we
already
released
that
part.
So
if
you
click
on
the
projects,
look
at
all
the
projects.
C
Yeah,
so
on
on
the
metrics
data
model,
we're
saying
targeting
end
of
april,
so
we
probably
want
to
change
the
message
here
just
to
communicate.
Clearly
what
do
we
mean?
And-
and
this
is
just
a
minor
thing-
because
I
I
got
some
folks
asking
me
about
api
sdk
and
when
I
explain
to
them
the
data
model,
those
things
they
start
to
have
the
question,
and
I
hope
we
can
clear
the
computer
here
and
sorry.
I
I
lost
you,
my
computer's
dying
what'd,
you
say
so
there.
C
There
are
folks
reaching
out
to
me
on
slack,
asking
all
the
questions
about
the
progress
on
metrics
in
general,
like
semantic
convention
api
data
model.
So
I
noticed
some
folks
were
confused
by
the
wording
here
so
like.
If
you
can
clarify
that
it
would
be
great
right,
yeah.
That's
that's
a
really
great
point
and
the
the
second
topic
in
like
that
I
want
to
probably
have
is.
It
seems
to
me
like,
like
nowadays
like
whether
it's
the
metrics
data
model,
sig
meeting
or
the
api
stk
sig
meeting.
C
We
normally
could
finish
earlier.
That
means,
if
we
could
combine
this
meeting
together,
like
the
only
reason
we
decided
to
split
the
meeting
is
at
that
time
there.
There
were
just
too
many
things
and
we
want
people
to
focus
on
a
particular
work
stream.
But
now
I
I
wonder
if
it
makes
sense
that
can
help
us
almost
double
the
the
frequency
of
our
like
movement.
C
G
C
Merge
the
meetings-
and
we
can
probably
do
something
like
30
minutes
for
data
model,
30
minutes
for
apn
sdk,
and
this
way
we
can
have
a
much.
C
Meetings
but
we
reporters
the
meeting
so
instead
of
having
the
tuesday
meeting
only
for
data
model
and
the
thursday
meeting
only
for
api
sdk,
we're
saying
these
meetings,
we
have
30
minutes
four
data
model
and
30
minutes
for
api
sdk,
as
some
run
from
someone
from
europe
from
a
european
times,
and
I
would
also
love
that
idea
because
for
me
it's
it's
really
really
hard
to
get
into
the
api
sdk
meeting,
because
it's
like
1am
my
time
or
something
like
that,
so
yeah
yeah.
C
A
I
I
think
I
agree
with
you
in
the
sense
of
if
you
look
at
the
things
that
we
have
left,
we
hash
through
a
lot
of
really
good
stuff.
I
expect
I
mean
just
frankly,
I
fully
expect
bogdan
josh
and
I
to
dominate
60
minutes
on
just
this
topic
alone,
let
alone
other
people
adding
to
that
conversation,
and
that's
just
because
I
talk
a
lot
right
so
like
I
want
to.
A
I
want
to
caveat,
there's
a
few
big
ticket
items
here
that
may
be
what's
worth
doing
because
again,
in
this
meeting,
we
already
had
a
bunch
of
teasers
in
the
gage
histogram.
Let's,
let's
see
if
we
can
get
together.
One
of
those
you
know:
here's
all
the
major
concerns
and
issues
documents
and
have
a
one-off
to
just
sit
down
and
hash
through
it
as
a
group
and
come
to
a
consensus
and
and
we'll
give
enough
people
for
europe
to
contribute
to
that
document.
A
I
also
don't
think
one
of
these
meetings
might
be
enough
on
its
own
without
some
prep
work,
so
I'm
personally
I'd
be
more
than
happy
to
share
the
meeting
share
the
the
leadership
of
this
like
just
running
the
meeting
with
you
and
then
like.
We
can
find
one-off
times
to
deal
with
these
big
topics,
because
I
don't
think
they're
going
to
be
frequent
going
forward
like
as
we've
hashed
through
stuff.
A
B
Yeah
I
would
like
to
volunteer
to
back
up
the
things
I
said
about
gage
histogram,
with
more
of
a
proposal.
I
did
put
part
of
that
into
issue
308.
I
think,
and
I
I
realize
it
is
contentious
and
but
I
do
have
an
opinion
and
I'd
like
to
share
it
in
a
more
detailed
way.
I
I
also
when
I'm
looking
at
this
list.
I
just
don't
think
gage
histogram
is
nearly
as
important
as
well
exponential
buckets.
That's
the
one
that
yeah
well.
B
At
least
my
employer
would
like
me
to
focus
on,
and
I
just
wanted
to
say
that
quick
question.
A
About
exponential
buckets
can
hold,
can
I
can
we
can
we
finish
this
conversation
and
then
we'll
talk
about
exponential
buckets?
Is
that
okay,
just
three
more
minutes
and
then
we'll
have
10
minutes
for
exponential
buckets
because
I
think
we've
had?
I
don't
think
I
think
both
of
you
were
missing
for
one
or
two
of
the
meetings
where
we
tried
to
talk
about
exponential
buckets,
but
let's
just
get
offline
finish
riley's
point:
do
we
want
to
merge
the
two
meanings?
Is
anyone
against
merging
the
two
meanings.
A
And
riley,
I
might
need
your
help
running
like
like.
Basically
this
time
I've
dedicated
to
make
sure
I
can
always
attend
the
api
one.
As
you
know,
I
have
almost
permanent
conflicts
with
that.
I'm
shuffling
around
so
I'll
need
help
running
this
part
of
me
when
we
yeah
cool
okay.
So,
let's,
let's
call
that
topic
done.
That
sounds
great
riley's
gonna.
Take
that
offline
bogdan
exponential
buckets
go.
G
B
A
Yeah,
so
so,
basically
there's
a
a
bucketing
strategy
from
prometheus
that
we
want
to
make
sure
that
the
current
otep
you
know
accounts
for,
but
basically
we
need
somebody
to
go
through
and
drive
figuring
out
how
to
take
that
hotep
and
make
progress
on
it.
So
what's
his
name,
you
you,
okay.
I
can't
pronounce
it
uk,
okay
uk.
If,
if
you
want
to
take
ownership
of
this
josh
and
talk
to
uk
and
kind
of
get
that
otep
driven
through,
I
think
there's
there
was
one
open
question.
A
We
talked
about
in
a
previous
data
model
sig
that
that
was
never
kind
of
fully
addressed.
The
otep
has
enough
approvals
that
we
could
merge
it
and
start
making
progress,
getting
it
into
the
specification
as
like
a
formal
thing,
but
no
one's
merged
it
and
it's
unclear
if
there's
any
momentum
on
it.
So
I
think
the
tldr
from
my
standpoint
is
someone.
A
Someone
needs
to
take
ownership
of
driving
this
into
the
spec
and
I
think
that
needs
to
be
someone
who
attends
this
meeting
regularly
or
someone
that
attends
metric
meetings
regularly
or
someone
who
can
approve
things
or
like
merge
things
in
the
spec.
So
somebody
to
be
a
mentor
and
just
drive
it
through,
I
think,
is
what
that
needs.
That's
the
tl,
dr
we've
had
a
bunch
of
discussions
about
it
here,
everybody's
way
on
board,
but
there's
all
these
open
questions
and
no
one
who
is
answering
them.
B
Yeah,
I
I
feel
first
of
all,
this
is
way
more
important
than
gage
histogram
and
since
I
just
mentioned,
I
could
do
that.
I'd
rather
do
this,
but
we
the
the
questions,
were
unanswered
and
I
feel
that
there's
nothing
we
can
do
without
creating
contention
somewhere
and
the.
The
point
now
seems
to
be
focused
on
this
open
metrics,
which
theo
schwarzenegger
wants
to
to
donate,
to
open
telemetry.
It
is
the
circle
histogram
circle,
circonus
histogram,
while
linear
histogram
it
is.
B
It
is
in
many
ways
a
great
histogram
and
in
many
ways
there's
not
one
good
histogram
to
rule
them
all
in
the
world.
So
there
has
been
a
lot
of
discussion
around
getting
exponential
buckets,
but
the
other
conversation
which
is
less
surfaced
is
about
whether
you
want
very
high
resolution
or
whether
you
want
like
self-collapsing
buckets
and
and
and
both
can
be
done
in
an
automatic
way.
There's
research
out
there
there's
practical
results,
but
they
seem
to
be
different
approaches
and
so
there's
a
lot
of
people
saying
gosh.
B
Wouldn't
it
be
nice
that
we
could
just
take
circus
histogram,
it's
been
donated
or
offered,
but
it
is
not
compatible
with
the
current
protocol
in
that
otp
it
would
require
more
protocol
to
be
added,
and
then
it's
not
clear
that
it
can
ever
do
that
sort
of
collapsing,
small,
like
low
resolution
histogram
stuff,
and
so
it's
just
it's
like
do.
We
want
someone
to
come
in
and
just
make
a
decision
and
move
us
forward,
I'm
not
even
sure
what
the
right
decision
is.
Unfortunately,
here's.
A
A
I
don't
know
what
prototyping
around
the
metrics
data
model
means
where
we
put
those
definitions
of
protocol
buffers
if
it's
a
complete
fork
of
otop,
that
lives
on
its
side
or
whatever,
but
we
need
a
way
to
prototype
that
stupid
thing,
get
it
flowing
through
a
collector,
get
it
flowing
into
metric
systems
and,
like
these
open
questions,
you
have
basically
say
we
want
a
prototype
of
what
it
looks
like
that
people
can
look
at,
they
can
touch
they
can
they
can
see,
and
let's,
let's
do
that
on
the
otep
prior
to
approving
the
otep,
just
to
make
sure
we
can
answer
those
questions
so
when
we
go
implement
it
and
open
telemetry
we're
implementing
with
like
a
foundation
right.
A
B
I
see
your
point.
This
is
basically
suggesting
that
we
need
to
fork
some
stuff
generate
the
generate
the
histogram
using
a
library
put
it
into
otlp
with
this
form,
and
then
it
sounded
like
you
wanted
even
more
like
put
it
into
a
collector
and
then
maybe
convert
it
back
into
the
the
original
histogram
with
explicit
boundaries.
A
A
B
That's
not
the
same
as
collapsing,
but
I
mean
it's
a
little
different
right.
B
The
collapsing
is
something
that
that
like
udd
sketch
does,
and
maybe
google
has
something
internally,
that
does
it
and
people
people
can
see
it
in
the
math,
but
it's
but
then,
when
you
get
to
an
actual
library
that
generates
this
type
of
data,
there's
a
question
of
what
algorithm
is
actually
being
used
and
then
we're
off
into
a
different
territory.
It's
not
about
the
data
model
or
about
the
protocol.
B
It's
about
how
the
sdks
are
going
to
generate
these
histograms
and
that's
the
reason
why
people
are
excited
by
the
sir
bonus
histogram
donation
is
that
there's
a
pre-built
library
that's
available
in
five
or
six
different
languages.
That
does
exactly
the
same
thing
and
has
exactly
the
same
like
logic,
but
it
generates
this
histogram
that
has
30
000
buckets
and
can't
be
collapsed
very
easily,
and
if
and
that's
just
some
people
are
going
to
be.
Okay
with
that
and
some
people
aren't,
I
think,
and
then
I
don't,
but
I
don't
know.
B
I
think
it's
not
clear
that
that's
the
first
desire
of
everybody
out
there
and
it's
not
clear
that
that's
gonna
make
prometheus
users
happy
if
we
have
30
000
buckets
and-
and
I
just
want
to
say
at
this
point
I
I
was
out
of
town
for
two
weeks-
theo
asked
me
to
comment
on
it
and
I
I
owe
him
a
response,
but
I'm
gonna
try
and
do
it
in
the
open,
where
the
rest
of
you
can
all
see.
It.
B
I
want
to
now
say
I
haven't
really
answered
your
question
josh
about.
Can
we
mentor,
uk
and
drive
this
through?
It
sounds
like
quite
a
lot
of
project,
but
I
think
we
have
to
do
it.
Yeah.
A
A
A
What
do
you
think
of
this?
We
can
look
at
what,
whether
or
not
it's
okay
to
we
can
try
to
answer
your
question
and
discuss.
Is
it
okay
to
launch
this,
even
if
prometheus
doesn't
support
it?
Well
today,
right,
like
those
are
all
things
I
think
we
can
start
to
answer,
but
right
now
we
need
to
collect
the
questions
and
figure
out
how
to
make
steps
towards
answering
each
of
those
questions,
and
I
think
you
have
all
the
questions
in
your
head
more
more
so.
A
Us
so
that's
why
I'm
suggesting
you
here,
but
I
know
you're
also
overloaded.
So
if
you
can
write
down
the
questions
like,
I
think
someone
else
could
drive
them
through
too
either
way.
G
Josh
another
thing
somebody
from
from
splunk
is
very
actively
looking
he's
one
of
the
researchers
here
and
he
he's
keep
pushing
me
about
klr
sketch.
Instead
of
an
exponential
bucket.
Have
you
thought
about
that
which
sketch
klr.
B
Dogs-
okay,
I'm
not
going
to
think
about
gage
histogram
at
all,
but
I
will
take
this
item
josh
of
trying
to
figure
out
how
to
make
forward
progress
by
writing
down
the
questions.
A
Open,
okay,
I
think,
if
you
just
come
up
with
the
open
questions
that
that
will
help
us
figure
out
how
to
how
to
make
progress
on
driving
it
forward.
If
we
know
which
ones
are
considered
unanswered,
which
ones
are
hard
to
answer,
and
we
can
work
through
that
so
for
next.
B
A
I
think
it
sounds
like
we're.
Gonna
combine
the
two
meetings
and
I
wanted
to
figure
out
what
is
our
top
priority
to
discuss.
Next
time
again,
we've
tried
to
discuss
exponential
buckets
here
and
just
not
been
ready
for
the
discussion,
so
I
don't
want
to
throw
that
on
the
agenda
unless
we
have
something
written
down,
so
I'm
gonna
put
that
on
hold
and
give
you
more
than
a
week
to
get
that
ready
because
that
might
take
a
while.
I
know
there's
work
on
the
multivariate
time
series.
A
It's
in
the
slack
channel,
that's
cool
and
then
you
know
do
we
want
to
discuss
any
of
the
open,
metrics
things
here.
B
G
G
You
so
anyway,
this
person
is
keep
trying
to
convince
me,
but
I
was
away
in
europe
and
I
haven't
had
a
chance
to
to
sync
up
with
them,
but
is
trying
to
convince
me
that
that's
better
than
circle
heast
or
db
sketch
for
good
or
for
bad.
I
need
to
to
learn
about
more
about
that.
It's
apparently
is
a
new
trend.
Somehow
in
the
sketch
world
cool
I
hadn't
heard.
B
There's
too
many
there's
too
many
possibilities
in
this
space,
but
I
will
I
will
try
to
not
disappoint
you
all
in
this
space.
My
employer
also
wants
this
a
lot.
G
Okay,
so
if
I
I'm,
if,
if
we're
gonna
have
a
one
of
30
minutes,
60
minutes,
I'm
willing
to
invite
more
people
from
from
our
side
at
least
to
talk
about
kell
or
why
do
they
think
exponential
does
not
work?
For
that
case,
at
least,
if
that's
important
for
you,
because
they
seem
very
opinionated
on
that.
A
Yeah
this,
this
might
be
something
where
it's
worth,
having
a
one
of
the
sonics
that
you
put
together
josh
and
I'm
I'm
more
than
happy
to
help.
You
figure
that
out,
like
a
you,
know,
two
focus
discussion
where
we
have
like
a
presentation
on
options
and
open
questions,
and
then
we
have
like
a
focused
discussion
on
trying
to
resolve
some
of
these
questions
and
and
reach
some
consensus,
because
I
think
it
it's
gonna
be
hard
decisions.
A
That
would
be
great.
I
think,
okay
yeah,
I'm
happy
to
help
you
get
that
set
up,
but
I
don't
think
that's
going
to
be
in
this
meeting
and
I
don't
think
it's
going
to
be
next
week.
I
want
to
give
everyone
back.
It
we're
one
minute
over
riley
I'll
work
with
you
offline,
to
figure
out
what
the
meeting
agenda
looks
like
next
week.
Thank
you,
everybody
for
attending,
and
I
think
we
have
made
really
good
progress
on
the
data
model.
So
it's
it's!
It's
good!
Thank
you!
Everybody
for
your
time.
Thanks.