►
From YouTube: 2022-01-14 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
Hey
nacho,
hi
bryce,
sorry
for
the
delay.
I
just
was
programming
and
forgot.
A
Okay,
yeah
one
thing:
did
you
have
time
to
review
a
beer
I
have
on
the
project.
B
B
A
B
A
Hurry,
I
will
have
said
yeah
justin
if
I
need
it
so
or
maybe
just
five
days.
I
don't
know
it's
something
related
to
the
data
log
exporter,
but
also
to
the
persistence
exporter
that
was
released
recently
about
changing
the
way
they
the
cues
were
handled
because
it
was
using
too
many
too
many
cues
for
the
reading.
There
was
no
need
for
a
q
and
also
for
for
configuration
on
the
persistence,
creating
creating
externally.
The
cues
is
something
that
doesn't
feel
like
really
comfortable
for
a
user.
A
A
Yeah
yeah
yeah,
it's
very
repeated,
so
don't
don't
hurry,
I'm
not
in
a
rush
with
that,
but
just
in
case
okay,
I
don't
know
if
bennett
is
coming
or
not.
Okay,.
A
So
maybe
he's
tuning
later,
I
don't
know
we're.
Gonna
start,
let's
see
okay
last
meeting
actions
we
were,
it
was
quite
a
long
ago.
So
one
month
happy
new
year.
A
A
A
I
had
to
check
the
source
code
of
the
library
in
shift
and
so
that
there
were
some
things
that
looked
like
what
we
were
using
and
effectively.
They
fix
it.
So
it
now
currently
inherits
correctly
the
activity
that
you
have
outside.
So
what
I
did
was
remove
all
the
code
that
had
in
the
library
with
concurrency
stuff
trying
to
fix
what
apple
didn't
that
it
was
not
perfect
and
the
the
thing
is
that
I
was
getting.
A
I
don't
know
if
I
mentioned,
but
I
was
getting
different
results
with
changing
the
different
versions
of
xcode,
and
that
was
really
strange.
So
it
took
me,
it
took
me
almost
a
week
of
trying
to
debug
what
was
happening
so
yeah.
Basically,
I
removed
that,
so
we
only
support
context
handling
when
using
xcode
13.2
an
app
in
the
concurrency
library.
That's.
A
We
will
have,
but
trying
to
fix
some
minor
version
that
no
one
is
probably
going
to
use,
because
concurrency
is
much
better
yeah.
B
A
Has
more
support
for
versions
in
unix
content
in
the
two?
I
think
we
are
not
going
to
support
that.
So
when
I
release
a
version,
I
will
mention
that
and
I
will
say
that
we
don't
support
concurrency
before
that,
the
context
handling,
because
it's
yeah
and
with
that
everything
works.
I
also
added
some
tests
quite
a
lot
of
tests
that
exercise
this
code
with
new
versions
of
xcode.
It's
not
what
runs
in
the
ci,
but
it
should
you.
A
A
A
B
A
So
that
that
was
my
my
idea:
releasing
everything
with
that
as
soon
as
possible,
so
anyone
can
use
it,
and
that
was
the
only
thing
I
did
related
to
the
project
lately
so
yeah
and
that's
the
last
meeting
actions.
I
think
so.
What
about
your
your
point
there
about
metrics?
Yes,.
B
For
time
it
seems
like
it's
probably
going
to
be
a
while
a
long
time,
because
there's
a
lot
a
lot
of
changes,
it
seems
like
so
the
that's
right
yeah
I
was.
I
just
noticed
that
we
didn't
have
a
so.
I
was
fiddling
around
with
cpu
monitoring
in
my
in
the
elastic
agent
and
I
was
reviewing
the
the
spec
documentation
for
open
telemetry
and
how
that's
supposed
to
look
and
they
recommend
using
an
async
counter
or
not.
Maybe
it
was
an
async
counter,
I'm
not
sure
exactly.
B
I
can't
remember,
but
it
was
one
metric
that
we
didn't
have
defined
yet,
and
so
I
started
going
down
that
rabbit
hole
of
adding
another
metric,
and
then
I
realized
that
our
they
finally
stabilized
the
metric
spec
and
so
then
I
started
looking
at
like
okay,
like
what
is
it
going
to
take
to
get
our
our
sdk
in
line
with
the
metric
spec
now
and
it
looks
like
there
are
actually
a
lot
of
changes.
B
Yeah,
so
one
of
the
main
changes
that
I
was
seeing
is
on
the
meter.
Basically
every
do
you
then
use
xcode.
I
I
do
sometimes
I've
been
playing
around
with
that.
A
B
Yeah
I've
been
playing
around
with
app
code
and
it's
it's
not
bad,
but
yeah,
so
I've
been
I've
been.
I
was
updating
the
the
meter
api,
so
kind
of.
I
just
wanted
to
get
your
your
thoughts
on
things
and
make
sure
that
I'm
kind
of
going
in
the
right
direction
and
see
if
you
had
any
feedback.
So
my
plan
has
been.
Is
I'm
not
gonna
remove
everything
that
we
already
have
just
for?
B
A
And
yeah.
B
So
it
seems
like
now
and
bring
all
the
the
methods
in
line
with
kind
of
the
spec,
and
they
all
me
they
all
have
like
a
a
consistent
parameter
configuration
on
them.
So
they
use
the
name
of
units
and
a
description.
A
B
B
A
Maybe
do
you
think
that
maybe
we
could
also,
I
don't
know
right,
create
another
name.
Oh.
A
B
Yeah
I
considered
that
okay
and
yeah.
That
was,
I
just
decided
to
go
this
way
for
the
time
being.
Until
I
got
your
feedback
but
yeah
that's
yeah.
I
think
that
comment
is
enough
to
push
me
over
the
edge.
My
my
main.
A
Yeah
I
mean
I
I
when
I
implemented
it.
I
basically
did
it
without
much
experience.
B
A
An
old
api,
and
maybe
a
as
I
told
you
in
the
comments
there
were
some
things
that
I
didn't
like
much
how
I
and
how
ended
up
implemented
like,
for
example,
the
the
template
thing.
Yeah.
A
But
using
generics
for
implementation
was
writing
code
just
once
yeah
for
many.
B
B
A
And
I
I
never
played
much
with
metrics
myself
for
my
product
so
just
implemented
because
the
it
was
in
the
spec
of
open
telemetry,
so
it
had
to
be
implemented
so
that
that's
the
main
reason
whatever
you
think
it's
better.
So
you
think
it's
better
replacing
these
meters
with
new
ones
instead
of
maintaining
compatibility
with
a
better
name
or
whatever.
A
B
Yeah,
it
might
be
yeah
just
as
I've
been
going
along.
I
think
that
it
might
be
better
to
to
to
pull
it
out
into
a
new
class,
like
maybe
a
stable
meter.
B
I
think
I
might
call
it
that
okay
yeah,
because
I
was
running
into
issues
with
just
like
the
protocol
not
being
defined
in
some
of
the
some
of
the
the
child
classes
that
are
using
the
protocol,
so
I
think
that'll
make
it
a
little
bit
cleaner
and
easier.
So
yeah
all
right.
I
think
that's
good
feedback,
but
yeah.
That's
just
I'm
gonna
be
chugging
away
at
this,
but
I
will,
I
think
I
will.
This
helps
a
lot
just
to
find
where
the
changes
are
so
I'll.
A
True,
maybe
adding
I
don't
know,
I
think,
there's
a
way
to
add
a
commentary
about
what
should
replace
it.
Maybe
yes.
B
Make
it
a
little
a
little
bit
yeah,
no.
A
Not
needed
to
be
extremely
clear,
but
just
say
please
evaluate
this
other
or
something
like
that.
Yes,
yeah.
B
A
For
the
uses
of
it,
I
don't
know
how
many
we
will
have,
but
I
think
at
least
james
sherlock
was
using
metrics.
B
B
B
I'll
try
to
get
this
together
and
then
once
yeah
we
can
get
some
feedback
from
james
and
stuff
since
he's
using
it.
Once
we
once
I
get
a
pr
up.
Okay,.
A
A
Yeah
because,
for
example,
having
that
any
in
the
name
is
something
that
I
shouldn't
be
in
a
user
api,
for
example,
it's
like
I
don't
know
why
I
kept
that
name.
It
was
because
it
was
somehow
hiding
the
type,
but
shouldn't
have
leaked
to
the
api
itself.
B
B
Okay,
okay
I'll
try
to
keep
that
in
mind
I'll
yeah
I'll,
try
to
clean
up
the
the
object,
names
or
the
class
names
and
and
obfuscate
the
the
template
stuff.
So
maybe
maybe
I'll
do.
A
A
Where
it
makes
yes,
I
thought
about
it,
but
yeah.
I
don't
know
why.
I
didn't
end
up
with
that
changes,
so
yeah
and,
for
example,
this
an
instagram
metric
that
we
have
here,
it's
a
public
type
but
for
the
user
of
the
library,
probably
is
not
creating
this
itself,
so
it's
only
referencing
and
receiving
what
the
library
provides.
A
B
All
right
yeah,
I
just
wanted
to
make
sure
that
I'm
on
the
right
path
and
yeah.
I
think
that
was
good
feedback.
B
B
A
A
B
Okay,
yeah:
it's
I'm,
I'm
not
totally
familiar
with
all
of
the
best
practices
in
swift,
so,
okay,
I
think
yeah
I'll.
Definitely
if
I
have
any
like
any
decisions
that
I'm
not
totally
sure
about
I'll
definitely
run
them
by
you
yeah
regard
yeah
like
because
I'm
like
is
templates
better
or
should
it
not
be
templates?
I
don't
know
if
there's
implication
for
interfacing.
A
A
B
A
Yeah
about
templates,
I
personally
don't
like
them
much,
because
I
think
they
somehow
creates
more
difficult
to
understand
code.
B
A
You
are
not
only
having
strings,
so
you
is
not
so
easily
readable
and
makes
things
like
with
yeah.
You
know
I
don't
like,
but
if
you
prefer
moving
in
that
direction,
just
I
mean
I
use
them
because
it
was
easier
to
implement
just
in
one
type,
having
the
proper
definition
for
the
type
just
being
a
numeric
type.
So
it's
an
integer
or
a
double.
So
just
one
implementation,
just
one
code
but
yeah,
but
it
it's
not
needed
for
that
to
be
linked
to
the
api
okay.
A
B
B
If
it
saves
duplicating
code,
I
think
that
that
might
be
good
yeah.
B
But
if
it,
if,
if
it
can't
do
that,
then
I'll
avoid
using
it
but
yeah
I'll
definitely
create
type
aliases
for
all
of
the
okay,
the
intended
types,
and
I
think
that
that
you
can
also
use
constraints
as
well.
So
we
can
avoid
avoid.
You
know,
access
to
the
template
type
like
of
a
string
or
something
can
cause
problems
there
so
but
I'll
investigate
that.
B
Oh
so
like,
if
someone
were
to
use
the
template-
and
you
know
and
say
I
want
a
string
metric,
oh
yeah,
you
can
prevent
that.
A
I
think
that
if
you
check
the
type
definition
of
the
template,
I
think
it
says
is
numeric
yeah
or.
B
A
B
A
Yeah
and
that
will
make
that
fail
for
other
types
that
are
not
supposed
to
work,
but
also
the
open,
telemetry
api
forces
you
to.
A
Ins,
so
that's
why
you
only
can
create
them
using
the
meter,
sdk
emitter
provider,
sdk
or
meter,
which
one
is
metric,
which
one
is
the
one
that
you
used
to
create
the.
A
B
That's
it
still,
it
still
says
yeah,
that's
the
that's
the
way
yeah.
So
I
guess
we
really
don't
have
to
worry
about
the
the
measurements
being
implemented
anywhere
else
anyway.
Okay,
cool.
A
A
If
it
breaks
okay,
if
we
need
to
break
it,
we'll
break
it,
but
we
can
also
change
to
add
two
dots,
whatever
version,
so
as
you
as
you
feel
it
better.
I
mean.
A
Okay,
great
cool,
so
I
think
we
are
done.
B
All
right
great,
have
a
great
rest
of
your
day.
Nacho.