►
From YouTube: 2021-09-02 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
Okay,
all
right
nice.
I
guess
we
could
just
get
started
thanks
for
adding
topics
beforehand,
guys
as
usual,
add
your
names
to
the
attendees
list.
A
Right
right,
okay,
cool
just
go
through
the
agenda
today
seems
to
be
oh.
Let
me
share.
My
screen
seems
to
be
a
bunch
of
pr's
related
to
talks
builds
this
week
other
than
that.
Some
you
know
pr
is
getting
approved,
smaller
issues.
Okay,
so
kant
is
your
comp.
E
H
A
We
can
go
back
to
it
if
he
joins
a
bit
after
minimum
required
approval.
Should
we
allow
merging
trivia
approvals
with
just
one
approval
collector?
Does
this
yeah.
H
E
A
I
get
this
the
need
for
this
yeah
having
two
people
look
at.
It
is
a
is
a
lot.
I
don't
mind
doing
this.
It's
it's
like
we're
going
to
have
a
set
of
eyes,
anyways,
looking
to
see
whether
or
not
something
is
trivial
or
not
anyways.
So
I'm
fine
with
this,
especially
like
for
the
like
the.
H
Maybe
hotfixes,
maybe
we
can
do
something
like
if,
if
the
person
approving
it
like
the
first
person
approving
it,
is
confident
that
it's
it's
good
to
go,
maybe
they
can
like
tag
plus
two
or
something
like
I
do.
What's
inside
one.
H
Yeah
github
doesn't
support
it.
I
mean
we
can
have
some
workflow
like
like
a
comment
or
something
or
at
a
time.
B
It
sounds
like
we
use
garrett,
we
switching
to
garrett.
D
D
No,
I
I
think
I
I
don't
know,
I
think
it
should
be
fine,
like
I
hopefully
we're
all.
We
all
have
enough
of
a
judgment
to
be
able
to
decide
if
something
is
trivial
or
not
yeah
for
diego
who's
shaking
his
head.
But
hopefully
everybody
else
feels
like
they're,
confident
and
deciding.
If
something
is
trivial
or
not,.
I
I
think
many
times
trivial
changes
or
something
that
may
look
real
gets
introduced
and
almost
every
time
some
someone
has
a
comment
or
a
suggestion,
or
something
or
an
objection
about
something
that
the
original
author
had,
I
think
about
considered,
and
it
ends
up
sparking
a
lot
of
discussions.
For
example,
my
last
pr
that
removed
the.
I
D
I
I
A
H
A
But
like
no,
this
does
have
value
for
those
like
one
one-offs,
where
it's
like
someone
just
like
fixes
a
comment
or
like
you
know,
and
there
are
there-
are
pr's
like
that
like
it's,
this
is
not
just
something
that
we
made
up
also
like
for,
like
I
don't
know
like
if,
if
one
of
the
maintainers
like
you
know
we're
trying
to
like,
do
a
release
or
something
like
that,
you
know
or
like
we
missed
something
like
some
version
change,
or
at
least
you
know
it
kind
of
speeds
things
up
right.
C
K
H
Yeah
one
example
for
a
diego's
question
was
like
the
the
docker
docker
test,
so
I
had
a
pr
for
for
the
flicky
test
and
that
we
are
getting
merged
would
have
helped
like
five
other
pr's,
don't
run
their
tests
without
feeling
so
situations
like
that.
It's
helpful,
but
not
a
big
deal.
Now
that
I
know
country
requires
anyone.
A
I
don't
care
about
this.
Okay
cool
all
right.
Let's
not
take
up
too
much
time
about
this.
It's
not
a
big
deal.
So
all
right,
moving
on
contributing
guidelines
need
some
love.
So
pretty
sure
these
are.
H
Try
to
export
for
falcon
3
on
surface
seems
to
be
a
simple
thing
to
do,
but
they
ran
into
a
lot
of
local
development
issues.
I
think
it's
related
to
like
there's
some.
There
is
something
wrong
at
some
point
and
ended
up
messing
up
the
dog's
directory,
and
now
it's
it's
not
working
as
expected,
but
still
it
was.
There
was
some
feedback
about
contributing
guidelines
and
like
setting
things
up
locally,
we
also
have
a
bit
of
a
non
non-trivial
setup
where
we
have
to
clone
two
repositories.
H
H
H
I
haven't
figured
out
a
way
to
run
pilot
locally.
I
always
rely
on
ci
and
then
there's
another
recurring
issue
with
bottle
instrumentation.
Sometimes
it
fails
because
it
cannot
fight
the
environment
variable
they
do
this
extra
key
and
then
weirdly,
even
if
I
said
it,
it
still
fails,
and
sometimes
it
runs
those
two
issues
that
these
have
run
into.
I
B
Worse,
I
think,
for
the
contrib
thing,
if
I
remember
right,
when
we
were
pretty
unstable,
we
wanted
to
have
those
checks,
because
there
were
a
lot
of
dependencies,
especially
right
after
we
moved
all
the
instrumentations
and
exporters
out
of
the
core
repo.
But
like
maybe
at
this
point
since
we're
not
even
since
we're
doing
like
monthly
releases
of
the
api
and
sdk,
it
would
be
okay
to
drop
the
the
check.
I
Sorry
to
but
does
that
mean
that
we
will
be
able
to
merge
something,
and
then
when
we
do
the
release,
we
will
have
to
do
land
fixes
for
all
the
stuff.
That
was
not.
B
I
I
are
we
talking
about
the
contrib
checks
on
the
core
repos.
A
Original
issue,
not
the
talks
stuff,
like
the
experience
for
like
just
setting
up
an
environment,
is
difficult
like
this
poor
guy.
He
just
wanted
to
run
lint
on
the
project
and
like
he
couldn't
get
a
lot
of
stuff
to
pass.
Mostly,
I
think
it
was
due
to
like
ours
kind
of
like
doubles
dependency
on
the
fact
that,
like
sdk,
still
depends
on
instrumentation,
but
everything
in
contrib
relies
on
stuff
in
core,
and
that
was
like
really
difficult
to
get
through.
A
Also,
I
think,
since
this
is
a
month
ago,
this
was
like
in
the
middle
of
like
I
think
we
had
that,
like
you
know,
build
issue
with
with
with
github
as
well.
I
No,
no,
it
ended
up
being
a
problem
with
the
elasticsearch
that
alex
submitted
right
right,
yeah,
yeah.
A
Branch
thing
yeah
like
just
though
there's
a
bunch
of
like
inconvenient
stuff
that,
like
it's,
it's
not
a
it's,
not
a
negative
on
like
our
docs
or
anything.
It's
just
that
we
kind
of
it's
just
a
a
combination
of
factors
that
each
have
been
lackluster.
That
kind
of
combine
to
a
really
crappy
experience,
so
yeah,
and
then.
H
Someone
one
thought:
can
we
can
we
remove
this
setup
having
to
clone
core
inside
contrib
and
by
default
depend
on
the
packages
from
core
publish
to
wi-fi,
then,
for
most
cases,
it'd
be
pretty
simple
to
contribute
your
contract,
but
people
who
want
to
do
changes
that
touch
both
core
and
contrib.
At
the
same
time,
they
would
have
to
clone
or
figure
out
a
way
to
use
dev
dependencies,
and
we
can
provide
a
way
for
that.
H
A
Like
like,
instead
of
I
don't
really
like,
like
such
you,
know
specific
logic
or
use
cases
for
our
builds,
even
though
like
yeah,
we
can
just
make
them
and
like
do
them
once
it's
fine
like
just
inherently
like
our
our
dependency
structure,
is
wrong
right
now,
and
I
kind
of
just
want
to
address
that
and
fix
that,
so
that,
like
no
matter,
what
like
contrib,
wouldn't
rely
on
core
right,
look
like
he's
right
like
what
is
the
point
of
having
core
package
if
it
depends
on
the
contrib
package,
like
vice
versa.
A
I
Is
because
we
always
had
this
concern
about
making
a
change
in
core
and
then
having
our
country
packages
break
so
to
make
sure
that
that
did
not
happen.
We
we
artificially
introduced
this
dependency
of
who
of
country
own
core,
so
that
we
can
run.
I
Time-
and
I
I
actually
I
mean-
I
understand
the
need
for
that,
but
I
think
the
problem
that
we
are
having
and
is
the
fact
that
we're
pretty
much
always
running
latest,
because
these,
if,
if
we
had
our
country
packages,
fix
it
on
core
component
versions,
then
we
could
update
core
and
we
could
only
update
the
dependency
version
of
the
contour
packages
after
we
have
tested
with
the
new
core
component
version
so,
but
but
we're
not
doing
that
we
we're
not
having
fixed
dependencies
and
upgrading
them
one
by
one.
I
I
also
think
this
could
be
the
solution
for
the
the
problem
that
we
just
mentioned,
that
what
do
we
do
if
we
need
to
introduce
a
change
in
a
contrib
and
a
core
component?
At
the
same
time,
if
we
used
fixed
versions,
we
could,
in
the
same
commit
that
updated
the
versions
we
can
introduce.
I
The
change
on
both
packages
see
what
I
mean
so
that
that,
of
course,
would
be.
No
sorry.
Well,
that's
a
solution.
Yeah.
The
problem
that
they
are
inseparable
is
something
else
to
consider,
but
we
could
help
us
a
lot
if,
if
we
use
versions
in
this
way
so
that
we
don't
create
this
dependency
of
core
on
country,
yeah.
A
Yeah,
sorry,
what
I
was
talking
about
before
it
was
was
irrelevant.
My
I
was
thinking
of
something
else.
Sorry,
but
yeah.
You
guys
are
correct
about
that.
I
don't
know.
If
that's
the
solution,
we
want
to
go
with
but
looks
like
if
anyone
else
wants
to
speak
up
to
that
topic.
Otherwise
we
can
actually
just
open
up
a
discussion
to
see
like
what
we
want
to
do.
Don't
want
to
take
up
so
much
time.
We
have
a
lot
of
other
stuff
to
go
through.
A
F
F
H
H
I
No!
No!
No!
No!
No,
because,
oh
sorry,
sir
nathaniel
they're
talking
about
any
hypothetical
case
that
would
we
be
able
to
do
that.
I
F
A
A
J
H
Do
scenarios
so
if
I'm
adding
support
for
next
version
of
django,
I
don't
need
anything
from
core.
Everything
is
on
wi-fi
for
me
to
install
that
django,
instrumentation
and
test
it
and
like
test
it
manually
test
it
automatically
everything's
there.
I
don't
need
code
at
all
when
I
need
core
is
if
I
am
making
a
change
in,
let's
say
to
some
the
instrumentary
interface
in
core
and
then
now
I
need
to
go
into
contrib
and
update
every
single
instrumentation.
I
Yeah,
but
nothing
has
has
a
valid
point.
I
mean
in
signal
scenario:
where
do
you
need
where
you
actually
need
a
change
in
core,
then
that
can
be
problematic,
because
if,
if
that
change
is
added
in
core
master
right
and
if
it
is
not
released
until
I
don't
know
like
two
or
three
weeks
afterwards,
then
that's
how
much
the
nd
school
will
have
to
end
up
waiting
for
the
user
to
be
able
to
install
it
with
it
right.
F
H
Yeah,
so
there
are
two
cases
here:
one
is
if
you're,
if
you're,
building
both
features
in
at
the
same
time
and
you're
the
author
of
both
changes
in
core
and
conjuring,
then
the
workflow
would
be
same
or
very
similar
to
what
we
have
today,
where
you
clone
core
and
we
have
some
tooling
to
automatically
use
it
from
your
locally
cloned
right.
Another
another
situation
is
when
we.
So
in
this
case,
when
you
commit
these
two
things
and
push
them,
then
how
do
we
have
a
dependency
from
the
core
package
on
the
dev
country
package?
H
I
think
that
can
be
solved
by
having
that
get
dependency,
because
pip
can
install
things
directly
from
approach.
So
in
that
case
we
can
say
now
this
package
doesn't
depend
on
the
hotel.
I
D
I
Every
committee
yeah
I
mean
if,
if
we
were
able
to,
I
mean
just
push
a
button
and
make
a
release.
A
H
B
F
I
was
going
to
say
that
I
mean
carol's
on
the
call
she
she
joined
aws
like
a
few
months
ago
when
she
worked
and
she
was
just
installing
stuff
for
the
first
time
and
then
a
colleague
of
mine
had
to
install
it
for
the
first
time
they
had
like
a
trouble
for
like
a
day,
and
then
they
asked
me,
and
they
pulled
me
in
to
explain
the
whole
country,
repo
and
stuff,
but
from
what
I
understood
it
made
sense
to
them.
After,
like
a
day
of
figuring
stuff
out.
F
A
Thing
right
should
make
a
tutorial
video
yeah.
You
know
that
or
like
maybe
like.
Instead
of
doing
all
this
fancy
stuff
with
our
builds,
we
just
make
our
documentations
really
really
good,
like
really
explicit
for
every
single
use
case
right
because
like
if
we,
if
we
just
add
more
of
these
like
hey,
if
you're
changing
both
of
these,
then
you
do
this
or,
if
you're,
only
making
a
change
to
the
contrib
repo.
Then
you
only
need
to
do
this
like
we're,
making
it
even
more
complicated
for
the
end
user
right
like
that's.
G
Yeah,
I
agree
with
what
nathaniel
was
saying
when
I
was
starting
and
setting
all
of
this
up
to
start
up
the
centralized
sampling
for
aws.
It
took
me
a
while
to
follow
the
documentation
all.
G
A
G
I
Time
right:
okay,
I'm.
I
B
I
I
don't
know
just
assign
someone
onto
that
task.
We
won't
make
much
progress,
so
I
I
understand
that
this
is
a
complicated
time
because
of
metrics
and
logs
and
distros
coming
along.
But
I
don't
know
is:
is
there
someone
who
can
volunteer
to
make
a
plan.
A
Yeah,
I
think
this.
This
also
covers
like
what
to
do.
If
you're
like
trying
to
merge
to
like
a
feature
branch
as
well,
you
know
it'll
be
pretty
comprehensive.
You
know
like
I
can.
I
can
help
you
out
with
this
actually
yeah.
I
mean.
D
I
I
feel,
like
future
branches,
are
a
mistake,
but
that's
just
my
yeah.
A
I
could
see
people
just
not
wanting
to
contribute.
You
know
because
of
this,
so
alright
cool
awesome
thanks
alex
any
anyone
else,
has
any
other
opinions
on
this
topic
before
we
move
on
I'd.
Even
look
at
this
page
holy.
A
B
A
Yeah
idea:
dump
cool
awesome,
wait
what's
next,
was
this
just
recently
added.
A
A
C
A
Then
I
think
it's
fine,
then
right
yeah.
That
was
what
our
that
was.
What
we
decided,
oh
by
the
way,
is
your:
is
your
checklist
thing
pr
merged
yet.
F
K
F
For
all
tickets,
yeah.
F
Thanks
guys,
this
is
part
of
kind
of
the
discussion
we've
been
having
for
the
last
few
months
about
getting
ready
to
release
stuff
in
contrivas
1.0.
We
talked
about
instrumentation
for
sure
it's
not
there
yet,
and
that
totally
makes
sense
and
we
talked
about
kind
of
the
stuff
that
needs
to
be
going
towards
it.
But
this
is
separate
from
that.
It's
just
something
that
you
know
our
aws
users
have
been
using
already.
We
just
want
to
at
aws
provide
the
stability
guarantees.
F
So
as
long
as
you
guys
are
okay
with
it,
and
you
know,
we
provide
our
our
confidence
that
we
will
be
attending
to
it,
making
sure
it's
stable
after
we
release
the
1.0,
then
yeah
it'd
be
great.
If
you
guys
could
help
me
publish
it
with
my
new
feature
that
we
can
just
put
a
tag
and
it
gets
published,
so
you
can
test
it
out.
F
A
You
so
much
yeah
after
we
get.
F
A
Okay
sounds
good.
Anybody
have
another
any
other
topics
they
want
to
cover
before
we
go
into
prs
and
issues
is
the
kant
here.
Yet,
okay,
I'll
just
see,
what's
up
with
this,
it's
the
otlp
thing
right.
A
Is
there
anything
pretty
sure
this
is
ready
to
merge,
I'm
not
sure
if
he
was
just
waiting
for
more
approvals
or
he's
just
trying
to
fix
the
build,
but
since
he's
not
here
I'll
just
go
over
this,
I
don't
want
to
assume
what
he
was
thinking.
H
H
A
huge
number
of
pictures
and
fixes,
so
I
I
suggested
the
author
to
to
split
it
up.
I
brought
it
up
because
maybe
we
should
have
this
like
as
an
official
contributing
guideline
that
you
should
try
to
split
things
if
you're
right,
using
multiple
issues
or
adding
features
and
fixing
issues.
D
A
You
know
if
you
ignore
the
tests,
it's
only
500
or
actually
no,
it's
like
only
it's
like
a
thousand
still
geez.
F
This
is
really
interesting
because
I
noticed
that
kind
of
gap
between
our
instrumentation
and
the
semantic
conventions
or
like
the
specs
for
the
aws
sdk,
like
the
I
had
to
work
on
the
javascript
one
last
month
and
it's
huge
like
they
had
a
whole
raid
before
it
and
they
did
a
bunch
of
stuff.
So
maybe
ours
is
with
this
pr
going
to
get
to
that
point
too.
A
Cool,
so
this
would
be
part
of
the
making
our
contributing
discussion
better.
I
feel
like
it's
just
right.
It's
part
of
the
whole
experience.
I
guess
something
that
we
just
remember
to
do
when
we
like
make
our
docs
better
or
something
like
that.
A
A
F
Yeah,
I
would
say
so
probably
the
last
person
who
had
comments
was
diego
two
days
ago,
so
I
added
all
his
changes
in
and
address
oasis
comments.
Thanks
for
the
approval
will
love,
if
you
guys
have
a
second
chance
to
look
at
it,
because
I
think
it's
ready
to
be
merged.
It's
just
an
update
to
the
readme.
A
But
yeah
nathaniel
what
you
said
here
I
agree
with
too
so
it
looks
good
to
me
great.
Thank
you
yeah!
So
diego,
if
you
can
just
like
take
another
look
through
this,
then
I
think
we'll
be
good
to
go.
B
Yeah,
so
I
spent
some
time
reviewing
reviewing
this
and
reviewing
sort
of
like
the
spec
and
seeing
where
the
spec
was
kind
of
hard
to
implement
too.
I'm
sure
diego
has
some
places
too
right
now,
it's
I
don't
know
what
happened
with
the
commits,
but
I
think
it
needs
to
be
replaced.
But
if
you
go
to
the
code,
I
think
there
are
a
few
topics
that
we
should
probably
like
bring
up
with
everybody.
B
A
I
That's
something
I
have
been
trying
to
fix.
I
don't
know
why.
I
I
have
like
a
bunch
of
changes
just
to
github,
because
when
I,
when
I
compare
that
to
my
local
repo
those
changes,
don't
don't
don't
show
up.
So
I
need
to
figure
out
what
the
hell
is
going
on.
B
Yeah,
so
basically
look
for
here.
You
can
see
it
right
here.
So
if
you
see
right
here
for
a
counter
the
add
method,
which
is
like
how
we
record
when
we
want
to
add
to
the
to
the
current
instrument,
the
counter
instrument
like
diego's
prototype,
has
attributes
as
keyword
as
like
named
arguments,
keyword
arguments
that
are
captured.
I
I
personally
don't
like
it,
but
I
think
diego
has
has
a
strong
opinion
too.
I
Yeah,
so
to
make
a
summary:
aaron
wants
those
functions
not
to
use.
I
mean
double
asterisk
and
keyword
arguments,
but
a
dictionary
object.
I
think
it's.
I
think
that
the
right
python
feature
for
this
situation
is
to
use
the
velocity
risk,
but
this
is
something
that
I
think
we
may
end
up
going
with
iron
suggestion,
because
of
the
here
is
an
important
point
that
the
slash.
I
B
Okay,
okay,
I
guess
we
don't
need
to
discuss
then,
unless
anybody
wants
to
add
anything
or
under.
Does
everybody
understand
the
context
here.
B
Okay
cool,
so
then
the
next
thing
was-
and
this
is
not
super
clear
in
the
spec-
I
think
in
the
counter
add
you'll-
see
that
the
the
prototype
here
checks
that
the
value
for
like
a
not
for
a
monotonic
counter
is
positive
or
rather
non-negative.
B
So
I
think
to
me
it
seems
like
we
should.
We
should
not
raise
here,
but
I
think
there's
like
definitely
room
for
for
interpretation
and
at
like
a
minimum.
We
should
probably
be
logging
so
that
people
can
find
instrumentation
errors
like.
I
Okay,
yeah,
I
was
just
asking
because
I
did
not
understand
really
what
what
you
were
suggesting
on
your
previous
comment,
but
I
think
your
last
comment
makes
it
clear,
yeah.
Oh,
I
can
turn
that
into
a
a
warning
instead
of
an
exception
being
raised.
B
I
B
Go
with
what
you
were
about
to
say:
okay,
okay,
so
yeah
here
here
that
was
it
go
back
up,
so
the
spec
does
say
something
about
instrument
names
having
to
be
unique
for
a
meter
instance.
B
But
it's
not
super
specific,
so
I
I
talked
with
josh
who's
been
working
on
this
and
just
for
suret
from
google
yeah.
I
think
the
intention
here
is
mainly
like.
If
you
look
at
the
data
model,
we
don't
want
to
have
multiple
writers
for
like
a
an
instrument
or
like
conflicting
definitions
for
a
given
instrument,
name.
B
So,
given
that
there's
also
the
question
like
what,
if
I
asked
for
a
meter
with
the
same
instrumentation
library,
same
version
same
scammer
version,
and
then
I
asked
for
like
conflicting
instruments
and
then
there's
also
the
the
possibility
that
we
can
return.
Somebody
asks
for
the
same
instrument
again
and
it's
compatible.
We
can
return
the
previous
instrument
instance,
rather
than
raising
the
exception
here.
B
I
But
so
what
exactly?
Is
that
you
arguing,
against
the
exception
being
raised
or
the
fact
that
we
don't
accept
the
name
to
be
reused?.
B
So
yeah
the
exception.
The
exception
is
like
a
separate
thing:
okay,.
I
Yeah,
but
we
I
think
we
agreed
on
that
already
right,
so.
B
I
I
No,
we
will
definitely
not
raise
an
exception,
because
that's
not
something
that
we
should
do
in
the
api,
but
yeah,
but
you
you
don't
want
the
instrument
to
go
and
instead
to
log
an
error.
That's
what
you
want.
B
I
I
Okay,
okay,
do
you
I
don't
have
any
objection
with
that
approach
either.
Do
you
want
to
add
that,
as
a
comment
or
in
the
discussion.
B
Yeah
yeah,
I
I
can.
I
was
wondering
if
anybody
else
has
an
opinion
and
then
there's
like
I
said,
there's
also
the
complication
of
if
somebody
creates
multiple
meters
with
exactly
the
same
instrument,
name,
schema
version
and
sorry,
instrumentation
library,
schema
version
and
version.
Can
they
like?
Basically
do
we
need
to
keep
track
of
these
instruments
at
the
meter
provider
level
instead
of
just
the
meter
instance
level.
B
So
it
is
because
it's
the
instrumentation
library
name
and
version
it's
given
version,
no.
A
No
but,
like
you
said,
that's,
that's
not
unique,
because
multiple
meters
can
use
the
same
instrumentation
info
right,
I'm
talking
about
like
the.
B
A
Uniqueness
checks,
I
don't
think
so,
no
right,
but
so
so
yeah.
So
my
question
is
like
just
based
off
what
you
said.
Should
we
also
make
the
meter
instance
be
part
of
the
uniqueness
of
it
or
like
what?
In
the
flip
side,
it's
like?
The
only
uniqueness
is
about
the
instrumentation
info
name
and
description,
and
so
like.
Yes,
we
would
have
to
keep
track
of
it
at
the
meter
provider
level.
In
that
case,
right.
B
Unless
they
have
the
same
instrumentation
library
and
version
and
schema
version
right.
D
B
Yeah,
so
in
the
spec
in
the
spec,
that's
basically
what
it
says.
I
think
meter
instance.
I
don't
know
if
it
uses
the
the
word
instance,
but,
like
I
I
know
from
from
reading,
like
the
data
model
and
just
following
the
metrics
say
what
they
mean
is.
Basically
you
don't
want
to
have
multiple
metric
streams
that
are
conflicting
right.
I
A
Yeah
so
then,
in
that
case,
it'll
be
it's
just
this
implementation,
because
because
because
the
the
instrumentation
names
falls
under
this
meter
instance
right.
B
Right
again,
unless
they
ask
for
another
meter
with
the
same
stuff
from
the
meter
provider,
like
I'm
just
trying
to
say,
there's
multiple
ways:
we
can
implement
this.
If
anybody,
if
anybody
has
suggestions
like,
I
think
we
could
do
it
correctly
in
several
ways.
A
Right
yeah,
I
guess
we
could
I'm
not
sure
of
the
implications
of
either
right
now
we
could
just
continue
the
discussion
on
the
on
the
pr
unless,
if
someone
has
anything
pressing
right
now
about
it,.
I
A
B
A
And
it's
it's
always
the
same
instance
that
they
return
right.
If
they
do
it,
multiple.
B
Times,
oh
it!
So
if,
if
it's
like
exactly
the
same
definition,
we
could
give
the
same
instance
and
then,
if
they
give
a
conflicting
one,
we
would
we
would
return
like
a
no
op
in
that
case,
to
the
second
caller.
A
B
Aaron,
do
you
want
to
talk
about
the
grouping
and
adding
topic
now
sure
sure?
So
I
think
we
talked
about
this
last
week
as
well.
Basically,
there's
in
this
prototype
there's
I
didn't
put
a
link
layton,
but
if
you
just
search
for,
I
think
grouping
in
the
I
don't.
J
I
It
is
oh
no,
but
that's
that's.
Oh
yes,
there's
a
line,
73
class
grouping
and
in
1969
class
adding
none
of
those
concepts
is
defined
in
the
spec
the
grouping
and
adding
is
something
that
it's
it's
a
concept
that
I
think
was
introduced
by
josh
mcdonald,
the
beginning
of
the
metrics
project,
and
it
pretty
much
me
to
identify
the
different
type
of
types
of
quantities,
those
that
can
make
sense
when
they
are
added
up.
For
example,
bytes.
I
I
have
an
example
now,
but
anyway,
the
the
point
is
that
that
is
not
defining
the
in
the
spec.
It
is
a
concept
that
I
found
very
valuable
to
have,
and
I
implemented
it
here.
I
can
make
these
things
private.
I
I
B
Do
you
think
erin
yeah,
so
I
my
opinion
is
like
since
they're
not
formally
defined
it's
a
little
bit
confusing
like.
Obviously
it's
not
in
the
spec,
like
you
said,
and
if
we
don't
have
like
a
use
for
it,
then
maybe
we
can
leave
it
out
for
now
and
add
it
later
and
definitely
at
a
minimum.
I
agree
with
what
you
said
about
making
it
private.
I
think
o.a
thumbs
up
this
comment.
I
don't
know
if
you
want
to
share
your
opinion
away.
I
Yeah,
I
can
make
them
private.
I
don't
want
to
remove
them
from
the
I
mean
completely,
because
they
I
find
them
useful
and
also
because
I
don't
want
to
mess
up
any
inheritance
path
already
so
yeah.
I
think
we
can
agree
on
just
making
them
private
for
the
time
being.
I
What
happens
is
that
the
classes
as
they
are
right
now
are
a
bit
of
a.
They
are
an
inheritance
to
you
right
I
mean
that's,
that's
why
these
classes
exist,
so
that
you
can
query
an
instrument,
for
example
an
uptown
counter
and
ask,
is
instance,
is
this
counter
monotonic?
Is
this
counter?
Adding?
Is
this
counter
grouping
by
querying
the
the
instance?
I
So
in
that
way
you
can
treat
instruments
differently
and
you
have
like
a
very
easy
way
to
know
the
kind
they
are
right.
So
that's
why
these
inheritance
three
exists,
so
that
instruments
get
categorized
and
the
end
user
can
query
on
that
and
ask
this
so.
I
If
we
remove
them
completely,
they
we
also
are
removing
the
capability
of
making
these
kind
of
queries
on
the
instrument
and
these
since
the
adding
and
the
grouping
instruments
have
come
behave
differently.
I
visualize
this
information
being
useful
for
the
user
when
they
want
to
treat
instruments
in
a
different
way,
depending
on
their
kind.
I
No,
it's
instance,
I
mean,
if
you
take
an
instrument
like,
for
example,
another
encounter
right,
yeah.
B
A
I
But
this
way
in
I
mean
that's
why
these
classes
exist,
because
in
that
way
it's
convenient
and
easy
for
the
user
to
treat
instruments
differently,
depending
on
their
nature
right
on
the
concepts
in
the
api.
I
agree
yeah.
That
makes
sense,
so
I
think
we
can
just
make
them
private
for
the
time
being
in
order.
B
I
To
lose
this
information
completely,
I
know
it's
less
than
ideal
right
because
you
don't
want
to
query
on
a
private
argument,
but
for
the
time
being,
I
think
that's.
B
Good
enough,
can
you
just
leave
a
comment
there
and
then
that
should
be
that
that
makes
sense.
For
now
we
can
discuss
more.
I
think
there
are
two
more
issues,
so
we
have
a
minute.
H
This
is
this,
is
this
is
different,
but
we
have
a
bunch
of
salary
tests
that
are,
they
have
already
been
disabled,
and
this
explains
why
they
like
how
to
fix
them.
So
if
anyone
wants
yeah
great.
A
H
Yeah
I
added
this,
but
this
looks
like
an
interesting
bug.
I
don't
know
if
it's
a
bug
or
if
it
if
this
is
how
it's
supposed
to
work,
I
haven't
looked
into
detail.
I
thought
maybe
yeah.
A
Okay,
cool
cool
awesome.
All
right
looks
like
we're
out
of
time
unless,
if
anyone
else
has
any
other
pressing
topics,
I
will
see
you
guys
next
week.