►
From YouTube: 2022-01-20 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).
B
Last
week,
but
yeah.
B
How
we
doing
time
what
okay,
1pm
101
actually
yeah,
it
doesn't
look
like.
We
have
anything
on
the
agenda.
I
don't
know
if
I
have
too
much
on
the
agenda.
I
just
think
it's
one
of
the
I
wanted
to
check
in.
I
did
notice
aaron.
We
had
talked
about
the
recording
status
of
this
meeting.
I
joined
it
said
that
it's
recording
it
so
yeah.
I
don't
know
if
it
said
that
last
week,
but
hopefully
this
one
gets
posted
and
is
recorded.
I
guess
xm.
D
Are
we
looking
at
a
new
meeting
document
meeting
notes
document?
I
couldn't
find
one
that
looks
familiar
and
this
document's
strangely
full
of
names
from
when
I
clicked
into
maybe
I'll
put
it
I've.
B
Yeah
yeah
that
doesn't
sound
good,
so
josh,
I
put
it
in
oh
there's,.
B
Yeah,
it's
especially
with
the
switch
to
the
per
calendar.
I.
B
D
D
B
Cool,
so
let's
dive
in
here
see
if
I
can
figure
out
how
to
share
my
screen.
Really
quick
looks
like
we
have
some
things
to
talk
about
nothing
too
much,
which
is
always
good.
A
I
hope
I
got
the
right
link
but
I'll
take
over
the
first
item.
If
you're,
okay,.
A
No,
no,
that's
fine!
It's
just
the
proto
version.
12
dropped.
I
just
put
in
a
pull
request
like
a
couple
minutes
before
this
meeting,
so
I
just
wanted
to
bring
people's
awareness
to
it.
B
E
This
is
removing
a
bunch
of
deprecated
fields
from
the
trace
and
metric
data
model
and
I
think,
there's
a
log
related
change
as
well,
but
that
should
be
additive,
so
I
don't
think
that
this
will
be
impacting
on
us
in
any
way.
We
should
have
already
changed
our
exporters
to
not
use
those
deprecated
fields,
but
the
test
will
tell
us,
I
think.
A
The
only
thing
that
I
can
see
being
a
problem
is
they
renamed
a
log
field,
but
it's
also
in
our
log
message,
which
is
you
know,
it's
unstable,
so.
E
B
Yeah,
I
agree,
I
think,
that's,
for
if
you
want
to
adopt
something
early,
be
aware
of
these
sort
of
things.
B
Cool
looks
good
to
me.
I'm
guessing.
I
probably
want
another
review
on
that,
so
somebody
has
some
time.
I
think
I
remember
the
deprecated
feels
I
think
we
should
be
okay
as
well.
Aaron
is
your
plan
after
that
upgrade
our
internal
use
in
the
otlp
okay
and
then
has
that
anthony.
Does
that
make
sense
from
the
collector's
standpoint?
Should
we
wait
for
the
collector's
support
v012
or
have
they
already.
E
There's
there
was
an
issue
open
today
to
do
that
as
well.
The
lease
just
happened,
so
it's
not
there
yet,
but
because
this
is
only
removing
deprecated
fields
and
I
don't
think
we're
using
them
anymore.
It
shouldn't
be
an
issue.
Okay,.
B
Cool
all
right
that
sounds
good
moving.
A
On
to
the
collector
use
a
completely
separate
implementation,
they
don't
use
this
package.
B
Oh
no
yeah,
they
don't,
but
it's
a
compliance
thing
of
message:
protozoa
like
yeah
you're
right:
they
use
they
even
use
a
different
proto
compiler,
but
there
have
been
in
past
breaking
changes
to
the
proto.
We
would
have
sent
valid
payloads
based
on
new
proto
payloads,
so
just
make
sure
that's
not
the
case
which
it
doesn't
sound.
Like
is
the
case
yeah.
What's
the
question.
E
B
Okay
josh
as
a
follow-up,
I
wanted
to
say
I'm
kind
of
bummed.
I
saw
that
you
all
reviewed
the
implementation
that
you
had
last
week.
It
unfortunately
didn't
get
recorded
or
shared
we're
still
trying
to
track
that
down.
So
I'm
I'm
pretty
bummed
about
that,
but
I
have
been
looking
at
some
of
the
work.
You've
been
doing
so
maybe
I'll
hand
it
off
to
you
as
a
follow-up.
I
remember
you
were
talking
about
this
sure.
D
Well,
I
I
didn't
want
to
like
dominate
this
meeting
the
way
I
did
last
time
because
it
was
it
was
hopefully
somewhere
I
mean
maybe
recorded,
but
I'm
happy
talking
about
it.
I
have
now
been
programming
with
generics
for
two
weeks.
Just
about
the
presentation
I
made
two
weeks
ago
was
when
we
first
asked
the
question
and
I
had
been
working
on
a
prototype
at
that
point.
I
just
branched
that
prototype
and
started
using
generics
and
learning
it
at
that
moment.
D
It's
looking
good
and
feels
really
right
to
me,
and
I
do
have
a
an
implementation
of
views,
but
it's
it's
still
like
a
skeleton
and
I
haven't
finished
an
end
to
end
like
even
like
hello,
world
version,
yet
learning
so
I
wouldn't
I've
proposed
to
talk
in
a
week.
D
2018
is
or
1.18
is
even
out.
I
think
we
have
time
to
do
some
generic
work
and
learning
together
before
we
make
that
move.
If
we
do
anthony
was
going
to
ask
answer
the
question
about
whether
it
would
be
feasible
for
us
to
separate
our
minimum
version
requirement
into
metrics
and
trace
and
then
have
metrics
have
minimum
1.18
soon
after
february's
release
of
that
version
of
the
runtime.
D
So
that's
an
open
question
and
I
think
we
could
probably
wait
to
talk
about
that
again
like
to
re
to
rediscuss
the
motivation
for
using
generics
inside
the
sdk.
But
you
can
probably
imagine
it
given
what
you
know
of
thing,
with
three
three
or
four
different
aggregators
and
two
different
number
types
and
so
on
anthony.
Did
you
want
to
respond
on
that
point?.
E
D
Yeah
just
just
to
to
clarify,
I
think,
you're
you're
sort
of
being
diligent
and
doing
a
technical,
like
validation,
that
this
approach
will
work.
But
it's
it's
also
a
policy
question
of
whether
we
are
willing
to
say
user.
If
you
want
to
try
out
our
now
our
metropix
api
or
sdk,
you
you're,
going
to
have
to
build
with
go
1.18,
whereas
you
could
use
trace
with
a
1.17
for
like
some
somewhere
around
six
months.
Maybe
is
what
we're
saying.
E
E
I
just
want
to
make
sure
that
that
is
an
option,
that's
open
to
us.
Technically.
If
we
decide
to
go
down
that
road,
I
think
we
can
defer
the
decision
of
whether
to
go
down
that
road
until
later
on.
If
it
is
open
to
us,
if
it's
not,
then
obviously
the
decisions
made
for
us
cool.
B
Awesome
yeah
thanks
for
the
the
recap.
I
also
know
that
aaron
anthony
and
I
met
earlier
this
week
to
talk
a
little
bit
about
metric
project
planning.
I
don't
know
where
we're
at
exactly
on
that
one,
but
just
kind
of
sync
with
the
rest
of
the
community.
The
plan
here
is:
do
something
similar
to
what
we
did
in
the
traces
1.0
release
in
validating
that
we
have
complete
implementation
of
the
metrics
api.
B
That
is
also
something
I
think
maybe
point
out
is
that
we
wanted
to
split
the
especially
the
development
work
from
the
api
and
the
sdk.
Given
that's
how
the
s?
The
specification
is
split
right
now,
and
the
next
goal
is
to
do
an
audit
of
our
api
and
not
necessarily
fix
it,
but
identify
any
gaps
or
any
oversights
that
we
have
in
the
api
and
make
sure
that
they're
documented
the
things
that
we
need
to
implement.
B
It
also
behooves
us
to
take
a
look
at
the
things
that
we've
implemented,
that
aren't
specified
and
making
sure
that
we
don't
want
to
support
those
in
the
long
term
or
we
commit
to
supporting
them
in
the
long
term.
So
recognizing
that
and
also
capturing
those
as
issues
so
that
we
can
have
discussions
about
them,
particularly
asynchronously
in
issues
or
in
this
meeting
here,
probably
in
the
future.
So
just
keep
in
mind,
that's
that
should
be
on
the
horizon.
B
D
We
had
we
talked
about
three
different
sort
of
areas
and
questions
last
time
it
was
the
api,
the
sdk,
and
this
also
the
sort
of
like
leftover
question
about
the
sdk
api
thing,
which
I
you
know
we
have
currently
the
the
lead
into
last
week's
presentation
that
I
gave
was
now.
D
I
remember
why
the
only
ever
good
justification
for
the
sdk
api
was
that
we
didn't
have
generics
and
if
we
do
have
generics-
and
it
seems
like
we
do
and
that's
then
I'm
all
in
on
eliminating
the
sdk
api,
and
I
I
doubt
anyone
would
disagree
if
they
with
that
statement
right.
D
D
It's
the
asynchronous
instruments
which
are
just
like
heavyweight
and
awkward
to
use
and
awkward
to
implement
and
full,
like
just
the
number
of
lines
of
code,
is
pretty
bad
all
in
the
name
of
getting
an
sdk
api.
So
if
you've
given
up
on
the
sdk
api,
then
I'm
I'm
absolutely
convinced
that
throwing
away
at
least
the
asynchronous
part
of
the
api
is,
is
like
the
next
thing
to
do.
At
that
point,
like
you
know,
or
the
wish
list
that
we
I
think
we've
always
had.
Is
that
that
you
start
with
a
go
doc?
D
D
Would
you
read
your
go
doc
and
make
sure
that
meets
the
specification
we
can
implement
and
I'm
volunteering
at
this
point
like
I
can
clarify
if
it
needs
to
be
but
like
right
now
we
have
this
existing
sdk,
which
I'm
the
most
familiar
with,
because
I
wrote
most
of
it.
It
is
matched
to
the
existing
api,
which
I
would
like
to
throw
away.
We
can,
but
because
we
had
this
sdk
api
in
place.
Now
that
was
one
of
its
justifications
was.
D
It
allows
us
to
change
apis
without
changing
sdks,
so
I
can
do
the
work.
It's
not
going
to
be
very
pleasant
of
getting
us
off
the
old
api
in
a
like
a
transition
plan
where
we
will
create
a
new
api
market
stable
and
continue
to
implement
the
old
api.
The
way
I
do
it
would
be
to
implement
the
new
api,
get
it
reviewed
and
whatever
awfulness
has
to
happen
to
make
that
new
api
work
with
the
existing
sdk
just
do
it.
D
We
have
some
tests
I'll
make
them
pass
and
then
we'll
be
able
to
release
a
version
where
we
have
a
new,
stable
api
or
we'd
like
to
like
we're
close
to
we'd
like
to
start
finalizing
on
the
stable
api.
It
functions
because
it's
been
back
ported
onto
the
old
sdk,
we're
declaring
the
old
sdk
to
be
end
of
life.
Soon
we're
looking
forward
to
a
generics-based
implementation.
We
have
some
prototypes,
hopefully
we're
more
than
one
prototype.
D
I
would
like
to
not
be
the
only
one
in
the
room
writing
the
code,
but
if
you
know
because
it's
hard
to
say
this
is
better
than
that,
when
there's
only
one
version,
but
I
think
that
would
let
us
move
forward
like
independently
and
then
when
the
new
sdk
is
available
and
tested
and
ready
to
go,
it
will
be
targeted
to
the
to
the
new
api,
not
the
old
api.
The
old
api
will
be
dead
after
one
or
two
releases.
This
way,
that's
my
pitch.
D
E
Yeah,
because
I
remember
you
saying
that
the
the
api
itself
wouldn't
depend
on
generics,
it's
just
that
generics
makes
it
easier
to
implement
the
api.
So
I
think
I
really
like
that
approach
and
that
also
kind
of
dovetails
with
in
another
week
or
two.
We
should
have
the
the
project
built
out
to
do
the
audit
of
the
api,
so
we
can
work
that
against
a
new
implementation
of
the
api
rather
than
the
current
one,
which
we
already
know
is
is
offspec
in
many
many
ways.
D
Yeah,
that
sounds
I
mean
like
I'd
like
to
hear
from
others,
but
I'm
I
hope
that
sounds
good
to
people
and
then
I
I
could
tease
you
all
with
just
a
look
at
the
api
that
I
pitched
last
week.
I
think
I'm
kind
of
working
on
an
end-to-end
pro
type,
so
it's
full
of
stuff
kind
of
I
moved
through
it.
But
what
we
didn't
talk
about
exactly
was
the.
A
A
My
understanding
is
the
the
your
current
approach.
The
way
you
want
to
approach
it
is
to
create
the
new
s,
the
new
api,
the
way
you
want
it
to
be
and
then
have
in
the
current
open,
telemetry
metrics
namespace
be
the
kind
of
translation
layer
from
that
to
the
current
api
sdk
api,
which
our
current
sdk
implements,
so
it
will
automatically
transition
over
there.
A
Doesn't
that
mean
we're
tied
to
the
current
sdk
api,
like
we
can't
actually
pull
like
that
eventually
has
to
become
part
of
the
canon
of
what
we
we
have
deemed
acceptable.
D
No,
no,
I
don't
think
so,
but
I'm
I'm
probably
not
being
very
clear.
The
the
everything
that's
in
the
current
metrics
sub
package
would
will
go
away
everything
completely,
so
maybe
the
simplest
way
to
imagine
organizing
that
would
be
to
move
it
all
into
a
new
package
sort
of
like
somehow
to
indicate
that
it's
we're
trying
to
get
you
off
of
this
prime
real
estate,
which
is
the
slash
metrics
package,
because
we
want
to
change
it.
What
that's
our
v2
yeah,
I
mean
yeah.
B
B
D
Actually
didn't
mean
to
try
and
dictate
the
rear
shuffling
of
packages.
That
was
one
thought
that
came
to
mind.
You
just
just
explained
why
I'd
break
stuff-
I
you
know,
probably
the
better
approach
is
to
do
it
with
it
all
within
the
package.
Then
I
I
I
this
is
project
planning
work
and
I
would
like
to
defer
to
you
on
that,
but
the
proposal
I
have
is
puts
very
little
in
that
metrics
name
space,
so
it
might
be
able
to
be
like
swapped
in
without
conflicting.
D
It's,
however,
currently
meter
is
a
struct
and
it
becomes
an
interface.
So
we
have
a
problem
and
I'll.
Let
you
all
create
be
creative
about
that.
I
I
just
do
I
also
don't.
I
also
want
to
try
and
accelerate
us
a
little
bit
because
I've
been
working
in
the
sdk
specification
forever,
as
well
as
the
api
specification
forever.
So
I
really
am
familiar
with
both
and
I
you
know
so.
I
feel
like
I
can
pitch
you
an
api
proposal.
D
That's
going
to
fairly
well
satisfy
those
specs,
or
at
least
get
you
close
enough
that
you
can
read
through
the
spec
and
the
and
the
proposal
like
one-to-one
and
and
look
at
them.
B
B
I
I
would,
I
think,
it's
kind
of
come
to
the
point
where
you
just
need
to
be
a
little
more
brutal
and
you
need
to
just
cut
cut
the
old
and
put
the
new
api
in
there
and
in
our
change
log.
We
need
to
be
you
know
apologetic,
but
to
the
point
of
the
fact
that
it's
not
a
stable
release,
and
you
know
that
you
want
to
try
to
build
a
better
api
like
it.
Keeping
the
old.
B
D
Maybe
if
you
want
to
be
brutal,
but
gentle
a
little
bit
is
we're
going
to
move
the
package
name.
Everything
in
that
old
package
moves
to
like
old
v
old
version
old,
and
if
you
must,
if
you
I'm
we're
sorry
for
that,
but
this
is
going
to
make
us
move
fast
faster.
We
have.
We
have
in
a
single
release
cycle,
put
a
new
api
in
place
where
the
old
one
was.
We've
moved
the
old
one
to
an
out
of
the
way
location
where
you
can
just
update
your
paths.
It
should
work
continue
to
work.
D
It
will
continue
to
work,
and
I
have
done
some
messy
work
as
I'm
saying
or
promising,
to
make
the
new
api
work
with
the
old
sdk,
so
that
within
one
release
cycle,
you'll
have
to
update
your
paths.
If
you
want
to
keep
using
the
old
api,
the
new
api
is
now
available
and
and
and
works
as
well
as
at
least
the
old
one
dead.
That's
that's
what
I'm
imagining!
It
is
a
little
brutal.
B
B
E
In
providing
a
transition
path,
but
I
I
think
we
know
where
users
are
gonna-
have
to
make
a
change
and
if
we're
going
to
have
a
working
implementation
of
the
new
api,
let's
just
throw
away
the
old
one
and
make
them
make
the
change
once
it
might
be
a
slightly
harder
change
than
just
changing
some
pads.
But
this
we've
still
got
tags
for
the
old
versions:
they're
they're
able
to
pin
themselves
to
the
old
versions
until
we're
able
to
make
that
change,
yeah,
100
yeah,
and
it's
better
than
dragging
this
out.
I
agree.
D
Cool
well,
so
then
the
question
is
the
sdk
api
directory.
Is
that
something
we
can
move?
That
was
never
meant
to
be
considered
public.
I
don't
think
people
are
depending
on
it,
but
maybe
that's
something
you
can
move
with
aliases
over
a
release
cycle
or
two
yeah,
so
I
I
I
would
be
able
to
do
that.
I
now,
if
you
wouldn't,
if
you
know
I
don't
know,
there's
nothing
else
on
the
agenda
yet.
So
let
me
show
you
this
a
little
bit,
so
I
dropped
you
into
the
pr
I've
been
hacking
on.
D
This
is
the
view
implementation,
but
let's
just
go
into
the
metric
package.
As
I
mentioned
the
last
time,
the
config
package
is
literally
unchanged,
except
I
removed
some
stuff
because
there's
no
longer
just
instrument,
config
is
gone.
There's
just
meter,
config,
there's
a
sub
there's
a
interface
called
meter
provider.
That's
that's
unchanged.
Meter
option
is
unchanged
meters
now
interface,
and
this
is
this:
is
it
five
methods?
If
you
want
to
build
an
instrument?
D
You
say
whether
it's
synchronous,
which
or
not
whether
it's
integer
or
floating
point
and
the
reason
why
I
want
to
put
these
in
separate
packages-
is
that
they're
very
similar
each
one
of
these.
These
two
synchronous
packages
are
practically
identical
and
the
two
async
packages
are
practically
identical
and
between
the
two
there's
a
lot
of
similarity
as
well,
so
there's
a
counter
method
in
every
one
of
them.
So
as
far
as
the
godoc
presentation,
every
one
of
them
kind
of
looks
the
same
and
the
user
is
going
to
get
real.
D
D
In
other
words,
this
is
the
meter
interface
for
constructing
instruments
of
a
synchronous,
integer
instrument,
same
exact
thing
for
the
floating
point
instruments,
so
they
have
practically
the
same
job.
You
can
see
me
switching
there's
only
integer
and
floating
point
differences.
D
Yeah,
I'm
being
conservative,
I
I
I
don't
know
that.
That's
what
what
anyone
wants!
I
I
was
I
was
trying
to
validate
the
question
about
the
sdk
last
time
and
I'm
still
trying
to
validate
a
views
implementation.
So
I
am,
I
am
personally
not
against
generics
in
the
api.
D
And
they
can
improve
on
some
things.
That
would
be
a
separate
type
of
feasibility
study
and
there's
one
I'd
be
glad
to
do.
Yeah.
D
D
D
D
B
C
I'm
not
sure
I
follow
the
entire
thing,
but
in
java
they
have
an
interface
for
every
instrument
type,
but
they
end
up
because
it's
java,
they
end
up
with
one
class
that
implements
multiple
interfaces
on
the
sdk.
So
so
the
sdk
can
be
simplified
in
that
regard,
because
you
can
have
only
one
class
implementing
multiple
interfaces.
B
Okay,
I
think
I
see
because
it's
not
an
explicit
it's
an
implicit
implementation
of
an
interface
yeah.
C
But
you
can
either
even
do
the
same
thing
here
I
mean.
The
only
thing
that
you
cannot
do
is
I
think
java
go,
does
not
support
overloading,
which
is
a
lot
of
a
problem
in
this.
If
you
are
using
so
essentially,
you
cannot
implement
with
the
same
struct
because
of
the
overloading
problem
here,
because
you
have
record
function
on
multiple
interfaces
and
they
have
different
signatures.
So
hence
you
cannot
do
that.
C
I
don't
know
if
the,
if
the,
if
the
generics
will
help
with
that,
because
I
think
with
the
generics
that
may
help
on
the
implementation
side,
implementation.
If
you
have
a
method
record
that
accepts
end
or
float,
I
think,
on
the
implementation
side,
you
can
have
only
one
struct
implementing
two
interfaces.
D
C
D
D
You
would
have
to
have
a
templatized
method,
so
what
I
can
do
is
make
a
an
interface
just
be
like
that's
generic,
so
I
could
have
a
meter
for
integers
and
I
could
have
a
meter
for
floating
points,
but
that's
not
what
we
want.
Yeah
you
end
up
having,
so
that's
that's
why
I
concluded
that's
probably
not
the
time
to
try
and
do
generic
api,
so
I.
C
Think
it's
interesting
yeah
can
I
can
you
try
one
thing:
if
you
have
two
interfaces,
one
record,
let's
say
a
long
counter
that
accepts
in
the
record
or
add
or
whatever
is
called
the
function
accepts
long
like,
except
in
64.
and
on
the
other
one.
You
have
another
record
that
accepts
float64.
C
D
That's
what
I
showed
the
start
of
last
week
and
yes,
I
have
a
prototype
that
the
implementation
gets
a
lot
nicer.
Yes,
but
the
the
kind
of
generic
help
you're
we're
kind
of
imagining.
I
feel
like
it
falls
apart
and
I
and
I
would
have
to
do
a
little
more
work
to
shout
out
to
you.
But
but
but
you
could
imagine.
D
The
meter
has
a
generic
interface
for
integer,
like
measurements
and
a
generic
measure
interface
for
floating
point
like
measurements
and
now
you're
going
to
create
instruments
that
somehow
know
how
to
use
one
interface
or
the
other
based
on
whether
they
were
naturally
floating
point
or
naturally,
not
naturally
integer.
And
I'm
not
saying
it's
not
going
to
work.
But
I
haven't
done
enough
work
to
say,
and
I
don't
think
it
comes
out
as
beautiful
as
you're
imagining,
because
you
can't
templatize
on
the
method.
B
E
There's
also
value
in
not
having
a
generic
based
api
at
this
point,
because
we
can
move
more
quickly
with
that.
We
can
ship
it
sooner
and
it
can
have
broader
compatibility.
We
don't
have
to
say
our
api
will
only
work
with
118
that
can
continue
to
work
with
117,
so
we
can
start
folding
it
in
instrumentation
without
worrying
about
version
issues,
whereas
the
sdk
is
the
only
part
that
we
would
have
to
really
say
depends
on
118
and
you
must
use
it.
E
C
We
don't
do
the
template
thing
for
classes
josh,
because
to
avoid
boxing
and
unboxing
java
problem
that
generics
has
to
be
classes,
and
these
are
primitive.
So,
in
order
to
avoid
boxing
and
unboxing,
whenever
you
you
record
things,
we
we
had
to
actually
rely
on
overloading,
essentially
not
on
not
on
generics
to
to
achieve
that.
D
Yeah
and
the
work
I've
been
trying
to
do
here
is
because
all
those
instruments
are
actually
interfaces,
they
they're
they're
unboxed
as
they
enter
the
sdk
and
then
I've
I've
made
it
so
that
for
the
most
part,
once
you've
compiled
a
view,
it's
like
it.
It
is
in
its
natural
type,
all
the
way
through
until
you
get
to
the
exporter
when
it
becomes
boxed
again
in
the
sense
of
you
know,
the
exporter
deals
in
both
floating
points
and
integers.
B
Yeah
this
is
this
has
been
a
really
helpful,
really
small
discussion,
but
I
think
if
this
is
also
pretty
useful
josh,
I
I
think
this
is
something
to
work
on,
as
we
described
from
what
you've
just
shown.
I
think
that
I'm
totally
in
support
of
just
ripping
it
out
and
showing
that
new
interface.
D
Maybe
okay,
so
I
was
I
was
trying
to
finish
and
and
with
like
several
demonstrations
at
once,
which
is
maybe
a
mistake
I
can
also
for
for
next
week
try
and
prepare
like
here's,
an
api
proposal
that
I
like
and
here's
one
with
generics,
and
you
can
see
I
mean
like
I
can.
I
can
give
a
mock-up
of
those
too
if
that
would
help,
but
I
appreciate
hearing
that
you're
willing
to
do
the
brutal
thing
I'm.
I
am.
B
I
I
just
think
that
time
one
lies
like
people
want
metrics,
and
this
is
going
to
get
us
there
trying
to
have
this
path
from
something
that
was
a
prototype
into
what
has
actually
become
a
stabilized
specification
is
only
going
to
tie
our
hands
and
I
think
that
it's
possible,
but
it's
going
to
be
so
messy
in
the
process
that
it'll
be
more
confusing.
B
I
think
than
anything
I
think
I
think
steve
wilbury
was
saying
like
it's
to
you
know,
have
the
pain
once
and
let's
just
make
it
make
it
happen.
E
It
seems
from
what
from
what
you're,
describing
that
most
of
the
value
is
going
to
come
with
generics
in
the
sdk
and
that
adding
generics
into
the
api
might
actually
add
more
complication
in
terms
of
compatibility
and
getting
that
to
implementation
in
instrumentation.
So
we
should
probably
not
focus
our
efforts
there,
yeah.
D
There's
a
there's,
a
question
about
whether
you
want
like
if
I
could
create
a
custom
type
called
like
something
which
is
an
integer
backed
type
and
when
I
metric
that
does
it
work
or
not,
and
I'm
not
sure
what
the
right
answer
ought
to
be.
And
I
and
I
I
don't
want
to
innovate
here.
I
just
want
to
be
simple
and
like
let's
make
an
api
for
the
pre-generic
world
is
kind
of
what
I
think.
B
I
agree
so
just
to
kind
of
progress
the
conversation
next
week
can
we
expect
a
pr
for
this.
Maybe
even
a
draft
pr
josh
take
a
look
at
this
new
api
and
how
we're
going
to
just
replace
the
metrics
package
with
this,
or
is
that.
D
Something
that's
something
I'm
willing
to
to
aim
for
yeah
the
for
me,
the
most
experimental
pro
aspect
of
what
I
had
done
in
the
api
of
the
pri.
D
It's
pending,
which
I
don't
review
it's
draft,
but
was
this
idea
that
asynchronous
instruments
are
just
synchronous
instruments
inside
of
callbacks
and
in
some
ways
it
makes
everything
feel
nice
and
clean
to
me
and
I'm
gonna
have
to
make
a
bridge
to
get
that
to
work
in
which
will
involve
implementing
12
classes
once
inside
and
the
sdk
and
then
probably
once
inside
the
global
package.
But
whatevs
we
could
do
that.
C
B
D
It
may
not
be
too
hard;
it's
like
it
just
means
like
copying
some
boilerplate
and
making
sure
it
gets
tested.
I
I'll
I
will
definitely
be
focused
on
this
on
the
in
the
coming.
B
Week,
I
I
would
100
support,
not
doing
it
in
the
same
pr.
That
makes
a
lot
of
sense.
Yes,
you
know
where
that
comes
in
in
the
release
cycle.
I
I
think
that
it
needs
to
come,
but
I
don't
know
if
it
needs
to
come
right
off
the
bat.
D
B
Josh,
please
reach
out
on
slack
if
you
need
any
help.
I'd
like
to
progress
this,
like
I
don't
have
much
time
based
on
my
ability
to
commit
these
days,
but
yeah.
D
E
E
D
I
actually
think
this
api
proposal
is
really
easy,
and
so
the
problem
has
been
that
I
was
focused
on
finishing
that
views
back
for
the
sdk
spec
and
a
few
other
things
I'm
reasonably
convinced
of
it
being
like
good.
At
this
point,
though,
I
have
a
few
questions
and
I
want
to
file
them.
I'm
also
like
that's
what
I
need
to
be
doing
as
well.
B
So
I
think,
if
that's
a
good
point,
so
this
is
a
good
conversation
to
have,
because
prioritizing
the
api
work
then
enables
anthony
myself
and
aaron
to
you,
know,
audit
it
and
make
sure
that
we're
compliant
and
that's
something
that
will
take.
You
know
out
of
your
hands,
essentially
so
yeah.
I
think
if
we
could
do
this
and
then
move
to
the
view
stuff,
it
would
help
parallelize
things.
Yeah.
D
Okay-
that's
a
great,
so
I
will
shift
focus
this
coming
week
to
try
and
get
us
off
the
old
api
and
make
a
couple
proposals
at
least
I'll
I'll,
give
a
better
explanation
for
why
generics
aren't
good,
but
I
think
we
are
just
stuck
through
it.
We'll
have
at
least
one
proposal
ready
to
go
in
a
pr.
B
That
sounds
great.
I
think
that
we've
talked
to
this
one,
I'm
sure
if
people
are
not
interested
in
metrics
they're
really
not
tuned
in
at
this
point,
but
if
we
can
kind
of
just
bring
it
back
and
maybe
ask
if
anybody
else
has
any
agenda
items
that
they
didn't
write
down
and
wanted
to
talk
about.
B
Otherwise,
I'd
like
to
ask
if
anybody's
done
some
interesting
things
with
the
open
temperature
go
project
at
all
past
out
in
a
month
two
months
I
know
boxing
was
pointing
out
that
somebody
else
pointed
out.
The
project
is
being
used.
A
lot
there's
like
I
don't
know
it's
imported
by
something
over
700,
maybe
over
800
at
this
point
other
projects,
some
of
which
are
forks
but
I'm
just
gonna,
say
they're
all
unique
and
they're
all
interesting
in
their
own
way.
B
But
nonetheless
I
do
think
that
that's
something
to
congratulate
everybody
on
like
the
work
that
we're
doing
here
is
important.
Don't
don't
think
otherwise,
so
I
I
really
appreciate
it
and
yeah
I.
I
definitely
want
to
say
thanks
again.
E
F
Yeah,
I
was
actually
thinking
about
that.
As
you
put
me
on
the
spot.
There's
two
issues
that
are
relevant:
one
is
in
the
hotel,
go
repository
asking
to
clean
up
the
crosslink
tool,
and
then
one
is,
I
believe,
in
collector
contrib
from
bogdan
asking
for
a
tool
to
automatically
insert
replace
statements
for
intra
repository,
go
modules
right
now.
F
It's
kind
of
done
by
hand
in
the
collector
contrib
and
in
hotel
go
it's
done
by
literally
just
inserting
all
the
replace
statements
possible
for
your
intra-repository
gold
modules,
which
leaves
you
with
maybe
unnecessary,
replace
statements.
F
So
I'm
working
on
a
proposal
to
move
that
into
the
go,
build
tools,
repository
and
also
making
sure
it
only
really
inserts
the
replace
statements
that
are
required,
whether
they're
you
know
direct
dependent
dependencies
or
transitive
dependencies,
then
that
way
it
can
kind
of
pick
be
picked
up
easily
by
either
collector
contrib
or
really
any
other
repository.
That
has
this
kind
of
multi-module
structure
that
we've
been
using
yeah.
F
I
referring
to
the
multi-mod
tool-
yes,
I
I
thought
about
that,
and
I
kind
of
pitched
the
idea
back
and
forth
anthony
about
it
and
my
argument
against
it
was
that
it
serves
a
pretty
strong
purpose
on
its
own
and
having
to
be
run
without
having
to
run
multi-mode,
so
it
existing
on
its
own
and
kind
of
just
doing.
The
pruning
could
be
useful
in
itself.
C
B
F
Cool
yeah,
it's
not
real
knock
on
wood.
It
wasn't
really
a
hard
problem
to
solve.
I
kind
of
have
an
implementation
already
built
out.
It's
going
through
feedback
right
now
for
the
first
phase,
but
yeah
it
it
already
kind
of
exists
on
its
own
and
it's
it's
doing
what
we
want
it
to
do.
I
just
got.
E
Those
moving
crosslink
into
the
go,
build
tools,
repository
so
we'll
be
able
to
share
code
easily
with
multi-mod.
It's
it'll
already
be
showing
the
the
repo
root
finder
and,
and
if
that
module
dependency
walking
is
something
that's
super
common
across
the
two
that
can
be
shared
as
well.
C
It's
not
only
sharing
sharing
is
an
option.
Brian.
The
other
option
is
you
can
release
that
as
a
standard
command,
and
it
can
be
embedded
also
into
multi-mode,
so
you
multi.
If
the
command
is
called
full,
you
can
have
multi-mode
full.
Do
the
same
thing
like
embed
the
entire
program
into
the
other
one.
E
Yeah,
that's
that's
a
good
idea!
Actually,
if
the,
if
the
crosslink
work
is
built
as
a
library
and
a
simple
command
wrapper
on
top
of
it,
then
it
can
be
embedded
as
a
multi-mod
command
multi-mod
using
cobra
that
becomes
fairly
easy.
Brian.
E
If
you
have
any
questions
about
how
to
make
that
work,
let
me
know
I
I
think
we
should
start
with
it
separate
and
then
do
the
the
integration
into
multi-mod
as
a
as
an
after
step,
but
that
would
be
a
good
way
to
keep
them
together,
because
most
of
these
replays
are
already
using
multi-mod,
so
that
would
make
it
one
dependency.
F
That
does
make
sense
yeah
I.
If
we
want
to
go
with
that
I'll,
just
think
my
words.
May
we
just
get
cross-linked
out
there
and
working
first
and
then
we
can
consider
that
improvement
by
just
adding
it
to
as
a
separate
pr.
B
Yeah,
that
sounds
good
okay,
and
I
also
want
to
say.
B
F
Yeah
yeah
yeah
we're
going
through
feedback
sessions,
I'm
hoping
it
doesn't.
I
don't
I.
I
have
something
working
that
works
with
the
simple
test
case
already,
but
we're
gonna
improve
on
it
first
and
when
it's
done
with
the
first,
maybe
round
of
feedback
sessions
and
anthony
gives
it
the
thumbs
up.
I
will
definitely
post
the
doc
for
public
review.
It's
it's
already
kind
of
going
through
those.
B
With
that
awesome
thanks
a
bunch,
brian
yeah
definitely
appreciated
work
for
for
both
us
and
the
collector.
It
sounds
like
so
and
honestly,
this
work,
I
think,
is
crossing
over
into
other
repositories
outside
of
its
own
tree.
This
is
a
pretty
useful,
tooling
set
that
I
think
we're
building.
F
I
I
totally
agree-
and
I
think
you
reminded
me
of
the
second
argument-
is-
I
didn't-
want
to
right
away
integrate
it
with
multi
mod,
because
I
didn't
want
to
force,
maybe
outside
of
open
telemetry
repositories
to
have
to
take
on
that,
like
versions.emo
syntax,
that
it
looks
for
already
when
doing
that.
So
this
could
be
integrated
automatically
without
any
extra
multi-mod
requirements
and
still
handle
those
use
cases.
B
Awesome
thanks
again,
anybody
else
have
anything
interesting.
They
wanted
to
talk
about
of
projects
or
user
stories.
B
Okay,
cool.
Thank
you
yeah.
I
know
I'm
always
interested
thanks
everyone
for
joining.
I
think
we
can
end
it
here
and
we'll
plan
on
seeing
you
all
next
week
and
see
you
over
online
and
yeah.
Thanks
for
trying
everybody.
Oh.
C
Josh
left,
I
was
having
a
question
for
him
because
we
have
a
strong
dependency
on
the
metrics
api
and
I
was
trying
to
get
a
sense
on
when
he
believes
he's
gonna
be
ready
with
that
pr.
B
He
said
before
next
thursday,
so
yeah
sounds
promising.
Okay,
all
right
see
ya.