►
From YouTube: 2020-10-29 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
All
right
I
had
to
miss
whoops
see
I
had
to
miss
the
the
one
two
weeks
ago
due
to
a
conflict
but
yeah.
Sorry
about
that.
B
Oh
no
worries
I
mean
I
missed.
Last
week's.
Do
a
conflict
of
me
taking
a
vacation
so
well
good
for
you!
Well
yeah!
I
don't
know.
I
came
back
and
there's
a
lot
to
do
so.
B
Yeah,
absolutely
absolutely
yeah.
No,
it's
all
good
work,
I'm
actually
kind
of
excited
for
today's
meeting
to
kind
of
just
re-sync
with
some
people,
so
yeah
should
be
good.
All
right.
B
Looks
like
we're
getting
decorum,
I
saw
jana
had
made
a
lot
of
really
great
issues
over
this
past
week
or
so,
and
so
I
think
I
was
hoping
to
join
as
well,
but
we're
pretty
close
to
quorum.
So
I
think
we
could
probably
jump
into
it.
Just
a.
D
B
I
think
he's
got
to
go
for
the
old
restart.
Unfortunately,
this
is
good,
gives
us
a
little
bit
more
time
to
wait
for
people
to
show
up.
E
B
Yeah
you're
really
quiet,
but
we
can
definitely
hear
you.
I
don't
know
if
that
makes
a
difference.
B
Well,
cool:
we
can
jump
into
it.
I
think
we're
getting
there.
I
was
hoping
that
janna
would
show
up,
but
maybe
that'll
happen
coming
along.
D
B
Right
so
welcome
everyone.
If
you
joined
last
week,
I
apologize,
we
were
half
out
of
town,
so
we're
kind
of
making
up
for
it
this
week
with
two
weeks.
I
don't
have
too
much
on
the
agenda.
Some
high
level
topics
there's
definitely
some
space.
If
you
would
like
to
discuss
a
particular
issue
or
topic,
please
be
sure
to
add
it
to
the
agenda.
Also,
please
be
sure
to
add
your
name
to
the
attendees
list,
so
we
have
some
record
of
it
generally.
B
What
we
try
to
do
starting
off,
is
just
kind
of
talk
a
little
bit
about
that
progress
towards
our
rc
candidate
by
looking
at
the
high
level
project
board
that
we
have.
This
is
just
a
summary
of
that
board
and
we
can
definitely
see
some
active
progress
in
this
past
week
and
a
half
there's.
There
was
a
lot
of
really
great
things
that
came
in
while
I
was
away
and
anthony
was
away
as
well,
and
so
just
kind
of
a
lot
of
backlog.
B
I've
been
going
through
classifying
some
issues,
so
a
lot
of
really
good
issues
came
in
a
lot
of
stuff
is
in
progress
for
sure
this
is
mostly
just
issues.
I
haven't
classified
a
lot
of
the
prs,
so
just
kind
of
keep
that
in
mind.
There's
also
a
lot
of
progress
made
in
the
past
two
weeks.
18
different
issues
or
prs
closed,
so
good
progress
forward.
I'm
really
excited
about
that
yeah,
so
just
kind
of
jumping
into
some
of
the
agenda
items
from
the
maintainers
meeting
on
monday.
B
There
was
an
ask:
this
is
an
old
issue.
I
probably
kind
of
looked
up
the
issue,
but
I
somewhere
in
the
backlog
to
move
the
project
from
circleci
to
github
actions.
I
didn't
really
understand
the
motivation
behind
this,
but
it
sounds
like
the
cncf
has
taken
over
the
finances
of
the
project
and
paying
for
get
circle
ci,
and
they
were
asking
about
this
progress
because
I
think
it
it
makes
more
financial
sense
to
move
to
github
actions.
So
there's
still
a
lot
of
work
to
actually
implement
that
change.
B
It
did
sound
like
how,
later
from
aws
had
mentioned,
that
there
are
some
engineers
who
might
be
on
the
call.
I
see
kelvin
sorry
if
I
mispronounced
your
name
from
aws
on
the
call
who
were
potentially
here
to
help
I'm
not
saying
that's
what
you're
here
to
do
either,
but
just
kind
of
opening
it
up
but
yeah.
So
definitely
we
should
be
thinking
about
that.
It
was
also
communicated
that
this
is
likely
not
gonna,
be
a
priority
for
us
until
after
the
ga.
B
But
I
I
said
that
if
you
know,
if
you
have
engineers
who
are
like
that,
are
dedicated
to
doing
this
work
and
that's
what
their
priority
is
like.
I
have
no
problem
reviewing
code
for
that.
For
that
purpose,
so
yeah
I
didn't
know
if
anybody
else
had
anything
else
they
wanted
to
talk
about
on
this
subject.
B
Cool
awesome
so
moving
on
to
the
next
thing,
also
from
the
maintainers
meeting,
I
was
kind
of
realizing
that
there's
there
was
kind
of
an
open
issue
currently
with
open
telemetry
in
general
in
communicating
the
stability,
and
I
think
that
this
is
a
interesting
challenge
for
us
going
forward,
because,
as
we
recently
did,
we
unified
the
api
to
the
single
top
level
package
based
on
some
feedback
and
honestly,
I
think
it
looks
much
better
from
the
user's
perspective
jumping
into
the
actual
project.
B
You
can
just
immediately
find
the
things
that
you
care
about
if
you're
going
to
be
instrumenting
in
a
single
place,
and
so
I
think
this
is
a
really
positive
move.
There's
still
definitely
some
cleanup.
I
think
that
could
be
done
here
as
has
been
identified
in
a
lot
of
the
issues
that
have
been
opened
in
the
past
few
past
few
days.
B
One
of
the
things
is
now
that
the
metrics
concepts
live
right
next
to
the
trace
concepts
which
would
eventually
live
next
to
the
logging
concepts.
The
question
becomes,
how
do
you
communicate
things
that
are
maybe
not
in
the
ga
phase
of
the
life
cycle
of
the
project,
and
so
that's
something
I
think
we
probably
want
to
brainstorm
on.
My
initial
thought
was
just
including
that
in
the
documentation
for
objects
that
are
still
a
work
in
progress,
but
that
is
seems
pretty
high
toil
given
each
exported
thing
needs
to
be
documented.
B
B
Cool,
well,
I
don't
know
if
there's
any
particular
answer
that
we
need.
I
also
just
wanted
to
raise
the
question.
Maybe
have
some
people
start
thinking
about
it?
I
could
also
open
an
issue
on
this.
One,
I
think,
is
probably
the
better
way
to
track
this
in
the
long
term.
So
I
think
I'll
do
exactly
that.
B
Yeah
no
worries
so
in
this
pre
ga
phase,
we're
in
this
beta
phase,
where
we
try
to
have
some
sort
of
stability.
But
if
I'm
being
blunt
about
it,
it's
not
a
really
strong
guarantee.
Given
a
lot
of
the
api.
Instability
comes
from
upstream
changes
at
the
specification
level,
so
that
has
that
has
predicated
a
lot
of
api
changes
here.
Backwards,
incompatible
api
changes.
So
I
think
that
our
guarantee
that
we
try
to
make
is
with
each
minor
release
prior
to
the
ga.
B
We
remain
backwards
compatible.
But
if
you
look
at
our
release
history,
it's
very
rare
that
we
put
out
a
patch
release
on
top
of
a
minor
release
that
is
backwards
compatible.
B
So
that
is
something
that
I
think
is
is
going
to
have
to
change
after
the
ga
release,
but
currently
right
now,
it's
pretty
free
form
and
trying
to
address
progress.
Going
forward
to
the
specification,
as
well
as
to
use
your
feedback.
A
Yeah,
I
think
we've
kind
of
treated
it
as
if
december's
just
shifted
one
to
the
right
right,
so
minor
is
equivalent
to
major
backwards
incompatible.
Changes
may
happen
between
minor
versions.
Patch
is
equivalent
to
my
to
the
previous
minor,
where
we
may
add
new
features,
but,
as
tyler
mentioned,
we
haven't
really
had
many
of
those
those,
I
think
very
rarely.
We've
done
them
for
like
bug,
fixes
or
something
like
that
that
we
needed
to
get
out,
and
we
also
maintain
compatibility
between
equivalent
minor
versions
of
the
main
repo
and
the
contrib.
F
Repo
yeah
one
thing
that
I'm
trying
to
understand
is,
like
you
know,
in
the
go
module
model,
there's
no
way
like
if
you
don't
have
like
split
mod
modules,
you
can't
like
version
them
separately,
and
then
you
know,
there's
no
easy
way
to
actually
like
say:
oh
these
parts.
You
know
we
may
end
up
like
breaking
these
packages,
but
you
know
api
packages
will
be
stable
for
a
while
and
so
on.
It's
just
like
there's
no
like
automatic
way
of
like
communicating
that,
like
with
you,
know,
versions
and
so
on.
F
So
I'm
kind
of
like
nervous
that,
like
we
may
not
ever
have
a
plan
for
this
like
what
grpc
has
done,
for
example,
is
they
document
it
on
the
packages
like
hey?
This
package
is
an
experimental
thing.
We
can,
you
know,
just
use
it
if
you
are
okay
with
that
like,
but
we
may
end
up
like
breaking
those
things
like
they,
but
it's
just
like
kind
of
like
a
you
know.
Documentation
notification
like
there
is
no
easy
way
to
unless
we're
splitting
things
into
different
modules.
F
There's
no
easy
way
to
communicate
those
breaking
things
or,
like
you
know,
giving
user
the
flexibility
to
be
able
to
pin
to
a
specific
version.
A
Kind
of
a
situation
we're
in
right
now,
as
well
with
being
pre
1.0,
go
modules
can't
really
provide
any.
It
doesn't
know
that
pre
1.0
modules
provide
no
guarantee
of
compatibility.
So
some
part
of
your
application
may
include
point
13
and
some
is
including
0.12
and
now
you've
got
compatibility
problems.
You
need
to
make
sure
that
you've
got
equivalent
levels
all
throughout
until
we
hit
1.0.
B
But
I
think
that
this
is
just
like
a
hard
question.
That's
actually
needs
to
probably
be
asked
at
this
point,
especially
prior
to
this
potential
release,
which
is
later
down
in
the
topic
list
is:
is
this
api
structure
really
best
suited
for
this
stability
guarantees
that
we're
gonna
try
to
give
good
going
forward?
B
That
being
said,
I
don't
have
a
dock
open,
so
things
like
this,
where
we
couldn't
really
partition
off
the
metrics
api
from
the
trace
api
currently
or
the
context
api
or
the
other
apis
propagation
api.
I
think
is
also
in
here
because
it's
all
in
the
same
package,
it's
all
in
the
same
module
at
this
point-
and
I
guess
that's
maybe
that's
kind
of
the
question
to
ask-
is
if,
if
that
is
appropriate,
going
forward.
B
Yeah
100
and
I
don't
normally
like
to
assign
blame
but
boy
there's.
Definitely
some
blame
that
I
deserve
on
this
one.
B
B
But
now
we've
run
into
this
exact
problem,
and
I
I
just
wanted
to
ask
this
question
before
we
make
a
release
and
then
we
have
people
depending
on
this
unified
thing,
and
then
we
go
back
to
the
other
thing.
I
guess
is
kind
of
where
I'm
at.
B
Because
this
is
not
a
great
situation,
if
we're
second
guessing
at
this
at
this
point
in
the
game,
but
it's
an
even
worse
situation.
If
you
know
a
week
from
now,
we've
released
this
and
then
we
have
people
going
like
this
doesn't
work,
let's
go
backwards,
so
I
just
wanted
to
make
sure
we
asked
the
question.
F
By
the
way,
can
I
can
I
say
one
more
thing.
I
think,
like
this
structure
is
usability
wise.
It's
also
not
a
good
structure
like
you
know,
there's
no
name
space.
You
know,
there's
there's
a
lot
of
like
concepts
in
open
telemetry
right
like
it's,
just
like
really
hard
for
me
to
you,
know,
wrap
my
like.
F
I
have
a
lot
of
context
in
this
field
and
it's
still
hard
for
me
to
understand
what
is
the
most
significant
you
know
constructs
that
I
will
be
working
with
so
like
this
particular
structure
is
just
like
making
it
extraordinarily
hard
for
users
to
understand.
You
know
where
to
begin
with,
so
I
still
believe
that,
like
it
would
be
super
nice
to
like
split
at
least
like
trace
or
metric
collection
related
stuff
into
their
like
respective,
like
packages,
even
though
it
doesn't
solve
any
problems.
F
So
this
is
like
a
you
know,
broader,
like
I
think
I
I
think
like
putting
everything
in
the
same
package
is
not
a
good
idea,
because
it's
just
makes
extraordinarily
hard
for
the
user
to
figure
out
where
to
begin.
When
you
know
in
open
senses,
we
realized
that
the
metric
collection
api
was
becoming
very
large
because
you
know
there's
metric
descriptors
and
then
views
and
so
on.
F
So
like
we
realized
that,
like
hey,
what
is
going
to
be
the
entry
point
that
we
will
be
giving
to
the
user
like
what
is
going
to
be
the
package
like
you
know
what
is
going
to
be
the
godot,
that
we
will
be
pointing
to
that's
why
we
ended
up
like
splitting
things.
You
know
into
two
or
three,
and
I
think,
like
splitting,
for
this
purpose
of
like
making
things
easier
to
highlight.
F
Like
you
know,
the
entry
points
is,
I
think,
a
good
way
and,
like
I
think,
with
this
model,
we're
doing
the
opposite
and
making
it
even
harder
for
the
user.
So
both-
and
I
was
like
you
know
talking
about
this
a
bit
he
mentioned
that,
like
you
know,
wouldn't
it
be
nicer
to
have
like
more
structure
again
because
you
know
like
he
understands
that,
like
as
a
person
who
is
not
like
daily
using
this,
you
know
library
just
harder
for
him
to
come
in
and
grasp
what
is
important
like
as
a
developer.
F
C
You're,
I
think,
you're
proposing
what
I
think
of
as
a.
I
hope
this
isn't
offensive
like
a
java
style
use
of
packages,
as
in
as
an
organization
technique
for
the
reader.
C
C
Other
sorts
of
export
control
mechanisms-
that's.
F
G
F
Implementation
lives
in
the
same
package
because
of
this
particular
reason
does
that
make
sense,
and
we
organize
by
responsibility.
So
it's
not
java
style
to
say
that
there's
going
to
be
a
trace
package,
it's
just
normal
that
there's
a
trace
package.
If
you
care
about
trace
package,
you
go
to
the
trace
package,
but
you
wouldn't
see
you
know.
Interfaces
and
the
implementation
is
split.
The
way
that,
like
you
know
in
different
packages,
the
way
java
is,
it
creates
all
this
like
possible
circle
dependencies
which
is
impossible
to
solve.
F
So
you
know
we
just
generally
don't
do
that
because
of
that
particular
limitation.
This
is
the
like
the
sixth
time
that
I'm
designing
trace
packages
by
the
way
in
go.
I
did
four
trace
packages
at
google
yeah,
so.
C
Now
I
I
don't
remember
well
I
mean
I
know
that
there
was
some
recent
consolidation
in
this
project,
but
I
didn't
it's
so
much
moved
honestly
that
I
didn't
get
to
see
whether
or
not
any
of
it
was
moved
for
the
benefit
of
things
like
changing,
how
we
implement
or
reducing
things
that
needed
to
be
exported
between
different
packages
or,
if
it's
just
more
a
matter
of
we
don't
like
the
path
to
this
name,
and
we
want
to
give
it
a
different
path.
C
B
I
think
yeah,
I
can
speak
a
little
bit.
I
think
a
lot
of
it
was
predicated
on
the
path,
especially
like
the
conflict
where
you
had
things
like.
If
I'm
understanding,
ghana
correctly,
is
like
api
trace
and
then
sdk
trace
and
then
sdk
export
trace.
Having
those
path
names
collide
was
a
really
big
problem
for
people
and
having
it.
So
you
can
just
import
the
api
as
importing
the
hotel
package
was
kind
of
the
idea
it
did
unify
a
lot
of
the
testing
package.
B
There
was
a
little
bit
of
an
overlap
there
as
to
like
what
you
would
actually
want
to
be
using
for
the
testing
package
and
internal
structures,
but
other
than
that.
No,
they
were
pretty.
I
think
name
collisions
other
than
that
it
was.
It
was
just
a
path-based
thing
if
I
had
to
take
a
guess.
F
I
have
a
maybe
a
grand
question:
would
it
make
sense
to
build
a
wrapper
around
this
api?
F
F
If
that's
going
to
you
know,
make
things
easier,
but
you
know
then
we
have
the
chance
of.
Actually
you
know
getting
this
right
like
it's
just
hard
for
me
to
you,
know,
figure
out.
What's
the
best
way
to
go,
I
mean
from
I'll
tell
you
the
metrics
api
is
already
too
big,
and
I
was
about
to
suggest
that,
like
we
should
split
it
into
a
couple
of
things
and
then
you
know
the
current
structure
is
just
like
completely
working
against.
F
You
know
where
I
was
actually
like
trying
to
get
to
so
I
maybe
I
feel
strong
about
this,
because
you
know
when
I
look
at
these
apis,
I
don't
know
as
a
user
where
to
start
and
lots
of
people
who
are
going
to
use
this
apis
have
absolutely
no
understanding
of
instrumentation.
It's
going
to
be
a
major.
I
think
I
think
adoption
blocker
for
us
not
to
give
them
something
like
easy
to
use.
You
know
this
is
where
you
start.
F
B
B
E
E
I
was
also
wondering
if
you
could
give
us
an
idea
of
the
metric
redesign
that
you've
been
thinking
about.
I
obviously
I
created
much
of
that
structure
and
it
was
done
as
part
of
an
exploration
into
semantics
of
metrics
apis
in
general,
so
we
there's
some
areas
where
we
over
did
go
because
we
were
investigating
and
I.
F
G
Hey
tyler,
sorry
to
interrupt
you,
a
bunch
of
us
can't
really
hear
you
or
is
there
someone
else
who's
talking.
F
Oh
okay,
maybe
I
can
present
or
tyler
you
are
presenting
right.
Can
you
share?
Can
you
click
on
the
link
that,
like
I
put
on.
B
The
doc,
sorry,
let
me
just
sorry
open
it
back
up.
I
just
paused.
F
Yeah,
if
you
click
on
that
like
so
my
idea
was
hey
like
this
should
be
what
an
entry
point
for
the
metric
api
should
be
looking
like,
like
users,
should
only
care
about,
like
the
meters
and
some
sort
of
like
you
know,
find
ways
to
like
access
to
these
agri-graders
and
all
that,
like
random
stuff,
if
we
can
split
it
into
like
you
know,
their
respective,
like
packages
like
like
say,
like
counters,
are
a
part
of
a
counter
package.
F
All
this
value
recorder,
whatever
is
in
a
split
package
if
this
will
create
a
lot
of
like
difficulties
in
terms
of
like
you
know,
in
cyclic
dependencies,
maybe
so
we
need
to
go
and
investigate,
but
if
you
give
a
user
something
like
this
simple
like
they
will
be
able
to
just
like.
Oh
you
know,
and
maybe
in
the
example
like
the
package
level
example
could
be.
An
you
know.
F
Example
of
this
is
how
you
create
a
metric,
and
you
know
this
is
how
you
create
an
counter
whatever,
and
this
is
how
you
you
know
like
record.
This
would
be
like
so
much
easier
for
people
like
at
least
they
know
like
hey.
These
are
like
the
types
that
I
should
care
about,
and
it
kind
of
like
summarizes
what
type
of
functionality
they
can
you
know
have
like
through
open
census,
telemetry
right
now
like
they
have
to
scroll
down,
and
like
I
mean
we
don't
have
any
examples
to
begin
with.
F
Maybe
that's
also
a
part
of
the
problem,
but
they
have
to
understand
a
bunch
of
you
know
different
types,
all
this
intermediate
types
and
so
on,
and
so
so
many
like
you
know,
concepts
in
order
to
start
working
with
the
metric
package
or
metric.
You
know
collection,
so
I'm
not
sure.
Like
I
mean
this
is
the
best
way
to
go,
but
I
was
exp.
I
would
rather
have
this
api
surface
to
be
simple,
focusing
on
the
you
know,
important
stuff
and
every
like
all
the
other
complexities
delegated
to
somewhere
else.
F
B
Yeah
I'd
love
to
hear
josh's
point
on
this,
but
he's
been
quiet.
It's
gonna
be
able
to
share
my.
I
really
liked
the
clarity
of
looking
at
this.
B
B
I
think
maybe
that's
a
little
harsh,
but
I
think
that's
pretty
fair,
like
we
were
really
exploring
like
not
only
just
like
the
implementation
and
go,
but
how
we
want
to
do
that
just
in
general
as
a
metric
system,
and
I
think
that
there's
some
some
cleanup
options
that
could
help
you
know.
B
I
think,
a
lot
of
the
wrapper
design
that
we
did
there
as
well
was
because
it
was
changing
so
frequently
that
we
wanted
to
make
some
abstractions
to
allow
those
changes
to
happen
a
little
more
freely
fluidly,
and
maybe
they
don't
serve
us
as
well
anymore.
But
I
I
do
like
the
simplicity
of
kind
of
what
you're
you're
showing
here.
B
The
translation
to
this
sort
of
structure
obviously
is
like
you're
saying
like
the
cyclic
dependencies
or
maybe
there's
some
sort
of
like
complications
of
like
we
need
to
abstract
some
some
of
these
implementation
details
and
maybe
an
internal
package,
our
details,
but
I
think
that
you're
right
like
if
we
could
hit
some
sort
of
api
that
looked
like
this
it'd,
be
a
lot
easier
to
explain
to
the
user
like
this
is
what
you
need
to
do.
This
is
where
you
need
to
go.
F
E
F
This
is
not
complete.
Right,
like
there
will
be
some
more
types
here
so
like
there
will
be
some
batch
related
stuff.
We
will
have
definitely
some
more
types,
but
you
know
like
what
I
wanna
wanted
to
demonstrate
is
like,
if
you
make
it
so
obvious,
like
hey,
these
are
like
the
top
stuff
that
you
should
care
about,
and
we
make
sure
that
they're
examples.
You
know
it
will
be
easier
for
them
to
understand
what
the
project
does
and
copy
paste
and,
like
you
know,
feel
productive.
E
F
E
F
And
go,
is
you
know
terrible
like
there's?
No
generics,
you
know
like
half
of
this
stuff
is
coming
from,
like
I
mean
more
than
half
of
it's
coming
from
because
of
the
duplication
and
so
on.
So
like
I
was
like
thinking
hey
like
I
mean
there
is
no
way
that
we
will
ever
come
up
with
something
that
looks
simple
because
there's
no
generics.
F
F
But
you
know
we
have
to
do
some
experimentation
to
figure
out
if
it's
actually
going
to
be
working,
whether
we
will
need
too
much
internal
inspectors.
E
E
E
E
We
have
four
different
ways
to
report
metrics
and
every
one
of
them
feels
justified,
but
it's
such
a
surface
area.
E
Everyone
feels
justified
because
you
have
the
prometheus
user
and
the
stats,
the
user-
and
you
know
the
real
code
base-
wants
batch,
recording
and
census
had
that.
So
we
got
everybody's
requirements
here.
B
Yeah,
no,
that
that
makes
sense
one
one
useful
thing
I
noticed
also
here,
though,
is
this
like
flip
64
meter
and
float
are
in
64
meter
that
kind
of
abstracts
that
duplicate
thing
for
the
instruments
into
the
higher
yeah.
I
think
that
makes
a
lot
of
sense,
and
then
I
was
noticing
that
these
are
then
all
broken
down
into
the
actual
instrument
so
like.
If
you
wanted
to
see
the
counter
like
this
is
grouped
here.
Yeah.
F
I
mean
these
are
not
complete,
but
you
know
that's
the
just,
so
we
need
to
figure
out
to
make
sure
that
it's
actually
going
to
work.
Sorry,
I
had
to
like
put
this
down
like
yesterday,
just
because
you
know
there's
this
meeting
today,
just
to
kind
of
like
because
I
talked
to
bogdan
about
like
the
spec
and
then
we
were
just
thinking
about
this,
and
then
you
know,
I
thought
that
you
know
maybe
splitting
is
a
is
a
good
way
to
go
at
least
as
an
idea
to
suggest
like
at
the
meeting.
B
Yeah-
I
really
like
this.
I
I
think,
if
there's
some
bigger
issues
as
to
like
how
we
want
to
split
this,
I
think
in
that
top-level
package,
I'd
love
to
get
results
sooner
rather
than
later
in
breaking
apart
the
api
again
or
encapsulating
the
api
in
a
positive
way.
I
do
think
that
I
had
a.
I
think
it
was
like.
The
next
point
was
just
that
release
planning
I.
B
After
having
this
conversation,
I
don't
really
feel
confident
that
I
really
want
to
release
what
we
have
in
master,
but
maybe
we
can
talk
about
that
just
a
little
bit
out
and
finish
up
this
line
of
thought,
I
guess,
is
the
idea,
I'd
love
to
hear
from
other
people
on
the
call
as
well.
A
Yeah,
I
I
so
I
was
not
100
sold
on
moving
everything
up
into
hotel.
I
thought
there
might
have
been
benefit
to
keeping
the
separate
packages,
but
it
also
seemed
like
a
simpler
interface.
There's.
Just
one
package
to
pull
in
you've
got
everything
you
need
right
there,
and
at
least
for
for
those
of
us
who
are
intimately
familiar
with
it.
Maybe
that's
easy
and
makes
sense,
but
I
do
also
see
the
point
from
the
flip
side
of
people
who
are
new
to
this
and
don't
want
to.
A
You
know
just
bite
off
more
than
they
can
chew.
They
want
to
be
able
to
take
baby
steps
and
ease
into
it.
Having
smaller,
discrete
packages
that
provide
focus
on
individual
signals
or
areas
of
a
signal
might
help
them
do
that
so
having
just
a
trace
package
that
has
a
tracer
and
the
span
and
the
ability
to
set
attributes
or
get
the
span
out
of
context
and
not
have
to
think
about
okay.
Well,
what's
all
of
this
other
stuff?
A
How
does
it
relate
to
me
wanting
to
you
know,
add
attributes
to
a
span,
that's
already
existing
from
some
instrumentation
or
something
like
that.
Could
make
it
a
lot
easier
for
new
developers
that
also
gives
us
the
place
where
we
can
make
those
go
module
boundaries
to
provide
varying
levels
of
stability?
A
I
would
still
be
kind
of
reluctant
to
call
any
of
these
1.0
until
we've
got
both
traces
and
metrics
ready
to
go
and
stable
at
1.0.
But
if
they're
in
separate
packages
and
separate
modules,
that's
a
decision
we
can
make.
If
we
decide,
we
need
to.
B
One
thing
I
did
want
to
follow
up
on
janna.
You
had
mentioned
something
to
the
effect
of
like
the
coupling
between
the
api
and
the
sdk.
So
essentially,
the
implementation
of
the
interfaces
is,
if
my
understanding
correctly
and
what
maybe
your
suggestion
is,
is
having
a
trace
package
that
trace
package
has
an
api
and
then
a
sub
package
that
is
the
sdk
implementation
and
maybe
even
a
sub
package
from
that
that's
an
exporter
implementation.
So
essentially
it
would
look
as
a
trace
sdk,
maybe
export
interface,
or
something
like
that
or
my
misunderstanding.
F
I
mean
I
have
no,
I
mean
I
have
no
strong
opinions
on
that
like
if
we
are
going
to
split
these
packages.
The
the
problems
you
know
are
still
around
like
right
as
soon
as
they
are
not
in
the
same
package.
The
problem
still
exists
of
those
like
possible.
You
know
cyclic
dependencies,
so
I
have
no
no
like
problem
with
sdk
being
you
know
its
own
directory
with
its
own
structure.
That's.
C
F
A
B
If
we
did
go
back
to
re-evaluating
those
smaller
problems,
I
wanted
to
I'll
probably
draft
something
up,
hopefully
with
some
design
choices
as
to
like,
what's
motivating
our
our
decision
there,
instead
of
just
blindly
flip-flopping
into
the
future,
and
so
I
think
that
one
of
the
questions
is,
do
we
want
to
have
that
directory
that
top-level
directory
called
api,
or
do
we
just
want
to
have
a
tracing
directory
underneath
the
open,
telemetry,
the
hotel
package
itself.
F
If
you
ask
my
personal
opinion,
I
would
love
to,
you
know,
have
like
top
level
trace
top
level
metrics
top
level
anything
with
apis,
and
you
know
so
go
ahead.
B
Yeah,
that's
my
opinion
as
well.
The
then
there's
this
alias
api,
essentially
at
the
top
level,
because
one
of
the
other
issues
we
had
before
we
had
moved
everything
up
to
this
top-level
hotel
package
was
the
fact
that
there
was
no
go
code
that
existed
up
here
and
that's
why
there
there
was
these.
You
know
aliases
for
the
tracer
the
meter,
and
I
think
there
was
an
error
reporter,
because
people
would
import
the
package
and
there
would
be
no
go
code
in
it,
and
that
was
confusing
to
them.
B
And
so
I
didn't
know
if,
like
that,
aliasing
of
an
api
is
something
we'd
want
to
like
talk
about
as
well
or
if
we
had
opinions
on.
I
guess
I
guess
I'm
more
asking
for
opinions.
F
Can
you
I
I
have
no,
I
I
think
I
have
very
little
context
on
this.
That's
why.
D
A
A
So
I
think
back
like
0.9,
it
would
have
been.
Maybe
we
had
nothing
at
all
in
the
top
level
package.
So
when
people
would
go,
get
go
dot,
open,
telemetry,
dot,
io
hotel
it
would
it
would
barf
on
them,
because
there
was
nothing
there
and
go
would
say:
hey,
there's,
there's
no
go
mod,
no
go
files,
no
module
here.
What
do
you
want
me
to
do
yeah?
So
we
added
the
type
aliases
to
the.
I
think
it
was
the
tracer
provider.
F
Just
put
something
else,
like
some
other
version,
whatever
type
some
function,
that
does
something
which
is
a
utility
area
or
related
to
everything,
rather
than
like
putting
those
aliases,
because
when
I
saw
those
aliases,
I
immediately
thought
that
oh
either,
one
of
this
is
deprecated.
I
don't
know
which
one
because
it's
not
like
documented-
and
I
thought
that,
like
you
know,
which
one
I
should
I
use
right
like
so
that
gave
me
that,
like
wrong
impression.
C
F
A
The
other
consideration
is
that
we've
we've
talked
about
what
to
do
with
the
global
package
and
we've
never
really
been
sure.
I
wonder
if
we're
going
to
move
everything
out
of
the
top
level
hotel
and
back
into
separate
packages,
maybe
moving
the
stuff.
That's
in
global
up
to
the
top
level.
Hotel
might
make
sense.
B
C
I
had
come
back
to
this
this
whole
library
recently
as
a
consumer
after
having
set
it
aside
for
maybe
six
weeks
or
so,
and
even
with
my
editor,
helping
me
to
import
packages,
it's
it's
amazing
in
a
given
source
file.
How
many
import
statements
are
required
just
to
get
your
hands
around
this
stuff?
C
And
so,
while
I
do
well,
I
do
appreciate
the
impulse
to
put
things
into
buckets.
C
I
do
think
that
it
would
help
if
they're
big
buckets
and
we
focus
more
on
getting
getting
a
couple
import
statements
into
a
given
file
and
then
at
that
point
things
like
language
server
can
start
helping
you
with
the
type
suggestions
and
such
that
you're
already
in
the
right
place
to
start
finding
things,
but
especially
when
you
get
into
things
like
contrib
and
the
plugins,
and
you
know
all
that
that
stuff,
like
hooking
into
http,
I'm
up
to
like
12
imports
or
something
just
related
to
open
telemetry.
At
this
point.
F
Is
it
also
partially
because
of
the
fact
that,
like
when
we
put
things
in
the
trace
package,
you
know
you
cannot
like
all
the
import,
maybe
because
it
traces
there
are
so
many
trace
packages
if
you
make
them
like
hotel
trays
or
something
would
that
help,
even
though
it
sounds
ugly
to
me
right
now,
but
at
least
like
if
there
was
a
way
to
distinct,
you
know
open
telemetry
packages.
Would
that
help
with
that
auto
importing.
C
I
think
yeah,
I
think,
if
they,
especially
if
the
names
were
more
distinguished,
it
would
help
there's
always
this
problem
in
go
where
you
can.
You
can
shift
part
of
your
name
into
the
package
and
then
you
wind
up
with
shorter
identifiers
in
the
package,
or
you
can
use
bigger
packages
and
you
wind
up
with
longer
identifiers.
C
You
know,
because
you
no
longer
have
the
package
boundary
to
identify
them,
but
just
the
the
ergonomics
of
the
tools
that
we
use
today,
even
though
again
they're
pretty
good
at
trying
to
come
up
with
suggestions
for
imports
like
once
you've
already
imported
something
you
have
really
easy
access
to
all
the
stuff
in
that
package
for
discovery.
Even
just
like
how
many
pages
you
need
to
open
on
package.go.div
or
godoc.you
know
whatever
site
you
look
at
navigating
those
right
now
is
really
plunging.
C
I
think
some
of
that
also
we're
being
penalized
by
having
so
many
distinct
modules
in
the
project
that
the
way
that
it's
presented
yeah,
especially
on
package
echo,
is
it's
really
hard
to
see
a
lot
of
it
at
once.
B
Yeah,
do
you
have
like
a
good
example?
This
is
like
I'm
thinking
of
things
like
labels
and
thinking
of
things
like
what
else
at
the
top
level
like
propagators,
are
in
a
different
package,
but
yeah.
B
Okay,
yeah,
I
don't
think
I
fully
understand
how
big
like
how
you
would
scope
the
buckets
right
now,
which
is
kind
of
I
probably
should
have
a
better
understanding
of
that.
So
maybe
I
can
sync
with
you
at
some
point.
C
B
Okay,
I
think
I
might
understand
so
you're
talking
about
like
in
this
in
setting
up
a
pipeline
like
you
have
to
have
a
lot
of
imports.
Like
I'm
sorry
like
the
the
api
you
need,
then
the
fastband
processor
and
your
exporter,
or
your
exporter
as
well,
and
any
sort
of
like
sampling
decisions
and
then
like
in
the
metric
side
of
things
like
you
need
the
push
controller.
You
need
the
aggregation
selector,
you
need
the
kind
selector
like
all
these
kinds
of
things
and
like
what
you're
saying
is.
B
C
That
that
helps
up,
as
I
say,
around
the
main
functions
but
down
lower
where
you're
off
into
just
you
know
straight
instrumentation.
We
assume
somebody
else
has
set
all
that
stuff
up.
It
still
seems
like
there's
there's
a
lot
involved,
maybe.
B
A
I
think
that
that
top
level
wrapping
package
guns
that
also
kind
of
gets
to
the
distribution
concept
that
some
of
the
vendors
have
been
working
with
like
lightstep
and
aws.
A
So
I
don't
know
how
far
into
that
space,
we
would
want
to
go
as
a
project
ourselves
versus
leaving
that
to
the
vendor
or
the
application
developer
in
the
applications.
I'm
developing
right
now,
where
I'm
using
hotel.
I've
also
built
a
package
like
that
for
myself
that
handles
all
of
the
initialization
and
then
the
services,
where
we're
using
it,
just
import
that
and
use
it
to
set
up
their
their
pipeline
at
the
top.
B
B
What
are
we
at
the
release
planning?
I
just
probably
want
to
pause.
Really
quick
here.
Anthony
are
you?
Okay?
Is
everyone?
Okay,
I
think,
probably
with
prolonging
the
release
of
this,
given
it's
not
something
we
particularly
wanna
we're
solve
in
a
decision
that
we
want
to
go
with.
A
Yeah,
I
think
we
probably
should,
although
we
should
also
be
sure
to
communicate
at
least
to
the
getter
channel
and
perhaps
any
other
forums
where
that
might
be
relevant,
that
we're
going
to
be
delaying
it,
because
you
know
we
we
had
already
delayed,
because
we
were
out
last
week
and
some
people
have
asked
when
the
next
release
was
coming
yeah.
I
can.
D
B
A-N-E-U-R-Y-S-M-9
yeah
every
time
I'm
always
like,
is
it
the?
U
and
the
e
and
okay
anyways.
Sorry
moving
on
josh
has
this
pr
here,
which
has
been
open
for
a
little
while
go
ahead.
Josh
sorry,
can
you
hear
me.
E
It
move
I'm
willing
to
make
changes
in
any
direction.
We
all
agree.
I
did
apply
the
change
that
anthony
asked
for
last
night
and
sort
of
I
would.
I
would
take
it
in
this
form,
but
but
I'm
serious
and
will
respond
to
feedback
if
you
ask
for
it.
B
Yeah,
I
I
just
looked
at
this
right
before
the
meeting.
This
seems
sane.
I
was
going
to
give
it
another
once
over,
but
otherwise
I
think
this
is
good.
I
was
kind
of
also
pointing
out
earlier
in
my
comments
like
sorry
by
the
way
like
I
think,
I'm
also
I'm
pretty
guilty
of
a
lot
of
things,
but
this
is
I,
I
probably
derailed
this
a
little
bit.
We
could
probably
I
think,
from
what
I've
seen
before
merge
this,
and
if
we
have
any
like
additional
changes,
we
should
probably
try
to.
B
You
know
have
separate
pr's
for
those
going
forward.
It's
my
initial
reaction,
like
I
said
I
want
to
give
it
another
once
over.
Sorry
about
that,
I
guess
I
was
just
starting
off
by
saying
it
sorry
joshua
yeah.
This
is.
E
Fine,
I
I
think
it's
important
to
get
this
right
and
I
I
don't
think
you
derailed
it,
although
I.
E
I
prefer
the
new
option
because
I
think
users
are
gonna
in
the
end
only
want
to
call
one
resource
method,
there's
a
second
method,
signature
which
returns
a
resource
and
no
error
and
only
takes
attributes
which
is
really
useful
in
testing,
but
not
really
very
useful
in
general,
so
I
kept
the
other
signature
called
new
from
attributes.
Using
all
tests
made
a
technical
change,
I
don't
mind
changing
it.
I'm
definitely
not
feeling
religious
about
this.
B
Yeah,
that's
exactly
what
I
was
thinking
as
well,
like
that's
a
really
important
thing,
having
not
only
the
telemetry
sdk
itself,
but
also
some
of
the
environment
stuff
as
well.
So
I
I
do
want
to
try
to
get
this
in.
I
don't
think
there's
any
major
opposition
I
think
x
sam
had
was
the
one
who
disliked
that,
but
I,
I
honestly
think
we
can
merge
this
and
discuss
it
in
the
issue
that
I
had
opened
to
kind
of
address
this
and
we
can
progress
the
conversation
there.
E
B
Yeah:
okay,
if
that's
the
case,
with
the
release
being
delayed
a
little,
I
I
this
looks
good
I'll,
probably
approve
right
after
this,
but
then
I'd
love
to
get
resolution
from
exam
and
understanding
that
that
that's
fine
with
them
as
well.
E
Yeah,
I
think,
I'd
like
that
too.
I
think
he
his
response,
and
I
I
do
think
that
there's
an
important
test,
only
method
that
we
should
keep.
E
Yeah-
and
the
second
item
that
I
had
put
on
the
agenda
here-
was
really
just
a
another
request
to
say:
hold
the
release
because
I'm
actively
working
on
a
fix
and
we've
been
using
otlp
0.5
protocol,
and
I
just
because
we
haven't
released
some
of
the
stuff
in
weeks
like
I
just
got
all
the
great
mods
replaced
and
tried
running
things
and
realized,
I'm
not
able
to
get
metrics
through
our
system
because
we're
missing
these
fields,
and
so
I
think
it's
pretty
urgent
to
get
this
working
and
I
have
a
pr
half
baked.
E
B
Yeah,
okay,
it
sounds
like
we
have
some
really
good
reasons
to
delay
this
release,
so
I.
B
B
Cool,
I
think
that
was
the
end.
I'm
guessing
there's
a
lot
of
other
things.
People
have
to
talk
about,
didn't
know,
I'm
just
going
to
pause
right
there
and
just
let
anybody
else
if
they
have
something
else
they
wanted
to
bring.
B
Up
okay
looks
like
on
the
left
yeah.
I
think
that
my
my
top
priority
is
to
get
this
api
refactor
and
and
revert
or
restructure
again,
hopefully
much
faster
than
the
past
month
and
a
half,
although
after
a
month
and
a
half,
I
think
it
should
be
a
little
bit
easier,
given
the
a
lot
of
the
work
that
went
into
it
but
yeah.
B
I
think
that's
that's
my
primary
goal
for
the
next
week,
so
hopefully,
by
the
next
meeting,
we
should
have
at
least
a
pr
up
for
something
like
this
other
than
that.
I'm
really
happy
to
see
everyone
and
we
can
probably
end
it
with
12
minutes
to
go
so
y'all
take
a
break
and
get
ready
for
the
metric
sick
because
I
know
you're
all
going
there.