►
From YouTube: 2021-11-12 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
A
B
B
F
A
So
we
didn't
have
much
to
chat
about,
but
we
did
chat
still.
I
know
that
josh
was
hoping
to
join
the
chat
about
metrics
with
you
underage
and
jack,
so
we'll
see
we
can
kind
of
tuck,
so
he
wanted
to
create
sort
of.
A
He
wanted
to
start
mapping
out
the
future
next
couple
releases-
symmetricals,
oh
yeah
and
james,
and
so
I
think
he
was
going
to
create
a
project
we
kind
of
discussed,
because
I
asked
because
I
had
struggled
with
this
in
the
instrumentation
repo,
whether
to
create
a
project
or
milestones,
and
I
thought
this
made
sense
in
my
brain
at
least:
was
projects
for
thing
milestones
for
releases
and
projects
for
anything
else.
Basically,.
G
H
G
A
Oh
yeah,
some
discussion
about
api
when
we
can
mark
the
api,
stable
and
josh
was
concerned
that
if
they
want
to
be
at
a
place
where
the
sdk,
I
think
is
close
enough,
that
there
wouldn't
be
concern
that
changes
to
the
sdk
could
impact.
How
we
want
the
api
to
look.
B
He
thinks
we're
not
quite
there
yet
but
close.
So
what
we
talked
about
this
morning
was
1.10
would
be
our
target
for
api
stability
for
taking
the
api
out
of
out
of
alpha,
and
hopefully
the
sdk
also,
but
it's
possible
that
might
stretch
out
until
it
would
be
better
if
josh
were
here
to
talk
about
his
feelings.
D
G
Sorry
jeff,
I
was
just
going
to
say
that
so
I
think.net
and
java
are
pretty
far
along.
I
don't
know
what
the
status
of
python
is,
but
if,
if
they're
really
going
to
abide
by
the
three
prototypes
kind
of
rule
or
recommendation,
then
you
know
you
kind
of
need
that
third
prototype
before
you
can
really
feel
confident
that
the
sdk
can
stabilize
or
be
marked
as
stable.
B
That
is
also
that
is
fair.
I
also
wonder
about
the
exponential
histograms
and
whether
they're
going
to
be
a
requirement
for
like
a
stable
release
or
not,
but
I
don't.
I
don't
know
whether
that's
in
the
plan
or
not,
but
I
think
the
api
like
we
got
the
api
we
haven't
touched
now
for
a
couple
releases
and
electrics.
B
B
Because
we
use
it
for
we
use
metrics
right
now.
We
grab
the
global
to
make
recordings
about
the
batch
stand
processor
and
I
think
the
exporters
also
create
some
metrics.
D
I
was
thinking
that
we
might
need
to
rework
the
sdk
builder
to
accept
factories
instead
of
components
so
that
they
can
then
have
those
things
injected
in
so
one
thing
that
wants
to
be
injected
a
resource.
I
think
josh,
like
I've,
always
had
the
sampler
use
case,
and
I
think
josh
came
up
with
the
use
case
also
in
one
recent
pr
and
then
that
spam
processor
probably
also
has
it
for
the
meter
provider,
so
this
might
be
happening
soon
now,
yeah
yeah.
B
A
Yeah
is
that
for
laziness
or
what's
the
need
for.
D
D
G
A
B
Your
side
of
the
bargain
is
not
not
yet.
D
B
B
B
F
Yeah,
it's
still
not
it's
still
not
a
publicly
callable
api,
it's
just
the
aggregator
and
the
metric
data
there
I
still
need.
The
exporter
still
needs
to
be
written
for
it.
The
there
and
there's
I've
also
created
a
couple
tickets
for
various
optimizations
for
it,
which
would
help
it
be
brought
out
of
being
a
prototype
into
the
actual
thing.
It's
just
the
reason
it's
a
prototype
now
is
because
there's
a
couple
of
things
that
just
need
to
be
tuned
and
optimized,
and
then
I
think
it
it
would
be
more
ready.
D
B
B
Well,
it
means
it's
the
java
the
spring
folks
will
be
very
comfortable
with
it.
Well,
this
is
still
in
auto,
configure
right.
B
B
B
D
B
D
The
method
name
is
actually
bad,
that's
true
or
is
it
dead?
I
don't
know.
D
E
A
B
So
return,
this
is
the
sbi
provider,
though
right
so
it's.
This
is
the
spi
interface
that
you
implement
and
then
we
grab
it.
Basically,
it
provides
it
to
the
spi
subsystem
right,
like
all
the
provider,
all
the
methods
in
our
sbrs.
G
Do
y'all
have
any
thoughts
about
the
package
that
this
lives
in
not
the
provider,
but
the
customizer
itself,
you
know:
do
you
have
any
issue
with
that
living
in
the
dspi
package,
alongside
other
providers.
D
G
It's
a
consumer
consumer.
There
you
go,
which
is
would
be
except
if
the
method
name
would
be,
except
if
we
wanted
to
follow
that
pattern.
D
But
so
I
feel
provider
at
least
it
provides
a
hint
that
this
is
a
class
people
implement
to
have
their
spi
loaded,
because
I
think
all
of
our
spies
currently
have
the
word
provider
at
the
end,
so
at
least
that
hint
is
sort
of
consistent,
even
if
the
meaning
of
the
word
provider
isn't
the
same.
In
this
case,
it's
still
sort
of
this
is
what
you
implement
to
do
spi,
and
I
think
I
like
that.
B
B
D
D
D
D
E
G
So
if
someone
has
okay
http
and
has
like
a
version
conflict,
there
could
be
an
issue
there,
but
they're
they're
welcome
to
bring
continue
to
bring
their
own
grpc
implementation,
and
everything
should
work.
D
B
B
H
D
D
D
B
D
B
D
D
D
A
B
D
B
D
And
then
we
could
also
have
examples
and
docs
on
that.
I
guess
yeah.
I
forgot
it's
less
about
the
docs
more
about
the
examples
where
I
was
hoping.
We
had
a
consistent
story
across
the
job
agent
and
on
job
agent,
examples
which
we
don't
have
right
now.
Yeah
the
example
may
be
different
yeah,
that's
a
that's
a
different,
so
I
thought
maybe
we
could
have
the
docs
and
examples
and
that
republican.
D
I
mean
it's
mostly
on
myself,
and
maybe
also
john,
but
probably
java
has
the
worst
docs
out
of
all
these
languages.
I've
gone
through
the
site
so
far
like
I've
been
doing
the
auto
instrumentation,
so
I've
actually
looked
through
gold,
python,
ruby
javascript,
and
it
was
surprised
that
their
docs
are
pretty
decent.
B
G
So
when
I
was
when
I
was
learning
groovy
a
while
back,
I
went
to
the
groovy
docs
and
I
was
impressed
that
their
docs
referenced
like
code
examples.
So,
like
you
know
they
had
like
working
code
intertwined
with
text
like
markdown
and
that
that
pretty
much
guarantees
you
that
your
code
is
always
functional
in
there
is
there
any
strategy
we
could
take
to
get
to
that,
because
I
think
that's
that's
the
problem
that
we
want
to
avoid.
Is
that
the
inevitable
drift
between
what
the
docs
say
and
what
actually
works.
B
Yeah,
if
you
have
a
good
idea
on
how
to
do
that,
I'm
all
ears.
What
what
you
so
I'll
tell
you
what
I've
done
jack
is.
I
actually
have
a
non-checked
in
file
with
all
of
the
code
in
the
in
the
docs
in
one
giant
file
that
I
make
sure
still
compiles
in
every
release
just
sitting
in
the
project,
but
that's
not
a
great
way
to
manage
it.
D
D
G
D
B
D
D
I
think,
having
docs
and
examples
together
would
probably
be
easier
for
us
to
deal
with.
I
don't
know,
maybe
not,
but
then,
like
any
time
you
update
a
doc.
We
can
also
update
an
example
like
we
can
have
that
sort
of
policy.
I
think
if
we
have
the
docs
and
examples
completely
separate,
maybe
it's
a
bit
harder
to
keep
those
two
up
to
date.
D
Also,
link
yeah
exactly
so.
Those
are
the
advantages
I
see
of
having
them
both
in
the
same
repo.
So
if
we
all
okay,
so
I
think
then
the
next
action
item
I
can
put
in
the
community
request.
I
got
us
a
repo
for
open,
telemetry,
hyphen
java,
I'll
still
call
it
docs
and
I
can
have
examples
inside
it.
That
makes
sense
right.
A
G
Cool
has
this
come
up
with
any
of
the
other,
like
in
the
maintainers
meeting
with
any
of
the
other
languages,
because
I
imagine
ever
they're
all
going
to
run
into
a
similar
issue
right
with
the
decoupling
of
the
the
sdk
and
their
instrumentation.
B
A
Yeah,
I
also
think
that
other
languages
are
have
been
more
focused
on
the
sdk
api
stuff,
but
our
I
would
expect
more
of
that
discussion
to
come
up
because
there
is
a
lot
more
instrumentation
getting
built
out
now.
A
Hey
that
kicks
us
over
the
the
morty
meeting
size.
This
is
definitely
a
first.
A
Oh,
the
last
thing
on
the
the
website
talks,
so
roberto
had
joined
and
he's
taking
over
from
ken
at
red
hat
ken
has
moved
to
work
day,
and
so
he
was
kind
of
going
through
this
doc
and
that's
why
the
topic
came
up,
and
so
we
were
talking
about
whether
he
should
be
using
whether
in
general
we
should
be
promoting
the
instrumentation
api
in
our
docs
more
and
not
really
promoting
the
api
tracing
metrics
direct
api.
A
E
A
He
had
really
good
things
to
say
about
the
instrumenter
api.
He
just
thought
it
was
really
confusing
because
it
wasn't
located
like
it
was
often
the
instrumentation
repo
and
like.
Why
is
it
a
api,
but
once
he
started
using
it,
he
really.
He
said
it
made.
It
really
easy
to
know
what
to
capture,
which
was
a
big
point.
D
A
D
A
A
Cool
josh,
we
chatted
about
metrics,
but
I
know
people
would
love
to
hear
from
you
directly
sort
of,
I
think,
primarily
the
path
to
like
your
thoughts
on
path
to
stability.
J
Yes,
yeah
so
in
terms
of
marking
the
sdks
table,
I
think
basically,
once
I
had
some
discussions
with
cjo
and
once
dotnet
and
python
have
working
prototypes
or
javascript
might
beat
them
to
it.
We'll
see,
I
will
be
more
comfortable
marking
that
as
stable.
Specifically,
I
I'd
like
it
if
someone
else
implemented
exemplars
besides
me,
since
I
wrote
a
lot
of
that
spec,
I
just
want
to
make
sure
that
it's
readable,
I
don't
expect
any
of
the
actual
must
to
change
in
the
spec.
A
Cool
and
then
for
did
you
have
a
claps
on
one
on
the
next
kind
of
two
releases,
one
or
two
releases
which
you
wanted
to
target
yeah
like
like
what
I
would
like
to
do
or
I
or
what
you
would
like
to
see
the
the
repo
do.
J
Well,
yeah,
so
there's
what
I'd
like
to
see
and
then
what
I'm
willing
to
help
with
I'm
not.
I
don't
want
to
ask
for
anything
unless
I'm
willing
to
put
my
own
work
behind
it
if
that
makes
sense,
but
if,
if
like,
we
as
a
group
are
like
commit
to
things,
that's
awesome
like
I'd
love
to
see
metrics
be
stable
right
now,
that's
not
realistic!
So
yeah,
I
think
a
realistic
goal,
1.10
being
api
stability,
1.11
being
we
so
1.10
kind
of
being
a
preview
stability
of
the
sdk
as
well.
J
Like
I
I'd
love
to
as
of
1.10,
we
we
are
comfortable,
saying
you
know
what
we're
we
don't
think
anything
significant
will
change,
but
we're
also
not
going
to
lock
anything
down
because
we
need
more
usage
and
bug
fixes
and
that
sort
of
thing
I'd
love.
J
If
we
could,
we
could
have
a
few
releases
of
that
before
we
go
stable,
if
that
makes
sense
so
like,
if
we
as
a
group
say,
as
of
1.10,
we're
going
to
start
treating
the
metrics
sdk
as
if
it's
stable,
even
though
it's
not
and
then
give
ourselves
a
few
releases
to
work
out.
Kinks
and
bugs.
D
We've
used
the
labeling
release
candidate
for
that
sort
of
concept
when
we
were
leading
up
to
tracing
stable
stability
like
it
was
still
marked
hyphen
alpha.
But
this
is
the
release
candidate.
We
don't
expect
to
make
any
significant
changes.
We
call
that,
under
the
release
notes,
we
can
do
something
similar
here.
Yeah.
J
The
only
the
only
question
in
my
mind
around
releasing
just
just
to
throw
it
out
there
is,
I
think,
1.10
should
be
getting
sdk
stability
features
in
place
that
we're
nervous
about.
If
there's
anything
that
we
think
is
it
gonna
take
more
than
a
week
then.
Well,
let's
push
that
to
one
down
eleven,
but
a
week
of
like
an
individual's
work.
J
The
exporters,
though
the
spec
for
prometheus,
is
really
not
done,
and
I
really
don't
think
we
can
launch
a
like
tell
people
to
adopt
open
telemetry
metrics
unless
we
have
a
really
consistent,
prometheus
exporter
spec
in
the
story.
So
I
expect
the
remaining
metric.
Sig
focus
is
going
to
be
on
getting
the
prometheus
spec
kind
of
up
to
speed.
J
I
missed
all
discussions
tonight
because
it's
thursday
nights
are
really
bad
for
me,
with
the
kids
and
with
you
know,
family
things,
unless
it's
a
really
late
meeting
like
this
one
for
me.
So
I'm
curious.
If
anyone
went
to
that,
if
they
know
like
what
the
status
is
on
the
prometheus
exporter
discussions,
that
happened.
Nothing,
that's
not
what
I
wanted
to
hear
jack.
Tell
me
don't
tell
me
okay,
but
do
tell
me
what
did
they
talk
about
this?
This
thursday.
J
Man-
okay,
all
right,
so
there
were
probably
a
bunch
of
discussions
that
were
that
were
meant
to
happen
around
prometheus
that
I
need
to
follow
up
on
when
I
have
a
chance
to
look
through
the
notes,
but
the
the
only
mandatory
exporters
that
we
have
are
otlp
and
prometheus.
J
I
think
the
stuff
that
jack's
been
doing
in
otlp
bring
us
in
line
with,
what's
going
to
be
in
the
specification
there
and
that's
coming
out
in
this
release,
so
I
think
at
this
point
we
just
need
to
do
all
the
polish
features
that
we
need
and
make
sure
that
what
we're
exposing
is
actually
clean
and,
as
you
know,
I'm
terrible
at
spelling-
and
I
don't
have
a
good
spell
checker,
so
I
apologize
for
all
of
that.
So
josh,
you
know.
J
J
J
One
of
them
yeah
did
you.
Did
you
see
I
I
I
created
a
project
that
has
so
it
might
be
worth
going
through
those
issues
and
like
putting
some
of
them
to
rest
and
then
figuring
out
if
it's
the
right
set
of
issues
like
if
we
have
time
for
that
discussion,
we
have
what
20
minutes.
Maybe
I'd
love
love
it.
If
we
could
do
that,
yeah
the.
J
Yeah
it
does
like,
I
think
it
would
be
okay
if
we
violated
that,
under
the
assumption
that
we
had
a
good
reason
and
that
it
was
clear
to
users
what
the
hell
we're
doing,
but
because,
for
example,
the
builder
pattern
we're
using
kind
of
is
different
than
the
way
it's
specified,
but
it
abides
by
the
spirited
spec.
So
if
you
have
a
good
proposal
around
that,
I
think
that's
that's
a
reasonable
thing
for
us
to
to
entertain
and
probably
not
super
hard
to
do.
J
D
D
Okay.
That
was
just
an
idea,
like
maybe
that's
possible,
but
we
didn't
really
try
it.
So
it's
probably
too
late
to
try
it
now.
J
It's
actually
the
the
main
problem
is
not
necessarily
the
it's
not
an
api
issue.
It's
like
a
semantics
of
the
recording
issue.
J
Yeah
just
so
you
know,
post
1.0
of
metrics
we're
going
to
probably
look
at
handling
this
thing
called
gage
histogram
at
some
point
you
might
have
seen
it
in
open
census.
J
J
Yeah,
I
think
it's
going
to
be
critical
for
how
we
handle
jfr.
I
think
it
actually
makes
a
hell
of
a
lot
of
sense
for
jfr
to
use
it.
I
well
yeah
anyway.
Well,
there's
a
there's,
a
really
big,
long
discussion
that
needs
to
happen
around
like
the
metrics
data
model
for
that
sucker,
because,
right
now,
all
of
those
will
probably
get
reported
as
oh
there's
a
bunch
of
metrics
that
will
come
out
as
histograms
that
I'm
not
sure
that's
the
right
solution
in
the
long
run,
but.
C
C
C
J
J
It
might
be
better
for
us
to
actually
kind
of
record
like
a
gaugey
histogram
thing
for
some
of
those,
some
of
them
it
doesn't
make
any
sense
and
some
of
them
we
want
a
synchronous
gauge
for
that's
the
other
thing
that
is
possibly
post
1.0.
We
got
rid
of
synchronous
gauge.
B
Cool
you
know
you:
can
you
can
hack
the
synchronous
gauge
with
a
view
right
now
right,
yeah,
yeah
yeah,
because
you
can
just
have
a
have
a
histogram
with
a
last
value,
aggregation.
J
On
it
right,
except
you,
if
you
want
a
synchronous
gauge
hack
today,
you
have
to
use
up
down
counter
and
that's
just
really
freaking
weird
can't
you
do
it
on
a
can't.
You
do
it
on
a
instagram
instrument.
Oh
yeah,
you
could
do
it
on
histogram
instrument.
Yeah,
that's
true,
my
bad!
That
single
bucket
hack,
oh
crap,
crap
crap,
that's
the
other
thing!
Sorry!
We
we
want
to
have
histograms
that
allow
negative
measurements
yeah.
E
J
No
you,
if
you
have
any
negative
measurement
in
your
gauge,
you
have
to
use
up
down
counter.
You
can't
use
it
fair
enough
yeah,
so
we
also
want
histograms
with
negative
measurements,
like
there's,
there's
a
few
like
weird
wonky
things
that
we
basically
compromise
to
make
sure
we're
fully
compatible
with
prometheus,
and
we
think
it's
valuable,
especially
since
we
allow
delta
metrics
to
allow
some
of
these
weird
scenarios
in
in
things
that
aren't
just
gauges
that
get
pulled
you
know,
but
that
so
that's
coming,
postmetrics
1.0
anything
around
there.
J
If
you've
run
into
issues,
probably
we
should
just
have
them
open.
We
know
that
their
problems
and
we
need
to
like
feed
on
the
spec
or
we
have
to
come
up
with
workarounds
I'll,
do
my
best
to
help
out
with
each
one
of
those
there,
because
we've
already
had
the
the
whole
batch
recording
thing
like
the
fact
that
we
lost
that
api
really
kind
of
hurts,
and
I
think
users
are
keep
asking
for
a
way
to
do
batch
recording.
J
If
we
had
this
notion
of
a
synchronous
gauge,
it
might
not
be
an
issue
at
all,
but
anyway
that's
a
different
story.
Okay,
so
that's
all
post
1.0
stuff!
If
we
go
back
to
the
project.
Well,
there's
there's
like
three
issues
to
talk
about
real
quick.
Let
me
pull
him
up
here.
I'm
on
the
wrong
computer.
A
J
J
Effectively,
what
he's
complaining
about
is
the
current
implementation.
Global
media
provider
doesn't
force
open
telemetry
to
instantiate,
so
he
was
calling
get
meter
and
getting
a
no
op
meter
provider.
It
also
could
be
a
complaint
about
how
auto
instrument
auto
configure
works,
not
positive,
but
effectively.
This
is.
He
was
confused
when
global
meter
provider
gave
him
a
no-op
meter
and
then
never
got
replaced
with
a
meter
later.
J
I
think
when
we
remove
global
meter
provider
and
use
the
open,
telemetry
global,
the
same
problem
that
he's
describing
here
what
happened
in
trace,
which
is
basically,
if
I'm
not
using
auto,
configure,
then
global
meter
provider.
You
have
a
race
condition
where,
if
I
don't
instantiate
my
global
open
telemetry
prior
to
someone
trying
to
access
it
in
my
class
loading
path,
I
can
run
into
getting
no
op
tracers
and
no
op
meters.
J
So
I
think
it's
the
same
issue
we
already
have
today
and
I
think
we
should
solve
it
in
whatever
means
we're
doing
in
trace,
which
is,
I
personally
think
we
just
push
on
auto
configure.
I
I
love
that
thing.
I
think
it's
really
good
for
users
yeah,
so.
D
Once
we
merge
this
into
the
global
pin,
telemetry
like
it'll
just
naturally
be
auto
configured
automatically
as
well.
So
I
think
that'll
become
better
yeah.
We
just
don't
have
like
right
now
when
you
call
global
until
it
doesn't
get
it
automatically
runs
auto
configure
the
same
doesn't
happen
for
google
meter.
So
that's
the
only
difference.
I
think.
J
B
B
Before
any
other
class
is
imported,
our
main
documentation
needs
to
be
don't
use
the
global.
Unless
you
have
a
really
really
strong
compelling
case
to
use
the
global
like
the
global.
Is
there
purely
for
the?
We
don't
have
any
other
way
to
deal
with
that
case
rather
than
the
the
like
you
the
way
you're
supposed
to
do
it
normally.
B
So
then
we
should
stop
using
it
in
our
own
tracers.
Well,
we
as
soon
as
we
we
definitely
we
talked
about
this
before
you
got
here.
J
B
J
That's
awesome:
okay,
beautiful
I'm
happy
to
push
on
that
bug
in
this
way
and
basically
use
this
as
a
proxy
to
fixing
global,
but
it
might
be
worth
it
to
take
what
you
talked
about
and
put
that
in
a
bug
as
well.
So
that's
this
one!
This
one
has
to
get
done
absolutely
and
I
think
this
one
should
be
in
the
net.
The
1.10
release.
B
B
D
J
B
J
For
for
global
meter,
could
we
just
have
it
call
global,
open,
telemetry
and
mark
it
as
deprecated?
Is
that
like
realistic
to
do
because
we
need
to
add
the
gut
meter.
D
G
B
E
D
I
mean
even
assuming
that's
not
a
problem
like
so
what
we
need
is
to
get
meter
provider
to
open
telemetry
like
even
related
to
global's.
That's
the
only
way
to
be
able
to
access
the
meter
provided
through
a
normal
api,
and
I
don't
think
we
can
have
that
interface
and,
like
it
just
wouldn't
compile.
I
think
yeah.
D
J
J
B
I
I
J
G
D
G
B
D
I
don't
think
it's
required,
but
still
even
not
even
really
to
the
deprecation
like
having
a
couple
of
releases
of
buffer
like
these
rc's
like
we're
gonna.
Have
this
new
api.
I
think
that's
what
I'm
more
concerned
with
the
get
meter
provider
on
the
open,
telemetry
object
itself,
so
having
a
couple
of
releases
to
bake.
That
would
be
nice.
I
think
that's
my
main
objective
for
this
rc,
not
necessarily
the
defecation
yeah.
J
D
E
J
So,
first
off
who's
going
to
consume
them
and
give
you
feedback.
Do
we
know
of
people
who
will
do
that
outside
of
ourselves?
Because
if
it's
just
like
the
like
making
an
instrumentation
agent
running
it
through
the
bringer
and
like
people
hear,
then
the
release
cadence
only
matters
to
people
here,
because
we're
just
delivering
it
to
ourselves.
J
If
we
have
a
community
of
people
who
actually
try
out
rc's
and
look
at
them
and
we
think
we're
going
to
get
valuable
feedback,
then
you
want
to
give
them
time
it's
just
based
on
their
schedule
like
if
you
think,
they'll
give
you
good
feedback
in
two
weeks.
Go
for
it,
but
otherwise,
leaving
out
there
longer
is
just
more
of
a
liability
than
anything
else.
F
We're
using
metrics
just
kind
of
a
little
bit
just
preliminary.
F
You
know
for
things
that
don't
matter
too
much
if
it
breaks
you
know
yeah,
I'm
just
I'm
actually
just
looking
at
that
code
now
and
that
might
that
probably
would
break
our
code.
I
think
we
do
use
the
global
media
provider,
but
I
think
it's
it
would
be
an
easy
change.
Just
to
you
know,
put
that
into
the
the
open
telemetry
like
object,
yeah.
F
F
B
J
D
My
vector
of
the
hand
just
guessed
was
that
around
two
weeks,
just
based
on
random
feeling
and
like
one
one
to
two
like
depending
on
the.
If,
if
someone
finds
some
problems
with,
you,
do
a
second
release
candidate
and
then
hopefully
that's
it
and
then
the
release,
like
that's
just
sort
of
a
random
guess
of
what
we
might
have
done.
We
might
do.
J
Yeah,
I
think
two
weeks
is
pretty
good
we're
out
of
time.
I
wanna,
but
there's
two
things
to
call
out
then
number
one:
the
concern
around
long
counter
long
up
down
counter.
Are
we
just
going
to
mark
that
as
closed
won't
fix?
Okay?
Second,
oh
just
like
closer
you'll
close
it.
The
second
run
around
removing
of
longs
from
double
counter
builder.
I
threw
it
in
there
just
for
consistency.
You
know
like
whatever
doesn't
matter.
If
you
want
to
remove
it,
remove
it.
J
If
you
want
to
keep
it,
keep
it,
I
I
have
no
skin
in
that
game,
so
I
don't
think
it's
it's
it's
part
of
the
spec
at
all.
It
doesn't
matter
it's
up
to
it's
up
to
us.
So
if
we
want
to
remove
it
totally
fine,
but
we
definitely
should
do
it
before
we
mark
the
api's
table.
B
A
D
E
E
J
So
I
think
it's
totally
reasonable
to
remove
it.
So,
let's
get
that
in
for
1.10,
not
next
release,
1.10
right
and
cool
cool,
that's
the
other
one
actually
is
something
that
jack
raised.
That
I
also
think
needs
to
get
in,
and
I
the
the
question
here
is:
is
that
something
that
you're
planning
to
work
on
jack?
The
you
you
brought
this
up
in
chat
and
opened
a
bug
for
it.
The
consistent
behavior.
G
Yeah,
I
can
totally
work
on
it
awesome.
I
I
had
a
we
can
talk
about
it
offline,
but
yeah.
I
can.
I
can
figure
this
out.
J
Cool,
I
think
that's
it
for
the
api,
then,
in
terms
of
stuff
that
we
know
about.
Unless
we
have
other
things,
we
want
to
open.
I
B
A
H
No,
I
think
it's
been
sounds
like
this.
Spawn
team
has
some
project
they're
working
on
yeah.