►
From YouTube: 2021-02-12 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
A
A
Up,
oh
thanks
thanks,
I
have
like
a
whole
recording
studio
in
here,
like
all
my
walls
are
like
covered
with.
I
see
dampeners
like
I've,
been
starting
a
youtube
series,
but
hasn't
just
a
lot
of
work
to
put
into
that
still.
So
you
know,
building
out
this
room
to
take
care
of
the
light
and
sound
wow.
That's.
A
How's
it
going
tyler
aaron
rich
mike,
is
that
what
what
kind
of
mic?
This
is
just
a
yeti,
blue,
nothing
too,
crazy!.
C
B
E
F
Yeah
and
you
also
have
to
get
a
very
decent
boom.
I
have
one
sitting
behind
my
monitor
too.
A
F
You
should
work
it
so
that
you
can.
You
don't
have
to
be
like
right
up
eating
the
mic,
because
I
don't
sound
too
bad
and
my
mic's
like
right
here.
A
You
should
totally
do
that.
Steve,
though,
like
join
one
of
these
calls
and
just
have
your
production
assistant
right
there
just
have
it
dip
it
every
once
in
a
while
see
what
I
can.
B
G
Well,
cool,
I
think
we
could
probably
get
started.
I
see
plenty
of
people
are
on
the
call.
If
you
haven't
already,
please
open
up
the
agenda
doc
and
add
your
name
to
the
attendees.
Any
agenda
items
you
wanted
to
talk
about.
Please
add
them
in.
I
see
some
people
typing,
but
we
can
probably
jump
in.
I
think
anthony's
on
the
call
for
the
first
item.
G
E
Sure
can
you
bring
up
that
issue?
I'm
not
sure
that
yep,
no
worse,
not
a
problem,
but
basically
the
the
the
issue
here
is
that
the
spec
has.
E
E
E
My
inclination
is
to
stick
with
record
error,
since
it's
it
matches
the
go.
Idiom
better
go
doesn't
have
exceptions.
Everybody
deals
with
errors.
Everybody
knows
what
an
error
is.
It
will
be
comfortable
to
go
developers
to
use
a
method
like
record
error.
E
Many
loggers
have
with
error
that
sort
of
thing,
but
to
produce
the
exception,
events
and
attributes
so
that
they
can
be
correlated
with
exceptions
produced
by
other
languages.
That
do
have
exceptions,
and
I
just
want
to
get
the
sense
of
this
group
as
to
which
way
you
think
we
ought
to
go.
B
I
was
sad
to
see
mention
of
of
the
rust
case
in
there
because
I
was
immediate.
I
immediately
jumped
to
the
argument
that
god
doesn't
have
exceptions.
We
don't
talk
about
exceptions
and
go
unless
you
want
to
make
an
argument
like
we
use
errors
to
indicate
exceptional
situations
or
we're
not
talking
about
exceptions
like
as
a
noun.
E
Yeah
and
looking
at
the
the
rust
issue
where
that
was
initially
added,
it
looks
like
they
briefly
discussed.
Well,
we
don't
really
have
exceptions,
but
this
says
to
do
exceptions,
so
I
guess
we'll
call
it
exception.
H
D
I
But
put
exception
attributes
on
that's
fine,
looks.
E
Like
jack
is
on
the
call
the
person
who
opened
this
issue,
do
you
have
anything
you
want
to
add
on
on
the
topic
or
is
just
does
that
work
for
you.
J
Yeah,
nothing
to
add.
I
was
just
curious
how
they
this
whole
process
goes.
J
I
haven't
joined
a
sig
interest
group
before
so
I
I
don't
really
care
the
method
name,
but
the
the
reason
I'm
opening
this
too,
is
just
because,
when
the
contributor
or
the
the
collector
we're
trying
to
pull
out
data
from
the
errors
that
occurred
and
so
like
pointing
to
the
spec
being
able
to
point,
at
the
exception
event
exception
attributes
to
pull
out
metadata
about
the
thing
that
happened,
we'd
prefer,
I
guess
to
have
one
thing
to
look
at
rather
than
two
different
types
of
events
to
pull
out
these
error
attributes
on
the
spans.
E
B
B
Yeah,
I
I
think,
that's
fine,
because
I
assume
that
we,
some
of
these
standard
attributes
that
go
in
there
are
just
we're
hewing
to
that
that
sort
of
lowest
common
denominator.
You
see
the
same
thing
with
the
resource
names,
also
where
sorry,
the
the
keys
that
are
defined
for
resources,
a
lot
of
them
aren't
necessarily
what
I
would
pick
myself,
but
I
kind
of
understand
what
they
mean,
and
so
it's
it's
valuable
to
just
accept.
F
E
No,
I
think,
we're
fine.
The
the
spec
language
is
shown
here
on
the
screen,
and
it's
it's
fairly
broad.
Actually,
you
know,
in
fact
it
says,
should
provide
a
record
exception
if
the
language
uses
exceptions.
So
I
think,
in
terms
of
that,
we
don't
use
exceptions,
we're
clear
to
not
provide
it
at
all
without
even
writing
a
file
of
the
should.
Then
it
goes
on
to
say
the
signature
of
the
method
is
to
be
determined
by
each
language.
It
can
be
overloaded
as
appropriate.
E
E
G
You
know
in
a
language
like
I
don't
know
c
c,
plus
or
something
like
that,
like
an
exception.
Well,
I
guess
c,
is
it's
just
a
panic
but
like
in
c
plus
plus
or
something
like
that,
like
an
exception,
is
you
know
also
accompanied
by
a
lot
of
like
metadata
that
that's
additional
to
it
like?
I
think
that
there's
also
down
here,
including
a
thing
like
a
stack
trace.
I
guess
it's
not
required.
It's.
E
Not
required
and
we
have
through
the
runtime
package,
the
ability
to
provide
assertiveness.
We
can
give
that
sort
of
information.
I
I
think
that
the
point
that
an
exception
is
not
an
error
and
an
error
is
not
an
exception,
is
a
fair
one.
It's
one
that
was
discussed
when
the
spec
was
constructed,
though,
and
right
the
sig
settled
on
calling
it
exception,
even
if
it
wasn't
always
a
good
match.
G
I
think
that
makes
sense.
I
I
we
probably
want
to
make
sure
that
that's
pretty
clear
in
the
actual
method,
signature
that
you
know,
even
though
you're
calling
record
error
it's
going
to
show
up
as
an
event
called
exception,
or
something
like
that,
but
other
than
that,
I
don't
see
too
much
of
an
issue
with
this.
H
I
have
two,
I
have
two
questions
and
these
are
minor
details
compared
to
the
overall
discussion
one.
Would
we
want
to
unconditionally
populate
stack
traces
from
runtime
and
or
would
we
want
to
use
the
pkg
slash
errors
notion
of
stack
trace?
H
So
that's
that's
one
bucket
of
question
and
the
other
is
do
we
want
to
think
at
all
about
recover,
recover
return
values
as
another
representation
of
errors
of
of
like
exception-like
things,
or
should
we
say
nope
errors
are
ghost
representation
of
exception,
like
things.
G
Yeah,
that's
a
a
really
good
point
as
well.
We
do
have,
I
believe,
it's
in
the
end
method
of
the
sdk
that
does
handle
recovery
of
any
sort
of
panic.
It
is
what
I'm
thinking
you're
talking
about
punya,
and
I
think
that
is
an
important
distinction
that
this
this
discussion
did
happen
before
and
I
think
you're
right
like
that
came
up
when
we
did
make.
That
definition
happen.
I
think
it's
spam
yeah,
because
we
do
record
something
on
a
recovered
event,
and
that
is
here.
G
Let's
see
if
you
can
find
that
yeah
and
that
event
name
is
air,
which
probably
should
also
get
changed,
because
that
is,
I
think,
more
in
line
with
what
an
exception
would
be,
but
yeah,
I
think
we
should
probably
handle
both.
I
think
that
we
should
probably
unify
on
what
we're
gonna
do,
and
I
think
that
anthony's
kind
of
like
I
like
the
proposal
that
he's
made
as
to
like
how
that
should
look
with
regard
to
the
putting
a
stack
trace
in
each
one
of
these
payloads.
G
I
would,
I
would
say
no,
but
I'm
I'm
open
to
hearing
suggestions
just
because
it's
not
a
required
parameter
and
I'm
guessing.
It's.
H
Sorry,
please
go
ahead.
E
The
spec
leaves
that
to
each
language
to
determine
so
we're
not
really
constrained
there,
it
does
make
it
optional.
I
agree
that
it
should
be
an
option
that
gets
specified
in
the
call
to
record
error
recorder
already.
H
E
Optional
arguments
so
adding
an
option
to
you
know
saying
with
stack
trace
or
something
like
that
should
be
pretty
easy.
H
Cool,
I
I
brought
it
up
because
there
are
community
packages
that
offer
a
built-in
convention
for
saying
I'm
an
error
that
has
a
stack
trace,
that
you
should
feel
comfortable
grabbing
right.
H
So
I'll
share
that,
and
you
know
we
can-
we
can
decide
if
again,
just
in
the
interest
of
you
know
getting
something
out
fast,
perhaps
doing
nothing
for
now
doing
just
doing
what
what
anthony
suggested,
plus
the
the
recover
and
then
worrying
about
stack
traces
later,
because
I
don't
think
I
don't
think
that
mean
that's,
not
a
compatibility
breaking
anything.
E
Yeah,
I
agree.
We
can
always
add
that
later
without
breaking
compatibility,
I
think
we'll
probably
even
be
fine,
adding
it
with
default
formatting
from
the
runtime
package
and
changing
it
later,
because,
again,
that's
not
part
of
the
public
api.
We
can
change
that
without
strictly
breaking
compatibility,
but
we
don't
need
to
do
it
right
now.
So
to
forget,
to
tell
later
is
probably
the
right
choice.
G
Yeah,
I
I
think
I
would
probably
agree
to
just
defer
it.
I
would
really
be
interested
in
seeing
this.
You
know
a
stack
trace
associated
error
thing
that
you're
talking
about
plenty
of,
though
that
sounds
really
interesting.
I
I'm
also
hoping
that
gets
rolled
into
the
standard
library
at
some
point,
but.
H
Yeah,
I
think
this
was
considered
for
the
student
and
at
least
the
errors
package
was
aware
of
this
work
and
elected.
Not
to
do
this
so
there's
a
question
of
taste,
yeah.
G
Yeah
but
yeah
I'd
love
to
see
a
link.
If
you
could
just
put
it.
G
Or
in
the
issue,
I'd
love
to
check
it
out:
okay,
cool
thanks
for
whoever
is
adding
the
notes
to
the
doc
puny.
Why
don't
we
jump
on
to
you
and
this
next
issue
that
you
raised?
I
don't
know
where
you
want
me
to
start
because
probably
jump
into
this
proposal
here.
H
Yeah
cool,
I
think,
it'd,
be
great
if
we
could
spend
a
couple
minutes
on
the
proposal
and
then
there's
three
pr's
they're
really
pain,
they're
chained.
So
I
I'm
also
looking
for.
Do
people
prefer
to
review
like
chained
pr's
as
three
commits
in
one
pr
or
as
three
prs,
which
then
you
know
mess
with
everyone,
because
they
keep
getting
squashed
anyways.
So
so
yeah
go
ahead.
H
Got
it
got
it
okay,
so
again,
maybe
people
can
take
like
two
minutes
to
read
this
and
then
I'll
take
I'll
take
folks
through
what
I
think
are
the
salient
points
that
okay.
H
H
So
I
I
sort
of
think
the
the
controversial
part
of
this
or
the
part
where
I
really
need
feedback
is
the
non-goals
right.
Everyone
likes
these
goals,
it's
great
to
have
a
release,
it's
great,
it's
great
to
not
churn
code
etc,
but
the
non-goals
are
desirable
things
that
I'm
saying
we
should
not
that
you
know
despite
their
desirability,
we
should
forego
these
things.
So
that's
really
what
I
want
to
talk
about
cool,
so
keeping
metrics
related
code
out
of
v
1.0
modules
right.
H
So
my
original
proposal
tried
to
be
kind
of
strict
about
these
things.
They
tried
to
say:
look
if
we're
releasing
a
module
and
we're
saying
it's
stable,
then
it
shouldn't
have
anything
to
do
with
metrics
anywhere
right
and
now
I'm
kind
of
relaxing
that
to
say
well,
if
you
have
metrics
related
stuff
that
isn't
exposed
outside
of
hotel,
meaning
it's
in
an
internal
package
or
it's
in
a
non-public
name,
that's
fine!
No
one
outside
of
hotel
will
ever
know
that
you
had
metric
stuff
in
it.
H
Right
now
I
mean
this
may
seem
like
a
pedantic
distinction,
but
it
really
matters
because
we
can
keep
having
lots
of
metrics
related
stuff
going
on
in
our
internal
package,
which
then,
for
example,
hotel
metric
can
import
the
internal
package
and
re-export
it
right,
but
that's
something
that
wouldn't
be
allowed.
If
we
said
the
top-level
module
must
be
metrics
free.
H
Well,
the
problem
is
that
it's
shared
by
lots
of
things,
so
it
contains
the
internals
are
used
by
metrics,
but
also
by
sdk
right
and
the
importability
of
internal
is
determined
by
where
you
are
in
the
hierarchy.
So,
if
I
move
the
internal
stuff
into
metric,
slash
internal,
then
slash
sdk
could
no
longer
import.
It.
H
And
so
we'd
have
to
then
do
a
lot
of
work
around
making
things
into
public
apis
that
are
somehow
public
only
between
these
things.
So
there's
like
I
went
down
this
path
and
it's
it
can
be
done,
I
think,
or
it's
close
to
being
doable,
but
it's
an
absolutely
massive
diff
that
will
that
will
churn
the
entire
ecosystem
right.
G
H
H
Yes,
though,
some
of
the
worst
offenders
yeah,
it's
like
there's
a
there's,
a
thing
called
a
label
set
and
yeah
I
mean
I
think.
If
you
look
at
earlier
versions
of
the
proposal,
you
will
see
refactors
to
to
break
up
some
of
those
moves.
H
I
think,
if
you
go
up,
if
you
go
to
the
issue
that
we
were
looking
at
and
scroll
up,
there's
a
hidden
comment
that
this
one,
that's
that
one
yep
that
one
okay,
so
those
are
some
of
the
moves
and
and
this
by
the
way,
doesn't
even
get
at
the
sdk.
Yet
this
is
just
moves.
You
have
to
do
for
packages
within
the
top
level
module,
and
then
this
has.
H
H
I
I
just
kind
of
began
doing
this
and
three
paragraphs
in
I
had
a
3
000
line.
Diff
and
I
didn't
want
to
go
any
further.
G
H
G
Yeah,
I
I'm
not
either
I'm
saying
like,
maybe
if,
if
there
are
package
restructuring
things
that
we
want
to
do
to
try
to
accommodate
this
in
a
more
like
idiomatic
or
long-term
maintainability
format,
then
maybe
we
should
be
more
motivated
to
do
that,
even
if
they
are
large
diffs.
You
know,
especially
if
they're
just
moves
like
these
are
things
that
we've
accomplished
in
the
past
and
tried
to
you
know,
scope
and
and
get
through
the
pipeline,
but
I
just
yeah
accommodating
a
package
structure
that
we
inherited.
G
You
know
I
mean
I
don't
either
probably
explain
too
too
much
to
you,
but
like
a
lot
of
this
is
inherited
from
opus
census,
with
a
merger
of
open
tracing
things
coming
in
here
and
both
of
those
come
from
different
package
structures
so
like
there's,
definitely
a
different
ideology
there,
and
so,
like.
Maybe
there's
not
an
appropriately
well
thought
out
plan
here,
you
know,
keep
in
mind
the
versioning
stuff
came
afterwards
right,
like
conversing
stuff
came
like
a
month
ago,
so
yeah,
it's
yeah.
I
I
I
I'm.
G
G
That
goal
of
having
dependency
of
stable
modules
on
unstable
ones
seems
like
it
opens
us
up
to
a
possibility
of
making
a,
not
a
deliberate,
but
you
know
a
non-deliberate
mistake
where
we
actually
are
changing
something
in
the
api
by
like
changing
the
the
functionality
or
the
performance,
or
something
like
that
of
a
stable
api
that
you
know,
users
are
depending
on
could
be,
could
be
problematic
and
I
guess
a
bug,
but
maybe
more
than
a
bug
like
that
could
be
a
conflict
at
that
point,
because
we
may
have
like
different
functionality
where
things
are
returning
things
in
different
formats
than
what
they
originally
were.
G
The
label
set
is
kind
of
the
thing
that
comes
to
mind
on
that
one.
That's
an
interesting
problem
and
I
think
that's
a
it's
something
yeah,
that's
something
that
I
think
to
worry
about
a
little
bit.
H
Yeah,
no,
I
I
agree
so
this
is
not.
This
is
not
an
easy.
This
is
not
an
easy
choice
for
sure
yeah.
Now,
regarding
what
you
said
about
table
packages
depending
on,
like
accidentally,
exposing
unstable
details,
there
are
things
you
mentioned,
such
as
performance
implications
or
erased
types
like
if
I
say
I'm
going
to
return
an
interface
and
then
I
give
you
back
a
different
concrete
type
than
I
used
to
give
you
no
one's
going
to
catch.
H
That's
not
that's,
not
an
api
change,
but
it's
a
it's
an
observable
behavioral
change,
so
those
are
real
things
and
I
don't
know
what
to
do
about
them.
However,
what
we
can
do
is
there
is
tooling
that
lets
us
say:
okay,
your
package
is
1.0,
which
means
that
1.1
must
be
compatible
with
1.0,
and
I
will
programmatically
verify
that
right
now.
That's
only
that's
only
verifying
it
at
the
like,
very
sort
of
legalistic
api
level
right.
H
It's
not
doing
any
of
these
subtler
concerns
that
we
talked
about,
but
it
is
something
it
is
something.
So
we
could
as
a
follow
on
to
this,
we
could
say
you
know
we
talked
about
building
tooling,
to
improve
how
we're
going
to
do
one
point
of
releases.
Part
of
that
could
be
1.0
and
we
will
enforce
compatibility.
G
G
I
think
it
was
dave.
Cheney
wrote
this.
I
can't
remember
who
wrote
this
it's
one
of
the
probably
so
I
remember
them
giving
a
talk
about
this
and
it
does
a
really
good
job,
also
of
testing
the
comparability.
That's
another
one
or
just
like
fields,
type
differences.
H
G
H
So
that's
one
now
so
we
talked
about
one
and
two
and
the
third
one
is
cyclic
module
dependencies.
So
again
I
I
spoke
about
this
last
time.
Something
I
realized
was
even
a
thing.
Maybe
a
week
ago
you
can't
have
package
dependency
cycles,
but
you
can
totally
have
module
dependency
cycles
and
one
good
thing,
arguably
about
module
dependencies
is
that
module
dependencies
actually
allow
us
to
keep
people
in
lock.
H
Step
like
let's
say
I
have
a
stable
x,
depends
on
unstable
y,
then
actually
there's
a
specific
version
of
unstable
y
that
works
for
stable,
x
right
because
unstable
may
change
at
the
next
one.
You
can't
safely
upgrade
from
0.5
to
0.6
and
expect
that
things
will
be
fine.
So
the
way
you
enforce
that
is
you
say,
1.0
depends
stable,
1.0
depends
on
unstable,
0.5
depends
on
stable,
1.0.
H
So
so
these
all
three
of
these
things
are
very
distasteful
and
I
want
to
be
sure
like
if
you
look
at
the.
If
you
look
at
the
pr
it's
a
big
diff
and
we
can
spend
time
talking
about
the
lines,
but
I
think
these
three
things
are
what
we
have
to
accept
right
or
we
want
to
take
a
different
approach,
and
then
I
I'd
love
to
hear
what
that
approach
could
be.
H
I
guess
one
bias
I
have,
and
maybe
I
don't
know
if
everyone
shares
that
bias,
I
think
it
is.
It
is
important
for
us
to
get
on
a
release
cadence.
It
is
important
enough
that
you
know
we
can
accept
some
some
of
these
warts
and
and
agree
to
maybe
more
painful
process
of
api
evolution
afterwards,
but
that's
better
than
not
releasing
and
just
trying
to
get
to
a
more
a
more
idiomatic
organization
of
our
code.
H
This
is
except
this
is
kind
of
choosing
between
two
evils.
Not
not
really.
You
know,
like
I
said
not.
E
As
you
say,
these
may
be
things
that
in
an
ideal
world,
we
could
also
make
goals,
but
I
don't
think
that
any
of
them
are
one-way
doors
like
we.
We
can't
we
can
back
out
of
this
decision
yeah
later
on,
because
I
think,
as
you've
made
clear
here.
All
of
this
is
talking
about
internals
of
the
implementation.
E
As
long
as
we
keep
the
apis,
the
public
apis
of
the
stable
modules
complying
with
semver
were
in
line
with
zenfer.
So
I
think
tyler's
looking
at
the
spec
for
does,
does
it
say
anything
about
explosive,
dependent.
H
In
my
opinion,
this
is
one
of
the
oddities
of
golang
areas,
rather
where
we
have
to
diverge
because
the
way
go
internal
package
dependencies
work
is
just.
I
haven't
seen
that
concept
anywhere
else.
E
Okay,
I'm
not
opposed.
It
sounds
like
the.
The
alternative,
then,
is
to
make
more
public
api
so
that
we
can
share
that
code
amongst
modules
that
otherwise
wouldn't
be
able
to,
and
but.
H
H
G
Yeah,
so
is
the
significant
refactor
of
code
moving
around
the
internals,
or
is
it
actually
changing
apis.
H
So
I'll
give
you
so
a
bunch
of
them
are
just
moving
around
internals,
but
here's
an
example
of
something
that
I
couldn't
figure
out
how
to
do
without
changing
apis.
There
are
so
there's
labels
set
and
then
there
so
there's
like
a
mutable
ish
label
set
and
an
immutable
label
set.
They
both
exist
and
there
are
translation
layers
going
from
one
to
the
other.
H
H
Okay,
and
now
I
I
I
couldn't
tell
you
why
it
was
on
my
critical
path.
I
think
this
is
like
one
of
those
yak
shaving
things,
but
but
it
like
it
wasn't
like.
Oh,
this
would
be
nice
if
they
could
be
unified,
it
was
they
have
to
be
unified,
because
otherwise,
there's
a
package
that
is
internal
that
has
to
be
made
public.
G
H
Like
right
now,
the
motivation
for
doing
it
is
oh,
it's
inefficient.
I
mean
it's.
It's
inelegant
that
there
are
two
similar
things
and
it's
inefficient,
that
we're
cut
that
we're
converting
back
and
forth,
but
also
one
of
them
is
private,
and
one
of
them
is
not
right
and
because
that
private
thing
is
at
a
module
boundary
it's
at
a
module
boundary
because
it
turns
out,
like
you,
store
these
things
in
context
and
then
someone
else
patches
them,
so
they
need
to
have
access
to
that
type.
H
So
there's
other
solutions
like
oh,
we
could
make
these
into
interfaces
and
then
type
assert
the
interfaces.
But
again
these
are.
These
are
semantic
changes
or
these
are
code,
changes
not
just
moves
and
renames,
and
I
think
after
my
first
four
weeks
of
working
on
this,
I
decided
that
it
was
risky
to
do
code
changes
at
this
time.
G
H
If
we're
hoping
to
get
to
shipping
release
in
a
few
weeks,
then
I
shouldn't
be
making
code
changes
that
maybe
require
a
lot
of
review
and
a
lot
of
testing.
E
Not
so
much
risk
that
it
won't
work
but
schedule
risk
in
terms
of
the
things
might
slip
because
of
reviews
and
approvals
and
dealing
with
the
the
fallout
of
those
changes
elsewhere,
there's
no
effects
that
are
unforeseen
yeah
exactly.
I
think
I
agree
with
that.
This
seems
like
the
most
straightforward
path
to
getting
to
1.0.
G
Yeah-
and
I
hear
you,
the
worry
that
I
have,
though,
is
that
the
release
of
1.0
is
not
going
to
be
something
that
is
going
to
be
like
really
desirable.
That's
the
that's
the
other
side
right
like
I,
I
get
it
like.
G
We
need
to
get
something
out
and
I
think
we
should
probably
try
to
push
those
timelines
and
accelerate
them,
but
the
idea
is
also
like
adoption
like
if
we
do
release
something
and
a
lot
of
people
are
not
anticipating
or
they
don't
really
enjoy
using
the
the
product,
because
it
includes
breaking
changes
where
it
includes.
G
You
know
some
weird
code
structure
like
I
don't
want
to
like
push
that
on
people,
because
then
their
adoption
from
weapon
census
or
open
telemetry
is
going
to
be
hampered
in
that
process
and
that's
not
really
ideal
either.
So
I
just
want
to
make
sure
that
that's
taken
into
consideration
here
as
well.
H
Absolutely
and
that's
why
I
think
anything
where
we
say
hey
the
public
api
of
this
is
bad
in
some
way.
We
should
fix
that,
but
again,
the
public
api
of
this
is
roughly
the
same
as
the
public
api
we
have
right
now.
H
H
G
Sure,
if
I
remember
correctly
also
that
I
thought
the
idea
was
to
dissolve
the
global
package
into
like
a
module
specific
package
so
like
the
global
package
was
to
be
moved
to
the
tracing
and
for
the
others.
H
Yeah,
I
think
josh
mcdonald
suggested
that
I
think
again
it's
a
good
idea,
but
I
triaged
it.
I
said
yes,
but
nothing
prevents
us
from
doing
that
later
because
again,
right
you're,
adding
to
the
api
you're,
not
you're,
not
taking
away
from
the
api.
E
G
Yeah,
okay,
I'm
with
you.
This
sounds
interesting.
D
H
Sure
I
think,
if
the
easiest
way
to
review
it
might
be
to
just
look
at
the
third
pr,
which
has
all
three
comments
and
then
look
at
look
at
it
commit
by
commit.
H
Yes,
I
think
this
is
this
is
the
one
to
look
at
yep,
so,
let's
quickly
look
at
the
first
one
automate
maintenance
of
replace
directives.
This
may
make
anthony
happy
or
it
may
not.
I
don't
know,
there's
a
go
file
down
at
the
bottom
of
this
if
we
scroll
down
to
that
yeah.
So
this
this,
what
this
does?
Is
it
pretty
much
so
right
now
we
have
replace
directives,
sort
of
hand
written
in
various
codot
mod
files
that
cross
link
the
modules
to
each
other
right.
H
So,
basically,
and
and
you
have
every
time
you
add
a
module,
you
need
to
go
figure
out
which
other
modules
transitively
depend
on
me,
so
that
I
can
go.
Stick
a
replace
directive
into
those
modules
right
right
and
this
is
sort
of
laborious
and
actually
there's
no
insight
that
goes
into
it.
So
this
literally
says
go
into
every
module
and
replace
every
other
module.
H
E
I
think
it
largely
is
some
of
the
no.
No,
the
examples
wouldn't
be
mutually
dependent,
so
it
may
not
be
as
much
of
an
issue
in
contributing.
H
But
again
like
if
we
wanted
to
have
this
kind
of
automated,
like
the
tool
that
I
have
written
has
knows
nothing
about
open
telemetry.
So
we
could
literally
use
the
same
tool
and
crosslink
contrib
as
well.
G
Yeah,
I
don't
think
it's
needed
and
contribute
just
because
I
don't
think
that,
like
you
know,
instrumentation
from
one
library
doesn't
depend
on
instrumentation
from
another
outside
of
like
empty,
so
the
example
or
the
top-level
version,
but
other
than
that.
I
think,
like
it's
yeah
you're
saying
a
hub
and
spoke
sort
of
model.
I
think
this
is
like.
We
have
a
lot
more
interdependence
here.
You
know.
G
Yeah,
that's
the
that's
the
thing
that
kind
of
I
guess
it's
the
we're
filling
up
the
bath,
I'm
just
wondering
if
we're
gonna
eventually
throw
the
baby
out
with
that
bath
water.
If
we
try
to
clean
this
up
in
the
future,
but
I
don't
know
if
you
can
in
that
script
easily
determine
like
dependencies,
it
seems
like
an
all
or
nothing,
I'm
sure
I
can
right.
Well,
I'm
sure
you
yeah,
without
without
like
syntax,
parsing
and
running
through,
like
you
know,
some
sort
of
dependency
tree
or
something
like
that.
H
No,
I
think,
I
think
what
it
takes.
Is
you
right
so
so
go
list
lets
you
figure
out
all
the
packages
and
I
can
prune.
H
Yeah,
that
is
how
much
thing
in
json
and
then
I
can
prune
it
down.
That's
it's!
Actually,
it's
doable.
I
just
again,
you
know
the
simplest
thing
that
works,
but
I
think
that
is
valid
feedback
and
I
can't
I
can't
incorporate
that.
E
H
G
No,
I
like
this
in
this
one
for
this
exact
reason,
in
fact,
there's
actually
some
things
here
that
I
wanted
to
probably
pull
out,
because
I
was
looking
at
trying
to
trying
to
do
very
similar
things
in
replacements
for
the
makefile,
because
right
now
like
we're
only
running
in
linux
and
that's
really
great.
But
if
you
want
to
try
to
test
this
on
windows,
like
I
don't
know
anything
about
windows.
G
Well,
I
I
mean
that's,
not
that's
a
lot
but,
like
I
don't
want
to
write,
you
know
powershell
or
something
like
that,
and
so
I
think
that.
G
G
H
D
H
Like
into
things
within
internal
slash
tools
as
libraries,
but
but
this
is
all
you
know
following
like
yagni
pretty
religiously.
G
H
H
Okay,
cool,
so
so
the
rest
of
this,
the
rest
of
the
diff,
is
all
automated.
I
think
there's
nothing
to
review
other
than
do
you
trust
this
code
itself
and
the
ugly
thing
about
it
is
that
you
have
replace
directives
in
a
module
with
itself
and
that's
necessary,
which
blew
my
mind.
G
H
H
G
Okay,
the
one
thing
can
we
track
the
refinement
of
this.
H
H
I'll
I'll
make
a
note
of
that
and
I'll
I'll
do
that
okay
track,
go
really
then
track.
H
Pruning
that's
what
I
wanted:
yeah,
okay
cool.
So
let's
look
at
the
other.
The
other
two
comments,
if
you
don't
mind.
G
Yeah,
so
it's
creating
the
metrics
trace
hotel
test,
sdk
export
metric.
H
G
H
It's
easy
to
layer
on
top
of
this,
because
the
tooling
now
will
maintain
whatever
nonsense,
like
whatever
automated
things
have
to
be
maintained.
G
Yeah,
I
got
you.
The
thing
that
also
really
stands
out
to
me
is
this
export
package
here,
like
this,
is
kind
of
we
talked
about
unifying
this
and
moving
these
packages
into
the
other
out
of
this
export
and
into
like
the
I,
the
trace,
at
least
that
made
a
lot
of
sense
to
just
take
what's
here,
which
is
really
nothing
and
try
to
unify
based
on
like
this
exporter,
it
is
more
of
a
part
of
the
sdk.
G
The
problem
is:
is
that
the
metrics
side
of
things
is
a
lot
more
complex,
and
I
don't
this
is
the
thing
like.
I
don't
think
that
that
should
like
stop
us
from
from
getting
rid
of
this,
given
how
like
unstable
the
metrics
sdk
is
currently
like.
I
don't
think
if
that's
something
we
really
want
to
like
persist,
because,
like
it's
already
existed,
I'm
not
a
big
fan
of
this
package.
G
I
think
that
especially
given
the
fact
that,
like
the
stable
part,
is
the
trace-
and
I
think
that
could
be
unified
into
the
sdk
itself.
So
that's
why
I'm
a
little
bit
worried
about
that
one,
but
I
think
that,
like
we
split
off
just
like
the
metrics
resource
trace,
this
is
an
interesting
one.
G
I
don't
know
if
there's
a
better
place
for
this,
it
needs
to
be
a
public.
It's
this
instrumentation
library
concept.
I
have
to
look
and
think
a
little
bit
more
about
this
but
yeah.
I
yeah
that's
an
interesting
question.
E
Okay,
yeah
and
that
I
would
be
wary
of
because
that,
basically,
the
only
thing
it
does
is
define
a
version,
and
thus,
if
it
can
drift
from
the
version
of
the
module
that
has
the
actual
code,
that
would
probably
be
a
bad
thing.
E
G
For
the
version
right,
it
doesn't
actually
provide
the
version,
so
this
is
yeah.
It's
it's
the
library,
essentially
the
instrumentation
library.
It's
just
this
concept
in
the
sdk
that,
like
the
trace
provider
and
the
meter
provider,
have
this
concept
of
an
instrumentation
library
that
have
a
name
and
a
version
and
like
this
is
the
only
place
that
it's
captured,
like.
I
don't
think
it's
a
unified
concept
across
metrics
and
tracing
it.
G
It's
probably
going
to
be
a
unified
concept
if
we
ever
have
like
a
logging,
sdk
as
well
and
so
like
it
needs
to
be
something
that's
not
in
either
of
those
two
packages,
but
at
the
same
time
like
it's
not
really
like.
I
don't
know
it's
a
single
structure
in
a
package.
H
Like
again,
I
would
ask
this
is
not
a
one-way
door
right.
The
the
the
guiding
principle
I'm
using
right
now
is
create
modules,
when
you
must
create
modules,
to
support
different
stability,
right,
yeah
and,
and
that's
not
necessarily
the
right
guiding
principle.
Maybe
it's
like
create
modules
to
to
capture
logical
groups
of
packages
and
like
that's
explicitly
not
what
I'm
doing
yet,
because
well
I'm
new
to
the
project.
I
don't
know
what
the
logical
groupings
of
packages
are
and
refining
module
breaking
modules
down
into
smaller
modules
in
future
versions
is
fine.
H
We
can
do
that.
Nothing
prevents
us
from
doing
it,
but
if
we
so
the
only
things
we
this
is
like
trying
to
do
the
smallest
number
of
things.
If,
if,
if
you'd
like
to
have
additional
modules,
even
between
now
and
the
1.0
release,
you
should
do
it.
This
is
just
saying
hey
if
you
wanted
to
release
1.0
tomorrow,
these,
like
only
aesthetic
concerns,
remain
there's
nothing
violating
once
you.
If
you
merge
this,
then
tomorrow
you
could
say
yeah,
I
have
a
1.0.
H
G
Yeah,
the
stabilized
api
and
the
sdk
that
I'm
like
much
less
confident
in,
especially
even
in
like
the
trace
side
of
things
like,
I
think,
there's
some
work
still
to
be
done.
I
know
there's
still
some
up
there
to
be
done.
G
Yeah,
yeah
and
also
api
is
an
overloaded
term.
Like
I
give
you,
like
the
you
know,
specific
application
program
interface
for
like
this
package
here,
but,
like
I
hear
what
you're
saying
like,
maybe
we
just
leave
the
instrumentation,
not
as
a
module
like
eventually
we
could
add
it
as
a
module
later
on
and
just
have
like
this.
H
If
we're
saying
sdk
is
like
the
go,
sig
is
not
planning
to
release
sdk
as
stable
as
part
of
the
trace,
1.0
release
only
apis.
I
think
it
will
limit
the
usefulness,
but
if
we
do
that,
then
we
get
out
of
making
some
of
these
module
changes
and
we
can
keep
iterating
on
it.
I
just
want
us
to
be
clear
like
how
what
are
we
defining?
As
you
know,
what
are
the
things
we
want
to
release
as
1.0
is
sdk
part
of
the
goal.
G
Yeah,
I
think
that's
a
really
important
question
like
and
I
don't
think
there's
there's
been
slight
discussion
on
that,
but
it's
been
really
preliminary
and
I
think
if
there's
like
two
schools
of
thoughts
there
right
like,
I
think
what
you
just
said
is
very
true,
like
it's
not
really
that
useful.
If
there's
no
sdk,
that's
stable,
you
know.
Maybe
it's
somewhat
useful
but,
like
you
know,
just
releasing
the
apis
is
probably
a
start,
so
the
instrumentation
libraries
could
depend
on
the
the
api
itself
and
start
instrumenting
things.
G
What
you
said
earlier
on,
where
like
having
a
release
cadence,
might
be
more
important
than
than
not
and
so
having
you
know,
a
very
limited,
1.0
release,
which
is
included,
like
you
know
the
trace
api,
whatever
the
spec
just
released,
essentially
like.
I
don't
think
that
the
sdk
has
actually
been
released
as
a
1.0.
Just
yet,
but
yeah
like,
I
think,
having
a
very
limited
release
on
that.
1.0
might
be
useful
because
just
increases
because
then
we
can
start
to.
You
know
make
that
a
rolling
setup.
G
Just
focusing
outside
of
the
sdk
is
a
good
idea,
also
maybe
putting
a
little
bit
of
pressure
on
people
like
me,
who
you
know
are
supposed
to
be
working
on
figuring
out.
Those
questions
in
the
sdk
is
probably
useful,
so
I
can
focus
a
little
bit
more
on
that
this
upcoming
week,
I've
been
looking
a
lot
of
tooling
just
to
try
to
like
get
a
full
force
multiplier,
but
like
yeah,
I
think
that's
probably
something
that
we
can
probably
take
a
little
more
look
at.
H
H
You
know
copy
them
into
into
a
text
file
or
a
spreadsheet
and
literally
say
which
of
these
things
are
like
whether
I'm
going
for
minimal
or
maximal
like
these
are
the
three
things
I
really
want,
and
then
you
know,
maybe
the
consequences
of
that
are
going
to
be
really
gross
in
tooling
and
death.
But
now
I
at
least
know
what
my
goal
is.
H
G
Us
as
well,
so
this
is
a
tradition
we
have
here
at
the
city,
so
you're
you're
you're
in
the
right
culture.
Then
that's
good.
H
Yeah
cool
and
so
then
the
third
piece
right.
So
we've
looked
at
this
diff,
which
is
about
which
modules
ought
to
exist
and
I
think
yeah
it'd
be
great
to
receive.
E
Feedback
there's
one
comment
I
did
make
on
on
that
diff.
That
probably
needs
to
be
addressed
is
that
the
go
mods
reference
go
1.16,
those
yeah
those
need
to
be
whatever
our
minimum
supported
version
is,
which
I
think
we've
talked
about
stretching
and
beyond
to
to
the
extent
that
we
can,
I
would
probably
define
them
as
1.14
unless
there's
some
feature
of
115
or
16,
that
we
need
in
the
module.
H
No
actually,
so,
interestingly,
we
have
first.
I
think
I
I
think
it's
a
great
idea
to
say
for
this
repository.
It
should
be
globally
1.14,
because
otherwise,
you
know
downstreams
will
have
a
hard
time
knowing
which
ones
work
and
which
ones
don't
work.
We
actually
have
115
stated,
as
is
required
in
some
existing
godot
mods,
and
I
would
be
in
favor
of
adding
a
ci
check
enforcing
114
until
you
know,
they're,
saying
either
114
across
the
board
or
114,
with
documented
exceptions
that
you
have
to
document
in
the
makefile.
H
That's
one
thing
and
then
the
other
interesting
thing
I
discovered
is
there's
an
actual
package
which
1.0
of
that
package
works
in
114
and
1.1
only
works
in
115..
So
we
have
yeah
we're
not
our
code.
It's
a
it's
a
third-party
dependency.
We
have
it's
ben
b
johnson
clock.
H
E
Yeah
yeah
and
that
that
may
end
up
being
out
of
our
hands
in
some
cases,
because
if
somebody
imports
another
dependency,
that
depends
on
the
higher
version
they're
going
to
get
that
higher
version.
So.
E
G
Go
for
that
minimum
discussion
point
here,
but
yeah,
I'm
with
you!
That's.
H
H
I
thank
you.
I
I
really
appreciate
the
time.
Thank
you
so
much
so.
Finally,
there's
package
moves
so
again.
Please,
please
continue
sending
comments
on
the
right
set
of
modules.
The
good
thing
is
now
we
can
implement
those
changes
quite
easily,
like
just
saying
make
a
module
here
here
here
in
the
existing
package
hierarchy
right
easy
to
do
and
then
the
actual
funk
moves.
So
a
lot
of
the
diff
is
because
well
the
funk
move
necessitates.
H
Those
are
the
changes
I
was
trying
to
avoid.
This
is
the
minimal
set.
The
question
is
like:
where
do
the
funks?
Where
should
the
funks
end
up
right,
they're?
Moving
from
global
to
somewhere,
I
created
a
metric,
slash
global
to
house
them.
Perhaps
they
should
have
gone
metric.
Perhaps
they
should
have
gone
somewhere
else.
Please
give
me
feedback
on
that.
G
We
will
have
conflicts
which
is
pretty
systemic
in
this
ecosystem
of
just
like.
We
have
like
three
different
global
packages
at
that
point,
and
so
there's
gonna
just
be
import
names
which.
G
Yeah
then
yeah,
I
think
that's
that's
reasonable.
E
Yeah,
I'm
kind
of
wary
of
just
the
the
global
package
name
for
that
part.
For
that
reason,
I
would
maybe
lean
more
towards
putting
them
one
level
up
just
in
metric,
but
I
will
take
a
look
at
this
and
think
about
how
well.
H
Metric
already
has
an
exported
thing
called
called
tracer
or
a
chord
meter.
So
again
I
could
do
it,
but
then
I'd
have
to
do
a
rename
and
not
just
a
move.
G
Yeah,
the
meter
function
itself
was
kind
of
a
a
short
shortcut
convenience
function,
so
yeah.
G
Don't
want
to
I'll
I'll
take
a
look.
This
is,
this
seems
reasonable.
I'm
with
anthony,
I
might
suggest
going
up.
One
thing
I
am
also
interested
in
is
like
there's
a
lot
of
internal
global
package.
Paraphernalia.
Did
you
move
that
to
here,
or
is
that
stayed
in
like
the
top
level.
G
H
G
G
Appreciate
it
well,
I
just
want
to
make
a
call
out
and
a
call
to
action
for
everyone
on
the
call
you
just
reviewed
this
pr.
So
could
you
go
take
a
look
at
this
and
just
put
your
comments
in
here
if
you're
paying
attention.
H
Should
I
close
the
two
other
chained
pr's
and
just
leave
the
last
pr
with
three
commits?
What's
the
easiest
way
to
review
this,
the
commits
are
very
clearly
separated,
but
you
know
reviewing
the
whole
pr
is
mind.
Numbing.
E
Yeah,
I
think,
that's
probably
the
the
easiest
way.
If
you
just
call
out
please
review
this
commit
by
commit,
it
will
be
easier
on
you,
that'll,
be.
E
As
maintainers,
because
then
as
we
go
and
try
to
merge
them,
we
have
to
merge
one
then
merge
master
back
or
main
back
into
the
the
other,
the
next
one,
and
keep
repeating
that
loop
waiting
for
the
ci
in
between
every
time.
It
kind
of
becomes
a
little
bit
of
a
hassle,
there's
only
three
here,
so
it's
not
as
bad
as
what
dependable
does
to
us
every
once
in
a
while,
but
I
think
that
would
be
slightly
easier
on
us.
H
That
would
be
great.
I
would
love
to
have
your
because
maintaining
those
chain
prs,
given
that
I
I
have
an
early
base
is-
is
hellish
so
yeah.
Let
me.
E
E
All
right,
I
think
the
thing
tyler
also
was
alluding
to
is
that
we
can
always
use
more
reviewers
and
approvers
in
this
project.
Many
of
you
who
are
interested
check
the
contributing
docs
to
see
the
process.
Let's
get
through
that.
If
you
want
to
become
a
reviewer
and
or
approver,
I
think
we
would
be
happy
to
sponsor.
Most
of
you
also
slightly
relatedly,
I'm
tomorrow's,
my
last
full
day
at
my
current
job
and
I'll
be
taking
a
few
days
off
or
a
few
weeks
off
before
starting
a
new
job.
E
So
there
may
be
some
time
in
the
beginning
of
march,
where
I'm
not
available,
while
I
figure
out
clas
and
all
of
that
stuff
with
with
a
new
job
how
that
works.
But
I
expect
I
will
still
be
around
and
contributing
going
forward.
G
Yeah,
I
I
think
if
you
haven't
met
the
requirements,
we
can
yeah
message
me
afterwards
if
you
haven't
met
the
requirements,
but
if
you
have
just
yeah
make
a
request
to
be
become
a
approver
here
and
then
we
can,
we
can
go
from
there.
We
should
probably
look
at
I've
talked
to
a
few
people
a
little
bit
about
the
maintainer
position
as
well
going
forward
if
anthony
doesn't
be
able
to
contribute
some
time
or
if
we
want
to
accelerate
the
program
getting
some
more
people
here.
G
So
we
can
probably
talk
a
little
bit
more
about
that
going
on
in
future
meetings.
It's
not
really
critical.
As
anything
you
say,
we
have
a
little
bit
of
time
so
we'll
make
it
work.
There
is
administrative
talk
going
on,
but
yeah
absolutely
thanks.
Everyone
for
joining
I'm
taking
way
too
much
for
your
time.
At
this
point
and
we'll
see
you
all
next
week
or
virtually
and
yeah
have
a
good.