►
From YouTube: 2020-10-06 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
C
Or
evening,
depending
on
your
time
zone,
I
guess
we'll
give
people
a
few
more
minutes,
just
in.
C
C
C
C
Well,
I
guess
we
can
start.
I
was
sort
of
I
was
hoping
mike
would
be
here,
because
this
time
was
sort
of
specifically
to
help
him
be
able
to
attend,
but
that's
fine.
He
might
be
running
late
or
just
unable
to
attend.
Today.
C
Let's
yeah
do
anyone
have
anything
they
want
to
add
to
the
agenda?
The
one
thing
that
I
had
so
far
was
that
we
should
discuss
sort
of
release
planning
generally
and
how
we
should
be
thinking
about
that
and
kind
of
the
upcoming
sort
of
before
the
ga
and
and
as
the
ga
hits
like
how
we
should
be
timing.
These
out
was
there
anything
else.
A
Since
we
are
heading
to
jay,
I
think
we
made
the
test
coverage
or
based
on
that,
we
made
it
more
test.
Wait
for
our
library,
don't
I
don't
think
we'll
have
those
already
right.
A
A
C
Yeah,
so
that
yeah
we
could,
that
should
be
relatively
easy,
but
yeah
we
could
do
that.
A
C
Yeah
that
that's
probably
a
better
point,
I
think,
adding
test
coverage
as
a
as
something
that
is
checked
would
be
relatively
easy,
but
really
having
a
high
test
coverage
would
probably
be
difficult
yeah.
So
that's
a
good
point.
B
Yeah,
I
mean
that's
a
that's
a
good
point
about
the
covering
all
the
protobuff
and
generated
files
with
jrpc
libraries
right,
there's
also,
probably
a
case
we
made
about
standardizing
what
library,
grpc
library
we
use.
I
think
the
otlp
exporter
uses
grpcio,
but
I
think
some
of
the
examples
use
tonic.
B
Yeah
I
there
was
a
reason.
I
chose
grp
cio
and
I
can't
remember
what
it
was
for
the
otlp,
because
something
with
the
there
was
something
I
couldn't
do,
which
was
necessary
to
satisfy
the
tracer
interface.
B
B
C
Okay,
well,
I
guess:
let's
just
run
down
these
real
quick,
and
if
we
have
more
things,
we
can
always
add
them.
So
from
release
perspective,
I
think
it
makes
sense
to
probably
do
one
now
we're
sort
of
at
the
point
where
most
of
the
open
breaking
changes,
at
least
in
the
issues
that
we
have
are
done.
C
There's
still
obviously
a
lot
coming
up
just
from
the
spec
open
prs,
but
I
think
that's
probably
fine.
We
could
just
keep
kind
of
rolling
out
breaking
releases
and
there
aren't
that
many
people
using
this
crate,
where
they'll
start
to
get
annoyed,
there's
definitely
a
lot
of
frustration
with
the
go
implementation,
because
people
are
actually
using
that
so
they
break
things
super
frequently.
Well,
I
guess
everyone's
breaking
things
really
frequently,
but
it
seems
like
they
have
a
lot
of.
C
They
have
more
traction,
so
people
are
starting
to
complain
there,
but
no
one's
really
complaining
here.
Yet
specifically,
so
it's
probably
fine
if
we
kind
of
increase
the
release,
kidney
cadence,
even
if
we
break
things
for
a
few
folks
is
there
did
anyone
sort
of
have
preferences
on
how
we
do
this?
Like
one
option
would
be,
we
basically
start
releasing
betas
or
other
ways
of
sort
of
signaling
that
this
isn't
quite
the
final
thing,
and
that
lessens
the
blow
a
little
bit.
A
C
Be
fine,
so
just
keep
keep
it
up
now,
with
the
assumption
that
things
are
going
to
break,
I
think
adding
something
to
the
readme
would
probably
help
yeah.
E
At
ga
I
will
it
would
be
nice,
but
we
need
to
wait
for
the
spec
to
stabilize.
I
don't
think
they
expect.
A
C
A
Speak
of
which
does
j,
the
spec
has
a
like
timeline
for
the
j.
B
C
C
E
And
have
the
j
1.0
yeah
they?
Well,
they
had
a
target
which
I
think
was.
C
Yeah
like
now
or
I
mean
it
was
basically
around
now-
there's
I
think
the
spec
sig
is
sort
of
behind
more
or
less
things
are
moving
a
little.
I
don't
know
if
you
two
have
been
in
the
the
maintainer
calls
or
the
the
spec
sig
calls.
But
there's
there's
been
a
lot.
C
There's
been
some
active
discussions
there
about
people
sort
of
voicing
their
frustrations
about
pr's
moving
too
slowly,
and
so
it's
one
of
those
gripier
things
sometimes
but
yeah.
I
I
think
it
was
supposed
to
be
around
now
that
that
the
trace
ga
was
supposed
to.
The
phrase
was
supposed
to
happen,
but
I
imagine
it'll
happen,
soonish,
probably
in
the
next
few
weeks,
nice,
but
so
I
think,
there's
a
few
things
that
we
should
consider
before
going
to
1-0
one.
C
The
big
one
of
the
big
ones
was
the
async
interface,
which
is
at
least
async
now
but
uses
asynctrade,
which
people
aren't
a
huge
fan
of
in
public
interfaces.
It's
only
for
the
exporters,
so
I
don't
know
that
we
care
that
much.
But
there's
still
a
few.
I
think
there's
a
few
questions
in
our
api
beyond
spec
compliance.
C
There's
a
lot
of
methods
that
take
stirs,
for
example,
and
it's
not
clear
if
we
should
be
taking
strings
or
if
we
should
do
something,
that's
into
cow
or
there's
other
sort
of
performance
considerations,
there's
sort
of
performance
and
ergonomic
considerations
that
I
think
aren't
like
sort
of.
We
should
go
through
the
whole
api
with
kind
of
a
fine-tooth
comb.
Before
we
hit
1.0
and
and
say,
these
are
the
final
ways
that
you
that
you
create
these
objects.
C
I'm
sure
some
people,
if
they're
more
performance
sensitive
in
the
rest
community,
would
be
would
like
to
see
more
options
for
doing
things
without
allocating
quite
as
much
so
if,
for
instance,
all
of
your
key
names
are
static,
then
having
better
ways
of
expressing
that
or
if
you're,
if
your
values
are
static,
for
instance,
right
now,
there's
no
way
of
having
a
you
have
to
basically
clone
to
get
a
a
value
associated
with
any
of
your
attributes,
which
some
people
might
like
not
like.
C
So
there's,
there's
sort
of
generally
performance
characteristics
you
might
want
to
think
about.
The
other
ones
would
be
the
async
interface
right
now
or
the
export
interface
still
uses
arc.
C
But
every
exporter
basically
will
will
probably
clone
every
span's
attributes.
C
C
So
if
the
exporter
actually
wants
to
do
anything
like
form
its
export
like
it's
basically
the
way
that
it
serializes
its
export
format,
it
has
to
copy
everything
from
the
span
in
order
to
do
that.
Okay,
no!
Oh!
That
makes
sense
yeah
because
we're
because
we
passing
references
basically
in
in
the
async
interface
and.
B
C
Yeah,
so
that
would
be
that
would
still
be.
That
would
be
the
right
thing:
the
propagator,
the
exporters
yeah.
So
there's
a
there's,
a
reasonable
question
around.
Should
we
just
be
cloning,
basically
on
on
the
spans
drop
method
right
now
it
creates
an
arc
and
then
sends
an
arc
version
itself
to
every
exporter.
Basically,
so,
but
there's
just
that's
sort
of
an
example.
C
C
And
then
people
could
look
at
them
and
see
if
there's
better
ways
of
expressing
that
or
more
efficient
ways
or
and
sort
of
use
that
as
a
method
to
get
to
1.0
in
terms
of
the
interface,
I'm
not
sure
if
there's
a
better
way
of
expressing
the
global
interface
right
now
is
trade
objects
for
everything
which
basically
have
to
box
a
number
of
times,
so
there's
a
huge
kind
of
performance
overhead.
Well,
not
a
huge.
There
is
a
performance
overhead
to
that
approach.
C
It's
not
very
large
and
I
think
some
of
the
open,
telemetry
api
sort
of
makes
that
inevitable,
but
that's
sort
of
an
area
that's
worth
considering
from
an
api
perspective
as
well
like.
Is
there
a
better
way
to
generically
express
these
concepts
and
rest
without
having
to
box
anyway?
C
Those
are
just
some
some
examples
that
I'm
thinking
about
before
we,
even
if
we
hit
one
o
of
the
spec
support,
I'm
not
sure
that
we
would
want
to
hit
one
o
of
the
crate
until
we
answered
those
questions,
the
other
one
is:
does
it
make
sense
to
split
out
the
implementations
of
tracing
and
logging
and
metrics
in
order
to
be
able
to
have
the
crates
b10,
because
we're
still
going
to
release
breaking
changes
in
those
areas?
C
You
know
it's
like
a
third
of
the
crate
would
be
1.0,
but
two-thirds
of
the
crate
would
still
be
highly
changing.
I'm
not
sure
if
there's
not
really
a
rust
way
to
signal
that,
outside
of
the
actual
crate
not
being
100
and
there
being
sort
of
a
open,
telemetry
tracing
sub
crate,
that
is
1
0.
C
Unstable
yeah
yeah,
that's
probab,
that's
probably
fine
and
just
those
are
the
ones
that
get
worked
out.
A
A
The
problem,
the
concern
I
have
about
breaking
those
into
three
crates
that
I
imagine
open
telemetry
in
the
end,
have
to
want
some
collaboration
collaboration
between
those
three
different
like
telemetry
tools.
So
if
we
break
them
into
three,
maybe
especially
comes
later
and
tells
us
there's
a
correlation
between
those
three,
we
may
have
trouble
like
combining
them
together.
C
That's
a
good
point:
do
you
think
it
makes
sense
to
have
so
yeah,
so
in
that
sense
we
should
have
metrics
not
be
a
default
feature.
C
Yeah.
If
we
have
that
be
yeah,
that
should
just
be
unstable.
Okay,
that
will
work.
Is
there
anything
else
we
want
to
discuss
about
the
release
either
the
cadence
or
the
strategy
for
doing
it
or
the
features
we
would
want
to
be
in
there.
A
C
A
C
Yeah
yeah,
I
agree
I'll,
do
that
I'll.
Do
that
today
the.
B
Yeah
so
there's
that
opr
I
opened
yesterday
and
so
there's
that
spec
change
looks
like
they
want
to
revert
they're
just
a
previous
decision
about
where
to
put
the
third
party
propagators,
that's
gonna
like
if
that
lands
the
other
way
fine,
then,
when
this
release
won't
mean
anything,
but
I
would
be
a
little
concerned
about
publishing
stuff
that
can
trip
crate
and
then
removing
it
later
on
I
mean
that's
not
a
big
deal,
but
that
just
seems
like
we'd
be
spinning
in
circles.
C
Yeah,
that's
that's
a
good
it's.
It
is
annoying
and
I'm
not
really
sure
where
people
are
leaning.
There
was
so
that
that
issue
was
discussed
in
in
the
maintainers
meeting
yesterday,
which
which
you
all
are
everyone's
welcome
to
go
to
join
that
too.
If
you
want
to
get
context,
there's
not
a
ton,
that's
useful
for
actual
maintainers,
but
it's
largely
spec
related.
But
things
like
this
are
sometimes
interesting
to
get
insight
on
it.
C
It's
yeah,
it
seemed
like
there
definitely
was
a
lot
of
resistance
to
there
being
any
proprietary
or
semi-proprietary
formats,
even
platform,
specific
ones
that
are
sort
of
supported
by
the
main
sort
of
core
teams
and
in
those
repos,
but
I
think
they're.
C
It
seemed
like
there
sort
of
wasn't
understanding
that
the
platform
propagators
at
least
like
the
the
google
and
the
aws
propagators
sort
of
made
sense,
as
they're
they're
defined
publicly
and
they
will
likely
be
used
by
the
majority
of
people
like
most
people
are
on
aws,
or
I
mean
most
developers
are
just
on
aws,
so
yeah,
there's
that
and
people
might
be
using
jaeger
or
some
other
thing
on
aws.
But
it
does
seem
like
a
very
common
one.
C
C
The
exporters
are
obviously
more
work.
Yeah,
I
don't
know
I
mean
andreas.
Do
you
have
like?
Would
you
prefer
that
we
wait
for
that
issue
to
close,
or
do
you
prefer
that
we
just
go
with
whatever
we
think
is
most
likely
to
be
the
outcome
for
this
yeah?
I.
B
Mean
so
for
what
it's
worth?
I
I
think
that
the
code
is
cleaner.
When
we
put
all
the
propagators
in
the
in
the
id
general,
then
we
have
two
ig
generators
now
in
one
spot,
and
I
don't
think
that's
a
huge
deal
and
if
we
really
are
concerned
about
having
people
import
stuff,
they
don't
need.
We
can
feature
flag
that
in
the
sdk
the
as
far
as
waiting,
I
don't
care
one
way
or
the
other.
I
just
really
want
these
features,
because
I
want
to
start
playing
with
them.
C
Yeah
I
agree,
and
especially
the
the
async
changes
are
important
because
there's
lots
of
bugs
in
the
current
async
exporting,
so
it
would
be
nice
to
get
those
fixed
for
people
as
well
yeah.
I
know
the
discord
folks
are
using
it
and
they're
often
annoyed,
as
we
saw
from
the
pr
yesterday,
they're
sort
of
annoyed
that
some
of
the
features
around
that
so
yeah
it
would
be
nice
to
get
that
fixed
for
everybody,
okay.
Well,
why
don't
we
just
release
it?
B
C
Right
and
with
with
sort
of
the
understanding
that
all
these
are
breaking
changes
anyway,
the
sort
of
moving
around
of
these
pieces
is
probably
going
to
be
inevitable
to
a
certain
extent.
Yeah,
I
see
that's
so
good,
okay
yeah,
I
guess
we'll
likely.
We
should
do
another
bump
of
the
semantic
conventions.
I
think
that
one,
hopefully
the
script,
still
works
to
keep
all
those
variables
in
sync.
C
Okay,
that's
great!
Well,
let's!
Let's
just
do
that
then,
and
move
on
stair
park,
replicators,
we'll
just.
C
Okay,
yeah
with
regard
to
test
coverage,
is
there?
Is
there
a
sort
of
strategy
for,
or
are
there
other
areas
to
discuss,
besides
sort
of
grpc
being
difficult
at
least
yeah?
That's
not
a
great
way
of
mocking
and
stubbing.
These
is
there.
Are
there
other
areas
that
people
are
concerned
about.
A
A
Yeah
yeah,
but
we
still
need
the
actual
number
to
say.
What's
the
what's
the
actual
deal
here,.
B
That's
good
and
I
think,
when
we're
talking
about
testing,
we
should
also
be
talking
about
like
our
benchmark
tests
too,
because
I
don't
know
how
often
those
run-
and
I
don't
know
if
we
have
a
way
of
tracking
performance
degradation
over
the
course
of
time.
A
C
Yeah,
that's
a
good
point.
Also
the
there's
a
spec
issue.
That's
pretty
active
right
now
on
getting
the
standard
performance
test
so
that
one
at
least
will
likely
track
historical
performance
and
improvements
on
performance.
C
So
that'll,
be
I'm
not
really
sure
where
that
will
be
if
that'll
be
in
this
repo
or
if
there'll
be
a
standard
where
maybe
they'll
be
like
a
central
repo.
That
just
runs
all
of
them
to
have
a
sort
of
common
way
of
configuring
and
running
the
performance
benchmarks.
But
yeah
it'll
be
good
for
a
number
of
ways.
C
I
think
the
running
the
performance
benchmarks
against
spans
of
various
sizes
might
help
answer
the
async
exporter
or
just
the
exporter
pattern
we're
using
generally
like
it
might
be
clearer
that
we're
copying
well
yeah.
I
guess
that
might
help
answer
the
question
of.
Should
we
have
arcs
or
should
we
clone
the
whole
span
but
yeah
running
getting
those.
It
would
certainly
be
nice
if
we
had
some
way
of
tracking
them.
I'm
not
sure
if
github
actions
have
a
way
of
recording
and
sort
of
comparing
the
previous
or
but
I'm
sure,
there's
something
there.
C
That's
true,
and
we
could
just
manually,
I
mean
it'd,
be
nice
if
there
was
a
way
of
looking
either
at
historical
like
to
have
it
fail
if
there
was
a
serious
regression
or
something,
but
I
think
I
think
you're
right
that
minimally,
it
could
just
be
posting.
So
we
had
some
record
and
we
could
at
least
kind
of
manually
eyeball
it
to
see
if
something
is
changing.
A
Yeah
to
that
point,
we
may
also
need
some
tesla
utility
tools,
like
some
work,
structural
trade.
For
for
the
testing
yeah.
I
just
copy
a
lot
of
things
wrong
because
I
think
would
be
nice
to
have
centralized
like
one
more
spam
processor.
C
Yep,
that's
a
good
point.
Yes,
we
can
open
an
issue
for
that
as
well.
Yeah
that'll
help
okay,
anything
else
or
should
we
move
on.
B
One
other
thing
that
might
be
helpful:
I
don't
know
if
this
goes
under
test
coverage
or
just
general
contribution
help
like
to
like.
We
have
all
these
requirements
in
the
contrib
file
of
like
run,
cargo
clippy
run
cargo
phone
front
and
whatever
like.
Maybe
we
should
just
build
a
make
file
or
something
just
say,
run
make
and
if
everything
passes
you
can
submit
your
pr.
C
That's
a
good
point.
It's
sort
of
unfortunate
that
russ
doesn't
have
that
there
should
be
a
like
rust.
I
don't
know
configured
run
or
something
like
it's.
It's
weird
that
rust
was
sort
of
supposed
to
replace
all
the
make
files
from
cpl
plus
anywhere
else,
and
then,
ironically,
you
just
end
up
right
back
at
a
point
where
you've
you've
built
so
many
cargo
scripts
cobbled
together
that
you
need
to
make
file
again.
C
But
that
is
a
good
point:
how
it's
sort
of
annoying
to
run
all
of
those
by
hand
and
then
it's
more
annoying
to
do
a
full
pr
and
then
have
it
just
fail.
Yeah.
C
C
C
Yep,
that's
a
good
point,
so
we
could
have
an
issue
for
both
of
those
would
be
nice
cool
yeah,
any
other
thoughts
there.
Should
we
good.
C
Cool,
let's
see
the
grpc
one
yeah
so
from
I
think
they're.
I
sort
of
prefer
tonic
from
a
few
perspectives
for
the
grpc
library,
but
I
think
a
very
strong
reason
to
not
go
with
it
is.
I
think
it
doesn't
support.
Async
said
it
all,
I
think,
would
be
tokyo
only
whereas
jrpc,
oh,
I
think,
is
just
uses
generic
features
which
or
has
its
own
eggs.
I
don't
really
remember
the
internals
of
it,
but
it's
not
specifically
tied
to
tokyo.
As
I
recall.
B
If
I'm
remembering
correctly,
there
was
that
and
when
I
tried,
I
had
two
separate
branches
working
for
otlp
and
the
tonic
branch
which
I
didn't
submit
like
the
mod
file
was
gross
because
you
had
to
like
nest,
five
levels,
deep,
all
these
mods
to
get
the
because
of
how
the
the
proto,
the
protobuf
files
were
nested
in
the
sub
module,
and
so
like
every
single
subdir
had
to
be
its
own
empty
module.
That
was
nested,
which
got
I
mean
it's
not
a
big
deal
but
like
from
a
maintainability
perspective.
A
To
that
point,
I
just
want
to
make
sure
that
our
current
objective
is
that
we
want
to
support
order
on
time,
including
tokyo,
async
standard
everything
like
that
right
like
we
want
to
go
out
and
say:
well,
they
support
tokyo
as
a
single
one
time,
yeah.
A
A
I
just
want
to
make
sure
if
we
like,
if
we
like,
from
my
point
of
view,
if
we
want
to
be
the
library
for
technology,
we
shouldn't
have
any
limitation
on
what
kind
of
long
time
the
application
uses.
C
Yeah,
I
I
tend
to
agree
with
that,
which
is
why
we're
doing
we're
sort
of
bending
over
backwards
to
support
all
the
runtimes,
which
is
still
yeah.
It's
causing
a
lot
of
annoyance
in
like
the
async
exporter,
to
do
that.
C
It
makes
it
makes
it
difficult
to
call
spawn
in
a
bunch
of
places
because
you
have
to
pass
through
so
many
generics.
So
we're
currently
just
not.
C
It
would
be
nice
if
they,
both
at
least
supported
if
there
was
yeah,
if
they
both
supported
the
sort
of
standard
future
spawn
or
some
other,
I
mean
at
least
spawn
the
interval
one
I
could
deal
with,
but
that
one's
pretty
annoying
yeah,
but
it
there's.
No.
C
Nobody
here
at
least
has
feelings
that
we
should
not
support.
Async,
that
or
other.
C
A
C
I
am
yeah,
I'm
fairly
sure
that
it
doesn't
support
as
instead
but
yeah
it's
worth
it's
worth
checking.
I
think
that
is
the
answer,
so
I
think
then
we're
in
jrp
cio
land.
C
Yeah,
which
is
so
we
can-
I
haven't,
really
looked
too
much
at
the
client.
I
switched
the
jaeger
one
to
be
executor
agnostic
using
the
other
http
client,
which
seems
fine.
I
haven't
run
into
any
issues
with
it,
but
it's
always
a
trade-off
when
you're
using
a
much
less
popular
crate
yeah
there
could
be
rough
edges
in
there.
C
Oh,
that's
a
good
question.
Do
we
want
to
do
that
in
the
zipkin
exporter?
Well,
I
guess
we
can
just
release
another
version
of
zip
code
exporter
that
doesn't
have
to
block.
C
It
doesn't
have
to
block
the
release-
okay,
yeah,
so
that
makes
sense
as
the
grpc
library
anything
else
to
consider
here.
C
C
That's
good,
okay,
cool!
Well,
I
think
that
yeah,
that
seems
good
anything
else
to
go
over
before
the
release.
B
One
thing
I
was
just
noticing
the
release
schedule
as
published
in
the
readme
is
super
out
of
date.
Oh
yeah,
that's
a
great
point.
We
should
remove
that.
C
Oh,
there
is
a
question
that
I.
C
Had
right
now
we're
basically
re-exporting
everything
into
api
and
sdk
from
trace
and
that
there's
sort
of
pros
and
cons
to
that
one.
It
makes
the
docs
really
messy
because
it
adds
a
whole
bunch
of
pub
use
into
the.
C
Into
well
it
sort
of
separates
how
people
commonly
use
the
the
structure,
trait
from
how
from
where
it
actually
is
so
in
in
metrics,
for
instance,
they're,
not,
you
have
to
actually
go
through
sdk
trace
metrics
to
get
to
it,
instead
of
just
sdk
and
the
same
with
api.
C
Do
people
have
feelings
about
that
or
sort
of
like?
Is
it
better
to
have
one
super
complicated
module
with
all
three
like
logging,
tracing
and
metrics
types
in
it
for
sort
of
fewer,
like
shallower
imports,
or
is
it
better
to
act
more
actively,
name,
space
things
and
basically
remove
the
pub
export
on
that's
currently
there
for
for
the
trace
module.
C
We,
I
don't
think,
there's
anything
that
will
conflict
there
used
to
be
provider
which
conflicted,
but
that
got
renamed.
So
I
technically,
I
think
it
would
work
yeah.
It
makes
the
docs
a
little
more
messy
because
they're
all
in
the
same
place,
but
I
think
it
is
possible
to
do
it.
I
think
there's
some
question
of
sort
of
from
a
from
a
rust
expectations
perspective.
C
A
C
A
little
deeper,
and
so
you
know
I'm
not
not
really
sure
how
to
what
the
best
thing
is
here.
There's
sort
of
pros
and
cons
to
both.
B
I
I
I
could
go
either
way.
I
just
think
it's
good
to
be
consistent.
I
will
say
from
a
user
perspective,
even
if
we
don't
collision
on,
there
aren't
name
space
collisions.
I
think
that
the
the
process
is
similar
enough,
that
it
might
be
confusing
to
someone
who
hasn't
studied
the
crate.
To
say
wait
is
this
builder,
this
provider
builder
for
trace
or
for
metric
or
whatever,
and
I
think
it
might
be
good
to
be
explicit
about
which
component
you
really
are
using.
C
C
A
I
mean
for
an
eyebrow
perspective,
it's
obvious.
If
we
use
api
as
per
liable
like
when
you,
if
you
want
to
do
sdk,
you
have
to
dig
deeper,
which
makes
sense
to
me.
C
I
basically
just
mirrored
the
the
go
implementation,
because
that
seemed
to
be
where
everyone
was
actually
developing
what
the
spec
was
going
to
be.
So
it
made
sense
to
use
that
initially
for
metrics
but
figuring
out
where
things
are
is
really
difficult.
C
Even
for
me
in
the
in
the
metrics
sdk
like
when
things
are
in
sdk
export,
whatever
the
name
is
versus
just
sdk,
whatever
the
name
is
versus
api,
whatever
the
name
is,
there's
there's
three
that
are
commonly
used
now
and
that
just
I
don't
know
it
seems
like
poor
api
design,
but
I
I
guess
that
it
makes
sense
from
the
you
know
what
is
technically
in
the
api
versus
the
sdk
and
then
what
is
sort
of
like
traits
in
the
sdk
become
a
little
confusing,
as
sort
of
when
do
you
include
the
trade
from
the
sdk
versus
the
trade
from
the
api,
but
either
way
it
seems
like
api
being
top
level.
C
C
C
It
seems
like
we're.
Leaning
toward
having
to
type
it
out
like
trace,
should
be
in
your
in
your
import
path
to
disambiguate
and
to
sort
of
clarify,
even
if
it
leads
to
longer
imports.
Does
that
seem
right.
B
C
B
C
Yes,
yeah
even
right
and
yeah,
that's
one
where
that
happens
in
the
standard
library
too,
where
you
have
to
get
said
collections
hash
map
hash
map
to
get
at
different
things,
because
not
everything
is
pub
exported,
but
yeah.
No,
I
agree,
I
think
everything
at
their
top
level,
I
think,
makes
sense
and
to
me
having
everything
within
it.
Be
private
also
makes
sense.
C
So
basically,
they're,
like
the
docs,
would
flatten
out
to
where
there
really
only
is
one
documentation
point
for
each
of
these,
like
sdk
trace,
would
just
have
all
of
the
types
and
they're
not
pub
used
they're
just
used.
C
C
B
C
Okay
and
that
will
break
basically
everything
for
everyone,
so
it
makes
sense
to
do
that
now
in
the
large
like
if
we're
gonna
break
everything
once
in
a
with
a
huge
amount
of
features,
we
might
as
well
do
it
now
because
at
least
there's
a
large
benefit
to
people
upgrading.
C
Okay,
yeah-
that
was
one
of
the
ones
that
I've
been
thinking
about.
Let's
see,
I
don't
think
I
have
anything
else
that
I
can
think
of
right
now.
Anyone
else
have
anything
that
that
came
up
during
the
meeting
or
anything
else.
You
want
to
discuss.
C
Andres,
did
you
you're,
not
a
member
of
this
or
yet
right?
I
am
not.
Did
you
want
to
be?
We
can
add
you
as
well.
Yeah
that'd
be
cool.
Okay.
We,
oh,
I
think
you
have
to
join
the
org
first.
C
Yeah,
do
you
want
to
open
just
the
issue
on
the
community
repo
there's
the
just
the
standard
one
and,
and
we
can
sponsor
you
for
that?
Okay
and
I'll
just
tag
both
of
you.
Yeah
just
tag
us
on
there
and
we'll
get
you
in
because
once
you're
once
you're
part
of
the
org,
I
can
add
you
to
to
the
approval
and
maintainers
and
all
that
that's
great
yeah.
That
would
be
convenient.
C
Oh,
that's
a
good
point:
how
do
we,
so
how
do
we
feel
about
the
the
approver
maintainer
split
right
now?
Does
that,
like
I
mean
there's
not
that
many
people
involved
here?
That
seems
like
a
lot
like
for
large
companies
that
makes
a
ton
of
sense
to
have
sort
of
a
smaller
group
of
people
that
are
able
to
merge
and
everyone
else
who's
not.
Does
that?
A
A
I
mean
it's
really
depends
on.
I
don't
know,
I'm
not
sure
if
there's
gonna
be
a
like
big
big
consuming
too
much
time
for
you
to
enter,
to
merge
every
single
pr.
C
C
So
if
I
want
to
do
things
like
change
the
test
configuration
or
you
know
like
required,
required
actions
or
something
I
have
to
find
one
of
the
the
core,
like
technical
committee
members
to
do
that,
and
it
just
sort
of
feels
like
kind
of
an
arbitrary
hassle
yeah
does
it.
I
just
want
to
make
sure
the
project
doesn't
sort
of
generally
feel
like
that
like
it
should
still
be
easy
to
contribute.
To
I
mean.
D
B
D
C
Yeah
I
so
I
don't
really
feel
super
strongly
about
it,
but
I
think
it's
one
where,
if,
if
anybody
does
or
if,
if
anybody
wants
to
be
a
maintainer,
I'm
more
than
happy
to
add
you
as
one
I
think
I
actually
was
recently
given
the
ability
to
to
adjust
group
memberships,
I'm
not
sure
who
changed
that.
But
so
I
can
add
people
if
you
specifically
want
to
be
a
maintainer
just
sort
of
throwing
that
out
there.
Okay
yeah.
We
should.
E
C
Yeah
sorry
yeah,
the
sort
of
random
things
were
coming
to
me
at
last,
but
yeah,
okay,
there's
there's
nothing
else,
yeah
and
that's
that's
all
from
my
end,
then
cool.
B
C
C
C
Turns
out
turns
out
things
things
change
a
little
bit
cool.
Does
the
does?
The
weekly
cadence
still
make
sense
to
people.
A
C
Okay,
yeah,
the
calendar
is
also
not
one
that
I
have
access
to
change
so,
but
we
can
just
sort
of
not
join
the
meeting.
You
know
on
the
days
that
don't
make
sense
yeah
that.
A
B
C
Is
this
time
convenient
for
both
of
you
if
it
seems
like
we're,
probably
the
maybe
there'll
be
one
other,
but
because
we
could,
for
instance,
do
the
3
p.m?
Pacific,
if
people
are
more
close
to
that
time
zone,
but
if
people
are
closer
to
time
zones
where
this
is
a
more
convenient
time,
we
can
just
stay
with
this
one.
C
A
C
Yeah,
I
think
it's
fine,
but
yeah.
I
think
if
we
plan
on
sort
of
every
two
weeks,
I
think
probably
is
right.
A
C
C
Cool
sounds
great
cool
thanks
a
lot
guys
yeah.
Thank
you.