►
From YouTube: 2022-03-10 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).
C
D
B
I
didn't
see:
oh
thank
you,
hi.
You
know
notes
of
a
forthcoming
release.
That
was
just
I
just
took
the
time
in
the
last
few
days
to
upgrade
to
the
the
latest.
Was
it
one
four
one
and
it
was
smooth?
I
didn't
actually
need
to
make
any
changes,
but
I
did
catch
a
bunch
of
slugs
in
my
own
code.
That
was.
D
Yeah,
that's
a
that's
a
good
one.
It's
a
tough
one
as
well
because
like
if
you
don't
do
it
like,
I
don't
know
like
there's,
no
way
that
the
sdk
knows
what
your
service
is
other
than
just
your
binary,
which
we
try
to
do
right,
but
like
yeah.
B
D
Yeah,
what
do
we
do
in
the
splunk
distribution?
We
log
like
a
error
or
warning,
or
something
like
that
to
kind
of
help.
Users
know
that
maybe
we
could
do
that
more
universally.
B
D
Yeah,
I
think
that's
kind
of
how
we
that
I
thought
about
it
as
well,
when
writing
that
splunk
distro
is
just
that,
like
we
don't
fail,
we
just
log
there
just
because,
like
you,
could
still
look
at
the
telemetry
at
the
end
of
the
day,
you're
going
to
be
confused,
you're
not
going
to
be
able
to
find
it
with
your
service
name,
but
that's
because
you
didn't
set
it,
and
so
there's
a
troubleshooting
dock,
essentially
saying
like
go
look
for
a
generically
enabled
or
named
you
know
service.
D
That's
probably
you
then
go
fix
your
problem.
B
Yeah
yeah,
I
think
it
tries
to
figure
out
the
process
name
to
include-
or
at
least
that's
what
the
spec
says.
It's
supposed
to
do.
D
Yeah,
that's
what
we
do
and
if
it
can't
determine
the
binary
name,
that's
running
the
system.
It
just
goes
defaults
to.
I
think
it's
all
unnamed
service
calling
go
or
something
like
that:
okay,
not
really
descript,
but
as
good
as
you
can
get
at
that
point.
Yeah
yeah
yeah,
it's
a
tough
one
and
yeah.
Then
then
there's
like
the
confusions
to
like.
D
Let
me
tell
you
like
writing
code.
I've
done
it
multiple
times
now,
but
just
like
you
know,
we
have
a
special
environment
variable
for
the
service
name,
but
you
can
also
just
include
it
directly
in
the
resource
attribute
environment
variable.
So
then,
how
do
you
resolve
the
two?
And
it's
like
the
spec
is
correctly
saying,
like
the
service
name,
environment
variable
should
be
honored,
but
then,
like
you,
have
to
parse,
essentially
both
to
find
out
if
it's
since
it
said
at
all
before
you
mourn
and
so
there's
a
lot
of
detail
in
there.
D
It's
not
the
most
intuitive.
It's
way
more
intuitive
from
the
user
space.
When
somebody
says
like
hey,
your
services
isn't
set,
go
set
the
environment
variable
to
this
that's
easier
than
saying
like
go
set.
The
resource
attributes
environment
variable
with
this
really
specific
resource
attribute
like
name
then
it
will
work
so
yeah.
E
B
D
B
D
E
D
Exactly
I
mean
I
think,
like
yeah,
if
you
have
like
a
really
generic,
like
you
know,
mono
repo,
or
something
like
that,
like
it's,
probably
going
to
be
named
what
it's
you're
going
to
be
named
at
compile
time,
but
like
that's
not
like
honestly
in
today's
modern
days,
that's
not
the
common
case
that
aren't
like
always
going.
B
F
D
I
I
don't
know
I
haven't
worked
in
a
space
that
doesn't
use
a
container
platform
in
so
long
that
this
just
seems
ridiculous
to
me,
but
maybe
that's
not
the
case
if
you're
still
like
artisanally
wrapping
some
services
and
deploying
them,
which
is
still
out
there,
that
was
the
start
of
my
career
for
sure
cool
I've
already
figured
out
how
to
share
so
I
don't
even
have
to
go
through
the
spiel
of
me,
not
knowing
how
to
use
computers
for
everyone
on
the
call.
D
Please
make
sure
that
you
sign
in
on
the
attendees
list.
If
you
have
anything
you
wanted
to
talk
about
on
the
agenda,
please
add
it
to
the
agenda
and
we
can
jump
in
here.
One
of
the
things
steve
is
going
to
point
out
earlier
in
the
conversation
I
said
we
should
do
a
release
last
week
and
I
have
not
found
the
time
to
do
it
yet.
But
my
goal
is
to
do
that
similar
to
last
week.
It's
not
gonna
include
any
of
the
metrics
work.
D
It's
just
gonna
include
the
large
swath
of
stable
packages
that
we've
updated.
So
just
a
heads
up
on
that.
I'm
I
think
tomorrow
is
free
for
me,
so
I
should
be
able
to
work
on
that.
Tomorrow
is
my
goal.
So
look
out
for
that.
D
That
said,
the
only
other
thing
I
wanted
to
bring
up
as
an
agenda
and
was
talk
about
the
metrics
progress
and
status.
Maybe
I
can
pass
this
over
to
aaron.
I
think
you've
been
leading
a
little
bit
more
on
this
work,
but,
as
I
see
it,
there's
two
outstanding
issues
to
address
before
we
can
do
an
actual
metrics
experimental
metrics
release.
F
Yeah,
I'm
going
to
start
off
with
the
global
package
first.
That
was
something
that
we
knew
that
we
were
going
to
need.
There
is
quite
a
bit
that
depends
on
that,
so
this
basically
adds
back
in
the
global
that
was
removed
for
simplicity's
sake
and
gives
it
a
once-over.
F
I
haven't
had
time
today
to
go
and
address
any
of
the
comments
that
were
left
since
the
last
grounds.
So
if
there
are
any
new
ones,
those
are
still
outstanding,
but
other
than
that,
I
think
we're
approaching
ready
to
include
it.
F
F
D
They're
they're
pretty
small.
So
it's
not
that
big.
F
Then
the
other
comment
is
the
or
the
other
issue
is
that
the
metrics
api
is
two
verbose.
Bogdan
has
asked
that
we
readjust
it.
I
know
that
there
was
one
issue
that
pulled
in
that
tried
to
add
additional
things,
and
I
don't
think
that's
the
right
approach
at
this
point.
We
can
rework
it
to
be
the
right
to
be
what
the
community
feels
is.
The.
F
Appropriate
access
method
for
this-
I
am
honestly
not
gonna,
put
a
lot
of
time
and
effort
into
this.
We
did
a
lot
of
this
at
the
beginning
of
this
and
it
feels
a
lot
like
rehashing.
D
Okay,
yeah,
that's
helpful
to
understand,
I
don't
know
who
other
than
bob
would
be,
so
I'm
just
gonna
send
it
to
him
at
this
point
I
looked
at
this.
I
don't
know
if
I
fully
understand
it,
I'm
kind
of
a
bummed.
I
don't
see
bogdan
on
the
call
and
I
think
he
said-
and
this
thing's
not
going
to
be
able
to
join
until
next
week.
D
The
soonest,
but
as
far
as
I
can
tell,
the
issue
is
somewhere
around
here,
where
you
have
to
have
some
sort
of
calls
into
the
sync
float64
and
the
door
counter,
and
then
this
instrumentation
package
import
were
the
only
two
things
that
I
saw
in
this.
F
I
think
that's
the
case
which
was
addressed
by
josh
before
we
even
started
the
metrics
like
the
api
prototype
right.
So
it's
it
is
a
rehash
of
that.
F
It's
not
that
I
don't
think
it's
worth
having
the
conversation,
it's
that
we've
committed
to
it
once
already,
if
we
need
to
revisit
it
that
that's
fine,
but
I'm
trying
to
to
work
on
the
issues
that
are
past
this
at
this
point
by.
B
F
E
Meter
there
is
an
instance
of
a
meter,
not
a
package
name.
So
oh
yeah.
E
And
I
I
think,
aaron's
right
about
what
what
he's
proposing
here
is
lump
everything
all
in
the
metric
package.
Have
it
all
in
one
and
we've
discussed
this
before
I,
I
think
we
agreed
that
it
makes
for
unreadable
documentation
and
an
undiscoverable
api,
and
that's
why
we
broke
it
up
like
this.
I
think,
looking
at
the
the
actual
code
here,
it's
apparent
that
the
only
thing
that
it
changes
for
the
end
user
when
they're
actually
writing
code
is
you
drop
a
dot?
E
Maybe
we
could
talk
about
removing
sync
from
the
sync
packages,
but
that's
about
all,
I
would
think
is
worth
discussing
of
this
proposal.
B
Yeah
it
looks
I
thought
josh
commented
below
with
this.
This
looks
right
for,
could
you
could
you
implement
a
gloss
layer
yourself?
On
top
of
it?
I
think
the
first
thing
I
do
is
write.
Some
helper
functions
to
compress
that,
and
the
only
thing
to
consider
is
well.
Is
it
unfortunate
lots
of
people
wind
up,
writing
the
same
functions,
and
you
know
the
help
that
I
don't
I
haven't
tried
using
it
myself.
D
Well,
one
of
the
things
that
I
did
notice
is
I'll
plug
aaron's.
Pr,
again
is,
if
you
do
review
this,
there's
some
nice
abstractions.
I
think
that
come
from
from
the
structure
that
we
have,
namely
where,
if
I'm
not
mistaken,
we
essentially
like
wrap
one
of
our
existing
types.
As
you
know,
an
async
instrument
provider,
or
something
like
that
or
a
sync
instrument
provider
and
then
add
you
know,
extend
methods
on
to
it
from
there,
which
is
really
slick.
Honestly.
F
Yeah,
I
would
look
under.
F
So
there
is
a
meter
here
that
actually
holds
all
of
the
different
instruments,
but
at
some
point
I
need
it
to
actually
provide
either
asyncs
in
instruments
or
async
float
or
sync
float.
And
if
you
scroll
down
to
one
of
those
instances,
all
I
do
is
alias
that
so
there's
an
async
float
instrument
provider
and
that
provides
that
and
it's
just
an
alias
of
meter
with
additional
functions
on
it.
F
D
Right,
which
is
cool
because
essentially
you're
overloading
the
counter
like
method
with
I
mean
it
technically
is
not
like
it's
all
different
types,
but
this
is
kind
of
a
way
to
do
that
by
abstracting.
That
overload
or
like
like
overloading
with
you
know,
splitting
off
those
types
while
they
still
all
still
have
the
same.
Underlying
type
is
kind
of
cool,
which
I
thought
was
really
useful,
because
then
you
can
consolidate
essentially
all
the
backend
logic
you
do
want
to
do
and
imagine
in
a
real
implementation,
not
just
like
a
no
op
throw
away.
F
It
is
somewhat
useful
in
that,
but
I
mean
this
isn't
just
a
no
op
throw
away.
This
is
actually
like
a
delegating
instrument
provider
right.
D
Yeah-
and
so
I
don't
know
like
if
you,
if
you
don't
do
this,
we
kind
of
are
back
to
what
the
original
api
was
anyways
like
where
you're
just
you
know,
instead
of
abstracting
each
one
has
to
implement,
you
know
11
or
12
different
methods.
I
can't
remember
how
many
instruments
there
are
right
now
but
like
and
it's
one
for
each
you
know
type
and
synchronous
or
asynchronous.
D
F
So
that
that
ends
up
coming
down
to
the
way
it's
recommended
in
the
spec
is,
unless
it
has
observer
on
it,
it
is
synchronous.
D
Okay,
yeah:
I
think
that
we're
all
in
the
same
understanding
of
this
so
I'll
try
to
put
some
words
into
here.
I
do
think
that
it's
important
that
it's
stated
that
aaron's
not
going
to
be
working
on
this,
so
I'll.
Try
to
capture
that
as
well,
but
yeah,
I'm
like
are
you
looking
for
the
underlying
thing,
but,
like
I
really
am
seeing
that
this
is
asking
us
to
go
back
to
the
old
api
and
we've
kind
of
held
a
large
amount
of
discussion
on?
D
Why
we
don't
want
to
do
that,
but
I'll
try
to
consolidate
that
and
to
anyone
else
listening
if
you
have
feelings
or
thoughts
or
ideas.
Please
make
sure
your
comments
on
here.
It'd
be
helpful,
because
this
is
asking
you
know
for
user
feedback
essentially
is
what
this
is
providing.
So
if
you
are
also
a
user
it'd
be
useful
to
hear
your
perspective,
it's
also
kind
of
like
the
chicken
and
the
egg,
because
it's
really
tough
to
get
users
to
start
using
it.
D
If
you
don't
release
it,
and
then
you
don't
want
to
release
it.
If
users
are
yeah
opening
issues
like
this,
so
okay,
yeah.
F
Okay,
yeah
I'm
in
the
process
of
seeing
what
it
will
take
to
update
the
collect
or
the
contrib
repo,
which
I'm
gonna
put
a
proposal
together
about
replacing
the
metric
test
package
that
we
had
with
an
in-memory
reader,
because
I
think
that
will
cover
all
of
the
tests
that
we
do
but
actually
use
the
sdk
as
our
testing
bed.
Instead
of
a
one-off
meter
provider,
which
is
you
know,
which
is
the
same
problem
that
we
kind
of
faced
in
in
tracing
or
we
had
the
trace
test.
And
it
was.
D
I
I'm
like
I'm
pretty
sure,
I'm
the
one
with
the
change,
so
I'm
like
99
sure
for
anything
that
was
yeah.
We've
moved
using
the
real
sdk
in
a
trace
or
a
test
package.
Yeah.
E
E
F
We
it
has
a
special
meter
provider
that
is
one
off
here
and
all
sorts
of
fun.
So
I
was,
I
was
gonna,
see
what
it
like.
A
minimal
in-memory
meter
recorder
would
look
like
and
then
our
metric
recorder
and
then
see
how
we
can
replace
the
test
with
that.
D
Yeah,
I
fully
support
that,
because
I
know
that
the
first
issue
after
we
get
the
api
at
the
sdk
out
from
bottom.
It's
going
to
be,
we
need
to
consolidate
them
just
like
it
was
for
the
test
sdk.
So,
however,
the
trace
sdk
so
and
rightfully
so
like.
I
don't
think
we
want
to
have
different
implementations.
If
you
want
to
validate
that
your
code
is
going
to
produce
what
99
of
users
are
going
to
expect.
You
know.
D
Cool,
okay,
that
is
about
it
for
the
issues
that
I
had
to
talk
about,
the
metrics
current
status,
progress
wise:
where
are
we
at
aaron
in
the
next
steps?
Once
let's
say
we
resolve
that
issue
and
that
pr
has
merged?
What
do
we
have
next
is?
Is
that
ready
for
a
release,
or
are
we
still
looking
for
something
else,
or
anybody
on
the
call
who
has
understanding
of
that.
F
F
I
think
that
kind
of
depends
on
how
long
we
can
hold
off
updating
the
instrumentation,
the
metrics
instrumentation
package
in
the
contrib,
because
I
can
I
could
take
out
the
the
test
that
we
do
against
the
the
metric
test
package
and
I
think
99
of
the
the
contrib
can
be
updated
with
almost
no
change
and
honestly,
a
lot
of
it
can
be
replaced
with
just
the
no
op
metrics
recorder
and
would
be
fine.
F
But
that
being
said,
if
we
actually
do
want
to
keep
coverage,
we'll
also
need
that
so
global.
We
need
to
resolve.
F
We
need
to
come
to
some
resolution
around
how
much
more
churn
we're
going
to
take
on
the
actual
api
itself
and
then
I
think,
that's
ready
for
a
release
and
then
there's
kind
of
a
bifurcating
path
of
we
can
release
it
without
the
test,
and
that
could
happen
the
next
day
or
we
can
add
in
the
replace
the
metric
test
functionality
and
then
the
contrib
will
be
released
after
that
right.
F
So
that's
a
long
way
to
say
there's
a
couple
steps
though:
okay.
D
F
Yeah,
I
think
I
think
that
is
an
acceptable
way
of
going
and
we'll
just
have
to
delay
the
instrumentation
that
relies
on
incontrib
for
a
month.
I
guess
or
one
cycle
the.
D
Okay,
yeah,
I
mean,
I
think,
if
that
seems
reasonable,
we
could
also
try
to
partition
that
there's.
D
There
right
because
we
need
that
testing
package
that
you're
talking
or
testing
recorder,
that
you're
kind
of
talking.
D
Once
you
have
that,
then
we
could
really
parse
that
out
to
a
few
people
to
try
to
work
on
different
instrumentation
factors.
I.
E
F
Yeah,
go
sequel,
go
sequel
there
there's
about.
E
Sorry
yeah
this
is
go
sequencer.
What
I
was
thinking
of.
F
Yeah
host
runtime
to
http
there's
a
go
cql.
That
also
has
it.
E
D
E
Recollection
is
that
be
go
delegates
to
the
net
http
instrumentation,
so
two
words
with
weapons
down
there.
F
Yeah,
actually,
I
already
have
a
patch
set
for
bigo
and
http.
I'm
only
running
into
any
kind
of
issues
with
cql
and
I
haven't
gotten
to
host
a
runtime.
E
F
F
F
Yeah,
I
know
it's
confusing
somewhere
down
near
the
end.
There's
like
an
assert
metrics
or
something
like
that
for
all
record.
F
It
might
be,
I
think,
scroll
down
just
a
little
bit.
It's
obtain
test
records,
so
it
converts
actual
stuff
from
the
hotel
or
the
metrics
test
batches
into
local
test
records,
which
is
there
this
local
test
format,
and
then
we
just
compare
them
so
that
they
have
the
same
right,
instrumentation
name
and
meter
type
or
meter
name
and
yeah,
and
they
have
the
same
attributes.
So
I'm
not
even
100
sure
if
that
gives
us
a
very
good
test.
D
Yeah,
I
don't,
I
think
it
does,
but
I
have
to
look
a
little
closer.
F
D
F
Which
I
I'd
be:
okay,
just
commenting
it
out
and
say:
hey
we're
gonna
re-add
this
when
we
get
something
that
is
based
off
of
our
like
a
test
suite
based
off
of
our
sdk,
which
would
be
dependent
on
an
in-memory
recorder.
D
Yeah-
and
this
is
this-
is
where
I
think
that
we
could
do
a
little
parallelization
and
assigning
out
some
some
tasks
to
multiple
people,
instead
of
just
having
a
single
person
work
on
it,
yeah
like
deleting
and
creating
an
issue
to
track
it,
and
you
know
having
it
assignee
to
that,
sounds
completely
reasonable
to
get
the
progress
moving.
E
F
D
Okay,
let's
take
some
notes
here.
F
So
I
will
bring
up
an
issue
for
the
in
memory
order:
okay,.
F
E
How
how
do
we
resolve
the
api
change
issue?
Are
we
going
to
entertain
this,
or
are
we
going
to
say
that
it's
decided
and
the
other
api
can
be
built
as
a
sugar
package
on
top
of
it?
If
someone
really
wants
that.
D
I
I
need
to
look
again,
but
I
think
that,
like
based
on
what
we
talked
about
here
in
our
understanding,
that
is,
that
is
what
I
would
say.
I
would
want
to
make
sure.
There's
consensus.
Well,
there's
not
going
to
be
100
consensus
in
the
community,
but
I
want
to
make
sure
that
we
all
kind
of
agree
to
that
and
that
we
make
sure
that
the
other
parties
are
hurt.
D
And
by
that
I
mean
I
might
want
to
wait
for
bogdan
to
to
feel
heard
on
this
one,
because
I
think
that,
as
far
as
I
can
understand,
like
he's
the
one
who
doesn't
like
the
new
api,
and
so
I
want
to
make
sure
that,
like
I,
we
went
over
what
the
issue
was,
and
I
think
that
we
have
the
same
understanding.
But
I
want
to
make
sure
that
we're
not
in
an
echo
chamber
and
so
there's
something
that
we're
not
missing,
that
he
is
aware
of.
B
Just
briefly,
two
considerations,
I
think
one
is
perhaps
perhaps
challenged
blog
first
of
all,
can
you
write
a
gloss
layer
without
it
being
part
of
these
packages?
So
can
you
do
this
from
the
outside?
B
If
you
can't
that's
interesting,
then
you
know
warrants
more
consideration,
but
also,
even
if
you
can
write
such
a
thing,
what
are
the
motivations
for
needing
to
bore
through
it?
In
other
words,
what
are
things
that
it
that
you
can
do
with
the
direct
low
level
api
you
couldn't
do
with
last
name
and
that
investigating
that
might
reveal?
Maybe
we
have
too
many
knobs
that
nobody
needs
and
it
could
be
simpler.
E
So
I
I
don't
think
that
it's
a
question
of
capability.
I
think
it's
a
a
question
of
structure.
You
can
do
the
same
thing
with
both
of
them.
I.
E
Already,
a
pr
that
builds
this
gloss
layer
that
implements
one
in
terms
of
the
other.
It
does
it
in
the
same
package
which
we,
I
think
aaron
and
I
are
at
least
in
agreement
on.
You
know
that
that's
not
the
right
thing
to
do
like
if
you're
gonna
build
this,
build
it
off
somewhere
else,
it
doesn't
belong
in
our
repo.
E
We
should
have
one
api
over
the
other,
but
you
can
build
one
in
terms
of
the
other,
because
the
the
api
that
bogdan
is
asking
for
is
simply
calling
two
methods
in
place
of
one
we're
calling
one
method
in
place
of
two
right,
so
you
have
a
float64
that
calls
sync
float64,
sorry
64
counter
they
called
syncfloat64
and
then
calls
counter
passing
in
the
arguments
that
I
got
right
so
that
that
part
is
dead,
simple
and
the
implementation
absolutely
can
happen
anywhere.
E
I
think
the
the
question
for
us
really
is
is
that
the
api
structure
that
we
want,
you
know
one
big
flat
name
space
and
we've.
You
know,
as
a
community
discussed
this
before
we've
had
an
implementation
like
this.
Before
we
decided
we
didn't
like
it.
We
didn't
like
how
the
documentation
works
out.
We
didn't
like
how
it
felt
right,
so
we've
moved
to
this
new
api.
I
think
tyler.
E
D
Oh,
I
yeah
I'm
not
saying
that.
Yes,
I
definitely
agree
that
having
a
deadline
inside,
I
saw
the
deadline
as
like
next
thursday,
because
that
was
when
he
said
he
was
gonna,
be
able
to
make
the
sig
meeting,
but
maybe
I
can
he
might
be
back.
Maybe
I
can
reach
out
to
him
asynchronously
and
see
if
there's
a
time
we
can
address
this
sooner
but
yeah.
I
agree.
I
don't
want
this
to
just
you
know
for
the
next
month
block
the
api
being
released.
F
I
would
also
recommend
people
go.
Take
a
look,
there's
the
tool.
Instead
of
godok,
it's
called
package
site
pkg
site
which
lets
you
run
essentially
a
local
copy
of
the
package.dev.gov
go.dev.
Whatever
it
is,
it's
it's
part
of
the
tool,
the
x
tools
package
right,
use
that
and
and
kind
of
like
that,
was
one
of
the
tools
that
I
was
relying
on
heavily
to
make
sure
that
we're
not
overloading
any
particular
position
with
information
on
like
what
can
you
do
at
an
instrument
level
versus?
F
What
can
you
do
at
a
meter
level
versus
what
not
and
if
you
throw
them
all
in
the
same
package
like
if
it's
all
in
the
meter
level
that
page
gets
large
and
it
it's
hard
to
kind
of
parse
out
what
can
be
used
as
a
meter
option
versus
a
metric,
an
instrument
option
and,
like
you
know,
asynchronous,
like
they're,
not
sort
of
they're,
sorted
alphabetically,
so
float64
counters
are
in
line
with
observe
like
it
becomes.
It
becomes
unwieldy.
D
D
F
F
Yep
it
it
works
very
similar
to
how
godoc
works,
where
you
just
hit
it,
and
then
the
only
thing
I
found
is
the
search
doesn't
work.
So
when
you
start
it
up,
you
actually
have
to
put
in
the
what
is
it
go.opentelemetry.org
or
whatever
our
our
actual
thing
is,
so
you
go
to
like
128.0.0.1
slash
our
package
site
like
r,
like
there's,
no,
no
way
to
quickly
link
directly
to
where,
where
you
want
to
be
gotcha.
D
Yeah,
thanks
to
the
link
too,
I
think
that's
it
for
the
next
steps
for
this
metrics
item.
I've
put
down
that
we
need
to
resolve
the
two
issues:
update
the
contributions,
rotation,
api,
we're
going
to
remove
the
complex
tests
and
create
issues
to
track
them.
Then
release
that
there's
going
to
be
an
issue
to
track
the
adding
a
recorder.
A
metrics
recorder
fix
contrib
with
that
metric
recorder.
I
think
this
is
kind
of
like
the
progress
and
timeline.
D
If
I'm
not
mistaken,
as
I
heard
it
saying,
you
had
nods
cool
all
right
with
that,
then
I
think
we're
done
with
the
agenda
items
I'll
pause
here
and
wait
to
see.
If
anybody
else
has
issues
they
wanted
or
agenda
items,
they
wanted
to
talk
about.
E
There's
one
more
quick
thing
on
crosslink:
I've
approved
brian's
pr,
I
think,
he's
addressed
all
of
the
the
concerns,
except
possibly
the
one
about
the
the
runtime
config
global.
Is
that
something
that
we
can
merge
the
tool
as
is
and
address
it
or
refactoring
if
needed,.
D
Yeah
hi
there
we
go
hey
brian,
so
I've
tried
to
take
a
look
at
it
again
and
being
over
4
000
lines
is
just
daunting,
so
I
I
think
that
maybe
I
could
just
talk
here
in
this
form
and
then
because
I
keep
meaning
to
respond.
Sorry,
there's
like
30
different
pr's.
I
have
open
right
now,
so
if
there's
a
possibility,
I
know
that
we
added
an
algorithm
in
there
to
reduce
the
essentially
the
dependency
graph
instead
of
just
posting
all
of
them.
D
One
of
the
main
things
I
wanted
to
comment
on
there
was
that
I
would
probably
try
to
build
a
graph
and
then
traverse
it
instead
of
there's
a
lot
of
for
loops
and
it
was
really
hard
to
read
but
yeah.
So
I've
got
like
I'm
looking
at
some
of
these
comments
now,
and
so
that
was
probably
one
of
the
things
that
I
would
say
to
try
to
reduce
the
size,
there's
still
a
config
issue.
I
haven't
gone
back
in
and
I
think
giving
you
a
proper
response
on
that.
D
But
the
issue
is
that
I
think
there's
an
a
tooling
structure.
D
That's
gotten
in
the
way
so
practically
wrong,
but
cobra
offers
some
like
cli
option
to
add
actions
and
all
these
other
things-
and
I
think
because
of
that,
the
structure
of
the
program
is
is
as
you
find
it,
but
it
is
relying
on
init
functions
that
accept
a
config
and
that
config
is
initialized
not
in
a
particular
order
and
there's
there's
initialization
issues
that
I
have
with
a
lot
of
that
and
it's
hard
to
think
to
describe
it
without
a
large
paragraph.
D
But
I
I
think,
there's
just
a
structural
design
to
how
the
command
structure
is
oriented
right
now
and
I'm
trying
to
find
some
time
to
to
go
through
it
and
make
a
proposal
in
there.
But
there's
there's
just
a
lot
of
code
to
go
over.
D
So
I
I
wonder
about
like
merging
that,
because
I'm
I'm
worried,
there's
some
severe
bugs
in
there
and
I
have
not
been
able
to
completely
review
it.
Given
it's
over
four
thousand
lines.
G
E
I
think
that
eliminates
the
value
of
the
tool
this
started
out,
because
the
contrib
repo
in
collector
is
also
looking
for
this
capability
and
there
that's
not
tenable.
There
are
hundreds
of
modules.
D
Well,
I
yeah,
so
I
okay,
that's
I
don't
mean
to
say,
stop
there,
I
I
mean
to
say,
put
a
stub
in
and
that
stub
is
essentially
in
all
and
then
the
next
pr
can
be
another
thousand
lines,
but
it
will
be,
you
know
dedicated
to
a
graph.
Traversal
algorithm,
I
think,
is
what
I'm
trying
to
say.
D
E
Deal
with
it
by
continuing
to
use
the
existing
tool
in
the
go
repos
and
getting
this
landed,
so
that
control
can
start
experimenting
with
it
and
if
there
are
bugs
we'll
find
them
there,
because
I
think
what
is
implemented
is
a
graph
reversal
algorithm
like
you're
describing
it's.
It
builds
a
graph
and
does
a
breadth
search
over
it.
F
D
Yeah
I
mean
it
wasn't
clear
to
me
and
that's
because
I've
already
gone
through
3000
lines
of
code
before
I
got
to
it,
and
so
it
was
like
you
know.
My
brain
is
just
not
able
to
parse
all
of
that,
and
so
that's
why
it
cohesively
seems
like
two
different
things
that
can
be
reviewed
separately
and
how
I
would
have
split
the
pr
up
right
like
you,
can
essentially
submit
a
pr
for
command
structure.
D
Because
again,
I
think,
if
there's
a
lot
of
feedback
that
can
be
just
attained
on
the
command
structure,
I
don't
think
you
need
as
much
structure
that
is
in
the
code
to
achieve
what
is
trying
to
be
achieved
there.
So
I
think
if
there's
a
there's
a
that
part
of
the
pr
that
can
be
isolated
from
the
actual
algorithm
for
graph
traversal.
D
So
that's
why
I
was
saying
like
if
you
put
in
a
stub
and
then
the
next
pr
came
back
and
said
like
okay,
now,
here's
the
graft
virtual
algorithm,
you
can
dedicate.
You
know,
review
resources
to
it
at
this
point,
it's
a
much
easier
to.
I
don't
know
if
it's
easy,
it's
easier
to
than
it
currently
is
to
to
review
it.
The
problem
is
it's
just
like
I
I've
gone
through
this
like
too
many
times
and
I'm
not
making
any
progress.
D
So
I'm
trying
to
make
some
suggestions
on
how
to
like
split
this
up,
because
it's
just
way
too
big
to
get
a
like
serious
review.
I
mean
I
understand
that
like
this
is
specific
to
like
tooling,
that
we
want
to
use,
but
I
it's
it's
really
frustrating
for
me
to
say
that
we
should
be
merging
things
that
have
not
been,
I
think,
fully
reviewed
by
people
who
have
tried
to
review
them.
G
I
I
hear
that
I'm
just
wondering
the
best
way
to
move
forward.
I
mean
I,
I
also
agree
with
andy
that
anthony
that,
like
ripping
out
the
well
not
ripping
out
but
removing
or
going
back
to
the
old
way,
seems
like
defeating
the
purpose
of
the
work
I
mean,
I
can
probably
add
the
air
quote
dumb
functionality
as
an
extra
command.
Like
that's
easy
enough
and
to
split
it
off,
I
mean
no.
I.
D
D
Like
yeah,
this
is
what
we
had
before.
This
is
what
it's
doing
again.
What
I'm
saying
is
like
when
you're,
when
you're
trying
to
build
this
out
like
yeah,
I
wouldn't
integrate
it
into
the
collector.
If
you
put
back
that
dumb,
you
know
include
everything
logic.
I
would
say
that
it's
not
ready
for
the
collector
to
try
out
until
you
get
the
second
pr
merged,
where
you
actually
have
the
graft
virtual
algorithm.
D
I
mean
I
would
look
at
this
as
durable
value,
and
so,
if
you
get
a
command
structure
together,
where
you
can
call
the
command
structure
and
it
does
no
op
operations-
that's
not
nothing!
That
means
that
you
have
a
command
structure,
that
you
can
then
implement
logic
into,
and
sometimes
that's
like
really
key.
D
If
you're
trying
to
do
a
complex
command
structure
that,
like
I'm
saying
like
there,
are
design
issues
with
that
that
I
think
need
to
be
addressed
and
it's
hard
to
then
say:
okay,
I'm
going
to
decouple
that
as
a
review,
all
right,
it's
hard
to
do
that!
I'm
going
to
do
that
as
a
review
and
at
the
same
time,
I'm
also
going
to
like
validate
this
graph
commercial.
G
D
I
think
so
looking
for,
I
would
imagine
it
would
shrink
the
pr
considerably
and,
and
that
would
help
you
know
get
through
this.
G
Okay,
yeah,
I
can
start
looking
at
that.
I
mean
I
I
we
I
know
I
think
anthony
may
agree
will
probably
bring
me
that,
like
we
see,
we
really
want
other
eyes
on
it
other
than
just
us
two,
because
we've
been
staring
at
it
for
so
long.
So
who
knows
what
we
missed?
So
I
think
we
can
split
it.
G
It
is
big,
but
also
you
mentioned
one
thing
in
your
earlier
statement
that
you
weren't
sure
of
the
validity
or
like
if
we're
missing
anything-
and
I
just
I
want
to
make
sure
that
my
test
cases
cover
that
I
felt
like
I
did
a
good
job,
at
least
for
the
main
logic,
but
I
do
worry
about.
I
don't
worry
about
it,
but
you
know
who
knows
what
edge
cases
we
may
run
into
and
I
did
validate
against
contrib
and
it
it
worked,
but
still,
I
think,
making
sure
the
test
cases.
D
Were
I
gotcha,
so
let
me
put
a
little
context
on
this
and
I
think
that's
a
really
good
point
and
I
consider
that
a
part
of
the
job
of
a
review
like
a
review
is
not
just
a
review.
The
code
is
to
review
the
test,
as
well
as
the
documentation
and
to
make
sure
that
it's
cohesively,
like
every
single
thing
about
that,
is
correct.
D
In
fact,
I
would
say
that
the
review
of
the
test
is
almost
more
critical
than
the
code
and
making
sure
that
not
only
what
is
included
is
you
know,
appropriate,
but
also
what
isn't
included
is
identified
and
so
again
like
yeah
to
making
sure
that,
like
it's,
it's
good.
I
think
you
need
to
review
the
algorithm,
but
you
need
to
also
review
the
test
that
you're
included,
which
again
kind
of
says
exactly
back
to
what
I
was
trying
to
tell
you
like.
D
If
you
split
out
that
part
of
the
test,
all
those
tests
for
you
know
traversing
the
graph
and
making
sure
that
it's
a
breadth
first
search
and
all
these
sort
of
things
can
be
isolated
and
they
can
be
reviewed
in
the
second
pr
against.
Like
slimming
that
down,
so
I
definitely
agree
got
it
on
that
on
that
on
that
fact
that,
like
I
do
want
to
put
some
eyes
on,
I
don't
want
to
say.
D
Don't
have
value
in
looking
at
it
yourself,
like.
I
think
you
probably
have
done
a
good
job
at
looking
at.
D
I
hope
you,
you
know,
have
looked
at
it
more
than
me
yeah,
because
you
wrote
it
right,
so
I
think
that's
important,
but
I
also
think
that,
like
trying
to
isolate
it,
because
I
just
I
feel
bad
because,
like
every
single
time
I
get
through
it's
like,
maybe
you
get
a
thousand
lines
before
it's
an
hour
and
I
have
to
go
somewhere
else
to
do
something
else,
and
it's
just
tough
to
get
through
4
000
lines
of
code.
G
Got
it
okay?
Well,
I
think
I
can
take
that
on
and
just
making
it
more
reviewable.
I
think
that's
a
good
feedback
in
itself
and
I
think
I
will
take
a
stab
at
that
and
make
sure
I
think
anthony
anthony.
Are
we
on
the
same
page
that
maybe
helped
me?
I
think
I
know
how
I'm
going
to
split
it,
but
yeah
that
makes
sense
to
me.
E
I
I
think,
if
that's
the
way
forward,
then
that's
the
way
forward.
I
think
yeah
personally,
my
perspective
on
this
is
that
this
is
a
tool.
It's
a
two-way
door
and
it's
the
impact
of
getting
it
wrong.
Right
now
is
probably
not
huge
and
the
value
of
getting
it
used
and
starting
to
use
it
in
the
collector
contrib
repos
could
be
significant
and
will
tell
us
fairly
quickly
if
it's
right
or
wrong,
and
we
can
come
back
to
the
the
implementation
details
of
the
command
structure
later.
D
Oh
cool
that
sounds
good,
brian
sorry
to
flounder
so
long,
but
like
I
just
I
to
throw
in
the
cards
just
saying
I
can't
get
through
the
review.
I've
tried
too
many
times,
so
I
appreciate
you
hearing
me
and
I'm
looking
forward
to
the
split
yeah.
G
We'll
do
I'll
get
working
on
that
next
week,
probably
so,.
D
Yeah
and
like
I
I
doubt
it'll,
take
much
more
than
just
removing
commits,
so
I
don't
expect
it
to
take.
G
D
That
sounds
good.
I
would
also
hope
that
that
could
also
include
reviews
from
the
contrib,
the
collector
contrib
repo
yeah.
G
E
So
bogdan
and
bogdan
and
tigran
may
be
the
only
people
from
collector
who
have
approval
rights
in
that
tools,
repo,
it's
not
all
of
the
approvers.
It's
only
the
maintainers.
D
Oh
okay,
I
didn't
understand
that.
I
guess
it
kind
of
only
applies
to
maintainers,
so
that
makes
more
sense
but
yeah.
Okay,.
D
Okay,
any
other
agenda
items
not
on
the
agenda.
We
want
to
bring
up.
D
Cool
any
other
cool
user
stories
or
use
cases
that
you
all
have
undertaken
in
the
past
week
or
so.
D
Getting
a
lot
of
head
shakes.
Well
then,
I
think
that
we
could
probably
end
the
meeting
here
cool.
Well,
thanks
everyone
for
your
time.
I
definitely
appreciate
it
and
all
the
effort
we
all
put
into
the
project,
and
we
will
talk
to
you
all
asynchronously
or
on
next
week's
sig
meeting.