►
From YouTube: 2020-12-09 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
A
B
A
C
C
D
C
A
A
I,
like
tristan's
job
description
in
the
attendee
list
of
the
open
maintainer
open
to
long-term
retainer
meeting
notes
as
postmates
or
uber
he's,
not
sure
which.
A
F
Yeah
actually,
carlo
and
I
are
kind
of
like
taking
over
for
michael
taking
some
some
of
the
workload
off
his
plate.
Cool
cool,
yeah.
E
So
usually
I'll
go
through
the
spec
sig
spec
sig
is
really
kind
of
focused
right
now
around
really
hate
trying
to
share
the
screen
on
zoom
here,
okay,
so
things
are
really
centered
right
now
around
this
versioning
and
stability
dock,
and
this
we
spent
quite
a
bit
of
time
at
the
maintainers
meeting
yesterday
and
then
at
the
specs.
E
The
meeting
again
today
talking
about
this
and
I
kind
of
posted
in
and
getter
that
they
would
like
us
to
kind
of
like
draft
up
how
our
sig
wants
to
approach
this
and
kind
of
have
that,
as
at
the
maintainers
meeting,
they
said
have
it
as
a
just
a
google
doc
and
there's
a
tracking
issue
that
we
posted
on.
I
know
that
java
has
a
draft
draft
already
that
they're
opening
as
a
pr-
and
it
looks
like
it's.
E
Introducing
is
adding
to
their
rationale,
doc,
which
apparently
they
have.
I
don't
think
we
have
this
doc,
but
we
could.
We
could
have
something
like
this,
where
it
kind
of
lives
in
our
our
repo,
so
for
the
most
part
like.
I
think
this
is
one
of
the
more
important
things
to
do
to
talk
about
today.
So
maybe
I
will
quickly
look
at
if
there's
anything
else
worth
mentioning
from
from
the
specs
egg,
but
it
would,
I
don't
know
like.
Has
anybody
had
a
chance
to
look
at
this
document?
H
Yeah
I've
read
through
most
of
the
doc
and
all
the
commentary
around
it.
I
haven't
looked
at
the
pictures
yet.
H
Yeah
the
primary
stuff
I
haven't
gotten
to
yet
is
the
version
numbers
section.
H
The
primary
takeaways
I
have
from
this
are
the
we
probably
need
to
break
up
our
packages
into
separate
signals
and
probably
a
core
package
that
provides
baggage
and
the
context
propagation
and
then
the
other
thing
is.
We
probably
need
to
break
out
all
the
instrumentation
into
a
contrib
repo
so
that
we
can
version
it
separately.
E
Yeah
I
had
some
similar
takeaways
and
I
don't
know
I
guess
I
started
this
very
slim
document
as
something
I
guess.
E
E
E
I
think
this,
I
don't
think
it
explicitly
says
this
anywhere,
so
I
could
be
misinterpreting
these.
H
The
there's
a
lot
of
talk
about,
I
think,
just
the
signals
so
separating
each
signal
I
feel
like
baggage
and
context,
are
not
signals.
They
just
belong
in
a
core
thing
that
everything
else
builds
on
top
of.
E
B
So
that's
that
said
the
reason.
The
whole
reason
for
breaking
out
the
signals
is
that
we
can
have
this
distinction
between
what's
stable
and
what's
what's
experimental,
so
that
you
can
have
a
a
signal
like
metrics.
That
starts
off
as
experimental
and
is
as
a
separate
package,
and
then
you
bring
it
and
then
once
it
gets
stable,
you
bring
it
into
you,
you
you.
B
Basically
it's
still
that
it's
still
that
package,
but
then
it
is
now
part
of
the
the
global
api
package,
and
I
you
one
could
conceive
of
something
like
a
corp.
You
know
context
we
have
context
and
baggage.
Now
what
if
we
have?
I
don't
know
config
or
something
something
in
the
future
that
that
gets
gets
added
as
a
core
package.
Would
we
have
the
same
issue
where
we
might
want
it
to
start
off?
B
As
a
you
know,
a
separate
experimental
package
and
then
bring
it
in
later
and
then
will
we
have
the
same
versioning
issue
that
we
are
trying
to
avoid
here
with
the
with
breaking
those
out.
B
Yeah,
and
so
I'm
I'm
wondering
if,
if
it
still
makes
sense
for
for
these
quote-unquote
core
packages
for
for
us
to
treat
them
or
use,
use
separate
packages
for
that
that
same
reason,.
E
So
were
you
saying
that
maybe
not
everything
should
go
in
a
core
and
that
having
them
a
little
bit
more
distinct
is
a.
B
I'm
I
guess
I'm
saying
that
aggregating
those
into
a
core
package
ice
instead
of
breaking
them
out,
I
think,
will
lead
us
into
the
same,
but
potentially
listen
to
the
same
problems
that
we're
trying
to
solve,
but
by
you
know,
we're
we're
trying
to
solve
a
specific
issue
by
breaking
these
packages
out
into
separate
packages.
B
If,
if
we
don't
have
separate
packages,
for
these
quote
unquote
core
packages,
will
we
will
ar?
Are
we
just?
Will
we
run
into
that?
That
issue
will?
Will
we
not
be
able
to
avoid
that
issue.
G
E
Okay,
I'm
fine
with
anything
reasonable.
Ultimately,
as
long
as
it,
you
know
makes
our
development
somewhat
sane
and
you
know,
isn't
producing
any
like
unnecessary
kind
of
challenges
or
ceremony
around
things.
So,
like
I
think,
yeah,
I
think
I
think
we're
probably
as
a
group
gonna
have
to
make
a
few
proposals
of
where
the
lines
are
and
kind
of
just
talk
them
over
and
make
sure
that
we're
all
kind
of
happy
with
them.
H
H
Question
is:
where
does
the
api
package
belong?
Is
it
an
aggregating
thing
that
is
somewhat
equivalent
to
the
instrumentation
oil
package,
or
is
it
the
bottom
level
stuff
that
absolutely
must
exist?
You
know
defining
the
open,
telemetry,
name,
space
and
so
forth.
E
So,
as
I
was
writing
this
up,
I
was
kind
of
thinking
like
the
api,
would
be
an
aggregating
package
plus
a
little
bit
because
I
think,
like
the
we
kind
of
have
the
the
open,
telemetry
module
and
a
handful
of
just
accessories
there
to
kind
of
wire
up
the
the
global
instances
of
like
the
tracer
provider
meter
provider.
E
All
of
that
I
was
kind
of
thinking
that
is
probably
all
still
the
api
at
the
api
level
kind
of
the
glue
for
all
the
in
individual
apis
and
the
accessories
for
the
actual
implementation
that
backs
them.
B
So
does
what
what
then
would
like
the
open,
telemetry
trace
package
then
need
to
depend
on
open
template,
telemetry
api.
B
Right,
but
we
have
this
global
api
package
that
you
know
if
it
indeed,
it
does
include
this
some
of
this
glue
functionality.
B
What
is
the
dependency
relationship,
then,
is
this
trace
depend
on
that
glue
functionality
or
is
trace,
able
to
be
ins?
You
know
just
just
in
terms
of
package
dependencies
can
we
have
trace,
not
depend
on,
because
if
api
is
global
cons
that
that
to
me,
that
means
that
it
depends
on
baggage,
it
depends
on
context.
It
depends
on
trace.
B
It
depends
on
metrics,
you,
users
will
install
open
telemetry
api
and,
by
virtue
of
transit
dependencies
they'll
get
all
of
these
separate
api
packages
that
they
need
to
use
open,
telemetry,
so
the
so
the
dependency
relationships
then
go
go
in
that
direction.
Open
the
telemetry
api
is
kind
of
the
higher
level
package.
B
E
Yeah
no
like
that
was
my
intention.
I
think
when
I
was
saying
glue,
I
feel
like
the
open
telemetry
api
is
gluing
together
the
trace
context
baggage
for
kind
of
for
for
the
user.
To
be
honest,
like
I
don't
think,
there's
any
like
cross
dependencies
between
those
packages,
but
I
would
see
the
yeah
it
would
be
open,
telemetry
api
that
would
depend
on
trace,
metrics
context
and
baggage
and
not
the
other
way
around.
B
Okay,
that
makes
sense,
would
it
what's
trace,
still
need
to
depend
on
context
for
some
reason,
or
will
we
need
it?
It
does
seem
like
it's.
It's
conceivable
that
there
might
be
some
cross
dependencies
among
the
components.
H
E
Yeah
so
like
context
kind
of
is
this
cross-cutting
concern,
I
guess
where
so
maybe
there
is
maybe
there
is
open,
telemetry
api
that
glues
together
all
the
signals
for
the
user
and
perhaps
there's
something
underneath
all
this
stuff,
and
maybe
that's
our
core
package
or
something
along
those
lines.
I
E
D
H
E
H
D
E
E
E
Probably
sorry,
sorry,
if
I
got
you
off,
was
there
something
else.
H
No,
I'm
I'm
looking
at
the
language
specific
examples
in
the
doc
for
go
no
experimental
directory
and
go
with
an
experimental
directory,
so
that
talks
a
little
bit
about
how
the
versioning
would
work.
H
H
H
I'm
just
trying
to
find
where
the
link
is
there's
a
link
to
a
whole
bunch
of.
H
Examples,
oh,
I
think
it's
maybe
in
the
issue,
but
not
the
issue.
Sorry,
the
pr
itself
has
some
text
that
links
to
the
original
document
and
the
document
has
a
little
bit
more
detail.
G
G
G
H
Yeah
yeah
and
then
eventually,
once
metrics
api
is
stable,
it's
renamed
to
hotel,
metrics
and
otl,
sorry
otel,
sdk
matrix
and
then
the
experimental
one
I
guess
is
removed
or
deprecated.
At
that
point,.
E
Yeah
that
I
was
kind
of
thinking
we
could
do
is
we
could
just
we
could
have
an
experimental
folder
or
we
could
just
suffix
the
package
with
experimental
and
as
long
as
experimental
appears
somewhere
in
the
name
that
that
would
be
what
we
could
do.
They
would
version
the
same
as
the
core
things
and
then
eventually
they
would
lose
that
suffix
and
we
would
we
would
end
up
adding
them
to
the
global
api,
but
it
seems
like
that's
just
a
minor
version
bump.
If
I'm
remembering
from
the
document
properly.
B
So
is
there
a
reason
why
we
it
on
the
ghosts
on
the
go
side,
it
looks
like
the
the
experimental
non-experimental
were
two
options
that
they
were
looking
at
is
that
is
that?
Am
I
right
about
that
yep?
B
So
we
could.
We
could
decide
to
use
experimental
or
not
right.
I
I'm
I'm
I'm
personally
hesitant
to
because
why?
Why
is
that
useful?
B
It's
it
seems
like
if
we,
if
we,
if
we
use
the
experimental
name
and
the
package
name
or
or
or
or
even
in
the
in
the
name,
spacing
the
the
you
know
the
ruby
classes,
then
we're
just
forcing
people
to
rename
things
when
they,
when,
when
we,
when
we
end
up
doing
the
final
stable
release
of
this,
whereas
we
already
have
zero
point
x
versions
to
to
signal
this
is
experimental.
E
So
I
think
you
can
have
experimental
stuff
in
your
1.0
and
so
presumably
like
it
seems
like
looking
at
this
example.
It's
kind
of.
E
B
Okay
and
that's
actually,
that
seems
actually
even
worse,
because
now
we're
now
we're
losing
the
ability
to
sember
properly,
things
that
are
experimental
are
going
to
have
breaking
changes
all
the
time,
and
that
was
the
whole
point
of
as
my
understanding
that
was
the
point
of
separating
out
the
packages
so
that
we
didn't
have
that
problem.
B
Now,
if
we
insist
that
experimental
packages
are
versioned
in
lockstep
with
stable
packages,
I
don't
see
how
you
can
do
that
and
and
follow
simba.
H
Yeah,
I
think
you
really
need
to
not
have
the
experimental
thing
and
instead
version
the
experimental
things
independently.
I
think
I
think
java
no
java
is
adding
an
experimental.
How
is
java
doing
it.
E
Kind
of
changed
in
the
o-type
process
and
the
otap
is
still
like
up
for
debate,
and
I
think
that
is
one
thing
that
could
still
be
discussed,
but
it
says
you
know,
for
the
purposes
of
versioning,
all
code
within
a
release
is
treated
as
if
it
were
part
of
a
single
package.
E
All
packages
within
a
release
receive
the
same
version,
number
keeping
version,
numbers
and
lockstep
end
users
can
understand
which
packages
belong
to
which
release,
although
it
does
somewhere,
it
mentions
that
contrib
doesn't
have
to
match
you
kind
of
consider
contrib
its
own
package,
but
it
doesn't
seem
to
say
it
doesn't
give
you
a
loophole
for
the
experimental
ones.
H
And
it's
currently,
I
think
the
loophole
was
a
language
specific
work
around
where
different
language
and
implementations
don't
have
to.
Oh
sorry,
no,
it
wasn't
that
one.
Let
me
find.
H
Yeah
for
version
numbers
just
before
the
major
version
bump,
it
says
different
language,
implementations,
no
jesus,
sorry,
I'm
still
looking
at
the
wrong
thing.
In
some
languages,
package
managers
react
poorly
to
experimental
packages
having
a
version
higher
than
zero
point
x.
In
these
cases,
language
specific
workaround
is
required.
H
Whereas
the
description
of
minor
version
bump
is
new,
experimental
packages
are
added,
or
you
have
breaking
changes
to
experimental
signals.
You
in
both
cases
you
get
a
minor
version
of
them.
E
Right
so
I
guess
ignoring
the
otep
for
one
moment.
What
do
we
have
an
idea
of
what
our
ideal
situation
would.
G
G
G
G
E
Would
would
it
be
okay
if
we,
if
we
didn't,
have
experimental
in
the
gym,
if
we
just
called
the
gem,
whatever
it's
ultimately
going
to
be
called
and
just
plastered
experimental
all
over
the
readme
for
it
and
did
not
and
did
follow
the
rule
that
it
was
not
referenced
by
any
stable
components?
And
it's
also
not
part
of
the
global
api.
G
G
E
Yeah,
I
think
the
main
goal
for
all
this
is
to
be
able
to
basically
facilitate
this
rolling
release
of
signals
and
allow
us
to
kind
of
like
ship
tracing
first
develop
metrics
ship
that
second,
but
in
in
the
period
from
where
you
shipped
tracing
to
where
you
shipped
metrics,
you
just
don't
want
the
user,
you
don't
want
anything
to
break
for
the
user.
I
think
that's
like
the
whole
kind
of
goal
behind
all
this.
E
So
there's
like
some
reluctance
to
is
to
like
make
make
it
easy
for
the
user
to
use
the
experimental
package
without
like
fully
knowing
what
they're
doing
and
signing
up
for
so
just,
I
think
that's
kind.
I
I
Correctly
so,
like
we'd,
have
our
open,
telemetry
api
gem,
but
would
it
be?
It
would
be
like
an
just
an
aggregator
of
baggage
contacts,
trays
right
now,
because
metrics
well
doesn't
exist.
But
let's
say
when
it
does
exist
and
it's
experimental
it
wouldn't
get
included
in
this
gem.
Would
we
have
like
an
open,
telemetry
api
dash,
experimental
that
would
include
metrics
and
so,
like?
You,
wouldn't
be
messing
with
any
of
the
names
facing
with
like
these
weird,
like
experimental
modules
you
just
wouldn't
be
including
it
as
part
of
like
the
stable
release.
E
I
mean
that
sounds
reasonable
to
me.
So
so,
if
we
wanted
to
have
this
example,
where
you
know
say
we
ga
we
have
tracing
baggage
context
and
then
we
have
open
telemetry
api
which
glues
those
together
and
then
we
start
working
on
metrics.
We
would
have
just
open
telemetry
metrics
as
a
package
would
not
be
part
of
api,
but
then
we
would
have
experimental
api,
which
would
kind
of
tentatively.
E
I
What
is
the
goal
of
this
whole
proposition
right
is
to
make
sure
that
people
can
use
this
with
some
form
of
stability.
They're,
like
the
thing
is
we'll
just
have
to
make
sure
that
those
cross-cutting
concerns
like
baggage
and
context
and
trace,
can't
depend
on
each
other
or
something
from
metrics
like
we
have
to
make
sure
that
there's
not
any
tight
coupling
there,
because
then
that
breaks
right,
because
then
you're
you
might
accidentally
be
pulling
something
you
shouldn't
or
like.
B
Really
do
not
like
we're
communicating,
I
guess
if
we
do,
that,
we
we
kind
of
have
to
have
yeah
the
experimental
pla,
even
if
we
have
experimental
plastic
all
over
the
read
me.
I
just
don't
like
it
having
a
having
a
1.x
package
that
we
consider
experimental
and
we
are
reserving
the
right
to
make
breaking
changes
in
a
patch
release,
because
you
know
it
is
considered
experimental
and
under
developments.
B
You
know
I
I
just
yeah,
I'm
sorry,
I'm
I'm,
I'm
a
I'm
a
bit
of
a
simva
purist
and
I
don't
like
the
the
idea
of
lockstep
versions,
but.
E
No,
I
I
appreciate
your
dedication
to
making
a
reasonable
versioning
scheme
and
I
think.
H
So
sorry,
practical
considerations,
firstly,
contrib-
should
be
versioned
independently.
I
think
should
we
be
moving
that
out
to
a
separate
repo,
so
basically
all
the
instrumentation,
the
auto
instrumentation.
Should
that
be
in
a
separate
repo,
or
can
we
manage
it
effectively
with
the
the
scripts
that
we
have
and
then
separately
from
that
if
we
want
an
experimental
signal
like
metrics
to
be
versioned
independently?
B
Good
question,
so
we
can
do
whatever
we
want
with
the
scripts
right
right
now.
I
I
think,
when
you
do
a
general
release
of
everything
you
you,
you
just
use
kind
of
the
all
colon
version
syntax,
which
you
know,
which
is
which
is
convenient.
B
Currently,
as
is
if
we
have
some
subsets
of
that
that
are
kind
of
the
api
packages,
and
we
want
them
versions
together
and
that
we
want
to,
and
then
we
have
contrib
packages
that
might
be
versioned
separately.
We
could,
you
could
still
do
a
release
where
you
specify
each
with
the
explicitly
specified
the
list
of
packages
in
in
the
field,
so
it's
possible
to
do
it
to
do
it
that
way,
it's
less
convenient,
although
again
this
we
we
own
the
scripts.
I
I
it's.
B
We
could
set
up
something
in
this
like
in
the
digs
where
we
say:
here's
the
here's,
an
alias
all
dash
apis
or
something
like
that.
Yeah.
We
list
the
packages
that
are
in
that
list
that
that's
that
and
then
we
can
and
we
can
use
that
syntax,
and
so
there
are
certainly
things
that
we
can
do
to
the
scripts.
If
we
don't
want
to
split
out
into
separate
repos,
if
we
think
that's
inconvenience,
how
is
the
tagging
going
to
look
in
that
case?
B
Attacking
would
look
the
same
way.
The
tagging
is
always
package
name,
slash
version.
B
B
So
I
think
yeah
it
would
not
be
hard
to
to
enhance
the
scripts
to
do
that.
So
I
think
if
we
feel
like
having
a
mono
repo
with
with
all
the
packages
just
in
one
convenient
place,
if
we,
if
we
think
that's
just
convenient
overall,
I'm
happy
to
to
enhance
the
scripts
to
make
releasing
different
subsets
easier.
B
If
we
think
that,
for
other
reasons
it
still
might
be
useful
to
break
out
the
the
breakout
contributing
to
a
different
repo,
I
I
don't
know
there
might
be
other
reasons
that
we
can
think
of
that.
That
might
be
useful.
Then
we
can
talk
about
that.
H
And
I
have
found
problems:
for
example,
the
collector
has
a
contrib
repo,
a
separate
contributor,
and
in
the
past
we
have
had
problems
with
those
getting
out
of
sync,
where
the
the
latest
version
of
the
collector
won't
won't
build
with
the
collector
contrib
and
like
the
latest
version
of
the
collector,
can
trip.
So
I
think
it's
helpful
to
actually
keep
them
on
a
repo
if
we
can
rely
on
the
release
scripts
to
do
the
right
thing.
E
Most
other
languages
have
ended
up
splitting
out
a
contrib
and
like
it
has
pros
and
cons.
I
think
I
think,
eventually,
all
these
projects
are
gonna
hit,
a
critical
enough
mass
that,
like
for
just
kind
of
like
issue
triage
purposes
having
them
split,
is
going
to
be
a
good
idea
because,
like
you
would
expect,
probably
you
expect
a
lot
of
stuff
going
in
and
it's
going
to
be
a
lot
to
keep
up
with.
E
If
you
have
all
of
your
instrumentation
and
and
kind
of
core
components
in
in
the
same
repo,
so
I
think
a
lot
of
people.
I
think
a
lot
of
other
projects
already
hit
that
point
actually
and
like
for
that
reason.
Split
things
apart,
but
basically
the
thing
that
ends
up
happening
is
that
the
the
core
repos
go
through.
Heavy
development,
contrib
is
woefully
broken,
and
then
they
release
the
the
core
package
and
go
through
and
fix
contrib,
and
it
releases
like
a
week
later.
E
That's
kind
of
at
least
what
I've
seen
and
kind
of
the
the
thinking
behind
a
lot
of
that
is
that
eventually,
the
core
stuff
is
going
to
slow
down
a
little
bit
and
the
breakage
to
contrib
should
be
a
lot.
Oh,
I
guess
a
lot
more
rare,
so
I
think
I
think,
there's
probably
some
truth
to
that,
but.
B
One
of
the
things
that
has
driven
some
of
the
breakout
or
not
breakout
decisions
with
with
on
my
team
at
google
is
differences
in
the
maintenance
team.
B
When
once
the
team
gets
large
enough
that
it
that
a
particular
subset
of
the
team
is
focused
on
one
set
set
of
one
particular
library,
one
subset
of
the
libraries
and
then
and
and
then
we
want
to
do
things
like
set
up
permissions
differently
for
different
packages,
then
that
seems
like
it's
the
point
where
it's
worthwhile
to
break
things
up.
B
E
Yeah,
I
I
think
everything
you
just
said
there
makes
sense,
so
I
think
the
I
guess.
I
would
recommend
that
we
don't
do
a
premature
splitting
of
the
repo
that
we
kind
of
we
decide
to
do
this
when
there
is
a
reason-
and
it
sounds
like
we
don't
yet
have
a
reason
for
this.
This
is
true.
E
Yes,
that's
true
yep
unless,
unless
the
reason
ends
up
being
our
versioning
scheme
that
we
are
trying
to
come
up
with
so
on
that
note,
I
know,
ted
was
really
hoping
that
we
could
get
some
sort
of
like
how
your
language
would
implement
this
thing
by
tomorrow,
which
is
like
you
know
very
soon.
E
Obviously-
and
I
think
we've
talked
about
this
for
about
50
minutes
and
I
feel
like
we've
had
a
really
good
discussion,
but
I
don't
feel
like
we've
gotten
anywhere
or
not
super
far,
but
as
we
have
this
discussion
like,
I
think
I
think
this
is
a
slightly
challenging
thing.
I
don't
know
that
a
lot
of
I
don't
know
how
many
people
have
experienced
trying
to
trying
to
sanely
version
something
in
this
way.
E
I
guess
I
feel
like
this
is
a
slightly
slightly
specialized
versioning
situation,
it's
at
least
an
extra
credit,
versioning
problem
and,
like
I
do
get
the
impression
that
daniel
you
have
opinions
and
some
maybe
some
possible
ideas,
and
I'm
curious
like
if
you
have
like
an
idea
of
how
you
would
like
this
to
work.
Regardless
of
what
the
otep
looks
like
and
see
see
what
we
can
do
to
either.
E
B
If
you're
asking
me,
if
I'm
willing
to
to
write
up
something
sure
I
can
give
it
a
shot
sometime,
I
give
it
a
shot
sometime
today,
I
I
I
definitely
have.
I
have
an
idea
of
what
of
what
I
would
you
know,
regardless
of
the
otep.
B
You
know
what
kind
of
versioning
I
would
like
to
see,
but
that's,
but
that
involves
kind
of
tossing
the
whole
version
lockstep
thing
which
I'm
just
not
a
fan
of
that
said
it
seems
like
the
otep
and
kind
of
the
the
the
maintainer
community
in
general,
has
has
kind
of
converged
on.
B
Yes,
we
do
want
lockstep,
at
least
for
the
the
stable
packages
that
there's
there's
there's
value
in
that,
and
so
what
it
looks
like
to
to
retain
that
and
still
have
something
that
is
reasonable
for
us
and
works
works
well
with
the
experimental
packages
and
how
ruby
is
think
about
versioning
and
things
I
don't
know
I
I
could
try
to
come
up
with
something,
at
least
as
a
starting
point
and
and
send
that
out,
and
it's.
E
Yeah,
I
really
don't
want
to
like
dump
this
on
you
and
I'm
more
than
willing
to
help
out
in
any
way
like
I'm,
just
like
I'm
just
trying
to
help
get
something
to
ted.
That's
in
the
spirit
of
in
the
spirit
of
the
otap.
That's
gonna
work
for
us
and,
like
I
guess,
I'm
just
slightly
fearful.
If
I
start
like
writing
a
bunch
of
stuff
in
a
google
doc
that
when
I
present
it
to
everybody,
nobody
will
be
happy
and
well.
B
I'm
sure
that's
probably
going
to
be
the
case.
If
any
of
us
write
something
that
there
will
be,
people
are
unhappy
and
there
will
be
discussion
and
for
for
tomorrow
it's
it
sounds
like
they.
They
just
want
a
an
initial
draft
and
maybe
the
the
even
even
the
the
sig,
the
language
sig
is
still
not
in
the
complete
agreement,
but
at
least
as
a
starting
point
is
that
kind
of
where
they're
at
or
are
they
actually
asking
for?
This
is
kind
of
what
the
language
sig
wants.
E
I
think
they
would
like,
I
think
the
biggest
thing
is
they
want
to
know
if
the
otep
is
going
to
work
for
people
and
if
it's
not
they
kind
of
want
to
like
you
know,
they
would
like
us
to
propose
some
changes
to
to
improve
it.
I
think
they
just
don't
want
us
to,
like
you
know,
take
a
month
to
figure
this
all
out.
So.
H
H
So
if
you
look
at
any
one
of
these,
the
go
one
or
the
java
one
of
the
python
one,
the
python
one
is
pretty
short:
it's
just
walking
through
the
steps
of
okay,
you
know
initially,
what
does
1.0
release
look
like
for
the
stable
things
and
then,
when
you
have
at
least
once
metrics
is
stabilizing?
What
does
that
do
to
the
version
increment?
H
Once
you
introduce
the
alpha
version
of
logs,
what
happens
there,
so
it
doesn't
need
to
be
particularly
like
in
depth
it's
just
kind
of
marching
through
at
each
of
these
steps.
What
happens?
H
One
question
I
had,
though,
was
if
we
have
a
stable
version
of
api
that
does
not
include
metrics,
and
we
have
people
who
are
dependent
on
who
choose
for
whatever
reason
to
try
out
the
metrics
api
and
they've
got
a
dependency
on
on
the
metrics
api,
and
subsequently
we
do
a
release
of
the
api
that
includes
metrics
as
a
stable
signal.
B
Yeah,
so
what
I
would
say
is
that,
and
again
my
my
my
thought
on
this
on
experimental
is
experimental.
Just
has
to
be
zero
point
x
and
and
then,
when
we
move
something
into
stable,
we
we
do
december
major
to
one
point
x
or
you
know
one
one
points
you
know
whatever
the
the
stable
current
stable
release
version
is,
but
it's
december
major.
B
So
at
that
point,
if
the,
if
the,
if
the
user
has
updated
their
their
stable
to
include
to
the
version
that
includes
stable
metrics,
they
can,
they
cannot
have
that.
You
know
december
wise
and
metrics
zero
point
x
because
then
they'll
have
metrics
one
point
x
and
metric
zero
point
x
in
the
same
bundle
and
that's
not
gonna
work,
so
they
will
have
to
remove
metrics
zerocoin
x
from
their
bundle
at
the
same
time
that
they
rev
api
global
to
to
that
version.
That
includes
metrics.
H
Okay,
so
the
key
requirement
there
is
that
the
metrics
api
does
need
to
be
separate
from
this
api
global.
We
couldn't
have
something
where
api
global
has
all
the
stable
things
without
dependencies
on
you
know,
one
of
the
ideas
is
that
you
break
out
tracing
context,
baggage
and
metrics
into
separate
separate
packages,
and
then
you
have
the
api
global
package.
That's
pulling
together
the
stable
ones,
the
other
one
is
that
you
have
tracing
context
and
baggage
or
living
in
that
global
api,
and
then
metrics
is
a
separate
one
on
the
side.
H
B
H
H
One
notion
would
be
that
you
keep
that
api
package,
but
you
just
extract
the
metrics
into
a
separate
package,
because
we've
said
that's
unstable
right
right,
but
it
seems
like
we
couldn't
then
clearly
indicate
to
people
that
hey
if
you
move
up
to
version
1.1
of
the
api
package,
which
is
now
now
has
a
stable
metrics
that
you
can't
also
have
the
metrics
zero
points
x.
H
I
H
Exactly
exactly
so,
we
really
are
forced
to
split
out
trace
into
a
separate
thing,
even
though
right
now,
we
believe
that's
stable,
we're
forced
to
separate
it
out
and
have
this
global
package
that
pulls
all
the
stable
signals
together.
B
What
we
are
forced
to
do
is
split
out.
Metrics
regard
we
can
do
you
know,
trace
trace,
you
know
technically
trace
could
still
live
in
the
in
the
global
package.
Although
for
consistency,
I
think
we
should,
it
still
should
be
split
out,
but
what
we
are
forced
to
do
is
put
out
metrics,
because
we,
because
we
need
to
make
this
distinction
between.
Yes,
it's
it's
it's
unstable
here
and
then
this
version
of
global
includes
a
stable
version
so
and
we
need
to
be
able
to
have
bundler
exclude
those.
H
B
Yes
sure
yeah,
so,
yes,
I
would
definitely
advocate,
for
we
should
still
split
out
trace
baggage
context.
You
know
for
for
consistency
to
to
to
show
our
users
that
this
is
how
things
are
are
structured
and
we
are,
you
know,
ends,
and
so
it
makes
sense
that
when
we
we
have
something,
that's
unstable,
it's
separate
and
then,
when
it
stabilizes
it
gets
brought
in
it's
very
clear
to
users.
You
know
what
what
the
mechanism
is
and
how
we're
what
our
policy
is.
Okay,.
E
Yeah
so
looking
looking
at
this
otap
like,
I
do
think
that
there
are
at
least
the
loopholes
that
we
need
to
be
able
to
version
our
version,
the
experimental
packages
as
a
non
1.0.
So
I
think
that's
good.
I
think
we
seem
to
have
like
some
clarification
about
how
we
would
do
that.
B
Do
we
think
that
we
would
need
to
do
the
same
for
our
sdk
packages?
I'm
I'm
I'm
not.
B
Is
is
there?
Is
there
kind
of
a
one-to-one
correspondence
between
do?
We
need
sdk
baggage,
sdk
trace
sdk
metrics,
I'm
guessing
yes,
for
the
same
reason
that
sdk
metrics
would
be
unstable
for
the
same
approximately
the
same
period
of
time
that
api
metrics
would
be.
E
Yeah,
I
think
that's
a
good
question
and
one
the
otep
doesn't
really
say
anything
about
how
the
sdk
should
be
divided
up,
but
that
was
one
thought
that
I
had
and
I
wasn't
sure
what
to
think
about
it.
E
Like
the,
I
think
there
is
some
verbage
in
here
that
talks
about,
like
the
the
surface
area
of
the
sdk,
that
the
user
would
interact
with
so
like
kind
of
constructors
for,
like
spam
processors
exporters.
That
sort
of
stuff
is
supposed
to
remain
backwards
compatible,
but
any
kind
of
like
internals
are
are
free
to
change.
D
E
There
is
maybe
a
world
where
you
can
have
everything
in
the
sdk,
but
as
long
as
you're,
careful
about
the
surface
area
exposed
to
the
user,
and
given
that
a
lot
of
it
is
actually
just
coming
from
from
the
api
and
you're
just
plugging
in
implementations
behind
it,
you
might
be
able
to
get
away
with
less
division
in
the
sdk,
I'm
not
advocating
for
either
one
over
the
other,
though,.
E
And
I
guess
yeah
like
I,
don't
know
the
answer
to
that
one.
The
other
question
that
I
had
when
I
read
through
this
document
and
it
kind
of
came
up
in
spec
sig
today
was
like.
Does
that?
Does
the
api
need
to
necessarily
be
bumped?
Does
the
version
need
to
be
bumped
every
time?
There's
an
sdk
change
and
I
feel
like
there
were
opposing
opinions,
but
I'm
definitely
in
the
camp,
where
I
don't
think
the
api
should
have
to
change.
E
If
for
like
an
sdk
change
and
like
there's
like
a
clear
decoupling
between
api
and
sdk,
that's
they're
supposed
to
be
and,
like
you
know,
they're
supposed
to
you're
supposed
to
feel
anybody
is
supposed
to
be
able
to
make
an
sdk
implementation,
so
why
our
sdk
is
so
blessed
that
it
has
to
bump
the
api
version.
Even
though
the
api
doesn't
change,
I
don't.
H
Yeah
ted
seemed
to
really
want
to
have
those
lock
step
versions
between
the
sdk
and
the
api,
but
I
think
we
expect
the
sda
sdk
to
change
more
often
and
to
you
know,
for
bug
releases
to
or
bug
fixes
to
go
into
the
sdk
more
often
than
the
api.
H
So
the
lock
step
requirement
just
seems
really
cumbersome.
E
H
E
Yeah
and
like
like
everybody
else
who
might
want
to
make
an
sdk,
they
shouldn't
have
to
release
their
sdk
every
time
like
a
new
api
changes,
like
happened
or
something
I
feel
like
you're
imposing
a
lot
on
on
other
sdk
implementations
if
anybody's
actually
making
them.
I
think
there
was
like
a
huge
desire
for
this
in
the
beginning
of
open
telemetry.
I
don't
know
how
much
people
are
taking
advantage
of
this
yet,
but
we
have
made
the
community
sdks
pretty
flexible
to
where
I
think
most
people
can
use
them.
E
E
And-
and
it
I
mean
so-
that's
probably
one
of
the
more
like
unlikely
scenarios,
but
still
likely
over
time,
but
I
think
also
like
frameworks
that
decide
to
ship
open,
telemetry,
instrumentation
first-party
instrumentation
in
in
their
code.
I
think
they
don't
want
to
have
to
always
be
updating
the
api
there
as
well,
and
I
think
honestly,
like
having
those
mismatch,
starts,
starts
to
actually
make
using
open,
telemetry
a
lot
harder.
E
Think
yeah,
hopefully
we're
able
to
at
least
get
that
change
to
the
other.
E
E
So
yeah
like,
like
I'm
saying
I
don't
want
to
force
any
work
on
you
daniel,
but
if,
if
you
have
the
time
and
wouldn't
mind
like
starting
off
a
draft
of
of
roughly
what
you
would
like
to
see,
I
think
it
would
be
helpful
and
if
you
want
any
help
or
like
collaboration
on
it,
like,
I
think
I'm
willing
to
pitch
in.
I
think
other
people
are
as
well.
B
But
yeah
I'm
happy
to
think
to
get
something
started
I
I
should
have.
I
should
have
yeah
I'll
go
to
the
time
today,
so
I'll
I'll
get
yeah
I'll
get
that
started
and
send
out
send
out
a
link
on
that
getter.
B
E
Yeah,
I
hate
doing
that,
but
I
do
really
appreciate
it
and
I
think
that
you
have
some
some
opinions
and
good
ideas
here.
So.
E
Okay,
I
keep
saying
I'm
gonna
do
it,
so
I
will.
I
will
make
some
kind
of
do
it.
I
I
also
that's
the
last
exciting
one
but
exciting
for
me.
I
threw
up.
I
gotta
have
some
feedback
that
I
need
to
adjust,
but
I
threw
up
a
little
instrumentation
template
generator
that
makes
all
the
boilerplate
crap
like
all
the
files
and
directories
you
just
say
like
generate
instrumentation
and
then
whatever
it's
called,
and
then
it
just
makes
the
folder
and
creates
all
the
the
stuff.
You
know
what
I
mean:
it's
all
stuffed
out,
so
that's
up
there.
I
wouldn't
mind
to
look
at
that.
I
love
it.
It's
really
useful.
I
I
played
around
with
it
yesterday
just
to
see
how
fast
I
could
like
get
to
actually
writing
code,
and
it
goes
from
like
it's
fast,
it's
nice
now
so
hopefully
that'll
make
it
easier
for
people
to
contribute
to
and
catch
like
little
mistakes
like
the
the
rails
fixed
that
francis
did
last
week,
which
was
like
I
missed
a
entry
point
file
and
like
there's
so
many
little
files,
it's
easy
to
miss
one.
H
Yeah
two
two
common
things
that
we
forget
to
do-
or
I
guess
I
forget-
to
do-
adding
stuff
to
instrumentation
all
and
adding
to
the
the
dot
toys
file
that
lists
all
the
gems
that
need
to
be
released.
G
I
I
don't
know,
but
yeah,
I
think,
just
having
like
a
general
checklist
of
things
that
need
to
be
done
before
this,
like
pr
is
ready
to
emerge,
would
be
nice.
I
just
don't
know
how
to
make
like
conditional
pr
templates
for
like.
Is
this
instrumentation,
like
here's
all
the
things
that
need
to
happen,
which
all
the
things
that
need
to
exist
before
this
can
get
merged?.
E
E
D
Great
right,
thanks,
yeah
online
okay,
thanks.