►
From YouTube: 2021-07-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
B
B
B
Okay,
so
the
first
one
is
really
a
quick
ask.
So
for
this
pr
we're
still
stuck-
and
I
talked
with
josh
suresh
offline
and
he
agreed
that
he'll
help
pick
it
up
once
he
like
come
back
from
the
vacation.
So
currently
he
blocked
the
pr.
B
But
I
believe
all
the
blocking
comments
has
been
have
been
resolved
and
for
the
others
when,
when
you
look
at
the
pr
I
want
you
to
be
very
specific
about
which
part
is
is
making
you
concerned
and,
and
I'm
happy
to
scope
down
the
pr
just
to
draw
the
skeleton.
So
my
goal
is
not
to
make
a
like
a
a
perfect
pr
that
covers
everything.
B
It
seems
like
people
in
general
they're
facing
trouble
when
you
have
multiple
exporters,
some
are
pushed
and
pulled
like
they
mixed
together
and
when
you
report
delta,
how
are
you
going
to
handle
that,
and-
and
currently
there
are
two
different
ways
of
thinking
about
this
problem?
Ultimately,
they
will
lead
to
the
same
thing,
so
you
will
have
the
mathematical
the
most
optimal
solution
for
both
paths
and
they
will
look
exactly
the
same,
but
as
a
starting
point.
B
Let
me
look
at
the
sdk
spec
for
now
we're
saying
on
a
single
meter
provider,
you
could
have
multiple
pipes
that
eventually
send
it
to
the
exporter
and
the
exporter
could
mix
and
match,
and
at
the
bottom
here
we
try
to
explain
it.
One
extreme
case
where
you
have
multiple
exporters,
push
and
pull,
and
they
all
mixed
up
together
and
to
make
this
easier
for
people
to
think
about.
You
basically
duplicate
the
entire
effort.
In
your
eyes,
they
have
multiple
pipelines,
each
one
is
independent.
B
They
have
no
idea
of
the
existence
of
the
other
exporters
and
you
basically
duplicate
the
work
for
every
single
pipeline.
You
receive
some
data,
you
do
some
processing,
you
maintain
the
state,
but
this
is
a
very
very.
I
was
a
naive
way
of
thinking
about
how
how
you
implement
this.
When,
when
you
start
to
do
the
real
implementation,
you
will
find
a
lot
of
things
like
the
memory
state.
B
They
can
be
shared,
so
you
can
potentially
do
many
smarter
things,
and
this
is
where
people
are
struggling
with,
and
originally
I
was
not
in
intending
to
cover
this
in
the
spike
at
all,
because
this
is
more
like
implementation
detail.
It's
like
if
I'm
going
to
write
regular
expression,
spec,
I'm
only
going
to
document
how
you
expect
from
a
regular
expression,
but
how
you
implement.
B
B
So
I
I
try
to
share
some
ideas,
and
I
the
the
thing
I
want
to
get
from
this
topic
is:
I
want
you
guys
to
tell
me:
is
this
something
you
think
that
we
should
clarify
in
the
spike,
or
this
is
out
of
scope,
but
for
people
who
are
doing
prototype
like
sharing
this
information
might
be
helpful,
so
you
can
see
my
screen.
I'm
sharing
a
pvp
file.
B
So
the
the
right
mark
here
is
when
the
pipeline
is
going
to
trigger
when
it's
trying
to
export
the
data.
So
you
can
see
at
this
point.
B
When
this
time
comes,
you
try
to
export
the
data,
you
will
have
the
exact
data
you
need,
however,
at
this
point
you're
not
supposed
to
drop
the
data.
So
when,
after
you
export
the
data,
you
have
to
somehow
keep
a
reference
inside
the
memory
saying.
I
cannot
just
delete
the
data,
because
this
data
is
supposed
to
be
used
by
another
exporter
pipeline,
which
is
a
pipeline
too.
B
B
Send
that
to
the
second
pipeline,
but
you
need
to
add
up
the
first
and
the
second
delta
and
send
to
the
third
pipeline.
Now
I
probably
might
stop
you.
You
need
to
add
both
together
to
send
to
the
second
pipeline,
because
this
one
hasn't
included
the
delta
yet
and
for
the
for
the
last
pipeline,
you
already
exported
the
first
delta,
so
you
can
ignore
that
and
just
export
the
second
delta.
B
In
this
way,
you
kind
of
having
to
keep
a
two-dimensional
in-memory
map
just
to
bookkeep,
which
instrument
is
consumed
by
which
pipeline,
and
is
the
pipeline
like
subscribing
to
that
instrument
and
is
the
particular
version
of
the
delta
has
been
exported
to
this
pipeline
or
not?
And
by
doing
this,
like
maintain
the
table
you
might
which
one
is
interested
in
which
instrument
and
which
one
is
already
consumed,
you
can
implement
some
logic,
how
to
combine
different
delta.
So
this
is
what
I
discussed
with
the
bolton
and
josh
sewerage.
B
D
B
It
can
potentially
reduce
many
many
synchronizations
like
in
a
matrix.
The
ideal
way
is
you
don't
use
any
synchronization
besides
the
cpu
primitive
like
compare
and
switch
anything
like
holding
a
lock.
This
is
the
dead
end
that
we
shouldn't
do
from
the
at,
at
least,
if
you
write
a
like
production
quality
matrix
ick,
I
I
think
we
should
avoid
anything
that
takes
in
like
operating
system
level,
lock
and
and
by
combining
data
here
you
can
share
as
much
as
possible.
A
And
then
riley,
would
you
say
that
this
there's
this
case?
I
think
we
were
describing
where
there
are
two
push:
exports
different
frequencies
and
one
of
them's
like
a
multiple
of
the
other.
Let's
say
so.
There's
an
obvious,
multiple
or
an
obvious
win
here,
which
is
the
faster
exporter,
is
going
to
export
the
raw
deltas
that
come
out
of
the
measurement
processor
since.
A
Slower
export
frequency
is
going
to
have
its
own
state,
where
it
will
essentially
double
buffer
it'll,
take
in
the
deltas
coming
out
of
the
higher
frequency
put
them
into
lower
frequency,
there's
just
a
reapplication
of
aggregation
again,
so
it
should
be
just
putting
the
same
parts
into
a
different
pipeline.
It's
just
an
optimization
thing
about
this
that
I
just
don't
feel
like
it's
all
that
useful
or
that
people
are
going
to
do
a
lot
of
it.
A
I
I
think
you're
talking
about
things
that
make
sense,
I'm
just
not
sure
that
this
is
like
demanded,
though
maybe
it
has
been.
I
just
I'm
not.
I
wonder
if
we're
we're
sort
of
overthinking
this.
B
Yeah
so
so
my
key
point
is
from
the
spikes
perspective:
we
don't
care.
These
are
the
implementation
and-
and
we
shouldn't
even
include
this
in
the
spec.
The
problem
I
found
is
a
lot
of
people
reach
out
to
me
asking
about
the
spec
pr
or
the
spec
just
because
they
they
have
a
trouble
following
the
spike
and
implement
that.
So
my
answer
has
been.
A
Say
by
the
time
you
understand,
I'm
sorry,
I'd
say
by
the
time
you
understand
all
the
components
are
implementing
this
and
you
understand
what
it
takes
to
do:
a
multi-push
pull
environment
you'll
get
to
wire
those
pieces
together,
correct.
You
know
in
the
most
optimal
way,
there's
so
many
variations
here.
I
just
feel
like
it's
almost
not
worth
describing
every
single
one
of
them.
B
Yeah
exactly
so,
this
is
why
you
don't
see
any
of
this
in
the
stack
yeah.
So
my
my
answer
is:
first,
you
don't
struggle
with
the
implementation
detail,
especially
how
to
optimize
this.
You
just
do
the
simple
way
when
you
do
the
prototype.
As
long
as
the
process
works,
you
can
build
some
ick,
although
not
super
performant,
but
you
start
to
have
the
idea
that
ict
might
work
and
then
I
just
need
to
find
one
particular
scenario
to
have
some
high
performance
experiments.
So
we
know
the
spec
is
not
giving.
B
It
is
not
going
to
restrict
you,
but
you
can
only
have
a
bad
performance
as
long
as
we
can
achieve
that
goal,
then
I
think
we're
good
and
if
you,
if
you
think
these
are
helpful
for
you
to
think
about
how
to
implement
the
ick,
with
understanding
that
I'm
not
going
to
put
any
of
this
in
the
sdk
spike,
I'm
happy
to
share
this
with
you
guys.
If
you
want
there
are
many
different
scenarios
like
the
cumulative
value,
is
treated
very
differently
from
the
the
delta
value.
B
B
So,
just
coming
coming
back
to
the
pr
I
have
currently
it's
it's
receiving
almost
like
80
comments
and
it's
blocked
so
I'll
I'll,
try
to
ping
josh
storage
today
and
see
what
are
the
other
blogging
issues
and
for
any
of
the
open
discussion
like
there
are
still
comments
I'll
reach
out
to
whoever
opened
the
comment
and
see
whether
we
can
resolve
that
or
you
think
it's
still
open
thing.
So
I'll
try
to
push.
A
Harder
any
other
comics,
it's
a
summary
there.
Riley
is
you're
still
trying
to
get
this
merged
and
you
want
people
to
either
resolve
their
comments
or
point
out
their
projections
and
so
that
we
can
get
it
merged.
B
Yeah,
so
my
goal
is
to
get
this
again
I'll.
Take
another
look
yeah,
so
my
goal
is
to
get
this
pr
merged
and
I
know
there
are
many
open
questions.
I'm
happy
to
scope
down,
because
the
initial
goal
is,
I
want
to
draw
the
skeleton
of
the
sdks
back,
so
we
know
we
need
view
and
whether,
like
the
the
particular
instruction
in
the
real
part,
is
clear
or
not.
B
If
we
decided
it's
not
clear
and
we
don't
have
a
clear
answer
for
now-
I'm
happy
to
remove
the
entire
detail
there
just
to
make
it
a
dbb.
Once
we
have
the
skeleton
it's
easier
for
us
to
split
the
work
we
can
see
for
this
section,
we'll
have
d
mac
b,
taking
care
of
that,
for
that
part
vector
will
help.
I
just
need
that
skeleton
to
to
be
in
place
first,
so
we
can
be
unblocked
and
so
people
can
work
in
parallel.
A
Again
so
I
think
the
the
summary
is:
we
need
the
skeleton
to
have
minimum
viable
structure
to
build
off,
and
hopefully
that
structure
helps
us
avoid
the
kind
of
the
indefinite
debate
over
all
the
kind
of
user
facing
fanciness.
Here
you
know
like
setting
up
views,
is
really
powerful
and
really
complicated
and,
and
we've
mostly
been
talking
about
the
components
and
the
machinery
and
the
sort
of
like
building
blocks
for
pipelines,
and
then,
when
users
see
this,
they
say.
Okay,
how
am
I
going
to
set
up
a
view
and
it's
missing?
A
B
Yeah,
so
the
idea
is,
if
we're
going
to
design
a
car.
What
I
think
the
first
step
is
we're
going
to
say:
they're
they're,
going
to
be
wheels,
there's
chassis
and
there's
an
engine
block,
and
I
know
design
design
engine
is
complex.
People
are
going
to
ask,
do
you
have
ignition
and
then
the
other
folks
would
argue:
hey
we're
building
like
full
electric
car,
there's
no
ignition
and
it
could
take
multiple
years
because
we're
still
exploring
but
having
that
skeleton
is
the
first
step.
B
B
And
anything
like
the
aggregator,
the
different
component
that
we
can
share
from
the
pipeline,
I
get
that
it's
important
like
eventually
we
want
people
to
implant
to
be
able
to
implement
their
own
aggregation
logic.
Some
people
might
want
to
build
unique
account.
Some
of
them
might
say.
I
have
my
specific
version
of
histogram.
They
want
to
build
that,
so
the
ick
might
allow
extensibility
in
the
future.
But
as
long
as
we
have
the
basic
things
today,
we
don't
have
to
block
on
that.
So
I
I
think
it's
totally
fine.
B
If
the
idk
spec
is
telling
you
you're
able
to
define
different
views,
you
can
interpret
existing
instruments
in
your
own
way,
but
how
you
do
that
and
what
the
pipeline
can
like.
Just
like
the
slides
I
shared
before
how
you
can
do
that
efficiently
and
how
you
can
allow
people
to
use
existing
components
to
build
something
on
top
of
them.
These
are
something
we
can.
We
can
do
later
as
additive
change.
So
I'm
not
going
to
focus
that
on
that
right
now,
because
we're
still
like
in
the
cross
stage.
B
Yeah,
so
so
how
has
to
make
progress?
And
if
anything,
you
think,
is
a
show
stopper
from
your
side
call
it
out.
I'm
very
happy
to
scope
that
if,
if
you
figure,
hey
riley
you're
trying
to
talk
about
the
fuel
injection
but
we're
trying
to
develop
electric
car,
there's
no
fuel
the
cars,
I'm
I'm
going
to
remove
that
and
just
leave
a
tbd.
A
A
discussion
about
histograms
topic
this
two
weeks
ago,
I
posted
referendum,
essentially
saying
we've
finished
our
research
and
our
discovery
process
for
histogram
format.
A
I
asked
everyone
to
look
at
this
issue
that
was
discussed
and
an
enormous
amount
was
written
on
the
issue.
I've
read
it,
but
through
it's,
my
my
summary
is
that
the
binary
approach,
sort
of
still
has
a
lot
of
favor
from
the
people
who
are
contributing.
Of
course,
the
people
who
are
contributing
are
the
same
ones,
helped
produce
the
binary
proposal.
A
So
it's
not
too
surprising
that
we
still
have
support
for
what
with
what's
there
the
for
me,
I
think
the
okay,
so
the
highest
level
of
feedback
was
look
at
the
relative
error
ratios
of
these
two
of
these
two
formats
and
you
can
see
an
improvement.
The
binary,
because
it's
the
sort
of
resolutions
are
spaced
a
little
closer.
It
has
a
little
bit
better
performance
for
maximum
relative
error.
That's
again
a
kind
of
a
technical
thing.
A
I
started
to
look
at
the
detail
of
how
one
implements
this
sort
of
claim.
Is
that
the
binary
proposal
you
can
use
the
floating
point
hardware
or
the
ieee
representation
of
your
floating
point
value
to
directly
compute
your
histogram
bucket?
I've
started
to
look
at
the
logic
for
that,
and
I
think
I
was
looking
at
opmar's
prototype,
which
was
written
in
java.
It's
linked
in
the
thread
here
somewhere,
it
didn't
quite
understand
and
everything
atmar
was
doing
so.
I
feel
like
at
this
point.
A
I
personally
am
ready
to
support
the
binary
proposal,
but
I
was
trying
to
implement
it
in
a
way
that
I
was
super
comfortable
with
which
I'm
not
yet.
So
I
was
thinking
that
this
week.
I
might
ask
some
questions.
I
know
george,
is
on
the
line
here.
I
was
looking
at
mars,
represent
lotmar's
prototype
and
had
some
questions
let's
say:
do
we
need
to
understand?
Do
we
need
to
represent
subnormal
values?
These
are
like
extremely
small
values
that
would
denormalize
representation.
A
I'd
say:
no,
we
don't
and
then
the
next
thing
that
we're
going
to
end
up
debating
or
at
least
need
to
spec
out
is
what
are
the
minimum
values
and
what
are
the
maximum
values
that
the
histogram
will
represent,
and
I
I
don't
have
more
to
say
on
this
right
now,
but
I
intend
to
this
week
post
to
that
thread
and
pull
in
at
least
one
more
person.
A
We
want
prometheus
support
here.
That's
almost
the
most
important
thing
we
can
get
more
than
the
you
know
technically
correct,
histogram
stuff,
so
I'm
going
to
make
sure
that
prometheus
has
voiced
support
for
it
before
we
go
on
and
have
a
prototype
at
least
one
prototype
that
I
can
that
I'm
confident
in
explaining,
which
is
different
than
having
atmara,
be
able
to
explain
it.
That's
all
I
have
to
say
on
this.
I
think
we're
going
to
make
progress
this
week
and
prototypes
are
what
we
need.
A
I
know
we
have
one
I'm
a
little
bit
interested
in
seeing
more
than
one
and
I'll
gather
some
detail
and
present
on
the
thursday
meeting.
What
I
find.
D
A
Yeah
well,
I
was
also
looking
at
atmar.
Has
one
it's
linked.
It's
in
the
comment
thread
from
149,
it's
java
and
as
I
was
looking
at
it,
of
course
I
read
java.
I
write
java,
but
it's
not
the
prototype.
I
wanted
myself
so
I
think
feel
like
there
are
a
couple
ways
to
prototype
this
and
that
comes
down
to
questions
about
whether
you
want
infinite
resolution
or
whether
you
want
fixed
space,
and
I
think
that
there
are
two
prototypes
to
ask
for
one
is
the
sort
of
extremely
high
resolution.
It's
going
to
be
approximately.
A
What
open
histogram
has
you're
going
to
end
up
with
tens
of
thousands
of
boxes
for
a
wide
ranges
that
that
is
an
appropriate
solution
for
some
people,
especially
when
you're
aggregating
a
lot
of
data.
You
want
to
have
a
lot
of
buckets.
There
is
a
different
cut
cost
of
application
in
my
opinion,
and
I'm
not
sure
how
much
demand
there
is,
but
I'd
love
to
see
it
prototyped
just
to
cover
our
bases,
which
is
a
fix,
throws
a
fixed
space
histogram.
A
So
I'm
going
to
say
something
like
I
want
64
buckets,
no
more,
and
if
you
give
me
data,
that's
clustered
very
tightly
around,
let's
say
one
number.
I
should
be
able
to
have
high
resolution
in
that
very
small
range
with
64
buckets,
but
as
soon
as
you
give
me
a
value,
that's
outside
of
that
range,
I'm
gonna
blow
up,
I'm
gonna
just
drop
resolution
and
keep
my
histogram
within
its
parameters.
So
I'm
gonna
have
a
lower
resolution.
A
Histogram,
it's
still
64
buckets
and
I
can
dynamically
adjust
the
histogram
I'd
like
to
see
the
code
for
that,
because
I
think
it's.
I
think
it
would
be
a
nice
demonstration
of
how
simple
this
representation
is
because
it's
binary
and
we
have
the
binary
representation
in
bits
in
front
of
us
essentially.
So
I
think
I'd
like
to
see
that
and
that's
what
I
was
working
on
at
the
end
of
last
week.
A
Okay,
I'm
looking
for
prototypes.
There
is
one
in
java,
I'd
like
to
produce
one
and
go.
This
is
not
tech
in
theory,
this
is
not
much
code.
It's
a
lot
of
bit
shifting
and
you
know
something
like
that.
B
Josh
so
quick
question,
I
I
believe
like
last
week
when
we
talked
about
this,
there
are
still
some
open
questions
and
we're
deciding,
and
it
seems
we
already
made
some
decision.
So
I
wonder
if,
if
someone
could
help
to
clarify
on
the
issue
like
just
to
list,
what
are
that
we
already
decided
and
and
what
are
the
things
that
are
still
open
for
discussion?
A
That's
what
it
looks
like
and
at
least
from
my
opinion-
that's
a
good
choice.
I
the
thing
that
we
don't
the
thing
open.
Histogram
has
the
base.
10
proposal.
Has
this
pretty
substantial
open
source
like
code
already
there
and
in
the
binary
model
we're
we're
sort
of
referencing
academic
publications,
we're
referencing
prototypes
that
have
been
done
recently
and
allegedly
these
are
simpler
to
work
with,
but
we
don't
have
as
many
prototypes
yeah.
So
I
was
basically
proposing.
A
A
There
is
still
a
little
bit
of
like
wiggle
room
here
and
I
and
there's
a
little
enthusiasm
from
the
hdr
histogram
people
and
I'm
going
to
at
least
address
that
in
words.
There's
something
like
a
do.
People
want
multi-resolution
histograms,
where
you've
got
one
section
with
high
resolution
and
then
tails
with
low
resolution.
A
That
was
that's
another
approach
that
I
didn't
mention
earlier
is
you
can
have
the
tens,
tens
of
thousands
of
buckets
you
can
have
fixed
64
buckets
or
you
can
have
a
situation
where
there's
a
dense
region,
32
buckets
and
then
there's
like
eight
more
buckets
outside
those
and
they
can
be
sparse.
So
it's
a
do.
We
want
to
mix,
sparse
or
dense
buckets
or
have
at
least
variable
resolutions.
That's
actually
what
hdr
histogram
is,
and
I
don't
know
if
that's
where
we
want
to
go.
That
could
be
done
later.
A
I'd
like
to
see
the
simplest
possible
histogram
right
now
and
so
prototypes
with
little
small
amount
of
code
that
take
advantage
of
floating
point.
Hardware
are
the
ones
that
will
convince
me
that
we're
making
the
right
decision.
B
E
B
Like
90
percent
of
the
folks
would
prefer
base
two
and
and
there's
still
open
question
about
this
time,
but
it's
very
unlikely
when
we
start
to
make
a
point
and
if
someone
starts
to
say
oh,
this
is
the
the
end
of
the
game.
We
cannot
do
that,
then
they
can.
They
can
scream
at
us.
So
at
least
this
helps
people
to
understand
where
it's
likely
like
we're
likely
to
go
and-
and
if
there's
a
particular
topic
that
is
like
50
50,
we
don't
see
clarity,
then
that's
probably
somewhere.
We
need
more
help.
B
A
That
I
will
summarize
that
what
you
just
said
today.
A
Okay,
I
I'm
going
to
ask
georg
who's
on
the
line,
if
georg
is
willing
to
either
to
step
up
to
present
or
atmar's
logic
in
his
code,
or
invite
mark
to
write
it
up
with
comments
and
communicate
with
us
how
the
dynatrace,
histogram
prototype,
looks
and
how
it
works.
A
So
a
little
bit
of
a
show
and
tell
for
atmar's
code
is
what
I
want,
and
I
I
think,
eric's
muted,
but
maybe
he's
able
to
answer
that
and
then
I'll
do
the
same
this
week
with
some
go
code
that
computes
these
histograms
and
I'm
gonna,
I'm
gonna
use
fixed
space
logic,
which
will
be
a
different
prototype
than
not
mars,
and
we
should
be
able
to
have
that
presented
by
next
tuesday.
A
I'm
not
asking
you
on
the
spot
right
now,
maybe
on
thursday
next
tuesday's
meeting
would
be
like
same
time
next
week
would
be
good.
Okay,.
A
Relate
back
to
him
because
I
read
through
it
and
I
can
mostly
read
it,
I
mean
there's
no
comments
and
I
didn't
no
one
expects
comments
in
a
sort
of
early
prototype,
but
I
had
some
moments
where
I
wanted
to
have
a
comment
and
then-
and
I
can
reverse
engineer
it,
but
it
it
looked
like
worthy
of
some
comments.
B
A
C
A
A
B
Sounds
better
to
me
as
well:
yes,
they
meet
him.
The
third.
This
week's
thursday
meeting
won't
work
for
you
guys,
so,
let's
put
that
on
next
tuesday
and
and
josh
help
us
to
list
the
top
questions
that
we
want
to
get
answer
like
yes
or
no
base
two
base.
Ten
do
we
want
sparse
and
then
it's
mixed
together?
What
are
the
other
questions?
Then?
Folks
can
quickly
make
this
video
and
out
of
the
media.
B
A
So
everyone
should
put
their
attention
on
17
30
for
now
and
I'll
get
some
updates
on
the
histogram
stuff
summarizing
this
meeting.
C
Just
from
a
sort
of
understanding
standpoint,
we
are
done
with
the
api
specification
right,
so
that's
mostly
finished
so
we're
now
working
on
the
on
the
sdk
spec,
if
I'm
mistaken
and
then
for
the
sdk
spec.
We
basically
only
are
waiting
for
the
view
part
right
so
that
yeah.
B
Yeah,
so
the
the
api
part
we're
reaching
experimental
version
last
month
and
which
means
we
think
it's
good
enough
for
different
language
to
start
implement
that
and
for
for
the
scope
before
we
reach
to
feature
freeze,
we
still
have
the
open
room
for
people
to
make
scope
changes.
For
example,
there
has
been
some
discussion
about.
Can
we
have
a
specific
instrument
for
for
mattering
duration
so
that
that
might
be
something
we
could
consider,
but
after
feature
freeze,
we're
saying
we're
not
going
to
change
the
scope
so
anything
that
we
think
is
important.
B
We
can
only
make
that
as
additive
change
after
we
release
stable,
because
we
want
to
focus
on
getting
the
stability
release
so
so
the
future
freeze
is
is
going
to
happen
like
very
quickly
and
and
after
that
there
will
be
only
bug
fixes.
So
if
something
like
notice,
the
spike
has
a
has
a
conflict
with
itself
or
there's
some
like
typo
there's
a
like
wording,
change
editorial
change.
These
are
the
only
thing
we're
going
to
change.
B
Otherwise,
the
wall
will
just
release
the
spike
is
and
for
the
sdk
part,
currently
we're
we're
having
some
delays.
Originally,
we
plan
to
release
the
experimental
version
by
end
of
june
and
now
we're
already
in
july.
I
I
figure
the
the
the
biggest
blocker
here
is
like
we
were
making
slow
progress
on
the
pr
just
because
some
sometimes
like.
If
you
look
at
the
view,
it's
a
little
bit
big
and-
and
here
we
all
try
to
be
perfect.
B
So
we're
trying
to
answer
all
the
questions
and
and
people
are
very
kind,
so
they
don't
give
a
specific
idea.
This
can
work,
or
this
wouldn't
work.
They
would
say
this
wouldn't
work
and
if
they
fix
that
it
seems
to
be
working,
but
they
might
have
some
other
concerns,
so
they
don't
give
you
a
thumb
up.
This
is
where
we
got
stuck,
so
I'm
I'm
trying
to
push
people
to
be
more
explicit,
so
we
can
move
faster,
but
it's
hard
because
this
is
open
source
community.
B
So
hopefully
I
I
can.
I
can
make
us
like
moving
faster
by
clarifying
the
scope.
B
Okay,
if
the
pr
is
stuck
and
the
other
scope
down
instead
of
trying
to
make
it
even
bigger,
and
once
we
have
view-
I
I
think,
there's
one
pending
thing:
we
haven't
yet
yet
figured
out
in
the
api
I
want
to
cover
before
we
reach
feature
freeze,
which
is
the
hint
the
hint
api
is
going
to
be
used
by
the
library
author
to
give
people
some
information
like
they
might
give
hint
about.
Hey
histogram
can
do
this
or
not,
and
I
believe
this
is
nice
to
have,
but
in
case
we're
running
out
of
time.
B
B
B
Like
default,
yeah
yeah,
it's
giving
you
the
default
option.
The
ultimate
control
is
at
the
user
side
when
they
define
the
view.
So
if
we
have
view
then
for
hint
is
it's
much
easier
for
people
to
understand
and
we
failed
on
the
view.
Then
there's
no
point
to
introduce
hint.
So
I
I
wouldn't
want
to
push
and
hint
unless
we
have,
the
view
in
place
makes
sense,
cool.