►
From YouTube: 2022-01-06 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
There
we
go
now
it
is
recording
okay.
Well,
this
is
perfect.
Let
me
hide
this,
then
welcome
everyone.
I
guess
we
can
probably
get
started.
I
don't
see
everyone
here,
but
now
that
I'm
recording
we
can,
I
think,
jump
into
some
some
issues
for
those
who
haven't
yet.
Please
add
yourself
to
the
attendees
list.
If
you
have
any
agenda
items
here,
also
add
those
to
the
list.
I
only
have
one
item
I
wanted
to
talk
about
which
I
don't
know
if
it's
gonna
take
up
too
much
time.
A
So
we
have
a
lot
of
time.
If
you
wanted
to
add
some
things
yeah
again,
let
me
figure
out
how
to
use
a
computer
and
we
can
jump
into
this
okay,
cool
yeah.
So
the
only
thing
that
I
have
that's
come
in,
I
mean
there's
been
a
lot
going
on
and
I'm
sure
everyone's
still
catching
up
on
everything.
That's
happened
over
the
past
two
weeks,
we've
foregone
the
meeting,
so
I
don't
think
there's
actually
been
too
much
development.
A
Either
I've
been
watching
some
pr's
come
in,
but
they're
pretty
minor.
I
don't
think
there's
been
any
major
changes
coming
in.
So
one
of
the
things
that
I
think
did
actually
come
in
was
bogdan,
pointed
out
that
go
1.18,
which
I
think
should
be
out
really
soon,
if
not
like
this
week
is
including
generics,
if
I'm
not
mistaken
in
in
the
api,
and
that
could
help
a
lot
for
anybody.
A
Who's
already
programmed
in
this
project
knows
that
pretty
painfully,
but
I
think
that
there's
some
really
great
opportunity
if
we
can
get
the
timeline
appropriately
set
that
we
could
try
to
build
the
metrics
api
around
these
generics.
But
it
would,
as
anthony
kind
of
points
out
here,
restrict,
is
based
on
our
budgeting
policy,
not
be
able
to
release
a
stable
api
until
119
comes
out.
A
Given
our
go
compatibility
statement
that
we
make
saying
that
we
support
the
current
supported
versions
ago,
which
would
be
the
one
active
minor
version
plus
than
my
the
previous
one.
So
it
asks
this
question
of
like.
Should
we
be
designing
these?
I
don't
have
a
timeline
for
when
119
is
going
to
come
out.
The
only
timeline
I
do
know
is
118..
A
Okay,
that
is,
I
think,
a
better
way
to
frame
frame.
The
question
then,
is
like:
do
we
want?
Do
we
expect
api
shouldn't
be
released
as
stable
until
august?
I
guess
is
the
question.
C
C
B
My
initial
exploring
of
generics
like
I
did
a
side
project
just
for
myself
to
see
if
we
can
do
functional
options
in
a
better
way
with
generics,
and
it
turns
out
that,
because
of
how
types
constraints
are
infectious
I'll
say
like
if
something
inside
of
your,
your
your
structure
has
a
type
constraint.
That
structure
also
requires
that
type
constraint.
B
You
can't
actually
have
like
lists
of
type
constrained
generics.
You
can
have
a
list
of
one
of
the
types
of
the
type
constraint
or
the
other,
but
there's
not
a
the
same
way
to
do
both.
I
don't
believe
in
which
case
you
can't,
then
you
would
have
a
a
like.
We
would
have
collect
or
not.
Collectors
we'd
have
like
a
metrics
provider
that
can
provide
either
float
metrics
or
in
metrics,
but
it
doesn't
it's
not
able
to
do
both
at
the
same
time
right
or
or
whatever.
B
D
I
I
would
say
that
august
2022
is
not
very
far
away
and
by
the
time
we
sort
out
all
the
other
issues
ahead
of
us,
including
all
the
other
open,
telemetry
issues
and
cadence
that
we
have
maybe
saying
we
can't
stabilize
until
2020.
Mid
2022
is
okay,
but
I
also
hear
you
aaron,
because
we
have
a
number
of
questions
about
the
feasibility
of
even
salvaging
much
at
all,
of
the
current
sdk,
for
example,
to
get
a
good
views.
Implementation
and
I've
seen
that
now.
D
So
it's
a
great
opportunity
for
us
to
ask
all
these
questions
and
I
wouldn't
try
to
rush
us.
We
were
still
having
a
like
a
debate
over
the
use
of
this
sort
of.
What
do
you
call
the
sdk
api
approach
to
having
a
different
interface
boundary
between
the
api
and
the
sdk
as
compared
to
the
user,
and
maybe
there's
a
way
to
use
the
generics
and
keep
the
sdk
api?
But
maybe
that's
not
what
we're
after
I
don't
know
what
the
right
question.
Even
if
that's
a
question.
A
Yeah,
I
think
that
all
makes
sense
I'm
trying
to
keep
this
in
a
record
of
the
in
the
issue.
I
agree.
We
probably
need
to
check
if
it's
possible
before
we
commit
to
it.
Does
that
mean
that
we
want
to?
Try,
though
I
guess
it's
the
the
question
that
comes
back
to.
B
So,
at
this
point
like,
if
somebody
wants
to
take
an
effort
and
go
and
try
I'd,
say
you
know
more
power
to
them,
but
like
honestly,
what
we
should
be,
what
I,
what
I
think
us
as
a
group
should
be
focusing
on
is
getting
either
what
we
have
morphed
into
something
that
is
stable
or
some
or
or
trying
to
propose
something
that
that
we
could
consider
stable
and
moving
it
that
way,
if
it
has
a
generics
or
not
and
like.
B
If
somebody
can
come
up
with
a
generic
proposal,
then
we
can
have
the
discussion
of
like
hey,
like
we
can't
stabilize
this
until
we've
accepted
118
and
119,
or
maybe
we
can
make
the
exception
of
that.
But
you
know
if
we're
trying
to
ask
whether
or
not
we
need
to
make
exceptions
for
something
that
doesn't
exist
yet
do
we
like?
Are
we
wasting
time.
C
Yeah,
I
I
think
our
focus
should
be
getting
a
stable,
metrics
api
and
if
using
generics
gets
us
there
faster
or
gets
us
there
better
great
than
we
deal
with
the
problems
that
that
may
cause
for
our
supportive
version
policy.
But
until
we
have
a
metrics
api
that
uses
generics
that
gets
us
there
faster
or
better.
A
Yes,
I
think
the
that's.
I
want
to
make
sure
we
get
that
clear.
So
it's
not
like,
we
need
to
move
to
a
stable
api
like
that's,
not
really,
that's
not
really
a
thing
right.
We
need
to
get
to
an
api
that
we
can
then
stabilize,
I
think
is,
is
the
way
to
say
that,
and
so
the
the
better
part
where
the
the
faster,
I
think
is,
is
important,
because,
honestly,
I
would
even
say
the
better.
I
don't
know
about
the
faster.
A
The
faster
that
we
can
move
to
a
different
api
is
not
really
like
a
metric,
that's
useful
to
the
user.
It's
the
better
right.
We
need
to
build
an
api
that
is
useful
and
you
know
I
think,
a
positive
experience
to
use.
I
think
that
needs
to
be
our
focus
if
we
can,
if
we
can
focus
on
that,
then
it's
just
stabilizing
is
just
vetting
and
and
having
it
tested
in
in
the
in
the
wild.
I
think.
C
A
Yeah,
that
makes
sense
okay,
yeah,
and
I
think
that
honestly
should
be
our
primary
focus
based
on
the
current
state
of
what
open
cell
nutrition
is
really
trying
to
push.
Currently,
like
I
mean
metrics
is
like
the
priority
number
one,
so
I
think
that
we
need
to
be
trying
to
strategize
in
building
some,
maybe
some
issues
or
projects
around
this.
A
I
know
that
there's
a
project
for
the
metrics
stuff
right
now,
but
fleshing
that
out
and
finding
out
like
what
action
items
we
need
to
actually
be
accomplished
and
see
if
we
can
push
the
needle
as
like
a
main
effort.
I
I
think
that
should
be
a
primary
part
of
the
the
development
of
the
project.
A
Currently,
I'm
not
saying
it
isn't,
obviously,
because
we
have
people
in
this
call
that
have
actively
worked
on
the
metrics
side
of
things,
but
I
think
it
just
needs
to
be
like
we
need
to
have
some
sort
of
north
star,
whether
that
is
you
know,
building
out
a
prototype
of
generic
building
out
a
prototype
with,
I
think
bogdan,
had
an
issue
that
he's
abandoned.
A
I
can't
remember,
but
something
along
the
lines
of
like
wrapping
things
with
like
a
small
struct
we
had
talked
about
before
you
know,
instead
of
switching
directly
to
interfaces,
but
I
think
we
probably
need
to
do
a
better
job
at
capturing
these,
and
I
could
take
that
as
an
action
item.
I've
been
kind
of
catching
up
this
week,
but
I
could
see
myself
working
on
building
out
that
task
list
next
week.
Unless
somebody
else
has
some
desire
to
work
on
it
or
his
art
started.
A
Can't
see
anthony
so
I'm
imagining
he's
shaking
his
head.
Yes,
in
agreement.
D
I
don't
want
to
force
this
terribly
boring
conversation
about
the
sdk
api
any
anymore,
but
there
is
this
claim
I've
made,
and
it
was
one
of
the
selling
points
used
in
the
last
debate
over
this
topic,
that,
by
having
that
api,
be
somewhat
neutral.
It's
like
neither
the
api
that
the
user
uses,
nor
is
it
the
kind
of
like
something
that
that
most
of
the
people
contributing
to
the
sdk
you're
going
to
interact
with
it's
just
this
sort
of
like
constrained,
crossover
point
between
api
and
sdk.
D
Because
of
that,
if
that's
stabilized
and
and
we
have
reasonable
evidence
that
it
works,
you
can
out,
you
can
have
more
than
one
api
and
you
can
have
more
than
one
sdk
and
that's
that
was
always
a
requirement
to
have
more
than
one
sdk
inside
of
the
open
telemetry
contract,
but
having
more
than
one
api
is
something
that
I
think
is
an
option
for
language
repositories
and
and
us
as
a
group
to
decide.
D
So
what
you
know
having
a
generic
interface
for
metrics
and
a
non-generic
interface
for
metrics
could
be
useful.
I
personally
have
not
done
any
investigatory
work
with
generics
yet
and
I
and
I'm
not
enough
of
a
programming
language
nerd
to
like
feel
like,
I
know
it
without
knowing
it.
I
have
tons
of
c
plus
plus
template
programming
experience,
but
I'm
not
sure
that
helps
me
here.
So
I
and
I've
also
programmed
in
some
java.
I'm
not
sure
that
helps
me,
so
I
can't
say
whether
generics
is
going
to
help
or
hurt
at
this
time.
D
C
D
Ideally,
the
the
the
amount
of
code
that
you're
maintaining
for
these
boundaries
between
the
user,
api
and
the
sdk
api
are
quite
small.
Hopefully
it's
not
too
much
to
maintain,
so
I
hope
it
doesn't
terrify
you,
but
it
certainly
is
an
opportunity
or
a
device.
We
could
use
to
help
with
this
transition,
so
I
I
did
make
some
changes
to
the
sdk
api
package
that
we
currently
have.
D
I,
I
do
believe
that
it
can
serve.
However,
for
the
synchronous,
api
it
works
pretty
well.
I've
had
I
have
doubts
about
the
asynchronous
support
the
way
it's
done.
So
you
know
with
some
changes.
I
think
we
can
keep
involving
the
sdk
api
as
we
as
we
prototype,
whether
we
keep
the
current
api
to
sdk
api
approach
or
find
something
new
or
find
something.
D
Generic
is
our
open
questions
and
at
least
having
the
sdk
api
in
place,
lets
us
experiment
and
and
have
alternatives
while
we
develop,
but
I
I
have
been
prototyping
and
if
you
give
me
a
kind
of
no
holds
barred
approach
like
if,
if
I,
if
the
cost
of
making
a
change,
is
zero
to
me,
where
I
can
just
edit
at
will
like
I'm
going
to
make
changes
that
is
sdk
api,
I'm
going
to
continue
making
changes.
D
As
I
learn
more
about
how
to
do
that
so
like
right
now,
I
would
redesign
the
sdk
api
a
little
bit
and
I
do
have
a
new
api
proposal
that
I
want
to
share.
It's
just
not
ready
right
now,
maybe
next
week
and
I've
learned
some
things
that
I
would
use
to
change
the
sdk
api.
D
I
do.
I
do
endorse
having
more
than
one
api
in
the
code
base
for
now,
but
the
the
the
asynchronous
code
was
so
brittle
that
I
basically
wanted
to
chuck
it.
I
found
a
better
way.
You
know,
and
I
think
there
are
many
alternatives,
there's
so
many
ways
to
implement
an
sdk
for
metrics.
So
I'd
say
it's
still.
An
open
question:
how
we'll
end
up.
A
So,
on
the
note
of
like
multiple
apis,
I
think
it's
also
there's
the
modular
aspect
of
go.
I
think
allows
us
to
prototype
in
our
own
repositories.
I
think
it's
kind
of
a
fun
thing.
I've
actually
was
playing
around
with
that
last
week
for
a
few
other
parts
of
the
code
base,
but
I
think
if
that's
a
great
point
is
like
if
the
sdk
api
already
provides
like
this
translation
layer
building
out
another
api
with
generics
or
a
different,
you
know
just
a
different
api.
A
It's
totally
possible
that
you
could
then
present
or
even
evaluate
in
some
sort
of
like
design
dock
with
a
code
example.
I
think
it's
pretty
useful.
You
know
if,
if
us
accepting
multiple
apis
into
the
project
is
something
that
is,
I
mean,
I
agree
like
it's
one
thing
to
like
prototype,
an
api.
It's
another
thing
to
dump
it
in
here
and
say:
okay
now,
everyone
else
maintain
it.
That's
it's
an
issue.
A
E
I'm
not
familiar
with
the
metrics
api
because
I
haven't
tried
to
use
it,
but
I
just
wanted
to
speak
on
the
idea
of
generics
in
our
library.
One
pattern
that
that
I
do
think
we
see
there
used
to
be
some
some
more
handling
of
just
like
handling
that
attribute
values
of
any
interface
type
and
then
sniffing
them
to
figure
out.
Is
this
an
end?
You
know?
Is
this
the
float?
Which
way
are
we
gonna
go?
How
do
we
handle
it,
and
then
we
we
have
this
api.
E
The
caller
wouldn't
have
to
say
what
type
they're
supplying
me
that
seems
to
be,
and
then
I
think
about
how
many
places
do
we
do
that
sort
of
thing.
That's
the
main
changes
that
I
would
expect
to
see
beyond
that.
I
haven't
seen
much
opportunity
for
things
where
I've
looked
at
the
code
and
thought
wow.
This
is
really
crying
out
for
generics
here.
A
Yeah,
I
I
think
I
think
attributes
is
one.
That's
definitely
come
to
my
mind
as
well.
Unfortunately,
that
can't
be
changed.
It's
released
to
stable.
A
The
number
is
the
next
thing
that
comes
to
mind,
as
bogdan
mentioned
in
the
issue
where
we
encapsulate
this
concept
of
number
and
it
is
essentially
implementations
of
a
float
or
an
ins,
or
something
like
that
and
those
I,
I
think,
are
a
good
candidate
for
living
engineers,
like
I
I'm
similar
to
josh,
like
I've
played
at
generics
in
other
languages
before,
but
the
you
know
I'll
be
honest.
Like
two
years
ago,
maybe
three
I've
looked
at
like
the
go
proposals
for
generics
and
it
looks
okay,
but
that
was
you
know.
A
D
In
addition,
like
I
don't
know,
I've
got
this
built
in
maybe
bias
or
preference
towards
like
making
performance,
high
performance
or
low
overhead,
and
in
this
particular
case
like
even
now,
I
can't
convince
the
lead
step
team
to
fully
adopt
open
geometry
because
there's
an
extra
allocation
like
and
I
and
I'm
I'm
always
going
to
say
if
there's
an
opportunity
to
save
an
allocation
and
it
means
redesigning
everything.
D
Maybe
we
should
reconsider
so
if
using
generics
means
at
some
point,
we're
going
to
have
an
interface
and
there's
no
way
to
convert
a
word-sized
value
into
an
interface
without
an
allocation
which
is,
I
believe,
still
the
case.
D
Then
it
means
you're
forcing
an
allocation
in
that
number
package
which
belongs
underneath
sdk
api
by
the
way.
There's
no
there's,
no
there's
no
use
or
use
user-facing
use
of
it.
But
it's
because
we
don't
want
to
have
an
allocation,
and
I
don't
like
just
saying
that
just
turn
into
interface
and
use
reflection.
For
that
reason
usually-
and
I
in
my
current
prototype-
which
I
will
share
the
there
we
to
get
that
one
allocation
back-
that
the
lightstep
internal
library
has.
D
We
have
to
use
a
fingerprinting
technique
to
avoid
allocating
a
string
or
a
map
or
like
an
array
which
is
what
how
we
currently
use
the
attribute
set
is
an
array
backed
by
it's
an
array,
backed
through
through
an
interface
that
you
can
use
as
a
map
key,
but
that's
a
mandatory
obligatory
allocation
so
to
get
rid
of
that
allocation
where
you're
not
using
a
map.
Key,
that's
allocated.
D
You
have
you're
now
using
a
map
key,
that's
a
fingerprint
value
which
is
like
a
64-bit
integer
and
that
that
gets
us
to
the
light
steps
performance
goal
that
we
want
it's
sort
of
like
for
the
synchronous
instruments,
but
again
we're
going
to
extreme
lengths
to
get
rid
of
an
allocation,
and
even
now,
I've
written
a
comment
in
my
prototype
that
the
the
sync
map
class,
which
currently
has
an
interface,
that's
based
on
interfaces,
needs
a
generic
counterpart
before
I
can
get
down
to
zero
allocations,
which
is
what
lightstep
would
like
and
if
using
generics
means
extra
allocations.
A
Yeah
again,
I
think
this
is
a
really
good
reason
to
build
the
prototype,
but
also
to
understand
generics
leave
a
little
better
as
they
come
out,
which
is
probably
already
ready.
I
mean
they're
pretty
well
documented,
so
maybe
it's
something
we
can
start
looking
into.
Well,
I
don't
think
maybe
we
could
start
look
into
it.
C
Yeah,
it's
certainly
possible
to
use
generics
with
gotip
right
now.
I
know
some
people
have
already
done
some
explorations
and
some
other
things
with
it.
So
there's
a
working
implementation,
that's
just
not
yet
released.
A
Okay,
that
sounds
good.
I've
got
some
action
items
from
this.
I'm
going
to
look
into
just
structuring
the
project
works,
hopefully
try
to
encapsulate
some
sort
of
prototype
or
exploratory
work
for
these
api
design
issues
if
they
haven't
already
been
captured
and
try
to
present
them
next
week.
Josh
is
potentially
going
to
be
sharing
a
prototype
next
week
or
the
week
after,
depending
on
development
time,
but
other
than
that.
A
I
think
that
we
could
probably
move
on
to
the
nothing
because
there's
nothing
else
on
the
agenda,
but
I
guess
just
open
up
the
floor
and
see
what
somebody
else
had
something
they
want
to
talk
about,
or
maybe
go
into,
show
and
tell
and
see
if
anybody
has
any
exciting
things
they
worked
on
during
the
vacation,
because
I'm
sure
you
all
love
coding
when
you're
you
know
on
holiday.
A
C
B
D
I
I
didn't
put
anything
on
the
agenda
today
and
I've
already
said
everything
I
had
to
about
the
metrics
sdk,
which
is
something
I'm
actively
working
on
I'll
get
get
to
it
later
today
and
tomorrow.
But
I
do
also
have
this
standing
pr.
Actually
I
have
two
of
them
and-
and
I
don't
want
to
badger
anyone-
and
it's
not
my
priority-
to
like
press
people
on
this,
but
I'm
I'm
sort
of
ready
or
waiting
for
for
something
to
happen
both
on
my
exponential
histogram,
as
well
as
the
probability
sampling.
D
So
probability,
sampling
is
not
merged
yet
in
the
spec.
So
I
can
I
can.
I
can
wait
on
that,
but
the
code
is
sort
of
good
and
I'd
say,
ready,
ready
to
merge
eventually,
somehow
after
the
spec
merges
if
I
get
spec
merged,
but
on
topic
of
the
exponential
histogram.
D
That
is
something
I've
just
sort
of
completed.
I
need
to
write
some
specs
that
say
like
guidance
for
sdk
implementations,
but
this
is
a
good
quality
code,
histogram
implementation
that
I'd
like
to
begin
recommending.
I
need
a
place
to
merge
at
and
I
just
gave
a
demo
sort
of
like.
I
don't
want
to
do
show
and
tell
about
this,
but,
like
I
just
gave
a
demo
of
this
pr,
that's
sitting
in
the
collector
contrib
repository
they
receive,
set
statsd
events
and
turns
them
into
these
exponential
histograms.
D
But
I
was
importing
code
that
I
had
on
this
branch
in
the
hotel
go
repository,
so
it's
this
histogram
aggregator
that
that
meets
the
current
aggregator
interface
of
the
current
sdk
and
when
I
think
about
what
what
will
be
saved
in
this
eventual
outcome,
where
we
have
the
view
spec
done,
I
think
the
aggregator,
the
core
logic
of
the
aggregator
kind
of
stays.
Maybe
there
will
be
some
interface
change,
maybe
there'll
be
a
wrapper
around
it,
but
the
core
logic
will
so.
My
statement
is,
I
think
this
code
is
worthy
of
merging.
D
Sitting
around
is
hard
for
it,
and
I'd
it'd
be
cool
if
we
could
look
at
it
as
a
implementation
of
the
otlp
v0.11
histogram,
that
was
the
protocol.
The
data
model's
written,
the
the
protocol
is
written.
Here's
a
an
actual
sdk
implementation,
and,
what's
next
I'd
like
to
say,
is
to
write
the
sdk
spec
for
what
each
language
will
do
to
implement
this
thing
long
way
of
saying
I
would
like
someone
to
review
2393
or
whatever
it's
numbered,
which
is
in
the
main
repository.
D
It
adds
a
new
aggregation
type,
which
would
correspond
to
a
new
otlp
data
point
and
it
adds
the
complete
end
to
end
so
that
you
can
use
it.
It's
got
the
otlp
exporter
and
then
it's
supported
by
the
collector
today,
so
it
could
write
through
to
your
vendor
if
your
vendor
supports
it,
and
this
vendor
is
not
quite
ready
to
support
it,
but
I
did
demo
that
yesterday,
so
it's
close.
C
Yeah,
I
saw
your
pr
in
in
collector
about
the
the
text
format
for
this
as
well,
and
I
had
been
looking
at
it
a
little
bit
earlier.
I
still
haven't
made
it
all
the
way
through,
but
I
will
I
will
make
time
today
or
tomorrow
to
definitely.
D
C
D
In
addition
to
that,
for
my
demo,
I
had
this
collector
receiving
statsd
and
outputting
otlp
to
lightstat,
but
I
had
it
to
printing
the
debugging
log
to
the
logging
exporter
and
the
logging
exporter
has
a
gap
and
then
tigran
says
well,
and
I
had
hard
coded
something
for
this
like
equation.
That
gives
you
the
boundary
based
on
the
index
number
and
scale,
and
I
had
hard
coded
something
and
tigran
said
well
shouldn't
you
put
this
through
a
library
where
it
can
like
help.
Everybody
else,
and
my
answer
is
sort
of
like
well.
D
This
isn't
quite
perfect
for
every
like
this.
Isn't
the
function,
the
implementation
I
would
use
for
graphing
results
in
my
console.
This
is
what
I'd
use
for
my
logging
library,
which
is
very
low
level
code.
So
in
other
words,
I
was
trying
not
to
import
a
dependency
on
a
extremely
thorough
and
tested
implementation.
I
was
trying
to
write
a
debug
log,
but
the
easy
thing
to
do
would
be
to
merge
this
code
2393
and
then
have.
D
The
collector
already
depends
on
the
hotel
go
library,
so
anything
we
put
in
there
kind
of
just
is
available
in
the
in
the
collector
as
well.
So
that
would
be
the
easy
approach
is
to
merge.
2393
have
the
collector
depend
on
it
and
then
have
the
logging,
the
logging
exporter,
just
call
into
the
mapping
function.
D
A
So
josh
this
is
3
600
lines
of
code
or
and
doc,
and
all
this
other
stuff.
I.
D
A
A
D
A
A
So
can
you
talk
a
little
bit
about
that
because
that
brings
up.
You
know,
hesitation
for
me
when
I
want
to
you
know
if
we're
still
working
on
api
and
sdk
design
and
we're
adding
aggregators
like
it's,
I
think
it's
cool
like
there's
some
really
interesting
computer
science,
stuff
you're
doing
and
probably
showing
like,
but
I
don't
want
to
waste
a
lot
of
time
if
we're
going
to
have
another
3
000
line
pr
come
in
because
we
have
to
completely
renovate
this.
That's
fair.
D
Perhaps
I
should
like
create
a
lightsaber
repository
or
something
like
that.
I
don't
know
how
to
place
reference
implementation
code
when
it's
been
written
for
production
use,
I
guess
without
without
putting
it
in
the
in
the
core
repository.
Moreover,
to
get
the
otlp
exporter
to
work
like
so
that
you
could
actually
use
this.
I
don't
see
how
to
do
that
without
drastic
change,
without
just
putting
it
in
the
repository.
A
So
I
guess
I
mean
so
let
me
let
me
back
that
up
though
so
I'm
like
I'm
not
like
opposed
to
being
here.
I
just
it's.
It's
tough
to
there's
a
lot
of
things
to
do
in
the
world.
Are
you.
D
No
actually
well,
I
I
I
I
was
asking
for
the
obvious
feedback
that
you
just
gave
me
in
perhaps
so
the
the
I
I
glossed
over
it
at
the
start.
What
I'm,
what
I'm
going
to
do
next
and
I
can
leave
this
open-
is
write
the
addendum
to
the
sdk
specification
that
says
you
have
the
option
or
the
requirement
to
beat
tbd
to
implement
another
form
of
histogram.
Today
you
have
the
explicit
boundary
histogram,
the
second
form
of
histogram.
D
Is
this
new
new
point
and
it
you
know,
uses
exponential
logic
to
calculate
boundaries,
but
that's
just
a
specification
for
how
the
data
is
interpreted
and
what's
needed
to
complete.
This
equation
is
like
how
does
the
sdk
configure
itself
and
how
does
it
manage
memory
and
how
does
it
decide
what
the
boundaries
would
be,
and
I
have
what
I
what
I
plan
to
do
is
write
that
down
and
see
if
people
agree,
I
guess
that's
that's.
D
D
I
guess
in
terms
of
both
being
a
new
protocol
as
well
as
a
from
scratch
implementation
based
on
some
some
of
the
other
prototypes
we
saw,
I
wrote
quite
a
lot
of
readme
and
quite
a
lot
of
tests,
so
hopefully
it's
and
and
also
comments.
D
Hopefully
it's
worth
your
your
read
and
hopefully-
and
I
guess
my
concern
is
that
when
someone
sees
my
specification,
it's
it's
not
going
to
look
like
enough,
like
an
implementation
for
them
to
be
convinced
that
it's
like
worth
worth
doing
so
now,
like,
let's
see
the
implementation,
so
I've
got
I'll
build
a
point
to
this
draft
and-
and
you
know
it's.
A
Yeah,
I
think
so.
I
agree,
I
think,
that's
a
really
great
approach,
because
I
there's
a
chicken
and
egg
problem.
There
is,
if
you
write
the
specification
and
then
you
don't
have
an
implementation.
There's
like
well.
Is
this
even
feasible
question
right,
but
now
I
think
you're
right.
You
have
a
implementation,
but
then
there's
the
the
other
side
of
the
chicken
and
the
egg,
where
this
implementation
may
not
be
universalized,
and
so,
when
you
go
write
the
specification
somebody
may
come
back
in
another
language
and
say
like
this
is
unachievable.
A
I
don't
know
if
that's
possible.
I
haven't
looked
through
this
closely
enough
to
say,
like
this
isn't
achievable
in
another
language,
but
I
think
it's
worthwhile
to
try
to
get
this
into
the
specification
and
point
to
maybe
this
pr
as
a
reference
implementation
would
be
helpful.
I
yeah
I
I
have
like
there's
a
lot
of
complexity
in
here.
I've
skimmed
this
just
just
briefly,
there's
some.
A
It
looks
like
some
pretty
good
math
going
on
in
here,
which
makes
sense,
given
what
we're
trying
to
accomplish,
but
I
I
would
I
would
want
to
make
sure
I
thought
through
it,
because
they
I
mean
I
I
as
a
reviewer.
I
want
to
make
sure
like
if
I
think
it's
approved,
that
I
think
it's
correct
as
well,
and
I
think
that's
not
part
like
out
of
the
wrong
possibility,
but
I
definitely
would
feel
more
confident
in
reviewing
this.
A
C
So
my
thinking
is
that
the
spec
already
the
the
otlp
data
models
back
already,
has
exponential
histograms
in
there.
There
are
only
so
many
ways
to
go
from
a
stream
of
value
observations
to
something
that
satisfies
that
spec
and
there
are
only
so
many
interfaces
that
can
be
had
for
that.
So
I
think,
if
what's
in
the
heart
of
this
pr
is
a
solid
implementation
of
an
aggregator
that
will
take
a
stream
of
value
observations
and
emit
exponential
histograms.
C
C
So
if
it's,
if
it's
easy
enough
to
separate,
what's
likely
to
change
from
what
isn't,
and
we
can
have
reasonable
confidence
about
what
isn't
going
to
change,
it
might
still
be
worth
reviewing
now
before.
There's
a
spec.
D
Yeah,
I
think
that's
the
spirit
I
started
with,
which
is
like
this
takes
the
existing
api
and
produces
valid
otlp.
But
it's
not
it's
not
really
complete.
There
is
a.
There
is
a
great
deal
of
what
am
I
going
to
say,
creative
license
that
that
I
had
had
in
this
process
of
creating
a
histogram.
So
it's
and
I
wrote
a
readme
to
tell
you
all
the
decisions
I
made,
but
I
do
think
it'll.
D
You
know
I
stand
by
the
statement
before
which
you
just
repeated
anthony
that
it's
not
going
to
change
in
the
core
much
the
the
interface
level.
Just
there's
only
one
option
for
this.
That's
like
optional
that
you
can
tell
me
how
much
size
you
want
this
thing
to
use
and
it
will
use
that
much
size.
The
only
optional
configuration
that
I'm
speculating
is
the
right
thing
for
prometheus.
D
You
know
what
the
ranges
are
valid
for
the
indexes
and
so
on,
my
feeling
for
how
that
will
go,
and
this
is
what
I
would
put
up
in
a
spec
right
as
a
question
or
a
proposal
is
that
you
can.
You
can
set
your
minimum
and
maximum
value
saying
that
this
is
the
largest
value
I
will
admit
to
this
histogram,
and
this
is
the
smallest
value
I
will
admit
to
this
histogram.
D
Given
those
two
optional
parameters
being
positive
and
finite,
you
can
turn
that
into
a
scale,
that's
fixed
and
then
proceed
as
you
would
using
the
same
exact
code,
knowing
your
scale
from
the
beginning
because
of
those
those
limits.
I
think
that
will
please
the
prometheus
community,
but
I
I
don't
have
any
way
to
perform
that
test.
I
guess
I'd
say
the
other
thing
that
I
took
from
the
java
implementation
that
that
was
used
during
the
prototyping
phase.
D
For
this
data
point
type
is
perhaps
not
very
go-like
and
perhaps
another
way
we
could
use
generics.
So
it's
it's
something
that
that
maybe
will
change
so
tyler
good
point.
We
should
resist
it's
this
decision
to
use
a
variable
size,
backing
array.
So
I
am,
you
know
if
the
counts
are
low,
I
don't
want
to
allocate
an
array
of
you
went,
64
counts,
that's
silly!
D
D
If
it's
adding
lines
of
code,
it's
not
adding
much
complexity
and
that
could
probably
be
redone
tbd
if
generics
work
out
for
us,
I'm
not
sure.
D
A
Okay,
yeah,
I
I'm
not
gonna,
say
you
convinced
me
to
put
this
at
the
top
of
my
priority
list,
but
I'm
gonna
try
to
get
this
reviewed.
I
think
in
the
next
week
before
the
next
meeting
would
be
ideal.
It
sounds
like
anthony's
also
motivated
on
this
one,
so
I
think
you're
right,
like
there's
a
there's,
a
need.
It's
the
more.
I
look
into
it.
It
is
complex,
but
I
think
it's
tractable
so
yeah.
I
think
you're
right,
like
you,
try
to
do.
A
D
Yeah,
I
mean,
I
think
it's
actually
a
higher
priority
for
us
to
work
on
views
and
the
metrics
sdk.
I
agree.
The
metrics
sdk
spec
is
still
in
feature
freeze
and
not
stabilized,
because
we
don't
have
enough
views
implementations.
So
I'm
I've
been
focused
on
that
the
histogram
as
stuff
is
secondary.
D
That's
why
I
put
it
in
the
collector.
It's
not
so
important
to
have
it
in
the
sdk,
but
looking
forward
it
kind
of
belongs
here.
We'll
see.
Okay,.
A
Okay
and
then
yeah
the
probabilistic
sampler
another
one
that
I
haven't
really
been
able
to
dive
into,
but
I'll
put
it
on
my
back
of
the
back
burner.
D
Yeah
I
get
you
know,
I
I
think
that
one,
that's
one
where
I'm
not
gonna
press
anyone.
I
think
aaron
has
looked
at
it,
partly
because
it
was
a
light
step
assignment,
but
but
it's
there's
still
controversy
in
in
the
specification
pr
that
I've
got
open.
I
it
there
almost
aren't
enough
reviewers
that
are
motivated
to
make
it
through
that
it
is
hard
to
have
nice
things
if
they
want
them.
D
We
have
to
review
them,
but
I
would
say:
let's
get
the
spec
finished
on
that,
because
there's
enough
controversy
and
this
code
is
not
hard
like
the
histogram
code-
is
hard
in
the
sense
that
I
had
to
test
it
in
lots
of
ways
to
convince
myself.
It
was
actually
going
to
always
work,
whereas
this
code
is
just
like
follow
the
specification
and
it's
supposed
to
change
it
a
little
bit.
You
have
to
change
the
code
a
lot,
so
I
don't
want
to
force
us
to
review
this
one
until
the
spectrum
ends.
A
Can
I
ask
a
favor
of
you
for
the
exponential
histogram
one,
it
looks
like
the
lint
and
the
the
ci
tests
are
failing?
Is
there
any
way
you
could
fix
that
before.
D
A
Cool
all
right
cool
does
anybody
else
have
another
topic.
We
wanted
to
jump
to
or
a
cool
thing
they
worked
on
while
they
were
on
vacation.
A
Cool
I
had
some
small
projects,
but
I
don't
think
there's
anything
worth
sharing
here.
I
think
that
we
could
probably
end
it
here,
as
I
have
a
lot
of
work
to
do
now,
including
doing
some
reviews,
but
otherwise
yeah.
I
think
that
if
you
have
anything
that
does
come
to
mind,
please
pop
into
the
slack
channel
and
post
it
there,
otherwise
we
will
pick
this
up
next
week.
A
I
think,
with
a
few
more
things,
thanks
josh
for
all
the
work,
I
think
that's
maybe
I
didn't
state
that
enough,
but
you're
doing
some
really
great
work.
So
I
appreciate
it.
A
D
A
It's
appreciated
nonetheless,
so
yeah
again
thanks
and
thanks
everyone
else
for
joining,
but
yeah.
I
will
end
it
here
and
I
will
see
you
all
next
week.