►
From YouTube: 2021-08-05 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
B
Yeah
no
worries
I'm
looking
at
the
agenda.
I
know
anthony's
out
today.
Maybe
he'll
join
for
the
meeting,
but
I'm
kind
of
expecting.
He
won't
he's
on
the
maintainers
calendar
as
being
out.
So
I
imagine
this
to
be
pretty
light
and
so
yeah
we
could.
Probably
I
honestly,
like
I,
don't
have
anything
external
to
just
checking
with
the
project
board.
There's
some
issues.
We
probably
won't
talk
about
there
that
were
added,
but
other
than
that
it
should
be
pretty
light.
So
yeah.
A
C
Yeah
right
here
they
come
yeah.
Here
we
go
cool.
B
Well,
yeah,
for
that
sake,
steve,
why
don't
we
try
to
jump
in
given?
I
think
we
have
six
people
here
and
we
can
try
to
optimize
steve's
gotta
take
off
early,
so
I
just
wanted
to
jump
in.
I
don't
think
we
have
too
much
to
talk
about
on
the
agenda.
Currently,
I'm
also
waiting
josh
just
joined
today.
We
want
to
talk
about
some
metric
stuff
which
isn't
on
there.
B
So
let's
jump
into
the
project
board
to
start,
but
as
always,
welcome
everyone
and
if
you're
on
the
call,
please
make
sure
that
you
add
yourself
to
the
attendees
list
and
I
will
learn
how
to
share
my
screen
again.
B
Okay,
cool
yeah,
so
yeah,
please
add
your
name
here.
If
you
haven't
already
and
we'll
jump
in
normally
we
try
to
start
by
talking
about
the
project
board.
These
are
the
priority
issues
and
pull
requests
that
are
in
the
hot
path
to
getting
our
stable
release
out.
So
these
are
the
critical
things
that
we
try
to
track.
B
There
hasn't
been
too
much
progress
in
the
past
week
here.
I
think
some
people
are
taking
vacations,
which
I
applaud.
I
also
like
taking
vacations,
so
it's
mostly
just
been
taking
some
small
things
from
the
to
do
putting
them
into
actual
actions.
B
There's
only
been
one
new
to
do
in
this
past
week,
so
to
do
that,
like
maybe,
as
normal
run
down
the
open
issues
and
maybe
some
comments
on
what's
actually
happening.
B
This
is
probably
where
we
want
to
start
inconsistent
global
set.
Behavior,
I'm
glad
josh
is
on
the
call,
because
you
have
the
history
as
well
here.
B
What
I
discovered,
if
you
haven't
already
read
this
issue,
is
that
for
tracing
for
metrics
meters
for
propagators,
we
all
allow
the
user
to
call
the
set
method
multiple
times
and
we
only
delegate
once,
but
we
allow
you
to
set
that
global
state
as
many
times
as
you
want
that
wasn't
true
for
the
error
handler,
it
was
a
one
and
done
you
could
only
set
it
once
and
it
would
only
delegate
then
which
is
inconsistent,
and
so
we
talked
about
this
last
week
and
the
consensus
was,
let's
make
this
consistent
by
allowing
the
user
to
set
it
as
many
times
as
you
want
delegation
just
once
so,
there's
an
open
pull
request
to
do
that.
B
That's
also
in
this
project
board
somewhere.
Maybe
not
actually
that's
something
we
should
fix.
If
it's
not
but
yeah,
it
needs
eyes.
I
don't
think
it's
fully
reviewed
yet
it
only
has
one
approval.
It
is
not
in
this
project
board,
but
it
should
be
already
making
progress
yeah.
B
So
if
you
have
eyes
or
if
you're
sure
you
have
eyes,
if
you
have
time,
please
take
a
look
at
this
there's
a
bunch
of
other
cleanup
as
well
things
like
learning
how
to
spell
convenience
and
that
kind
of
thing,
but
it's
at
the
heart
of
it.
It's
just
essentially
copying
over
what
we
did
in
all
of
the
other
global
states
by
tracking
some
sort
of
global
variable
that
uses
an
atomic
value
and
then
updating
that
so
yeah.
B
It
should
be
pretty
straightforward
if
you
have
time
cool
moving
on
this
has
been
in
active
state
for
a
little
while
for
a
few
weeks.
Actually,
I
think
that
there's
been
some
movement
on
it,
but
I
think
it
needs
some
more
reviews.
Actually,
I
think
a
lot
of
the
stuff
has
been
resolved,
so
it's
back
to
being
reviewed.
If
you
have
time
this
is
another
one.
B
It's
I
think
one
of
the
first
prs
of
the
author,
so
the
more
information
you
can
provide
in
the
responses
or
or
your
feedback,
I
think,
is
the
better
just
to
kind
of
heads
up
on
that
one.
I
think
then
we're
back
into
the
in
progress.
This
I
just
picked
up
today
is
kind
of
an
interesting
one.
I
probably
will
give
you
a
high
level
overview,
but
I
would
probably
recommend
just
diving
in
and
actually
reading
this
it
comes
down
to
this
array.
B
Attributes
that
we
added
a
while
ago
are
really
designed
in
a
way
that
it
kind
of
assumes
duct
typing
and
it
doesn't
enable
a
lot
of
the
static
typing
benefits
of
the
go
compiler,
and
because
of
that,
you
can
get
some
really
odd
situations
like
the
second
situation
here,
where
a
user
can
add,
semantically
valid
attributes
say
like
an
interface
slice,
but
it
actually
has
an
underlying
type.
B
That
is,
you
know
valid,
so
these
integers
and
it
will
be-
you
know,
accepted,
but
this
doesn't
actually
parse
and
because
it
doesn't
parse.
This
is
an
invalid
array,
so
you
get
something:
that's
semantically
valid
syntactically
valid,
but
in
an
invalid
array,
can
you
purify
why?
What
do
you
mean.
B
Yeah,
that's
a
fair
question.
Let
me
see
if
I
can
pull
this
up
really
quick,
so
the
code
that
we
have
that
actually
parses
arrays
is
very
type
specific
and
so
what
it
looks
for
it
explicitly
looks
for
something
that
is,
you
know
an
array
or
slice,
but
then
it
has
to
match,
like
the
underlying
element.
B
Type
has
to
match
this,
okay,
which,
if
you'll
notice,
doesn't
include
an
interface
type,
which
means
that
what
I
just
showed
you
will
not
match
this,
and
then
it
won't
actually
parse
this,
and
what
you'll
get
is
the
default
case
which
returns
invalid
when,
in
reality
the
concrete
type
of
the
interface
isn't
int
here.
B
So
in
theory,
it
should
be
able
to
parse
this,
but
it
really
you
know
this
kind
of
just
brings
up
like
I
think
I
there
was
a
pr
to
try
to
fix
this,
but
it
was
to
fix,
like
this
one-off
case,
the
the
underlying
issue
is
still.
There,
though,
is
that
we
have
a
api
right
now.
B
That
requires
the
user
to
understand
the
open-source
specification
for
what
it
can
pass
to
us
and
the
syntax
of
what
we
designed
doesn't
lend
itself
to
telling
the
user
exactly
what
it
should
be
doing,
which
is
not
ideal,
and
it's
going
to
lead
to
confusion.
It's
going
to
lead
to
cognitive
overhead,
and
so
what
the
proposed
solution
that
I
put
forward
is
just
like
yeah.
Unfortunately,
I
made
another
gripe
again.
B
Generics
are
not
a
part
of
this
language
and
we
should
probably
just
bite
the
bullet
and
provide
users
with
you
know:
they're
allowed
to
provide
string
slices,
so
let
them
have
a
function
for
it.
They
provide.
You
know
bowl
slices
so
like
essentially
all
of
the
actual
types
they're
allowed
to
provide
build
functions
for
it,
because
there
aren't
generics
which,
if
you
look
at
the
prior
every
other
statically
typed
language,
that
I've
looked
at
rest
in
java.
That's
not
an
issue
so
yeah.
B
I
think
it's
just
one
of
those
things.
We
need
to
do
a
better
job
at
like
providing
the
user
interface
that
doesn't
allow
people
to
put
semantically
or
syntactically
invalid
attributes,
and
you
know,
like
the
worst
part
that
was
pointed
out
in
the
issue
that
this
that
caused
this
is
that
this
situation
compiled
ran
and
was
totally
fine
until
the
user
went
probably
looked
at
their
telemetry
and
was
like
where's
this
attribute.
B
I
can't
like
it's
not
there
and
had
to
go
and
look
at
our
implementation
to
figure
out
why
it
wasn't
there.
So
that's
just
that's
a
really
bad
user
story
and
honestly
it
would
happen
here
as
well.
You
know
they're
providing
syntactically
invalid
according
to
the
specification
but
like
it
would
still
parse
and
still
run,
and
then
you
would
still
have
that
problem.
So
yeah
yeah
there's
a
few
other
alternatives.
B
I've
proposed
here,
which
involves
logging,
maybe
some
other
things
but
like
it,
really
is
like
it's
going
to
require
like
it's
never
going
to
like
it's
always
going
to
compile.
If
you
take
one
of
these
other
solutions-
and
it's
always
going
to
cause
issues
that
you're
going
to
have
to
go
digging
through
code
or
digging
through
logs
to
find
out
why
it
didn't
work
so
yeah,
so
that
said,
I
started
working
on
this.
B
I
really
don't
want
to
take
too
much
more
memory
space
on
this,
so
I'm
really
trying
to
look
at
the
benchmarking,
as
I'm
defining
this
and
trying
to
add
extra
allocations
or
extra
too
much
memory
allocations,
which
I
think
is
achievable
so
stay
tuned
for
this
pr,
but
yeah.
That's
the
the
pr
that
came
in
this
week
based.
A
B
Yeah,
I
don't
think
this
is
something
we
should
accept
but
like
I
think
that
we
could
extend
it
right
now.
I'm
trying
to
add
base
permit
to
the
test.
Essentially
I'm
trying
to
say
like
this
right
here
will
not
compile.
You
can't
send
us
something
that
looks
like
this.
I
you
know
maybe
in
the
future.
We
could
add
something.
That's
like.
I
really
don't
want
to
do
this,
because
underlying
it
still
would
compile
right
like
that.
This
is
like
the
under
like
you
could
still
send
this
to
us
and
maybe
it
would
work.
B
Maybe
we
could
parse
this
and
say
like
okay,
yeah,
your
interface
actually
has
an
underlying
concrete
type.
That
is
correct,
so
we'll
use
it,
but
like
what
happens,
if
123
wasn't
what
was
put
here
right
or
there's
non-homogenous
data
that
was
here
or
there's,
you
know
byte
arrays
that
are
here
or
something
like
that.
B
Right,
like
you,
would
have
that
same
situation
again
like
even
if
it's
homogeneous
structs
that
are
they're
all
put
in
there
as
an
interface
type
that
would
fail
to
compile,
or
that
would
fail
to
actually
render,
but
it
would
compile.
So
I
don't
want
to,
I
don't
want
to
provide
an
interface
and
do
that.
I.
A
But
yeah,
if
you
have
different
thoughts,
please
add
them
here.
Sorry
yeah!
Oh,
I
know
I
was
just
gonna
say
it's
interesting,
I'm
gonna
read
it
a
little
more.
I
gotta
drop,
though
so
I'll
follow
up
later
on
that
one
okay
sounds
good
thanks.
B
E
Do
yes,
thank
you,
tyler,
that's,
like
really
well
said.
I
think
that
the
user
experience
of
of
being
able
to
compile
telemetry
that
disappears
is
the
most
frustrating
thing
there
is
and,
like
I
hadn't
thought
it
through
before.
I
remember
that
the
specification
was
quoted
at
some
point
is
how
we
got
here.
You
know
the
word
homogeneous
is
used.
I
could
I
could.
I
could
paste
the
link.
I
just
looked
it
up.
I
think
this
is
a
good
solution
for
go
and
I
wouldn't
object
to
it
on
a
spec
level.
B
Great
awesome,
cool
yeah,
then
I'll
keep
moving
on
my
prototype
on
this
one,
like
I
said,
trying
to
just
keep
memory
footprint
in
in
mind,
but
it
looks
like
it's
achievable
from
what
I've
seen
hopefully
get
a
pr
up
by
the
end
of
the
day
on
this
one
cool.
This
is
related
to
this
pr,
so
we
can
move
it
over
here
this
pr
or
this
issue
here.
B
Duplicate
of
the
hotel
test
package
is
currently
blocked
on
this
pr,
which
again
just
needs
some
more
eyes
on
it
or
another
set
of
eyes
on
it.
I'm
not
necessarily
saying
you
have
to
go
and
prove
it.
If
you
have
disagree
on
this,
I'm
definitely
willing
to
have
a
conversation
or
talk
a
little
more
about
it,
but
yeah.
If
you
have
more
time.
Unfortunately,
these
are
kind
of
bigger
pr's.
The
other
one
is
200
lines.
This
is
400.
I
will
say
this.
B
One
is
mostly
a
copy
paste
and
then
there's
a
lot
of.
It
essentially
is
moving
the
internal
package
moving
stuff
into
an
internal
package
here,
but
this
is
blocking
like
three
other
pr's
that
could
eventually
get
us
into
deprecating
the
hotel
test.
I
talked
about
this
last
week,
so
yep
just
highlighting
cool.
I
think
that
that's
it
all
of
the
other
issues
that
are
in
the
to-do
column.
B
We've
already
had
conversations
about,
so
I
will
pause
here
and
see
if
anybody
else
wants
to
talk
about
anything
on
this
board.
Otherwise
we
can
jump
back
into
the
agenda.
B
Awesome
yeah
and
I
was
telling
steve
beforehand
this
might
be
a
slow
meeting.
So
hopefully
we
can
get
some
time
back,
but
I
really
want
to
jump
into
whatever
is
useful
and
I
think
metrics,
I'm
glad
josh
for
something
because
there's
some
useful
conversations
we
had
here.
I
think
so.
Josh.
E
I've
I've
tried
to,
I
mean
like
it
takes
like
like
the
actual
situation
in
the
code,
there
is
pretty
sophis
like
pretty
complicated
and
I'm
not
saying
it's
bad,
but
it
does
need
some
refactoring
and
some
structural
improvements,
it's
just
kind
of
aged
over
the
last
year.
This
is
like
kind
of
the
lowest
hanging
fruit
among
those
refactorings
that
I
think
are
needed,
and
I
think
it
stands
alone.
E
Regardless
of
those
other
questions,
it
also
produces
a
nice
simplification
in
the
otlp
export
path,
and
I
just
wanted
to
to
say
I
think
it's
reviewable
I
I
had
made
a
mistake
which
anthony
caught
in
an
early
review
and
I
totally
fixed
it.
E
It
did
involve
some
slight
rewriting
of
the
way
resources
are
handled
and
and
tested,
but
I've.
I
think
I've
kept
all
the
original,
behaviors
and
stuff
at
this
point
added
some
tests
and
feel
confident
about
it.
E
This,
I
think,
agrees
with
the
spec.
I
I
got
confused
and
had
to
reread
it
a
couple
times
like,
but
this
basically
says
you
can
only
get
one
resource
per
meter
provider
and
that
just
bases
that
requirement
into
the
code
so
that
you
don't
have
to
like
ask
questions
downstream.
E
How
many
resources
might
I
have
like
the
answer
is
exactly
one
for
per
meter
provider,
and
that
means
that
you
can
call
export
with
a
single
resource
for
your
entire
pipeline,
and
I
think
that
that
is
what
the
intention
of
the
intent
of
the
specification
was
in
that
case
anyway.
E
So
this
feels
uncontroversial
as
a
result.
It's
also
an
improvement
in
you
know,
performance.
B
Yeah,
I
think
I
said
last
time
that
I
would
review
it
for
you,
but
I
didn't
so.
You
can
hold
me
to
it
and.
E
You
I'll
just
say
I've
done
no
work
on
the
metrics
sdk
in
the
last
week,
mostly
personal
interferences
that
I've
gotten
here,
but
also
I'm
working
on
a
sampler
thing
that
lightstep
really
wanted.
So
I've
been
working
in
the
go
sdk.
I
actually
have
a
positive
result.
I
can
share
it
at
the
end
if
anyone
wants
to
see
or
hear
about
it.
E
E
That's
going
to
finish
this
cleanup
the
streamlining
of
the
of
the
export
path,
so
each
meter
will
have
instrument
kind
of
sorry,
instrumentation
library
and
version
information
that
will
pass
through
as
well
and
I've
prototyped
that
code.
Already
it's
just
like
I've.
I
realized
that
this
pr
in
front
of
you
is
much
easier
to
sort
of
digest
first
and
then
that
second
step
after
after
that,
second
step,
the
otlp
export
path
will
have
no
map
building.
Essentially,
it
will
be
a
straight
through
like
generate
some
protocol
and
go
no
more
of
that.
B
Okay,
cool
yeah.
I
think
that's
putting
some
emphasis
because
the
if
people
aren't
following
along
in
the
metrics
world
of
open
telemetry
things
are
freezing
up,
apis
are
freezing
up
and
other
languages
have
prototypes,
so
it'd
be
cool
if
we
could
provide
feedback
to
the
sig
by
also
having
a
prototype
and
showing
that
like
it
works
and
go
so
yeah.
I
think
that,
like
I
said
like,
I
really
want
to
get
this
review
today.
Unfortunately,
you
know
yeah
the
company
that
pays,
for
I
mean.
E
My
opinion
is
that
the
hotel
go
api
satisfies
the
prototype,
with
few
exceptions
that
are
related
to
naming
satisfies
the
the
draft
spec.
It
was
what
I
mean
and,
and
one
path
to
get
us
to
very
close
to
the
spec
would
be
to
just
simply
rename
the
instruments
and
I've
written
an
issue
about
this
somewhere.
You
know,
histogram
is
the
new
name
for
value
recorder
and
gauge
is
the
old
name
for
value
observer
and
so
on.
E
If
we
just
did
that,
I
would
say
I
would
still
feel
kind
of
lukewarm
about
the
current
stuff
and
it's
in
part
due
to
a
lot
of
conveniences,
that
added
just
a
lot
of
bulk
to
that
code,
that
code
directory
and
then
which
I'm
now
in
favor
of
eliminating
like
no
conveniences
like,
let's
keep
it
as
small
as
possible,
and
the
kind
of
feedback
that
I
felt
like
was
super
useful
from
yana
over
a
year
ago
about
the
like,
starting
with
the
the
documentation
structure,
to
make
sure,
like
a
user,
can
approach
it
and
understand,
like
there's,
not
very
much
for
me
here.
E
So
I
should
just
understand
what
little
I
see,
rather
than
like
being
overwhelmed
by
this,
like
many
pages
of
like
package
interface,
so
my
earlier,
I
have
a
draft
pr,
that's
still
in
there.
You
know
if
we
do
want
to
talk
about
the
metrics
api
and
the
sdk,
the
api
in
particular
like
they
think
that
that
there
is
room
for
go
to
do
a
prototype,
and
I
I
mocked
it
up
a
little
bit.
E
I
think
the
sdk
can
stand,
it's
good
enough.
It's
it's
pretty
good
and
allow
all
the
ways
it
needs
to
be
it's
just
that
the
api
is
really
hard
to
like
see
because
of
the
huge
package.
So
if
we
take
that
agree
that
the
sdk
is
good
and
functional
close
enough
to
it,
you
know
production
of
otlp
is
our.
E
Is
our
metric
as
our
measure
for
is
the
sdk
you
know
good
and
that
there
we've
we've
definitely
got
that
if
we
can
agree
on
that,
then
the
sdk
api
just
gets
pulled
away
to
take
it
out
of
the
user's
face.
E
At
that
point,
I
would
advocate
for
something
like
my
draft,
which
is
not
fully
complete
and
it's
hard
to,
therefore,
to
access,
but
it's
an
open
pr
and
I
really
just
kind
of
started
with
the
go
doc
and
it's
it's
a
empty.
It's
a
skeleton
with
a
godox
that
I
think
I
could
implement.
B
Yeah,
I
think
that
all
sounds
really
good.
I
like
the
direction
that
that's
going
in.
Thank
you
cool,
so
I
think
josh
not
to
keep
you
talking
too
long,
but
I
think
we're
actually
all
done
through
the
agenda.
If
you
wanted
to
share
some
of
the
success
that
you
were
talking
about.
Oh
yeah,.
E
Just
briefly,
I
guess
I
had
a
little
bit
of
a
maybe
sort
of
uncertainty
or
doubt
about
the
sampler
api
spec
in
general,
from
the
hotel,
like
we
didn't
finish,
sampling,
there's
a
to
do,
and
so
the
question
was:
is
it
actually
going
to
work?
E
And
at
this
point
we
have
a
an
otep
which
is
essentially
saying
we
can
we
can
do
what
we
need
to
do
within
the
framework
of
w3c's,
trace,
parent
and
trace
state
today,
and
what
I,
the
experiment
that
I
did
was
to
prototype
that
and
actually
see
that
it
can
be
done
without
modifying
the
hotel
go
sampler
api.
E
There
is
a
question
which
is
going
to
come
up
and
it's
not
a
failure
of
the
sampler
api,
so
so
much
as
it
is
a
failure
of
the
w3c
trace
context
stuff,
and
what
we're
seeing
right
now
is
we'd
like
to
include
a
few
extra
bytes
to
do
sampling
well,
not
in
a
trace
state
where
it's
like
30
bytes
overhead,
but
in
trace
parent,
where
it's
like
two
or
three
bytes
of
overhead,
so
that
we
can
get
an
unconditional
always
on
probability
propagated,
so
that
we
can
count
our
spans.
E
So
the
positive
result
is
you
can
do
that
using
trace
state
without
changing
any
apis,
and
I
have
a
pr
and
some
tests
to
show
it.
So
that's
good.
The
the
negative
result
about
w3c
is
really
that
the
right
way
to
go
here
is
that
you
want
to
make
a
the
sampler
has
to
be
involved
in
the
root
decision.
When
you
generate
those
trace
ids,
you
essentially
want
to
bake
in
some
random
randomness
and
we
may
just
specify
64
bits.
The
leading
64
bits
are
random.
For
example,
that's
good
enough.
E
We
only
need,
like
63,
turns
out
or
like
something
like
that,
but
if,
if
w3c
said
exactly
which
bits
are
random,
then
we
could
rely
on
it.
But
right
now
it
just
says:
don't
collide,
here's
128
bits
for
you
to
use,
don't
collide,
and
that's
not
really
great
for
us
and
if
so
one
thing
that
we
want
to
spec
out
that
randomness,
but
the
other
thing
is
the
sampler
needs
to
inject
its
own
probability.
E
So
that
means
we
change
the
trace
parent.
As
you
make
your
sampling
decision,
which
is
which
is
not
going
to
work
and
would
require
an
hotel
level.
Spec
change
of
sampler
api
somehow
like
sampler,
needs
to
be
involved
in
the
root
decision
or
in
setting
the
trace
parent,
which
it's
currently
not.
E
B
Did
you
get
a
proof
of
concept
built
using
the
go
sdk.
E
E
Review
but
if
you
are
following
my
otep
I
can
I
can
paste
it
here.
Where
is
that
draft.
E
The
otep
number
is
168
and,
let's
see
yeah,
I'm
just
going
to
put
in
the
zoom
chat
actually
I'll
put
in
the
notes
and
the
zoom
chat.
Okay,.
E
Here
it
is
in
both
places
anyway,
this
matches
160
168
and
it
is
a
prototyping
as
much
as
I'm
not
sure
what
to
do
with
the
existing
trace
id
based
trace
id
ratio
based
sampler,
because
the
point
is
to
change
it,
it
doesn't
really
work,
it
was
a
to
do
so.
Can
we
just
literally
change
it?
Is
that
breaking
the
spec
or
what
I've
done
in
that
in
this
branch
that
I've
just
showed?
E
B
So
it
looks
like
you
replaced
the
trace
id
ratio
based
sampler
with
something
that
does
that
load
adjustment
count.
Is
that
true.
E
F
E
B
Like
is
that
ford
compatibility,
I
guess,
because
yeah
this
is
a
tough
question,
because,
like
this
api,
like
you're
saying
doesn't
take
in
some
sort
of
you
know,
adjusted
count,
it
actually
is
really.
E
B
E
To
half-
and
I
think
probably
rounding
down
is
there
well,
one
of
them
is
the
right
one.
B
E
Yeah,
so
well
that
that's
that's
why
I'm
asking
is
it
is
that
the
spec
literally
has
a
to
do
saying,
trace
id
ratio
based
kind
of
doesn't
work,
and
so
I'm
not
sure
what
you
do
with
a
to
do
in
a
spec.
I
don't
think
we
should
break
it
like
it
from
a
compiling
like
to
to
keep
it
compiling
is
one
thing
I
could
just
round
the
number
to
get
one
of
these
specul
probabilities
to
preserve
its
behavior.
I
can
also
do
that.
E
It's
the
spec,
I
just
sort
of
said
it,
but
maybe
not
very
clearly
the
the
the
data
model
spec
in
otep
proposed
that
says
well
170
now
that
proposes,
one
of
two
attributes
must
be
used
when
your
adjusted
count
is
not
one.
So
one
is
the
natural
adjusted
count,
it's
an
adjusted
count
of
one
event.
So
if
you
have
one
event,
you
don't
need
to
say
I
haven't
adjusted
kind
of
one.
So
if
it's
zero
or
more
than
one,
you
need
to
say
it.
E
But
if
you
don't
know
it,
that's
my
proposal
is,
if
you
don't
know,
a
just
account
which
is
going
to
happen,
and
one
of
the
cases
where
it
would
happen
is,
if
you
preserve
this
interface
and
this
behavior
and
then
do
I
I'd
like
to
just
call
it
something
else.
So
tricity
ratio
based
with
an
arbitrary
fraction
becomes
probability
based
with
an
arbitrary
fraction.
E
At
this
point,
and
that's
the
draft
I
like
it
because
it
means
you
can
have
just
like
one
byte
needed
and
you
of
of
information
needs
to
be
propagated.
But
maybe
that's
not
what
people
want.
B
Well,
cool
yeah!
This
is
really
interesting
in
some
ways
way
over
my
head,
so
I'm
excited
to
do
some
more
reading
on
it,
but
yeah
this
is
cool.
I
like
the
directions.
It's
going.
E
This
there's
an
otep
170.
I've
mentioned
a
couple
times
now.
It
was
a
troublesome
one
because
at
the
I
wrote
this
lengthy
document
trying
to
fill
in
people
and
and
like
look
kind
of
provide
an
edge
like
a
little
education,
because
I've
I've
been
reading
about
this
for
a
long
time
to
try
and
understand
it,
and
I
feel
like
if
you'd
asked
me
some
of
these
questions.
Eight
years
ago
I
was
in
the
same
place
like
don't
understand
sampling.
E
It
took
me
a
while
so
170
now
it
contains
like
a
what's
really
going
on.
Here
is
there's
some
statistics
that
were
published
70
years
ago.
That
tell
you
you
can
do
this
guaranteed
to
work
and
that's
the
foundation,
and
I
did
make
up
the
word
adjusted
count.
There
are
other
words
you
could
use,
but
I'm
the
argument
goes
that
if
you're
going
to
do
one
in
n
sampling,
that's
like
an
intuitive
thing
that
you
understand
one
and
n.
The
thing
we
want
to
record
is
n.
E
Not
1
and
n
and
n
turns
out
to
be
the
effective
count
or
adjusted
count.
Is
the
word
I'm
using
what
it
says
is
you
you're
sampling
and
to
count
this?
You
need
to
adjust
its
count
in
the
in
the
population.
Basically-
and
I
and
I
took
that
word
from
some
other
research
on
sampling
that
uses
adjusted
weights
well,
in
this
case,
we
are
adjusting
the
weight
of
something
which
is
a
count,
and
so
it's
the
adjusted
count.
E
But
it
is
a
really
deep
topic
and
if
you
can,
you
can
get
to
a
place
where
the
basics
don't
apply
and
you're
you're
off
in
statistics
land
and
it's
hard
to
tell
people
when
they've
left
the
rails
of
like
the
basic
stuff
we're
trying
to
do
and
all
the
confusing
things
out
there
in
the
world
which
of
which
there
are
many
head
sampling,
tail
sampling.
It
gets
very
confusing.
I'm
I
love
to
try
and
help
people
in
this,
but
yeah.
So
that's
my
best
effort
was
otep
170.
B
Cool
I've
added
it
in
the
agenda
docs
if
people
are
interested
and
want
to
take
a
look
at
it
at
some
point
in
the
future
as
well
or
if
you're,
watching
the
video
of
this
but
yeah.
I
think
with
that,
are
there
any
other
success
stories
we
can
share
from
customers
or
for
usage
of
the
oka
tonji
go
project?
B
I
wonder
if
david,
if
I
can
call
him
back.
E
I've
got
a
bug
report
I'm
supposed
to
be
investigating,
but
I
don't
think
it's
it's
hotel.
I
think
it's
slight
step
satellite
doing
the
wrong
thing
and
I
don't
like
investigating
that
kind
of
bug,
because
it
always
ends
up
me
burning
a
bunch
of
time
on
the
client,
never
mind,
gotcha,
something
about
infinite
retries.
I.
B
G
B
So
yeah
I'm
all
about
it.
Please
make
sure
you
share
it
in
the
side
channel
when
you
do
get
it
out,
yep
we'll
do
yeah
well
cool.
I
see
steve
has
just
came
back
just
in
time.
We
could
probably
end
it
unless
steve
has
some
cool
user
stories
as
well.
I
don't.
D
Cool
great,
I
actually,
if
we've
got
a
minute,
just
ask
it's
my
last
week
next
week
and
so
it'd
be
really
cool.
If
anybody
could
look
at
my
prs,
anthony
has
already
looked
over
him.
A
lot
he's
checked
over
that
checked
off
that
one.
So
if
we
could
get
somebody
else
to
review
it,
that'd
be
really
cool,
so
I'll
be
leaving
soon
and
I'd
love
to
get
that
merged.
Before
I
leave
yeah,
I'm
the
exact
same
boat,
it's
pretty
funny.
B
So
garrett
and
eddie
could
you
post
links
to
the
pr's
you
want
in
the
agenda
and
yeah
I'll?
Do
that
for
sure
there
are.
B
Watch
the
video
of
this
afterwards,
they
may
have
some
more
cycles
as
well,
so
yeah
be
helpful.
Yeah.
F
B
Yeah
cool
yeah,
if
you
guys
can
post
them
in
the
notes,
that'd
be
ideal.
When
you
can
get
job
motivated
boy,
he
will
review
your
pr's
but
yeah.
It's
something
you
gotta
pay
backwards,
though
well
cool.
I
I
see
you
guys
updating
anybody
else
have
some
topics.
I
wanted
to
talk
about
that
weren't
in
the
agenda.
Before
we
closed
this.
D
Okay,
I've
got
the
instrumentation
link
in
there
now,
so
hopefully
that
should
work
for
you,
and
then
I've
also
got
that
second
package
that
I
know
we
talked
about
a
little
bit.
That's
the
configuration
stuff
that
we
got.
Okay,
oh
I
look
like
I'm
frozen.
D
D
B
B
F
Totally
great
yeah,
I
don't
know
tyler
or
anyone
else
if
you
wanna,
if
you
want
me
to
like
go
through
a
quick
demo
or
like
step
through
the
major
parts
of
the
pr
that
I've
had,
I
could
do
that
after
this
meeting
or
something.
B
F
B
Yeah,
I
think
I
I
seem
to
spend
more
time
looking
at
it,
it's
a
big
pr,
and
that
takes
a
long
time.
So
I
need
to
dedicate.
B
Much
right
now,
but
yeah
I'll
try
to
prioritize
that,
like
I
was
saying,
but
yeah
it's
a
tough
one
for
me.
Have
you
reached
out
to
anybody
in
the
collector
space?
I
noticed
that
there
was
a.
F
Yeah
yeah
for
this
one
specifically,
it
could
be
applicable
to
the
collector
for
sure.
That's
like
our
end
goal,
but
like
right
now,
it
seems
like
only
anthony,
has
really
been
using
this
tool
for
the
a
couple
of
rc
releases
he
had.
So
I
don't
think
a
lot
of
the
people
in
the
collector
decide.
Maybe
jurassic
you
really
even
know
much
about
what
this
tool
is
for,
how
it's
used.
B
Okay,
well,
it
seems
like
this
was
intended
to
be
used
across
the
platforms.
I
would
definitely
want
to
make
sure
that
they
have
some
understanding
and
insight
into
what
we're
trying
to
accomplish
here.
I
thought
that
there
was.
D
B
Desire
from
them,
you
know-
and
I
think
that's
kind
of
a
really
good
important
thing
from
what
I
was
seeing
was.
It
needs
to
be
useful.
You
need
to
have
like
more
generic
functionality.
I
think
to
make
sure
that.
B
Use
this
or
or
we
need
to
have
a
path
forward
to
make
that
a
an
important
you
know,
yeah.
B
F
I
think
right
now,
though,
we
were
trying
to
get
this
like
skeleton
of
the
app
just
merged
into
the
repo,
so
that
it
could
be
actually
pulled
by
the
tools
during
like
the
release
process
by
anthony,
for
example,
and
also
like,
I
said,
like
there's
several
more
like
improvements
that
I
need
to
make
once
this
pr
is
merged.
B
So
we
got
you,
so
is
there
a
way
you
can
pare
this
down?
Because
if
there's
a
way
you
can
get
like
a
base,
skeleton
in,
I
think
you're
gonna
have
a
lot
more
success.
The
thing
that
really
kind
of
stuck
out
to
me
is.
B
Things
like
this
essentially
are
copied
straight
out
of
our
release
process,
and
I
would
want
to
make
sure
the
collector
release
process
can
also
use
these.
It's
really
easy
to
add
things.
It's
a
lot
harder
to
remove
them.
So
you
know
if
we
do
come
through
this
process,
and
we
have
things
like-
I
don't
know
where
the
make
target
thing
was,
or
even
just
like
iii.
B
Okay,
yeah,
maybe
just
have
a
once-over
and
ask
yourself
like.
Is
this
something
that's
specific
to
the
release
process
that
opens
up
your
go
or
you
know?
Could
this
be
added
later
you
know.
Are
there
are
the
things
that
I
could
pull
out
of
this?
That
would,
you
know,
reduce
the
code
space
but
also
reduce
like
the
actual
functionality.
So
you
could
get
a
an
actual
bare-bones
skeleton,
I
think,
is
really
how
I
would
try
to
approach.
B
Maybe
taking
another
look
at
this,
like
I
said
I
haven't
gotten
much
past
about
here,
though,
because
I
just
I
don't
know
the
time
right
now,
but
that
said,
if
there
are
other
people
on
the
call
that
do
have
the
time
with
it,
you
know,
I
think
that's
maybe
something
you
guys
can
provide
feedback
on
as
well.
B
Yeah
exactly
so,
if
we
can
make
this
easier
to
review
by
breaking
this
out
into
some
sort
of
like
components,
I
think
that
would
help
or
just
a
lot
smaller
prs.
I
can
usually
get
a
few
hundred
lines
of
code
reviewed
and
just
well.
It
depends
on
the
complexity.
Sometimes
ten
lines
of
code
takes
me.
Two
hours.
C
Yeah
but.
B
F
And
then,
in
that
case
I
think
if
I
had
to
create
new
pr's,
then
anthony's
approval
would,
I
guess
not
be
on
those.
Is
that
fine
fighter?
B
B
And
so
like,
this
is
one
of
the
things
where
you
kind
of
have
to
weigh
your
options
here,
and
I
think
that,
like
you,
have
to
ask
yourself
when
you
submit
a
pr
like
the
complexity
of
the
lines
of
code,
are
going
to
be
barriers
for
people
to
review
it.
Sometimes
it's
going
to
just
be
really
high
priority
and
people
just
need
to
be
doing
their
reviews
on
it.
B
Like
that's,
definitely
happened
in
our
in
our
code
space,
but
sometimes
it's
not,
and
so
I
think,
if
you're
in
a
tough
position
here,
because
it's
a
high
priority
for
you,
because
you
need
to
get
this
done
for
your
internship
to
think
the
the
releasing
process
is
not
as
high
priority
as
a
lot
of
other
people.
B
B
B
B
B
Thing
so
there
is
a
double-edged
sword
there,
so
we
can
go
too
small
30
line
codes.
It's
not
really
you're
never
going
to
get
this
done
in
a
week,
but
I
I
would
try
to
see
if
you
can
find
some
way
to
like
make
this
a
little
bit
easier
in
the
review
process
for
the
reviewers.
E
You've
reminded
me
of
my
pr,
though
tyler
like
2120
pulling
a
resource
field
out
of
an
export
record,
caused
a
tremendous
amount
of
change,
and
it
is
largely
mechanical,
but
it's
not
entirely
so
the
the
size
of
the
pr
is
somehow
bigger
than
its
real
nature,
but
it's
not
small
either,
and
I
mean
I
I
can
see
why
that
would
make.
No
it
make
it.
So
no
one
wants
to
review
it.
I
could
imagine
being
asked
to
split
it
into
at
least
two
parts.
E
It's
still
going
to
be
a
big
pr,
but
but
it'll
be
the
more
mechanical
portions,
isolated
and
the
otp
change
could
be.
I
could
make
it
a
like
a
placeholder
change.
Instead,
you're
gonna
have
to
change
that
code,
but
I
could
I
could
keep
it
like
almost
the
same
and
then
follow
it
with
another
pr,
and
then
we
get
into
a
situation
where
it's
not
just
administrative
overhead.
It's
like
like
round
trip
time.
E
Like
me,
I
know
that
waiting
to
get
two
pr's
merged
is
going
to
take
longer
than
waiting
to
get
one
pr
merge.
So
I
think-
oh
that's
just
for
me.
It's
much
easier
to
write
these
two
together,
but
it's
way
harder
to
review
that
way,
because
you
can,
you
can't
tell
how
independent
the
two
parts
of
this
change
are
from
a
sort
of
simple
examination.
B
Yeah,
I
guess
eddie
welcome
to
the
grind,
because
this
is
something
that
you
will
be
working
on
in
your
career
like
you're,
not
alone.
I
should
I
share
that.
F
A
A
And
they're
like
it's
too
much,
I
don't
know
what
to
do
with
this.
B
B
F
I'll
just
make
another
pass
through
just
to
make
sure
that
I'm
not
adding
extra
functionality
that
can
be
added
in
a
subsequent
pr
just
so
I
can
get
at
least
one
merge
with
some
of
the
base
functionality.
B
Yes,
I
would,
I
would
recommend
that
I
think
that's
a
really
good
idea,
thanks
post
in
the
channel,
if
you
do
something
like
that,
okay
or
just
after
your
second
review,
I
think
that'd
be
helpful
to
understand.
F
B
B
Cool,
I
think
that's
it.
If
you
have
time
both
garrett
and
eddie
would
love
reviews,
and
if
you
have
more
time
I
think
it
there's
definitely
stuff.
We
talked
about
originally
on
the
project
board,
the
cutest
reviews,
I'm
going
to
review
josh's
pr,
because
I
said
I
was
like
multiple
weeks
now
and
I
have
not
so
you
can
review
it
and
say
split
it
in
two.
B
It's
a
valid
review,
sometimes
yes,
totally
valid
bogdan,
is
the
king
of
that.
So,
if
you
ever.
E
B
B
F
B
Nature
of
these,
it's
just
small
changes.
B
D
B
Easier
to
review
most
of
the
time,
because
if
you
understand
and
you're
really
clearing
your
description
as
to
what
those
changes
were
and
why
this
is
showing
up
in
20
different
places,
it's
a
lot
easier
to
do
that
versus
like
you're
trying
to
include
20
different
pieces
together.
That's
really
hard
to
get
not
only
review
but
get
right.
There's
almost
certainly
the
size
of
things
trying
to
include
at
one
point
in
time
is
going
to
include
the
number
of
bucks
but
yeah.
This
is
just.
I
don't
have
a
really
good
answer
for
you.
B
This
process
is
it's
tough,
but
it's
important.
It's
really
important
to
make
sure
we
provide
quality
codes,
so
I
want
to
make
sure
that's
something
to
do
so.
Okay,
everyone,
I'm
starting
to
wax
poetic
at
this
point.
So
why
don't
we
go
ahead
and
end
it
and
thanks
everyone
for
joining
there's
a
metric
sig
later
on
at
4
p.m.
I
think
so,
if
you
have
time,
please
join
that.
Please.