►
From YouTube: 2021-03-04 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
C
C
D
Cool,
so
I'm
seeing
some
people
filter
in
it's
like
we're,
still
got
a
little
bit
of
time,
but
we
might
have
critical
mass
to
maybe
start
this
thing
off.
So
anyone
who's
on
the
call
please
be
sure
to
open
up
the
doc
and
hand
yourself
as
an
attendee,
and
if
you
have
any
agenda
items,
please
add
them
to
the
list
and
go
over
it
and
start
sharing
my
screen.
We
can
start
digging
into
this.
D
So
maybe
just
start
us
off
yeah,
I'm
just
going
to
restructure
this
entirely.
Let's
start
by
looking,
maybe
here
at
the
project
board.
That's
a
good
idea,
maybe
start
at
the
top.
The
project
board
has
been
definitely
accreting
a
lot
of
really
good
issues
that
we're
identifying
as
we
go
towards
the
rc.
D
So
definitely
we're
definitely
picking
up
a
lot
of
new
to-do's
as
we're
finding
a
lot
of
gaps
in
our
implementation,
from
the
specification
which,
from
what
I've
been
seeing
in
the
stream,
that's
coming
in.
It's
just
really
great
stuff,
really
good
items
to
address
or
changes
that
people
are
proposing
so
definitely
worthwhile.
If
you're
on
the
call-
and
you
want
to
help
us
get
to
rc-
or
you
wonder
why
we're
not
at
rc,
there
are
four
reviewer
approved,
prs
right
here.
D
Some
of
you
on
the
call
have
already
actually
taken
a
look
at
them.
So
I'm
not
talking
to
you
obviously,
but
definitely
these
are
the
ones
that
could
use
another
set
of
eyes,
the
reason
they
have
merged.
They
just
have
one
approval
or
there's.
Maybe
there's
I
think
here
I
haven't
responded
to
steve,
so
don't
talk
about
that,
one
that
one's
definitely
taken
out
take
a
look
if
you
want,
but
some
of
these
are
are
waiting
for
me
to
do
things
on
them,
but
they
could
definitely
use
some.
D
Some
looks
people
look
at
it.
I
in
particular
this
one
from
patty,
j
and
aaron
has
a
nice
one
from
just
adding
in
the
http
json
to
the
hotel
exporter,
which
they
both
seem
pretty
straightforward
to
use
another
pair
of
eyes,
and
this
helps
us
get
towards
the
rc.
This
is
definitely
something
time
well
spent.
If
you're
looking
for
prs
to
review.
D
That
being
said,
the
we're
still
in
the
process,
I
was
hoping
to
have
this
done,
but
it
it
was
a
little
more
complex.
That's
not
the
link.
I
was
trying
to
make
there
the
spec
conformance
review.
We
have
definitely
some
momentum
going
here
as
well.
We're
still,
I
think,
gonna
have
to
maybe
look
at
the
existing
issues.
I
think
anthony's
on
the
call.
So
we
can
maybe
talk
a
little
about
this,
but
we're
definitely
moving
forward
and
finding
a
lot
of
those
gaps.
D
I
think
we've
done
a
really
good
job
at
outlining
from
the
specification
compliance
matrix
all
the
tasks
that
are
needed
here,
but
I
was
kind
of
posted
in
slack
that
compliance
matrix
is
it's
missing
sections
it's
outdated
and
in
some
cases
it's
conflicting
with
what
the
specification
says
to
be
doing,
and
so
it's,
I
think
something
we
may
have
to
restructure
these
a
little
bit
in
the
strategy
to
actually
make
sure
we're
fully
comprehensively
addressing
all
of
the
specification
that
we
need
to
release.
D
But
I
think
that
this
is
a
pretty
good
list.
15
item
sees
about
right.
Maybe
we
need
to
add
one
here
or
another
there
or
something
like
that,
but
I
think
this
is
pretty
good
for
what
we
are
need
to
do
to
get
this
actually
dialed
in
anthony.
I
don't
know
if
you
want.
C
D
C
When
I
created
these,
I
created
them
off
of
the
high
level
topics
in
the
compliance
matrix,
which
I
think
should
have
pretty
good
coverage
of
the
major
components
of
the
spec
that
need
to
be
reviewed.
So,
even
if
these
areas
in
the
compliance
matrix
have
missing
items
within
those
sections,
I
think
if
we
cover
all
of
these
review
sections
and
look
at
the
spec
in
addition
to
the
just
the
matrix
we
should
have
covered
most,
if
not
all,
of
the
spec
that
is
relevant
for
this
rc
yeah.
I.
B
Want
to
put
one
call
out
there,
I
started
delving
into
1603.
The
spec
is
split
into
multiple
files
in
some
cases,
so
just
be
aware
of
that.
D
Yeah,
you
just
wanted
to
call
that.
I
think
that's
something
also,
I
noticed
was
like
in
some
of
these
sections,
like
it's
split
across
the
api
and
sdk
in
the
sections,
and
so
like
the
export,
I
can
only
imagine,
is
just
way
worse
how
split
that's
going
to
have
to
be
aaron.
I
was
actually
wondering
about
this
one.
Is
this
not
okay?
If
I
assign
this
to
you
or
go
ahead,
okay,.
D
D
Yeah,
I
don't
see
punya
on
the
call,
but
yeah
he'd
ask
a
little.
You
know
a
leading
question
which
hopefully
we
can
try
to
answer.
I'm
hoping
to
try
to
answer
after
this
project
has
been
resolved
is
to
like
timelines
for
our
rc.
It's
really
tough
to
give
a
timeline
in
general
just
ever
which,
but
it's
even
harder
when
you
don't
really
have
a
good
understanding
of
scope
work.
So
I
think
that
this
is
a
really
good.
D
You
know
plan
that
we
have
put
forward,
I'm
hoping
to
have
this
done
by
next
thursday.
I
know
that
I'm
planning
to
dedicate
a
lot
of
my
time
next
week
to
resolving
the
rest
of
the
issues
as
much
as
I
can.
There
definitely
are
roadblocks
trying
to
resolve
things
in
the
specifications
sometimes
but
like.
I
think
that
that's
kind
of
my
goal
is
to
next
thursday
have
something
to
solve.
So
with
that.
D
I
think
that
we
should
be
able
to
then
maybe
kind
of
move
on
to
this
next
stage
of
looking
at
the
rc
project
board
and
maybe
start
trying
to
give
t-shirt
sizes
story
points
or
whatever,
like
I
don't
know
thing,
we
want
to
use
there
and
just
maybe
like
understand
like
how
long
some
of
these
issues
are
going
to
take
us
and
then
get
like
a
rough
estimate,
as
we
can
think
about
an
rc.
D
I
know
that
there's
a
lot
of
people
in
the
community
that
would
love
an
arbitrary
number
and
as
long
as
we
can
treat,
I
think,
communicate
it
as
an
arbitrary
number,
which
you
know.
Obviously
it
implies
that
there's
gonna
be
some
sort
of
caveat
that,
like
we're
trying
to
hit
these
dates,
I
think
it'd
be
helpful
to
the
community
to
know
this,
especially
if
a
lot
of
companies
are
trying
to
take
a
dependency
on
this
project
would
be
really
really
useful,
so
cool,
I
see,
putin
just
joined.
D
I
don't
know
how
much
of
that
you
caught
but
yeah.
Hopefully
that
was
helpful.
D
Cool,
so
after
jumping
onto
that,
let's
I
wanted
to
kind
of
touch
briefly
on
this.
It
was
identified
when
you
pointed
out
that
people
who
aren't
maintainers
or
people
who
don't
have
right
access
to
the
repo
can't
actually
dismiss
stale
reviews,
and
I
don't
think
I
actually
intended.
I,
I
think
I've
misunderstood,
dismissed
versus
re-request
a
review,
but
I
think
it
dismisses
probably
what
we
want,
which
is
unfortunate.
D
I
looked
into
the
repo
settings
and
it
looks
like
we
can
have
other
people
dismiss
reviews
like
you
can
explicitly
set
other
people
to
allow
the
dismissal
reviews
is
an
option
I
proposed
you
know
like,
should
we
include
the
restrictions
to
go
approvers
or
just
open,
telemetry
members
in
general,
I
I
mean
dismissing
your
review,
doesn't
seem
like
it's
something
that's
going
to
get
too
abused,
so
it
didn't
seem
too
scary
to
me
to
allow
that
the
other
thing
was,
as
I
was
looking
into
again
the
requiring
the
code
change
having
the
man.
D
What
was
it
dismissed?
Still
reviews
yeah,
I'm
not
re,
so
just
clicking
this
button
as
well.
The
not
the
new
reviewable
commits
I
double
checked.
Merging
from
maine.
Does
not
actually
dismiss
the
reviews,
which
is
not
really
a
problem?
D
It's
when
you
merge
in
things
that
are
like
review,
edits
or
something
like
that
or
somebody
like
suggested,
a
review
that
then
it
will
dismiss
things,
and
so
it
can
kind
of
be
a
pain
when
somebody
like
suggests
a
review
and
you're
like
yeah
I'll,
accept
that
and
then
it
dismisses
their
review.
But
I
I
don't
know,
I'm
also
like
on
the
fence
of
how
much
time
we
want
to
spend
on
this
because
it
seems
to
be
like
what
we
have
is
working
right
now.
So
I'm
not
too
worried
about
it.
C
Yeah,
I
don't
think,
there's
been
much
of
a
problem
with
steel
reviews.
It
would
be
nice
to
have
something
slightly
more
automated,
but
I
think
if
we
broaden
the
scope
of
who
can
dismiss
reviews,
then
people
who
make
substantive
changes
to
their
own
prs
should
be
able
to
understand
when
dismissing
the
previous
reviews
would
be
appropriate
and
we
can
rely
on
that.
D
Yeah
that
sounds
fun
to
me.
Cpu
knew
with
the
thumbs
thumbs
up.
Would
what
are
you
thinking
go
approvers,
or
are
you
thinking
just
open?
Tell
me
your
members
in
general.
C
I
think
probably
members
in
general,
okay
yeah,
then
that
at
least
gives
us
one
lever.
We
can
tweak
yeah
in
case
someone
abuses.
It.
F
C
D
Yeah,
so
let
me
see
if
I
can
show
you
a
little
example:
you're
not
alone.
I
I'm
pretty
familiar
with
like
the
re-request
review.
D
D
Available
to
everyone,
when
you
do
it,
it
does
actually
say,
like
you
know,
why
are
you
dismissing
the
interview,
so
you
have
to
provide
some
context.
We.
E
D
Now,
yeah,
that's
actually
pretty
fair
right,
so
yeah,
so
that's
kind
of
just
like
it
it's
instead
of
because
the
thing
is,
if
you
leave
the
old
review
on
and
just
re-request
the
review,
I
think
that
like
if
it
was
a
change,
request
or
request
for
changes,
it
still
will
persist
even
across
the
re-request
of
the
review.
D
So
like
somebody
does
need
to
go
in
there
and
dismiss
it
if,
like
they,
never
came
back
and
gave
you
another
review
kind
of
thing
so
yeah
say
I
came
in
steve
and
I
said
like
hey,
you
need
to
make
some
changes
and
then
I
drop
off
the
face
of
the
earth
and,
like
I
have
you
know,
30
days
later,
like
I
can't.
I
can't
clear
his
review
kind
of
thing
is
the
problem
so
yeah.
E
C
Yeah,
I
think
that's
the
situation,
I'm
more
concerned
about,
I
think,
if
people
have
said
changes
need
to
be
made.
We
understand
when
those
changes
have
been
made
and
are
appropriate,
and
you
know
even
if
they're
not
around,
to
say,
okay,
yes,
this
is
good.
Hopefully
they
were
explicit
enough
in
requesting
the
change
that
the
rest
of
us
can
evaluate.
Whether
they're
concerned
have
been
satisfied.
C
D
Well,
cool:
I
will
take
that
as
an
action
item
and
I
I'll
set
that
up
right
after
the
meeting.
It's
pretty
easy
to
do.
The
last
thing
I
had
on
the
agenda
was
in
the
maintainers
meeting
or
spec
meeting.
I
can't
quite
remember:
anthony
was
there
as
well,
but
the
idea
behind
the
versioning
requirements
for
these,
the
project
in
general,
open
telemetry
in
general
safety,
the
apa
ipa
might
change
without
compatible
backwards
changes
for
the
sdks,
and
so
this
was
kind
of
like
question
just
like
does.
D
This
is
going
to
work
with
our
cyclic
dependency
of
modules
and
I
hadn't
I
haven't
spent
any
more
time
other
than
putting
this
action
into
the.
C
C
So
I
think
the
expectation
is
that
the
api
will
have
the
flexibility
to
introduce
new
methods
to
interfaces
if
those
interfaces
are
only
expected
to
be
implemented
by
sdks,
and
the
expectation
then,
is
that
the
sdk
also
gets
updated
to
implement
that
interface
and
users
who
update
to
a
new
version
of
the
api,
will
have
to
update
to
a
version
of
the
sdk
that
supports
it.
So
the
question
is:
can
we
use
cyclic
module
dependencies
to
say?
E
Yeah,
I
I
think
we
could
use.
We
could
use
cyclic
dependencies
in
that
way.
I
don't
think
we
have
to,
though
right.
I
think,
right
now.
At
least
I
view
our
our
use
of
cyclic
dependencies
as
an
unfortunate
necessity,
because
we
want
to
get
the
release
out
and
then
there's
a
maybe
more
legitimate
use
of
cyclic
dependencies
to
negotiate
a
major
version
bump.
E
D
Yeah,
so
that's,
I
think
the
contentious
point,
because
the
specification
project
doesn't
see
it
that
way
and
since
our
major
version
has
to
keep
in
lockstep
with
the
specification
version,
we
can't
do
a
major
version
of
unless
it's
specific
it.
C
C
Yeah
can
we
bring
that
up?
Because
that's
that's
an
important
point,
because
if,
if
we're
going
to
say
that
adding
a
method
to
a
public
interface
necessitates
a
major
version
bump
on
our
end,
but
it
doesn't
in
the
spec
or
any
of
the
other
apis,
then
we're
going
to
quickly
become
an
outlier
there
and
not
being
able
to
version
independently
of
the
spec
version
will
be
a
problem.
B
Yeah,
that
is
something
that
we
were.
F
Also,
there
was
there's
that
pr
about
blocking
consumer
consumer
implementations
of
certain
interfaces
for
those,
isn't
it
the
case
that
we
are
at
liberty
to
add
methods,
because
we
know
that
no
one
else
could
implement
them.
C
Yes,
but
that's
exactly
a
package
right
so
that
that
wouldn't
be
the
situation
we're
talking
about
here
either.
What
we're
talking
about
is
if
the
api
has
interfaces
that
are
expected
to
be
implemented
by
sdks,
which
are
separate
packages
and
separate
modules
and
maybe
even
be
an
entirely
separate
implementation.
Someone
may
have
a
completely
different
implementation
of
the
sdk
that
satisfies
this
api.
B
D
C
D
Yeah,
I'm
not
too
sure
where
it
is,
but
I
don't
know
this
is
like.
I
think
one
of
the
things
that
ted
my
understanding
from
ted
was
that,
like
he
wanted
all
the
implementations
to
main
remain
like
the
minor
version
was
one
thing
like
it
wasn't
an
issue
that
was
expected
to
diverge
but
being
on
the
1.0
specification
means
that
you
should
also
be
on
the
1.0
version
of
whatever
your
library
implementation
was
yeah.
D
C
Think
that
got
dropped.
So
if
you
look
at
the
in
the
spec
yeah,
do
you.
D
E
E
D
Implement,
okay
and
what
file
is
that
from?
Is
that
from
the
versioning.
E
E
F
C
Know
a
couple
couple
points
up
from
that,
though
it
also
talks
about
api
sdk
and
semantic
conventions
may
be
at
different,
independent
version
numbers
and
there
are
separate
major
versions
there.
You
know
api
one
and
sdk2
right,
so
we
could
absolutely
end
up
with
an
api
2
and
an
sdk
1.1
that
works
with
api
2,
because
the
api
2
had
the
new
method
in
the
interface
which
is
breaking
for
its
consumers.
But
adding
a
method
on
an
implementation
doesn't
break
consumers
of
the
sdk.
E
Yeah
and
I
think
anthony
you-
and
I
discussed
this
a
little
bit
when
we
were
talking
about
versioning
stability-
that
it's
totally
fine
for
we
can
have
a
major
api,
a
major
bump
of
the
api
and
a
minor
bump
of
the
sdk
that
simultaneously
supports
both
api
major
versions
right.
I
think
that
would
be
desirable
right,
because
adding
support
for
a
new
sd,
adding
support
for
a
new
api
version
is
additive
from
the
point
of
view
of
an
sdk
right.
C
It
should
be
the
the
things
that
I'm
concerned
about
that,
I
think,
may
be
issues
for
us
when
we
get
to
incrementing.
Major
versions
of
anything
is
going
to
be
like
context,
propagation
and
the
keys
that
are
used
to
insert
and
retrieve
values
out
of
go
contexts
right
which,
since
they
will
be
scoped
to
a
package
and
different
major
versions,
are
have
different
import
paths.
B
E
The
way
we
could
do
it-
and
I
think
this
is
the
this-
is
a
kind
of
the
approach
that
the
the
description
and
the
go
issue
also
goes
into.
Is
we
could
have
an
internal
package
that
is
visible
to
both
modules
right,
so
it's
exported
from
the
internal
package.
It's
not
visible
to
anyone
outside
of
our
tree
and
therefore
it's
a
back
channel
through
which
the
two
things
can
coordinate.
D
Exist,
I
posed
the
question
in
the
open
source
channel
as
well
just
to
get
clarification
on
it
and.
D
Sure,
but
I
it
sounds
like
we
have
some
ideas
here.
I
definitely
want
to
have
this
correctly
understood
rather
than
you
know,
six
months
from
now,
all
of
a
sudden
we're
like
what
we
can't
do
this
so
yeah.
I
I
think
that
we
have
some
plans
in
some.
C
Some
but
yeah
okay,
this
also-
and
I
I
think,
even
if
we
are
able
to
version
them
independently,
bargains
concern,
I
think
is-
is
still
that
he
doesn't
want
to
have
rapidly
incrementing
major
versions
of
api
packages
which
this
may
still
lead
to.
So
that's
probably
still
something
we
have
to
discuss
with
him
about.
C
Is
this
a
situation
where
we
kind
of
skirt
around
the
the
strict
definition
of
semver,
just
because
of
goes
kind
of
weirdness
with
not
having
abstract
classes?
You
know
or
default
implementations
of
interface
methods
that
pretty
much
every
other
language
can
do
or
do
we
stick
strictly
to
it
and
say
yeah,
that's
going
to
cause
us
to
be
revving.
The
major
version
of
the
api
more
frequently
than
you
might
expect.
E
Right,
if,
if
the
problem
really
is
about
abstract
based
classes,
then
we
could
do,
then
we
could
go
with
the
solution
that
that
protobuf
uses
right,
which
I'm
sure
by
now
like
aaron,
is,
is
neck.
Deep.
In
that
we
could
say,
we
have
an
interface
with
an
unexported
method.
We
have
a
required
base
class,
a
required,
embedded
struct
that
has
that
unexported
thing,
and
then
we
can
involve
that
interface.
C
I
think
that
really
is
the
concern
here.
Is
that
that
the
the
spec
authors
want
the
flexibility
to
add
new
methods
to
interfaces
without
needing
that
to
be
a
major
version
of
the
spec
and
concurrently,
then
also
wanting
that
not
to
be
new
major
versions
of
apis
that
let
the
spec.
D
I've
been
thinking
about
this
for
a
little
bit
the
the
idea
of
like
embedding
an
internal
implementation
because,
like
we're
required
to
have
a
no
op
implementation
for
pretty
much
all
of
the
api
interfaces
that
we
have,
and
so
I
mean
it's
not
like
impossible
to
do-
that.
The
downside
of
doing
something
like
that
is
also,
then,
if
we
extend
it
and
we
extend
the
no
op
implementation,
then
by
default,
everyone
that
is
going
to
just
bring
in
that
new
node
implementation
isn't
going
to
get
anything
but
a
noaa.
D
So
it
may
be
like
a
little
bit
unclear
and
so
like.
Okay,
now
we
have
this
new
method
that
it
supports,
but
it's
actually
not
doing
what
we
you
know
want
it
to
do.
So.
You
know
that
I
was
thinking
about
that
like
it's,
not
necessarily
like
the
end
of
the
world.
That's
like
better
than
not
compiling,
but
you
know
the
other
option
and
go
is
to
always
like
just
extend
the
interface
by
adding
another
interface
and
saying.
D
You
know
like
this
is
an
extension
of
the
interface
that
maybe
you
can
wrap
the
old
interface
or
it
could
just
be
that
new
method
that
is
actually
being
added,
and
then
you
just
play
with
the
naming
to
make
it
somewhat.
You
know
related,
and
you
know
identifiable
in
that
situation.
Then
it
becomes
a
little
bit
more
as
to
like
put
pogging
called
duct
typing,
which
it
is,
but
I
just
heard
first
time
I
heard
it
would
go.
D
F
I
was
like
the
expansion
pattern
or
extension
interfaces
and
go
now.
It's
yeah,
it's
kind
of
sad,
though
it's
the
same
problem.
D
E
Well,
I
actually
think
the
context
thing
is
well,
so
I'm
going
to
go
into
personal
preferences
here,
so
I'll
try
to
try
to
time
box,
but
but
the
context
thing
what
I've
seen
for
the
most
part
is
here's
a
new
intent.
Here's
a
new
interface.
E
E
D
I
see
you're
right
yes,
that
you're
right,
that
is,
that.
E
E
C
I
think
doing
the
interface
extension
thing
like
read.
Closer
also
runs
the
risk
of
getting
to
the
situation
we
see
with,
like
the
http
instrumentation,
where
we
have
to
use
something
like
http
snoop,
to
deal
with
the
response,
writer
and
the
combinatorial
explosion
of
interfaces
that
that
may
implement.
E
B
E
I
think
the
challenge
is
that
if,
for
example,
if
you
wanted
to
go
with
the
unimplemented,
the
like
embedded
struct
approach,
then
it's
too
late
by
that
time.
E
E
Oh
no
worries
iron.
I
was
saying
that
we're
trying
to
steve
off
a
major
version
bump
right.
So
if,
if
we're
saying
okay,
the
first
time
we
have
to
do
it,
we
will
take
the
major
version
bump
and
then
we'll
stave
off
a
v3.
E
C
Yeah,
it
sounds
to
me,
like
we've,
got
a
variety
of
different
ways
to
address
the
situation.
If
it
comes
up
and
we
can
choose
the
one
of
those
that
is
best
suited
to
whatever
the
appetite
of
the
project
seems
to
be
at
the
time.
D
C
I
think,
if,
at
that
time,
avoiding
a
future
revision,
because
we
expect
that
to
happen
again
is
critical
and
we
want
to
avoid
getting
to
a
v3,
then
going
to
v2
with
embedded
structs
would
be
the
way
to
go.
If
it's
not,
then
going
to
v2
with
new
struct
or
new
interfaces
that
have
new
methods
on
it
would
be
the
way
to
go.
D
Yeah,
I
think
that's
true,
except
if
we
do
want
to
go
with
the
embedded,
struct
approach
right
now.
You
know
like
the
way
bogdan
was
talking
about
extending
interfaces.
D
He
sounded
like
go,
get
him
into
possibly
extending
him
pretty
quickly.
So
I
I
don't
know
like
you
know,
if
it's
three
months
from
now
and
like
we
were
not
allowed
the
embedded
struct
option,
we
realized
that
was
a
would
have
been
a
good
idea
like
that
seems
like
we
might
be
shooting
ourselves
in
the
foot
a
little
bit.
But
so
that's
why
maybe
just
I'm
like.
Maybe
we
should
answer
the
question
or
at
least
have
an
understanding
that
we
don't
want
to
go
the
embedded
struct
option
right
now,
at
least.
D
It
I
don't
actually
see
it
to
be
too
hard,
given
we
have
a
no
op
implementation
for
all
the
stuff.
It's
just
adding
that
private
method
and
making
sure
that
you
can't
actually
implement
the
interface
outside
of
it.
Without
you
know,
embedding
the
structs
is
it's:
it's
pretty
straightforward
in
the
process.
I
wouldn't
imagine
it
taking
much
more
than
an
hour
to
and
the
trace
api
is
pretty
small.
So.
E
Do
we
know
which
interfaces
are
likely
to
like?
Have
this
kind
of
churn,
or
are
we
just
gonna?
You
know
apply
it
to
the
to
everything
across
the
board.
D
I
think
it
has
to
be
applied
to
anything
that
is
gonna
be
in
disgust
or
in
the
sdk,
whatever
the
sdk
is
going
to
be
implementing
from
the
api,
because
that
was
the
demarcation
like
anything
that,
like
the
user
is
going
to
be
implementing,
is
something
that
they
don't
expect
to
change,
but
anything
the
sdk
is
going
to
be
implementing.
I
think
that
was
correctly
from
wrong.
Anthony
yeah.
C
Yeah,
so
I
think
there
are
two
types
of
interfaces
that
were
discussed
here,
plug-in
interfaces
where
we
expect
the
user
to
be
implementing
these
like
spam
processor,
and
we
want
to
be
very
careful
not
to
change
those
in
any
way
that
might
break
users,
including
adding
new
methods
to
them.
And
then
there
are
the
implement
the
the
interfaces
that
are
expected
to
be
implemented
only
by
sdks
and
those.
They
want
the
flexibility
to
be
able
to
extend
with
new
methods
at
pretty
much
any
time.
E
Yeah,
I
think
okay,
so
now,
having
heard
all
of
this
and
coming
around
anthony
to
your
original
proposal,
which
is,
do
nothing
and
use
cyclic
tips.
C
Yeah
right
because
because
the
aka
is
entirely
within
our
control
and
we
can
force
the
api
to
have
the
problem,
there
is,
and
the
api
actually
has
a
dependency
on
the
sdk.
E
And
that
concludes
that
precludes
truly
independent
sdk
implementations,
which
is
like
a
theoretical
goal
that
we
want
to
support.
E
D
Yeah,
that's
not
that's
not
true!
So
coming
back
to
the
embedded,
struct
approach,
like
the
reason
I
was
like
saying
like,
maybe
we
don't
want
to
do.
That
is
because
we
have
implementations
that
are
going
to
just
import
the
new
method
without
actually
understanding
it,
but
saying
going
through
the
whole
the
whole
process
that
doesn't
make
any
sense
right,
because
these
are
the
interfaces
that
the
sdk
should
be
implementing.
And
you
know
if
you're
an
sdk
author,
we
just
assume
that
you
are
going
to
be
understanding
these
and
moving
forward
with
us
in
lockstep.
D
Sdk
implementers,
I
don't
know,
I
think
if
that
sounds
reasonable
to
me,
it
like
sounds
actually
like
the
best
approach,
because
it
avoids
that
dependency
the
hard
dependency
on
the
other
one
well
yeah.
I
think.
C
I
don't
think
we
want
to
panic
right,
because
that's
that's
almost
as
bad,
if
not
worse
than
a
compile
time
failure,
but
logging,
an
error
is
saying:
hey
you're,
using
an
sdk
that
hasn't
implemented.
This
method
that
I
I'm
trying
to
use.
Something
has
called
me
and
it's
not
giving
it
the
implementation
that
it
expects
because
you
never
get
called,
then
you
never
see
any
errors
and
there's
no
problem,
but
if
it
does,
then
at
least
someone
gets
alerted.
E
D
Yeah
exactly
okay,
I
really
like
this
idea
of
trying
to
look
at
it
that
way
the
embedded
solution
for
all
of
sdk
implemented
interfaces.
I
can
take
that
as
an
action
item
to
create
a
ticket
for
it.
If,
if
everyone
thinks
that's
a
decent
approach,
I.
E
A
E
Sorry
aaron
was
the
one
who
who
I
think
was
was
probably
most
disinclined,
so
I
want
to
hear
from
him
before
before
we
come
into
this.
B
B
If
you
have
a
few
minutes
after
this
call,
I
can
show
you
we
have
one
in
the
otlp
protobuf.
It's
there's
just
a
struct
in
that
that's
generated
with
it.
That
has
an
unimplemented
method
and
those
are
all
required
as
part
of
the
interface
as
well.
B
So
I
I
I
can
walk
you
through.
It.
D
By
bryan
c
mills
that
go
into
a
lot
of
this
stuff
as
well
yeah
and
I
think
the
go
release
as
well
helps
the
guys
yeah.
They
wrote
a
great
blog
post
around
this
as
well,
but
you're
right,
it's
not
necessarily
the
most.
Once
you
see
it,
you'll
be
like
oh
yeah.
This
makes
a
lot
of
sense,
but
it's
not
yeah
immediately
obvious.
D
B
C
F
D
It's
getting
there,
so
I
think
that's
it
for
the
agenda
items
that
we
have
listed.
I
don't
know
if
anybody
else
had
anything
else
they
wanted
to
talk
about.
We
have
20
minutes
left,
so
I'm
happy
to
give
this
time
back
or
have
stephen
aaron
continue
on
without
us.
That
sounds
good
too.
Anyway.
C
C
D
About
that,
I'm
sorry
that
was
my
mistake.
I
if
I'm
not
mistaken,
that's
the
one
that
had
like
a
map
look
up
for
the
yeah
yeah
that.
C
D
Thanks
for
doing
that,
I'm
sorry
I
totally.
I
knew
that
it
existed.
I
didn't
realize
it
existed
that
close
to
home,
but
we
should
definitely
try
to
extend
the
simplest
fan
recorder
to
support
that
eventually
or
if
you
solve
this
test
like
I
would
just
move
on.
C
Yeah
and
I
suppose
the
other
option
would
be
to
go
back
and
change
the
simple
spam
recorder
and
make
18.1
quickly
and
totally
skip
18.0
and
contrib.
If,
if
working
on
this
becomes
enough
of
a
problem,
we
can
discuss
that
later.
Yeah.
Let
me
know
I
I'm.
E
Steve,
I
posted
a
link
to
an
an
instance
of
the
embedded
start
pattern.
I
saw.
F
That
thank
you.
I
open
it
in
my
browser.
I
will
study
it
momentarily.
I
just
wanted
to
mention
on
the
subject
of
contrib
and
the
upgrade
anthony
I
was
I
was
poking
around
in
there
yesterday
after
I
saw
the
release
announcement
looking
for
signs
like
okay,
so
when's
contrib,
gonna,
gonna,
bump
up,
because
I
I'm
possibly
not
helping
at
all,
but
I'm
one
of
at
least.
F
I
think
four
people
now
who
are
using
the
database,
sql
wrapper
and-
and
it's
an
interesting
case
of
where
we
have
this
contrib
library
and
people
want
to
get
in
when
apparently
they're
already
accumulating
clients.
So
it's
a
question
of
like.
B
F
C
I
think
we
were
at
with
with
the
sql
instrumentation
in
particular,
was
that
there
were
a
number
of
potential
approaches
and
we
weren't
really
sure
which
one
was
the
one
that
we
should
put
our
stamp
on
and
say.
This
is
the
way
we
ought
to
go.
C
So
I
think
in
that
case,
really
it
should
be
the
the
case
that
have
them
go
live
elsewhere,
at
least
temporarily,
and
if,
if
one
of
them
does
clearly
become
the
winner-
and
this
is
the
thing
we
want
to
put
a
sample
approval
on,
we
can
bring
it
in
to
contribute,
or
we
can
say
if
you
need
a
sql
implementation,
here's
a
good
one
that
we
recommend
either
one
of
those
will
work.
I
I
don't
think
that
all
of
the
instrumentations
need
to
live
in
control.
C
There's
some
conveniences,
but
there's
also
overhead
for
us
as
maintainers
which-
and
we
need
to
kind
of
balance
that
so
lately
we've
been,
I
think,
reluctant
to
add
more
more
to
contrib
as
we
work
towards
getting
two
with
one.
Oh,
I
think
we'll
get
well.
This
pendulum
will
swing
the
other
way
once
we
ship
one,
oh
and
things
settle
down
and
the
the
overhead
of
keeping
things
up
to
date.
With
all
of
the
breaking
changes
that
we're
making
lessons,
then
we'll
be
more
willing,
I
think,
to
accept
things
and
begin
trip.
I.
F
Wonder
if
it
would
help
if
we
publish
something
that
I
that
stated,
a
policy
I'm
thinking
of
something
like
how
cncf
does
things
where
they
expect
some
incubation
period
for
projects
or
even
ahead
of
that,
they
expect
a
project
to
exist
independently
and
have
shown
signs
of
growth
and
interest
and
healthy
maintenance
before
they
consider
pulling
it
into
their
umbrella
and
with
contrib
like
in
a
case
like
this,
where
you
say
there
were
multiple
implementation
techniques
that
were
possible
for
a
library
like
this.
F
It
may
be
the
case
there
shouldn't
even
be
just
one
and
and
that
we
really
should
say,
go
off
on
your
own,
publish
this
module,
maintain
it
build,
build
a
user
base,
and
then,
if
it
seems
like
by
by
whatever
signals,
github
gives
us
or
something
we
can
see
after
six
months.
This
seems
like
the
one
we
should
probably
bring
this
in,
and
you
know
maintain
it
on
the
same
schedule
or
whatever
it
takes.
D
Yeah,
so
I
mean
this-
this
all
comes
back
to
like
the
the
goaling
center
library
itself.
Right,
like
I
mean
I
think,
if
there's
the
x-repo,
that
was
there
specifically
for
the
experimental
and
it
was
kind
of
like
the
same
sort
of
the
same
purpose
for
going
in
itself,
and
then
you
know
the
context
package
comes
to
mind
where,
like
that
was
brought
in
from,
I
think
it
was
a
google
thing
and
like
eventually
they're
like
this,
is
just
so
important.
D
We
need
to
bring
this
in
the
main
line,
and
so
I
think
that,
like
I,
I
was
hoping
we
could
do
something
like
this,
where
we
could
have
an
experimental
like
sort
of
setup,
and
I
think
anthony's
kind
of
describing
a
very
similar
thing.
The
idea
I
think
originally
for
the
database
one
was
there
was
like,
I
think,
three
or
four
different
approaches
to
it.
D
We
were
going
to
put
it
in
an
experimental
directory,
but
I'm
I'm
just
bringing
that
up
for
history,
because
I
don't
know
if
that's
actually
a
really
good
solution,
because
you
run
into
that
same
problem
where
it
still
is
the
responsibility
of
us
as
the
maintainers
of
the
repository
to
like
still
curate.
It's
still
updated
still
do
all
these
sort
of
things
versus
having
some
sort
of
help
where
there's
like
a
dedicated
individual
and
I'm
not
opposed
to
putting
it
in
an
experimental
directory.
D
If
somebody
wants
to
take
on
that
task,
like
I'm
going
to
be
the
curator
of
this
instrumentation-
and
you
know,
whenever
you
do
it,
release
I'll
coordinate
with
you
to
get
that
done,
but
it
seems
like
they
could
do
that
in
their
own
repository,
and
I
I
like
the
idea
of
just
like
you
know,
moving
it
over.
D
I
yeah
I
kind
of
like
the
idea
of
just
having
it
curated
in
a
different
location
and
maybe
organically
grow
to
the
point
where,
like
it
becomes,
you
know
a
viable
solution
that
we
want
to
move
in
and
it's
not
just
the
you
know
the
one
solution
in
our
pr
like
I
definitely
know
three
other
authors
have
made
database
sequel
wrappers
around
it
and
so
like
there's,
definitely
a
lot
of
people
who
have
thought
about
this
one.
And
I
don't
it's
a
it's
a
huge,
huge
challenge.
D
So
I
think
the
answer
I
would
probably
say
is
to
like
I
take
anthony's
approach
to
just
like
have
it
as
an
external
dependency,
and
I
don't
see
why
it's
not
it's.
You
know
if
it's
a
full-on
project,
that's
fully
supported
and
by
a
community
like
that,
sounds
good
to
me
like
I'd,
rather
have
you
know
a
distributed
like
teamwork,
to
support
open
telemetry.
That
sounds
great,
but
if
we
could
just
like
list
it
on
the
open,
telemetry.io
registry
or
listed
in
our
instrumentation,
I
know
we
did
this
for
redis.
D
I
think,
or
something
like
that,
like
there's
external
instrumentation
in
the
redis
package,
like
we
listed
it
in
our
list
of
instrumentation,
I
have
no
problem
like
just
adding
a
line
there
in
the
documentation.
Like
saying,
like
hey,
go
check
this
out
for
the
sequel
package.
You
know,
even
if
it's
like
20
different
sql
packages
like
that
and
then
yeah,
we'll
totally
move
whatever
has
the
highest
star
rating
and
so
go
start.
Your
favorite,
I
don't
know
yeah.
C
I
think
the
steve's
point,
though,
having
some
formal
statement
of
that
policy
would
be
good
so
that
we
have
something
to
point
out
in
contributing
saying
the
these
are
the
packages
we
will
or
the
types
of
things
we
will
bring
in
to
contribute.
These
are
the
types
of
things
we
think
should
live
elsewhere.
These
are
the
types
of
things
that
may
move
from
one
to.
F
The
other
right,
because,
right
now
I
it's
just
a
weird
artifact
of
github
and
go
modules.
I'm
not
really
sure
where
to
point
the
finger,
but
it's
this
awkward
situation
where,
because
you
have
an
author
who's
knocking
on
the
door
to
get
in
using
his
work
right
now
is
actually
harder
for
for
the
the
potential
consumers,
whereas
if
he
just
said
you
know,
I
have
my
hat
over
here.
My
code's
over
there,
hey
contrib
people.
What
do
you
think
of
my
repo?
F
That's
very
different
than
I've
got
a
pr
that
I
keep
on
updating.
You
know
trying
to
get
in
the
door
here
that
doesn't
really
have
its
own
identity
somewhere
else.
I
know
it
is.
You
know
possible,
it's
possible
to
get
the
you
know
to
to
address
his
repository,
but
then
his
his
module
import
paths
are
wrong
because
we're
assuming
that's
hosted
inside
contrib
well,.
B
One
aspect
of
that
is
like:
if
we
eventually
move
it
into
contrib,
he
could
just
have
a
facade
package
that
just
pre-implements
the
contrib
package
yeah
right
like
there.
There
can
be
a
path
forward
with
backwards
compatibility,
but
I
mean
yeah.
F
Yeah,
so
all
I'm
saying
is
that
at
some
point
I
think
we
need
to
know
when
to
say
no,
because
as
even
though
it
sounds
mean
it
sounds
like
we
don't
want
your
work,
it
might
actually
be
the
gift
to
all
the
potential
users,
which
is
to
say,
if
you,
if
you
take
your
work
elsewhere,
more
people
can
use
it
right
now.
D
Yeah-
and
I
think
that
that
is
the
answer-
there's
just
not
enough
time
in
the
day
and
the
community
that
we
are,
you
know
a
part
of
right
now
is
just
too
small
to
handle
all
of
the
asks
for
instrumentation.
Currently,
I
think
anthony's
timeline
is
spot
on,
like
after
the
release
and
things
stabilize.
I
think
that
that's
a
good
primary
part
of
our
job,
but
yeah
like
right
now,
like
it's
just
it's
not
my
focus,
I
feel
really
bad,
there's
just
a
lot
of
pr's.
D
I
haven't
reviewed
over
like
a
trip,
and
I
don't
plan
to.
F
D
F
If
I
were
because,
because
I
have
a
vested
interest
in
this
particular
case
sure
if
I
were
to
say
something
similar
to
the
author
of
this
pr,
do
you
think
that's
out
of
line
or
do
you
think
this
is
an
accurate
take
of
what
the
group
here
thinks
you
know
if
I
were
to
suggest
like
let's,
let's
take
this
and
publish
it
somewhere
else.
F
C
At
this
505.
yeah,
so
I
think
sam's
going
to
be
reviewing
the
the
video
of
this
meeting
later
once
it's
published
anyways.
So
he
will.
He
will
see
this
conversation
great
hi,
sam.
We,
we
should
probably
also
they'll,
make
that
explicit
on
on
the
ticket.
I
don't
know
tyler.
Do
you
think
that's
something
that
should
come
from
us
or
is
it
something
that
so
you
can
say
hey
I
really
want
to
use
this.
C
Can
you
help
me
out
by
making
it
live
over
here
until
such
time
as
we're
able
to
figure
out
how
it
should
land
and
contrib
or
whether
to
land
you
can
trim.
D
Yeah,
I
think
that
we
should
probably
do.
We
should
do
something
and
say
something
on
the
issue
anthony.
I
don't
know
if
you
have
something,
can
that
you've
got
in
mind.
I've
got
a
few
things
here.
Exam's
gonna
come
on,
but
the
other
thing
is
like
the
next
person
that
comes
in
line.
We
want
to
make
sure
that
it's
clear
to
them.
D
I
think
steve
brought
up
a
good
point
like
we
need
to
make
sure
this
communication
is
clear,
so
we
need
to
have
something
in
our
contributing
docs
or
in
the
readme
docs,
or
something
like
that
steve.
If
you
wanted
to
create
a
pr
to
one
of
those
docs,
I
would
really
appreciate
it
into
that
repo.
You
know
that
can
absolutely,
I
think,
that's
totally
fine.
D
Coming
from
you
or
honestly,
you
could
say
the
other
thing
as
well
like
it's
a
community
but
yeah,
and
I'm
happy
to
review
that
kind
of
thing
and
make
sure
the
language
is
correct,
saying
something
to
the
effect
of
the
instrumentation
is
under
a
freeze
until
we
have
a
release,
is
totally
fine
in
my
opinion,
but
yeah.
D
I
think
that
having
a
path
forward
and
saying
like
it's
under
a
freeze
but
also
go
host
somewhere
else,
show
there's
like
viability,
show
that
you
have
like
user
feedback,
show
that,
like
you,
have
a
community,
that's
supporting
it.
It's
going
to
be
a
lot
easier
for
us
to
accept
that,
as,
like
a
you
know,
fully
supported
instrumentation
package
going
forward.
Okay,
yeah!
D
D
F
Can
imagine
that
over
time
we're
going
to
have
some
in
there,
where
you
know
anthony
you're,
saying
you're
working
your
way
through
contrib
you're
digging
through
I'm
assuming
you're
digging
through
code?
That's
all
over
the
place
with
concerns.
Some
of
that
stuff
could
be
abandoned
for
all.
We
know
it
could
be
helping
out
with
things
that
have
fallen,
integrating
things
that
have
really
fallen
out
of
favor
out
there
in
the
world,
where
it's
not
nice
to
to
break
existing
code
but
other
hand.
It's
a
maintenance
burden,
that's
only
going
to
grow
over
time.
F
If
we,
you
know,
if
we
keep
on
bringing
things
in
like
that.
C
One
of
the
nice
things
about
the
the
current
interpretation
contribute
is
that
most
of
it
is
around
http
middleware,
and
so
it's
all
very
same-ish.
You
know
the
lots
of
implementations.
Look
the
same.
Many
of
the
frameworks
have
similar
interfaces
because
everybody's
going
to
take
an
http
request,
and
then
they
have
a
response.
Writer,
eventually
somewhere
right
and
there's
going
to
be
a
context
available
to
you
on
the
request.
C
So
from
that
perspective,
things
are
not
huge
from
a
maintenance
overhead
burden
kind
of
thing,
but
as
we
expand
out
into
more
and
more
different
types
of
instrumentation,
that
could
certainly
change.
D
Yeah,
I
am
a
little
worried
about
the
maintenance
burdens
of
what's
already
existing,
but
I
don't
think
that's.
I
don't
know
what
to
do
about
that.
Right
now.
C
I
I
I
think
it'll
be
much
less
awful
once
we
stop
breaking
things.
C
C
F
F
D
I
totally
forgot
about
that
wow
this
project's
been
going
for
a
while.
Okay,
I
think
that's
enough
for
the
agenda
I'm
going
to
give.
Hopefully
I
need
five
minutes
back
for
my
next
meeting.
So
I'd
love
to
talk
more
y'all,
more
see
online,
see
all
the
pr
world
and
yeah
have
a
good
week
thanks
a
lot.