►
From YouTube: 2022-04-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
A
Calendar
is
missing
today's
meeting.
There
is
nothing
for
four
o'clock
for
dot
net.
It
shows
a
different
one,
but
it
looks
like
it's
a
temporary
ratio
because
I
can
see
it
for
the
week
after
next
on
4
pm.
So
yeah
I
don't
know,
I
don't
have
access
to
fix
the
calendar.
So
since
everyone
is
already
here,
we
just
like
do
this
ad
hoc
thing.
A
A
A
It
looks
like
we
have
few
items,
so
we
can
get
started
start
with
the
release
plan.
So
go
to
my
installs
first
installs
1.2.
A
We
have
just
two
items
left
closed,
pretty
much
everything
else.
A
I'm
still
doing
the
public
api
review
and
I
found
like
one
item
which
I
just
sent
apr
like
one
two
minutes
back,
we'll
go
over
it
in
a
moment,
but
that
I
said
then
we
have
a
pr
which
is
addressing
the
inventory
exporter,
but
that
I
said
there
is
nothing
preventing
the
sdk
from
going
stable.
So
I
will
do
a
release
candidate
after
the
today's
meeting.
It
will
be
like
a
little
later,
but
sometime
today,
itself
call
it
like
release
candidate,
six
or
whatever
is
a
number
before
and
then
yeah.
A
A
I
want
to
hear
from
at
least
someone
who
has
authored
a
exporter
because
we
just
broke
the
exporters
with
the
like
the
coming
release,
so
just
want
to
make
sure
like
they
are
good
with
that
change.
So
that's
why
we
need
like
at
least
two
days
to
make
sure
like
things
are
still
working
there
weren't
any
api
changes
since
the
last
one.
A
So
not
like
too
worried
about
that
part
apart
from
the
exporter
side
of
things,
and
we
also
address
the
metric
view
thing,
but
that's
like
a
really
really
corner
case,
so
I
don't
really
expect
that
to
be
a
major
issue.
As
of
now
soil
market.
Does
I
mean
that's
the
release
flag
here
to
the
top
of
the
agenda.
A
So
there
are
two
things
which
we
want
to
call
out:
one
is
prometheus.
Exporter
will
be
like
left
out,
and
then
there
is
the
in
memory
exporter.
So
we
discussed
this
last
week.
There
is
an
open
pr,
so
I'll
see
if
we
can
get
it
merged
today.
If
not,
we
can
keep
in
memory
exporters
just
like
the
prometheus
for
in
rc
state
for
one
more
week
or
whenever
we
are
ready.
A
Prometheus
is
quite
likely
not
just
one
week,
because
spec
are
still
specs
are
still
being
flushed
out,
so
I
think
it
will
be
like
a
while
before
it
becomes
stable,
but
in
memory
it's
like
really
in
our
hands.
So
if
we
don't
finish
this
today
should
not
block
the
overall
sdk.
We
can
still
release
and
then
fix
in
memory
and
make
it
stable
whenever
it's
ready
and
yeah
no
change
with
the
instrumentations.
A
They
remain
fully
candidate
unstable
until
semantic
conventions
are
stable,
so
that
this,
what
we
just
discussed
is
almost
correctly
reflected
here,
because
we
have
put
april
15
as
the
due
date,
which
would
be
correct.
If
we
do
the
release
on
friday
worst
case,
we
can
do
it
on
monday.
In
case
we
want
to
get
because
I
know
like
two
at
least
two
export
all
this
one
is
within
microsoft.
So
I
how
I
could
control.
I
can
go
ahead
and
fix
it
myself.
A
Then
dynatrix
also
has
use
the
thing
which
we
just
removed,
so
I
already
think
joe
from
planetrace.
So
if
you
don't
hear
from
them
in
like
two
or
three
days,
then
we
should
be
able
to
move
forward,
but
the
dynamic
dynamics.
Exporter
is
anyway
beta1,
so
shouldn't
be
a
big
deal,
but
just
out
of
courtesy,
we
are
like
actively
reaching
out
to
them.
A
Okay,
so
alan
has
put
this
thing
and
it
says
we
can
ignore
it.
Oh
no.
C
I,
for
whatever
reason
I
hadn't
quite
this
hadn't
quite
occurred
to
me.
It
was
it
struck
me
as
odd
one
day.
I
almost
always
add
the
using
open
telemetry.metrics
at
the
top
of
my
file.
Just
it's
like
a
reflex
at
this
point,
but
I
didn't
this
one
time
and
then
I
was
like
trying
to
figure
out
where
the
build
method
on
the
on
the
meter
provider
bill.
There
was-
and
I
was
like-
why
is.
A
This
is
right
here
you
need
both
like.
If
you
use
the
force,
then
you
need
one
more
if
we
had
like
some
discussions,
while
the
tracing
was
being
released,
but
we
settled
with
this
so
now
we
have
to
leave
it.
C
A
This
upcoming
account
counter
support.
So
let
me
open
this
one,
so
I
haven't
checked
the
net
builds
recently,
so
I
I'm
assuming
it's
already
part
of
the
like
first
preview
or
alpha.
What
whatever
is
the
thing
which
stockton
has?
It
should
already
be
part
of
it,
so
we
could
start
playing
with
it.
Maybe
like
we
can
wait
like
three
more
days
and
then
actually
take
the
new
bits
in.
A
We
will
discuss
like
how
we
handle
that.
Maybe
we
need
to
keep
that
temporarily
in
a
different
branch,
because
if
you
take
a
dependency
on
dot
net
seven,
then
we
cannot
do
another
stable
under
number,
so
we
may
want
to
like
keep
it
unmerged
or
keep
it
in
a
separate
branch,
because
there
is
a
good
chance
that
we
want
to
do
another
staple
between
now
and
number.
C
A
A
Need
to
mention
anything
about
the
the
up
down
counter
will
only
complicate
the
monotonicity
aspect,
which
is
not
captured
in
the
metric
type,
or
I
think
it
would
be
captured
similar
to
the
temporality,
which
I
believe
is
on
the
metric
class.
Let's
quickly
check
yes,
so
right
now,
this
is
on
the
metric
class,
because
every
metric
point
within
this
metric
will
have
the
same
temporality
so
think
that
would
apply
for
monotonicity
as
well,
so
we'll
having.
A
We
can
add
a
new
thing
on
to
the
matrix
which
explains
or
which
adds
the
is
monotonic
true,
a
false,
so
that
we
don't
really
need
to
touch
this,
and
we
don't
need
to
yeah,
because
this
one
we
still
need
to
expand
it
when
we
add
the
main
max
support
for
histogram
and
when
we
add
exponential
histogram,
so
we
have
it
reserved,
so
I
think
a
line
like
my
answer
would
be
like
we
can
add
it
to
the
metric
class
itself.
A
All
we
need
is
just
the
monotone
acidity.
That's
it!
We
don't
really
need
anything
else,
because
aggregation
is
still
some,
so
it
could
fall
in
either
of
this,
even
with
up
down
counter
whether
it's
monotonic
or
not,
will
be
determined
by
like
the
to
be
added
property
here.
So
it
should
be
like
additive
change
right
here.
C
Yeah
yeah,
I
think
that
makes
sense
yeah.
I
was
looking
at
this
from
the
standpoint
of
the
otlp
exporter
and
just
noted
that
it
basically
has
like
a
big
switch
block
that
based
off
of
metric
type
and
right
now
is
monotonic.
It's
just
hard
coded,
it's
true,
but
yeah
you're
right.
If
there's,
if
the
metric
had
a
notion
of
monotonicity,
it's
very
similar.
A
A
I
really
don't
know
whether
we
should
be
doing
because
no
I'm
trying
to
look
like
one
is
like
you'll,
be
like
spending
cpu
cycle
just
to
do
the
validation,
it's
like
very
negligible,
but
still
it's
hard
work,
we're
trying
to
be
like
as
minimal
as
possible
in
terms
of
overhead,
but
the
real
reason
why
I
like
abandoned
my
previous
item,
was
we
don't
really
have
a
good
way
of
dealing
with
overflows
because
the
negatives
could
be
coming
because
of
the
overflow.
A
A
B
A
Because
it
would
be
like
this
is
like
really
hot
path
like
we
cannot
do
anything
upfront.
We
have
to
check
the
every
apa
call
to
check
the
value,
so
that
would
be
like
very
expensive
number.
One
like
expensive
number
two
is
like:
we
don't
know
whether
the
value
is
negative
because
of
overflow
or
whether
it
was
like
accidentally
negative,
because
even
today
the
back
ends
have
to
deal
with
that
part
right,
because
we
are
going
to
do
the
addition
here
still
sharing
right
here.
A
A
I
don't
know
whether,
like
every
x,
I
mean
every
backend
has
such
capabilities,
but
yeah.
This
was
one
of
the
reason
why
I
mean
without
knowing
like
what
do
we
do
with
the
overflow
in
the
actual
metric
stream?
We
don't
really
know
what
we
want
to
do
in
the
incoming
measurements,
so
it
was
the
reason
why
he
said.
Okay.
This
is
something
which
requires
a
better
discussion.
So
we'll
come
back
to
it.
I
haven't
really
ruled
out
the
fact
that
we'll
never
do
it.
A
We
may
do
it
if
it
makes
sense,
but
as
of
now,
I
don't
think
it
should
be
a
like,
like
a
blocker
for
the
release,
have
you
actually
encountered
like
I
mean?
Have
you
actually
seen
any
customer
reporting
issue
with
the
output
of
the
metric
stream
or
flowing
with
and
or
going
to
negative.
A
B
C
Talking
with
jack,
who
I
work
with,
who
works
on
the
java
api
or
sdk,
I
mean,
and
he
does
do
checks
there,
though
I
didn't
ask
him
about
overflow.
So
I'm
curious
what
he
has
to
say
about
that,
but
I
agree.
I
don't
think
that
it
needs
to
be
a
blocker.
I
just.
I
just
think
that.
A
We
have
the
issue
open
here,
like
I
remember
like
creating
this
issue,
and
I
put
a
tag
and
a
comment
saying
why
we
are
not
immediately
solving
it.
So
we
can
continue
that
discussion
based
on
what
you
hear
from
other
successful.
A
But
this
is
a
real
problem
like
this
can
happen
and
like
if
the
back
end
is
not
like
going
to
handle,
then
it's,
I
don't
know
what
what
what
impact!
That's
it,
because
you
have
a
counter
which
is
going
up
and
then
all
of
a
sudden
it
goes
negative
for
no
bug
from
the
user.
It's
purely
done
inside
the
sdk,
so
I
haven't
heard
any
complaints
from
users,
but
that
doesn't
mean
there
is
no
complaint.
A
It's
just
that
like
long
has
a
very
fairly
big
range,
so
it's
very
unlikely
to
hit
that
limit
in
practice
when
nova
was
doing
the
initial
prototype
in
the
early
days
of
matrix,
he
did
mention,
and
he
put
like
some
statistics.
The
probability
of
this
overflowing
is
like
very
low.
I
remember
like
some
experiment
here
and
like
he
has
to
run
that
for
like
so
many
years
in
a
typical
machine
to
really
reach
that.
A
Yeah,
so
there
was
like
some
conclusion
at
that
time,
but
this
was
not
part
of
the
official
report.
He
was
doing
this
prototype
when
he
was
designing
the
api
within
the
dot-net
runtime
itself.
A
Okay,
so
since
we
decided
not
to
block
it,
let's
spend
some
time
reviewing
couple
of
things
which
I
really
want
to
make
sure
like
we
review,
so
we
already
merged
the
pr
to
unblock,
but
this
is
something
which
we
discussed
two
weeks
back.
A
A
It's
surely
discussed
oh
yeah,
this
one
so
like
alan
had
the
pr-
and
it
looks
like
turned
out,
turned
out
that
it
was
the
right
thing,
because
we
had
this
thing
called
aggregation
temporality
on
the
metric
class.
So
if
we
expand
it
to
include
anything
more
fancier
like
stateless,
then
it
would
have
really
be
leaking
to
the
exporters
as
well.
So
with
this
change,
the
user's
preference
is
captured
with
aggregation,
temporality
preference
yeah
metric
reader,
temporary
preference.
A
So
this
is
where
the
user
would
configure
whether
they
want
delta
or
cumulative
or
in
the
future,
stateless
all
sort
of
combinations
which
users
want,
but
the
exporters
they
will
just
see
one
thing,
whether
it's
actually
or
delta,
so
you're
not
leaking
any
usage
configuration
into
the
export.
So
this
is
the
right
thing
to
do.
I
merge
this
pr
in
case
anyone
has
concerns.
Please
take
a
look.
I
have
tagged
some
people
just
to
because
this
is
a
breaking
change
for
exporters.
A
So
prometheus
is
already
taken
care
and
like
things
which
are
shipped
from
this
report
and
has
already
fixed
it,
but
for
other
others,
it's
a
breaking
change.
A
A
If
there
is
a
view
config
like
there
are
multiple
views
configured
for
the
same
instrument,
we
will
create
separate
streams,
even
though
it
results
in
a
conflict,
and
I
think
we
do
a
log.
So
if
user
enables
the
diagnostic
cloud
they'll
see
that
we
are
creating
a
conflict
intentionally
because
of
it,
so
some
some
messaging
respect
for
this
things.
Even
if
you
do
this
now,
there
is
nothing
prohibiting
us
from
the
spec,
but
there
is
an
open
spec
which
seems
to
take
this
direction.
So
if
that
spec
is
merged,
then
we
are
like
fully
compliant.
A
If
that
doesn't
get
merged,
then
also
it's
not
a
big
deal,
because
tech
is
very
much
silent
about
this
part.
So
most
likely
we
are
still
find
there,
so
just
be
bringing
some
awareness,
because
these
two
are
the
only
like
significant
peers.
We
emerged
since
the
last
release
candidate.
C
Actually,
while
you're
here
mike,
you
had
a
you,
had
a
comment
on
one
of
my
prior
pr's
to
try
a
structural
equatable
and
I
actually
did
try
that
and
for
whatever
reason
it
was
failing
in
net
461,
and
I
didn't
I
didn't
investigate
it
yet.
But
I
I
plan
to
come
back
to
that,
because
I
don't
know
why
it
would
make
a
difference.
I
kind
of
looked
at
the
net
that
framework
implementation
of
how
I
structural
credible
worked
and
it
looked
like
it
should
be
doing
the
thing.
But
I
don't.
A
Know:
okay,
yeah:
we
can
come
back
to
this
one.
It
should
be
like
purely
internal
change,
yeah
yeah,
so
those
are
all
the
topics
and
like
I
have
I
mean,
let's
just
go
through
the
public
apa
one.
Once
again,
I
just
went
to
it
like
a
couple
of
times
in
the
past,
but
I
did
it
again
just
to
make
sure
like
we
are
not
having
anything
and
leaked.
This
is
only
one
which
stood
out
and
I
created
a
pr
just
to
remove
it.
A
Like
that's
a
pr
which
I
sent
out
like
a
few
minutes
earlier,
so
like
just
to
make
progress
right
now
I
removed
it
with
medit
internal
and
gave
it
special
access
to
promises
just
one
blog,
so
we
will
figure
out
if
from
this
really
needed,
because
there
is
no
other
exporter
who
needs
it.
So
it's
very
specific
to
promote
this
thing.
So
if
we
still
think
that
it's
a
useful
thing,
then
we
can
bring
it
back.
A
There
is
already
like
a
fairly
big
change
happening
in
the
promises
exporter,
which
branch
has
already
sent
apr
few
weeks
back.
So,
let's
ship
the
1.2
with
this
public
api
removed,
then
when
we
work
on
prometheus,
if
it
realizes
that
okay,
this
is
really
needed.
We
can
bring
it
back
or
we
can
fix
prometheus
exporter
to
not
require
this
api
to
work
so
either
way.
I
would
supposed
to
like
remove
it
and
worry
about
prometheus
afterwards,
just
to
stick
with
the
timeline.
A
Otherwise,
we
need
to
go
and
modify
promoters
to
not
use
this
api,
so
you
can
see,
like
I
temporarily,
cheated
by
giving
access
to
internals
to
prometheus,
so
yeah.
So
for
me
this
is
the
last
dr,
which
must
be
merged.
Before
I
hit
the
first
release
for
the
sdk
yeah.
This
is
just
fyi
and
like
now
we
can
I
mean
if
anyone
else
have
like
any
custom
concerns,
we
can
take
it
now.
Otherwise
I
don't
have
anything
else
in
the
topics.
A
Let's
see
there
is.
C
C
C
A
So
what
we
can
do
is
the
let
me
open
the
trace
exporter,
yeah
log,
so
yeah
you
are
removed
temporarily
right,
yeah.
We
are
not
storing
category
name
anywhere,
which
is
good
for
now,
because
we
can,
we
can
add
it
back
as
attribute
depending
nothing.
What
digrand
mentioned
at
that
time
was
alternate
is
to
store
it
as
an
attribute,
so
we
can
store
it
as
an
attribute
and
it
shouldn't
be
a
breaking
change
for
the
otp
exporter,
because
it's
still
like
very
much
in
the
beta
state.
A
So
that
should
not
be
a
concern
for
us
anything
else
which
broke
us.
Oh
sorry,.
C
A
C
C
Up
with,
I
had
another
pr,
a
while
back,
I
didn't
really
push
on
it
to
go
forward,
but
it
was
basically
just
doing
the
whole
thing
like
downloading
the
protos,
with
ms
build
and
then
compiling
the
protos
and
all
that
without
the
need
to
keep
all
of
the
the
protos
actually
within
our
cluster.
So
that's
something
I
experimented
with,
and
I
might
follow
this
pr
up
with
that.
But
it's
not
strictly
needed
it's
just.
It
just
makes
revving
the
version
like
a
one-line
change,
yeah
just.
A
Okay,
yeah
so
yeah
for
this
one,
like
I
would
say
this
should
not
like
block
one.
We
can
add
it
even
afterwards,
so
I
mean
we
can
still
merge
this
pr
without
name,
then
we
can
follow
up
with
another
pr
where
we
can
populate
category
to
wherever
the
it
should
be
attributes,
because
if
it's
not
in
the
top-level
field,
then
it
has
to
be
attributes
and
there
are.
Interestingly,
there
are
folks
who
wants
to
bring
it
back.
A
I've
seen
like
long
discussions
occurring
to
bring
back
the
name
again
to
log
record,
so
maybe
we
need
to.
I
mean
we
can
do
like
nothing
for
now
to
see
where
it
finally
lands
and
based
on
that
we
can
do
but
yeah
for
now
we
can
put
it
into
attributes
yeah
anyone
else
with
any
anything
to
be
so,
I
know
like
mike
planche
has
a
pr
which
shall
curse
review,
but
it's
in
the
premature.
A
So
as
soon
as
I'm
done
with
the
rc
today,
we
basically
block
the
repo
from
any
not
just
two
metric
stkps,
but
prometheus
can
continue
to
scan
and
everything
is
just
to
keep
same
bit
stripped
when
we
actually
do
the
stable.
So
now
would
be
the
right
time
for
me
to
go
and
look
at
any
other
pending
peers,
which
has
been
like
waiting
for
quite
long.
A
So
that's
all
from
my
side
on
like
metrics
any
other
topic
which
we
want
to
discuss
so
I'll.
Just
give
a
quick
update.
What
I
intend
to
do
right
after
1.2
stable,
is
done
number
one.
Priority
is
like
if
metric
in
memory
is
not
done,
we'll
need
to
do
that
shortly
after,
if
not
done
before.
A
Second
is
the
prometheus,
and
there
has
been
like
a
lot
of
speculated
updates
on
the
prometheus
side.
So
so
whatever
blanche
has
been
doing
here
is
mostly
about
like
internal
changes,
but
now
we
need
to
look
at
the
spec
and
compare
rb
compliant
with
the
spec.
And
the
third
thing
is,
there
was
a
proposal
to
split
the
prometheus
into
multiple
one
like
one
providing
the
core
functionality
and
then
extensions
on
top
for
sp,
net,
core
and
other
web
frameworks.
A
So
those
are
the
things
which
we'll
be
immediately
tackling
after
1.2
and
we
need
to
like
decide
whether
we'll
have
a
stable
release
after
1.2.
Based
on
that,
we
need
to
decide
how
to
do
the
like
logistics
for
bringing
the
dotnet
7
changes.
A
So
this
is
what
I
intend
to
like
tackle
like
immediately
after
the
1.2
release.
There
are
like
few:
there
were
like
at
least
one
or
two
pr's,
which
we
decided
not
to
merge,
given
that
we
were
very
close
to
release
so
we'll
come
back
to
that.
One
of
them
was
in
the
logging
and
actually
second
one
is
also
under
logging,
the
performance
and
safety
enhancement.
A
There
are
like
several
other
issues
which
requires
attention,
but
we've
been
like
funding
it
just
to
keep
focused
on
the
release.
I
have
tagged
like
few
folks
here
and
there
so
I'll
go
and
find
all
those
issues
and
like
try
to
get
the
right
folks
involved.
I
think
I
remember
like
grpc,
had
an
issue
the
metric
instrumentation
for
almost
all
the
packages
like
asp.net
core
http
and
they
are
all
relying
on
activity.
A
So
if
someone
runs
on
tracing
and
metrics
won't
flow,
so
there
are
like
issues
to
be
addressed
but
we'll
get
to
it
right
after
1.2
any
questions
I
got
one
question:
okay,
oh
yeah!
Go
ahead.
B
Didn't
see
your
handwriting
go
ahead
for
the
in-memory
exporter,
we
introduced
those
copy
methods
in
the
metrics
api
and
then,
as
part
of
my
current
pr,
I
was
adding
the
internals
visible
to
so
that
the
in-memory
exporter
could
use
those
internal
methods
should
that
go
as
a
separate
pr
just
to
get
it
in
before
your
release,
candidate.
Let's.
A
Yeah
yeah:
this
is
making
it
available.
Sorry,
so
yeah.
This
is
making
it
available
for
the
memory
exporter.
This
is
a
side
effect
of
that
rest
of
the
changes
are
contained
with
yeah
so
like
this
should
not
affect
the
open
elementary
sdk
release,
because
this
is
only
touching
the
open
elementary
in
memory
exporter.
So
we
see
if
we
can
get
that
in
the
next
two
to
three
days.
So
the
only
reason
why
I
mentioned
that
this
should
not
block
the
overall
release
is.
This
is
not
part
of
the
core
sdk.
A
It's
part
of
a
separate
package,
just
like
prometheus,
so
you're
not
being
brought
by
prometheus.
So
just
like
that,
we
don't
need
to
be
blocked
by
memory.
I'm
trying
to
like
release
1.0
at
the
promised
time,
because
our
1.1
has
issues
that
it
cannot
work
in
dot
net
six
because
of
the
upper
bound
restriction.
So
we
really
want
to
get
one
point
two
out
at
the
earliest
right.
Well,
that
makes
sense.
I
just
want
to
double
check.
Thank
you
yeah!
A
I
I
didn't
actually
remove.
I
mean
actually
read
all
these
comments,
but
I
know
that
this
requires
some
discussion,
but
I'll
definitely
help
with
that
as
soon
as
I'm
done
with
like
first
part
of
the
job,
which
is
to
get
the
sdk
shipped
yeah,
and
there
are
like
open
pr's
about
like
dogs
like
a
certificate,
at
least
for
me,
it's
a
lower
priority,
but
now
that
you're
done
with
rc
one
like
end
of
day
today
I'll
come
back
and
start
responding
to
all
the
other
issues.
A
Yeah.
There
are
like
some
log
improvements,
but
I
think
there
are
more
test
improvements
which
mothra
you
are
adding,
but
then
there
is
this
fairly
big
issue
about
logic,
but
yeah.
All
of
them
would
come
back
as
soon
as
possible.
So
expect
that
to
happen
like
in
the
next
two
to
three
days,
so
I'm
still
not
updating
the
milestone.
It
still
remains
15,
which
is
this
friday,
and
I'm
hoping
that
we
should
be
able
to
do
that.
A
Any
other
questions
or
like
anyone
else
so
I
had
I
mean
there
were
like
few
issues,
but
I
don't
think
we
have
any.
Like
I
mean
we,
we
don't
have
like
many
peers
to
go
over.
A
These
are
like
really
small,
like
we
just
need
to
like
spend
some
time
to
review
it.
I
know
like
alan,
was
already
working
on
this,
but
we'll
have
more
time
to
focus
on
it,
but
this
is
a
pr
which
I
already
talked
about.
We
need
to
come
back,
because
this
is
promising
specific.
A
This
one
is
technically
mergeable.
It's
I
actually
always
forget
like
whenever
I
come
and
try
to
merge
it.
Someone
had
something
else
as
small,
so
I
need
to
rebase
again
I'll
check
with
utkarsh
again
he
is
working
remotely
from
india,
so
he
will
be
coming
on
like
little
later
so
I'll
check
with
him.
But
again
this
is
not
really
required
for
1.2.
So
even
if
we
add
it
after
1.2,
we
shouldn't
be
in
any
issue
at
all
yeah
anything
else
here:
okay,
yes,
so
that
means
we
don't
have
any
agenda.
A
So
the
immediate
action
item
is
on
me
and
alan
to
like
merge
these
two
pr's
and
then
I
I
will
do
the
actual
release.
I
may
do
it
like.
Little
later
today,
I
will
have
like
quest
available
online
from
india.
So
he's
his.
What
time
starts
when
we
are
about
to
go
to
sleep
so
I'll
use
this
help
to
get
any
change,
love
peers,
so
we
should
be
like
doing
the
release
today,
so
we
just
need
to
merge
the
first
two
pairs.