►
From YouTube: 2020-11-30 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
B
Spent
a
bit
of
the
morning
catching
up
from
last
week's
agenda
items,
I'm
also
on
a
new
setup.
I've
got
a
thunderbolt
monitor.
So
if
things
are
weird,
let
me
know
and
I'll
switch
back
towards
just
like
going
into
the
laptop
if
it's
not
working
so
much,
but
I'm
going
to
try
sharing
from
just
the
window.
E
Show
all
right
looks
like
we
got
a
good
crew,
I
think
morgan's
still
on
vacation.
If
I
recall
correctly,.
E
E
E
D
Well
want
to
kick
it
off
andrew
sure.
Are
you
happy
too
hope
everyone
had
a
good
thanksgiving
break.
B
From
at
least.
B
Celebrated
that
last
year
last
week
and
getting
back
in
swing
of
things
we
have,
let
me
see
status
of
the
p1
issues,
we're
tracking
for
ga,
spec
burndown
and,
having
a
look
at
this
earlier
this
morning,
there
wasn't
a
huge
amount
of
change.
I
think
one
additional
all
right
I'll
bring
up
the
old
window.
B
Actually,
I
think
that
was
a
p2,
but
we
have
17
in
the
to
do.
I
believe
14
of
them
are
metrics
related
three
in
progress
with
associate
prs,
but
also
one
related
to
the
protocol,
which
I
think
we're
trying
to
reserve.
B
A
report
and
53
has
have
found
resolution,
and
since
we
also
achieved
the
so
moving
on
to
the
next
topic,
since
we
also
achieved
the
trace,
spec
freeze,
milestone
with
the
freeze
of
the
trace
context,
propagation
and
the
baggage
from
the
spec
being
frozen
well,
we
can
now
concentrate
on
the
metrics
items
that
need
to
be
frozen
for
the
spec,
and
I
brought
the
topic
up
before,
and
I
promised
the
metric
sig
that
I'd
bring
the
agenda
item
to
the
maintainers
meeting
today.
B
A
I
would
I
would
say
that
we
need
probably
another
two
or
three
just
because
we
still
are
behind
on
that,
and
we
probably
can
discuss
better
in
that
sig
because
it's
more
focused
on
this.
But
it's
a
personal
opinion.
E
B
F
Or
force
anything
just
trying
to
find
the
appropriate
time
yeah.
My
my
counterpoint
for
this
is.
I
really
would
like
to
get
people
who
have
not
been
involved
in
metrics
yet
involved
in
metrics,
especially
who
are
in
the
like
traditionally
in
the
spec
meeting,
because
we're
not
just
tracing
we're
both
tracing
in
metrics
and
eventually
logs
and
it'd,
be
really
good
to
get
get
all
of
the
existing
tracing
experts.
Also
up
to
speed
on
metrics.
E
Yeah,
I
definitely
like
to
see
metrics
move
into
that
meeting.
So,
let's
make
that
happen.
A
E
E
Yeah,
maybe
we
could
merge
them
into
a
single
document
going
forwards.
Yeah.
A
Yeah,
I
think
that
is
probably
a
good
point.
Let's,
let's
try
at
least
merge
into
one
document,
even
though
it
happens
separately
or
focus
on
that.
Let's,
let's
do
that,
let's,
let's
start
with
the
with
this
at
least
merge
into
one
document,
even
though
for
for,
as
I
said
for
the
next
couple
of
weeks,
we
need
an
extra
meeting,
but
after
that
we
should
remove
it.
That's
great.
B
So
what
is
proposed?
Is
it
just
like,
literally
because
it's
on
different
days,
we
can
just
like
stitch
them
together
into
the
same
google
doc.
Would
that
be
helpful
for
facilitating
the
meeting
yeah?
So
I
can
do
that
they're
just
like
elbow.
You
know
just
busy
work
in
order
to
freaking
get
that
together
and
if
that
helps
with
at
least
being
able
to
see
in
the
same
documents,
previous
discussions
doing
a
search
and
all
that
stuff.
We.
A
So
there
is
a
calendar,
invite
I
mean
in
the
calendar,
invite
in
google
docs,
sorry
in
google
calendar
or
whatever
people
are
using.
We
need
to
update
that
entry
to
point
to
the
specs
document
and
most
likely
we
need
to
freeze
the
previous
metrics
because
we're
not
going
to
copy
it.
We
need
to
freeze
it
and
put
a
banner
that
from
this
point
all
the
discussion
happens
in
this
document.
This
is.
G
B
Okay,
that
that's
all
I
have
for
that
agenda
item,
I'm
happy
to
keep
sharing
and
as
before,
but
if
anyone
else
wants
to
take
control
in
order
to
more
easily
communicate.
Why
not?
Just
let
me
know
and
I'll
really
relinquish
the
share,
but
we
can
move
on
if
that's
suitable.
I
I
Additionally,
at
a
top
level,
if
you're
making
an
announcement,
this
dot
net
announcement
is
more
aligned
to
the
top
level
online
announcement
as
well,
so
I've
pasted.
The
link
over
here
definitely
need
some
feedback
plus
one
understand
the
terminology
we're
using
moving
forward.
E
Yeah
funny
you
should
mention
that,
because
we're
still
in
the
process
of
trying
to
define
it
so
before
we
go
any
further,
I
just
want
to
say
very
clearly
please
under
no
circumstances
should
you
release
a
1.0,
so
I
appreciate
that
you're
checking
in
here,
but
I
do
want
to
make
it
clear
we
have
to
like
define
what
1.0
means
before
we
start
slapping
it
on
everything.
I
think
we
have
a
skewed
understanding
right
now,
because
we
haven't
done
a
great
job
of
writing
it
down.
As
you
mentioned.
I
E
Yeah
so
last
week
was
thanksgiving,
and
that
was
a
wash.
I
did
propose
this
last
monday
and
got
some
good
feedback
on
it.
So
I'm
going
to
try
to
do
another
round
on
this
and
present
it
at
the
spec
meeting
tomorrow,
since
I
wasn't
able
to
do
that
last
tuesday,
the
main
feedback-
I
think
people
didn't
like
the
term
like
long-term
support,
had
a
lot
of
baggage
associated
with
it.
Ga
didn't
need
anything
so
trying
to
basically
clean
this
up
by
saying
the
versioning
numbers
we're
using
are
used
to
define
releases.
E
So
if
you
make
a
release
of
open,
telemetry
is
defined
as
all
of
the
packages
have
the
same
version
number.
So
that's
currently
what
we're
trying
to
do,
but
if
we
do
something
like
that,
then
following
semver
becomes
difficult.
E
If
we
want
to
have
the
major
virgin
bumps
mean
anything
related
to
like
major
support
guarantees
showing
up.
So
that's
actually
the
the
trickiest
bit
here,
I
think,
is
just
trying
to
figure
out
how
we
exactly
follow
simvar
or
how
we
diverge
from
senber
in
a
way
that
makes
sense
to
people,
but
I
think
most
of
the
other
things
in
here
are
less
controversial,
but
we
do
have
to
also
define
what
our
actual
support
guarantees
are,
because
we
haven't
clearly
written
those
out.
E
There's
a
general.
You
know
feeling
that,
yes,
the
api
needs
to
be
backwards
compatible.
We
should
clarify
that
further
and
then
there's
a
question
around
support
guarantees
for
things
like
sdk
components,
for
example.
Currently
we're
presuming
it's
easy
for
end
users
to
stay
up
to
date
with
the
latest
version
of
the
sdk.
E
If
that's
not
a
valid
assumption,
then
we
have
to
think
about.
Are
we
going
to
support
multiple,
older
versions
of
the
sdk
and
back
port
patches
and
bug
fixes?
So
I.
A
Another
question
I
have
is
I'm
confident
on
the
api
that
we
can
do
a
good
job
of
of
keeping
backwards,
compatibility
and
everything
once
we
once
we
put
one
zero
and
maybe
follow
the
semantic
version,
but
on
the
semantic
conventions.
I
am
more
worried
about
this.
I'm
worried
that
semantic
conventions
will
involve
differently
and
stuff.
A
Should
one
of
the
effort
be
maybe
split
the
semantic
conventions
out
of
the
api
package,
I
know.
Initially,
it
was
a
push
to
have
that
in
the
api
package,
but
I'm
I'm
like,
should
we
just
remove
it
and
have
a
different
semantic,
versioning
or
different
schema
for
this
compared
with
with
the
api?
Anyway,
it's
just
a
proposal.
It's
just
an
idea,
but
I
I
I
feel
like
we
may
have
troubles
because
of
that.
E
E
A
And
I
think
from
what
I
saw
c
plus
plus
java
sigs.
They
they
know
about
this
problem
and
they
they
they
do
a
good
job
on
splitting
the
things
and
making
sure
they
they.
A
Keep
the
the
api
compatibility
as
well,
and
so
I
would
not
be
worried,
but
yes,
indeed,
we
should
avi
compatible
where
is
needed
because
some
of
the
languages
are
not
compiled
so,
for
example,
for
python.
I
think
you
don't
have
that
problem.
Compare
with
the
with
java,
where
you
do
have
that
problem.
So.
E
Yeah
and
go
is
in
its
own.
You
know,
state
like
what
people
will
have
to
maintains
will
have
to
be
able
to
judge
future
changes
and
understand
whether
they
break
backwards,
compatibility
or
not.
We'll
need
some
tests
around
that,
but
to
your
point
around
semantic
conventions.
E
If
those
aren't
stable,
then
we're
totally
breaking
these
same
call
sites.
So
it
seems
to
me
like
those
have
to
be
just
as
stable,
which
simply
means
legacy
support
right
like
if
we
totally
change
our
schema
later.
If
we're
like
you
know
what
dots
were
a
bad
idea
for
separators,
this
elastic
schema
looks
great
we're
gonna
just
do
this
differently.
E
J
At
play
here
with
the
api,
at
least
you
get
some
compiler
help
to
tell
you
that
you
are
braking
or
not
breaking
something.
When
you
make
changes
with
semantic
conventions,
you
you
don't
get
any
compiler,
usually
right
so
validating
that
whatever
changes
you
make
are
backwards
compatible
requires
a
different
approach
for
semantic
prevention.
You
may
need
to
do
it
differently
compared
to
the
changes
to
the
sdks
or
apis.
E
I
I
really
don't
think
well
two
things,
one
bogdan
it
wouldn't
matter
if
it
was
in
a
separate
package
or
not
if
all
the
packages
have
diversion
together
in
order
for
us
to
keep
track
of
like
what
an
open
telemetry
release
is,
and
it
seems
like
that's
a
good
quality
for
our
end
users.
For
clarity.
A
E
Well,
I
think
that's
that's
actually
the
core
question
of
like
if
we
want
to
keep
all
of
these
packages.
Api
semantic
conventions
sdks,
like
the
whole.
Everything
in
core
saying
like
this
is
release
point
14
of
open,
telemetry
js.
So
all
of
the
packages
have
point
14.0
and
then
0.14.1.
E
If
we
do
something
like
that,
then
strictly
following
senfair
starts
to
become
tricky.
E
For
this
very
reason,
right
like
either
it'll,
be
like
breaking
change
everywhere,
all
the
time
or
some
things
that
might
count
as
a
breaking
change
against
and
say
an
sdk
component
wouldn't
trigger
a
major
virgin
increment,
and
so
we
just
have
to
decide
what
which
of
those
approaches
we
want
to
go
with.
E
E
E
But
you
can't
do
it
with
just
the
version
number
unless
we
end
up
with
version
skew
across
all
the
same
packages,
all
the
packages
in
a
coherent
release.
A
The
reason
why
I'm
not
following
your
argument
is,
if
you
have
in
in
one
package,
if
you
have
something
that
breaks
api,
for
example
in
java,
like
the
binary
compatibility,
then
it
simply
cannot
load
the
package
or
cannot
run
the
pac
with
that
package.
So,
even
though
you
you
or
somebody
else,
a
third-party
library
uses
a
part
of
the
the
api
artifact
that
is
not
backwards
compatible.
The
entire
app
will
crash.
A
E
Yeah
I
mean
I
I'm
just
that
just
seems
like
a
smell
to
me,
though
I
mean
I
hear
you're
saying
like
it
would
be.
The
whole
point
of
carving
out
the
api
package
from
everything
else
is
to
be
able
to
watch
it
like
a
hawk
and
be
able
to
to
have
like
just
reduce
the
surface
area
of
what
you
know
requires
that
kind
of
guarantees
and,
at
the
same
time
reduce
the
number
of
dependencies
that
might
get
pulled
in
by
that
stuff.
E
But
it
seems,
like
the
semantic
conventions
fall
in
that
same
category
of
if
you,
if
you
eliminate
them
or
change
their
meaning
or
change.
What
keys
and
values
they
produce.
E
You're
gonna
screw
somebody
up
who's,
who's
in
production
and
you're,
going
to
create
a
situation
where
all
of
the
instrumentation
is
going
to
have
to
get
okay
or
we
have
to
continue
to
just
you
know,
support
the
old
things
and
just
be
a
creative
right
like
we
just
come
up
with
new
conventions
and
version
the
conventions
rather
than
touch
the
old
stuff.
The
old
stuff's
just
treated
as
immutable.
E
A
I
I'm
I'm
confused
about.
What's
your
point,
my
point
was
okay,
so
I
think
you
are
mixing
two
two,
two
things
that
I
said
one
about
splitting
the
semantic
conventions
out
and
but
still
maintaining
semantic
versioning,
but
being
able
to
go
to
a
major
version,
much
faster
or
independent
of
the
epi,
which
was.
E
We
can't
go
independent,
that's
the
thing
that
I'm
saying
if
we're
saying
that
a
release
of
open
telemetry
like
you
we're
if
we
want
to
come
out
with
coherent
releases
like
this
is
release.
One
release,
two
release
three
release:
four
and
in
each
one
of
those
releases,
there's
a
variety
of
packages
right.
The
api,
sdk
packages,
semantic
convention
packages
either
all
of
those
packages
have
the
same
version
number
and
that's
the
version
of
that
release
of
open
telemetry,
which
allows
end
users
to
intuit
all
the
relationship
between
all
of
these
packages.
E
A
E
All
have
different
version
numbers
and
then
we
have
some
other
way
of
defining
a
release,
and
maybe
that's
not
a
big
deal
to
do
it.
That
way,
but
that's
I
think
that
that's
like
a
thing
we
have
to
sort
out
actually
is:
do
we
want
these
packages
to
all
increment
independently
of
each
other
or
not.
A
Does
that
make
sense
yeah,
but
you
mentioned
something
else:
you
mentioned
that
you
want
to
allow
breaking
changes
in
an
api
artifact
for
a
specific
directory
or
for
a
subset
of
that
artifact.
A
So
so
so
a
problem
of
mixing
versions.
Yes,
it's
a
problem.
We
can
fix
that
we
can
figure
out
how
to
fix
it,
but
like
five
minutes
ago,
that's
where
I
started
the
second
point
where
you
say:
okay,
if
we
release,
if
we
release
only
one
artifact
and
we
have
different
guarantees
for
different
parts
of
that
artifact,
I'm
saying
that
that's
not
possible
and
that
will
be
completely
broken
for
users.
A
E
Yeah
we're,
I
think,
we're
talking
past
each
other
a
little
bit
like
I.
I
get
that
point
I
was
just
you
were
mentioning
things
versioning
faster
and
I
was
just
bringing
up
the
point
that,
regardless
of
where
we
put
them,
the
versioning
is
going
to
be
the
same.
But
yes,
there's
different
guarantees
right,
like
a
major
version.
E
Bunk,
we
would
say
only
like
has
different
meaning
for
things
in
api
packages
and
sdk
packages
and
semantic
conventions
as
well,
and
we
could
say
semantic
conventions
are
like
the
sdk
stuff
where,
like
we
may
break
these
things,
it's
a
best
effort
to
not
break
them.
But
if
we
do
then
oops
sorry,
we
created
some
work
for
you.
I.
K
Think
that's
probably
going
to
have
to
be
on
a
language
by
language
basis,
because
some
languages
have
package
management
ecosystems
that
expect
that
senver
is
going
to
be
respected
like
in
go
if
we
were
to
have
backwards
and
compatible
changes
marked
as
a
minor
version.
Increment
things
are
going
to
break
in
a
lot
of
places,
because
some
dependency
may
depend
on
that
higher
minor
version.
E
It
may
be
the
case
that
if
we
want
to
have
them
all
have
the
same
version
number,
then
it's
going
to
be
mostly
like
major
version
increments,
and
maybe
that's
just
completely
fine
and
that's
just
what
we
should
do
because
then
we're
following
senfair
and
then
you
know
the
milestones
we
make
are
just
announcements
around
the
development
life
cycle
of
these
signals.
It
seems
like
we're
talking
about
open
telemetry
1.0
like
it's
a
big
deal,
but
it's
more
like
tracing
is
now
stable.
Metrics
is
now
stable.
Logging
is
now
stable.
E
The
you
know,
collector
control
plane
is
now
stable,
like
whatever.
Whatever
these
things
are,
when
they
get
added,
there's
like
a
coherent
set
of
functionality
that
has
a
life
cycle
and
those
I
don't
know
that
we
can
fully
capture
all
of
that,
meaning
in
a
single
version.
Number
anyways.
E
And
there's
also
this
issue
with.
I
think
that
semver
should
be
controlled
like
package
managers
should
not
just
be
grabbing
the
latest
version
of
any
open
telemetry
package
they
find
and
mixing
and
matching
right
like
when
these
things
get
hauled
in
through
a
package
manager
like
the
dependency
tree
has
to
be
defined
in
such
a
way
that
it's
exact
version
matching.
E
So
you
know
if
someone
just
happens
to
you,
don't
want
to
end
up
with
like
oh,
I
got
some
packages
from
release,
one
of
open,
telemetry
and
then
a
couple
from
release
two
of
open
telemetry,
because
those
are
in
the
process
of
getting
released
or
something
like
that.
Does
that
make
sense
like
you
want
to
make
sure
that
that
all
of
those
packages
stayed
in
lockstep
with
each
other
anyways.
E
E
C
E
Yeah,
so
it
seems
to
me
that
it's
inevitable,
when
someone
upgrades
open
telemetry
when
they
want
to
move
the
sdk
up
they're
going
to
have
to
potentially
do
some
configuration
work
right
like
all
of
these
breaking
changes.
We're
talking
about
are
things
that
are
identical,
ideally
like
centralized
in
one
part
of
bootstrapping
right.
E
So
it
shouldn't
be
a
lot
of
work
for
an
end
user
to
just
upgrade
to
the
latest
version,
especially
if
they're,
mostly
depending
on
instrumentation,
that
we're
providing
and
and
core
stuff.
Obviously,
if
they're
providing
on
third-party
stuff
there's
going
to
be
a
lag
there,
we'll
have
to
wait
for
that
third-party
stuff
to
get
updated
as
well.
A
Okay,
I
think
we
are
talking
about
different
things
and
I
think
what
you
say
is
probably
the
right
thing
to
do.
But
again
there
are,
there
are,
there
are
very
strict
requirements
for
api
artifacts
and
there
are
maybe
less
strict
requirements
for
other
things,
but
we
need
to
document
at
least
for
for
the
api,
because
that's
if
we
break
that,
if,
if
we
break
the
sdk,
somehow
I'm
less
worried
because,
as
you
said,
it's
only
one
place,
it's
only
the
final
user
that
can
do
some
small
work
to
upgrade.
A
E
So
yeah,
oh
andrew
you're,
sharing
the
screen
so
yeah.
If
you
you
look
through
here,
I
think
the
relevant
parts
is
one.
This
development
life
cycle,
I
think
that's
pretty
straightforward,
but
if
we're
going
to
define
stability
for
api
level
stuff,
it
seems
like
it's
it's
on
a
vertical
of
signal
by
signal,
I
think
that's
reasonable.
E
E
Do
we
have
version
skew
across
packages
within
a
release,
or
do
we
kind
of
deviate
from
semvair
and
have
major
version
bumps
mean
something
a
little
bit
different
from
what
are
described
in
sember,
so
that
I
think
that's
an
important
issue
that
we
should
hack
out.
I
think
it's
all
debatable.
E
That's
why
we've
been
debating
it.
So
I
think
that's
that's
like
the
core
thing
and
if
you
keep
scrolling
andrew,
the
other
thing
is
where
it
says:
stability
and
support
just
strictly
defining
what
these
guarantees
are
right
because,
as
you
mentioned,
we
have
stricter
guarantees
for
the
api
and
we
have
some
other
expectations
around
the
sdk
stuff
for
api.
It's
more
about
interface,
stability
and
compilation,
compatibility
for
the
sdk,
it's
about
our
commitment
to
bug,
fixes
and
security
patches.
E
E
So
I
think
it
really
comes
down
to
that
like
what
are
the
specific
support,
guarantees
that
we
want
to
offer,
and
how
are
we
versioning
this
thing
to
communicate
that
clearly
as
clear
as
we
can
to
people.
E
I
was
two
reasons
one.
If
you
come
up
with
just
a
regular
schema
of
saying
when
a
signal
becomes
stable,
you
do
a
major
version
bump
tracing's
becoming
stable
before
metrics.
So
if
we
want
to
like
by
end
of
year,
have
feel
like
we
have
tracing
in
the
bag.
From
the
perspective
of
like
we
feel
like
the
spec
for
tracing
could
be
1.0
and
we've
got
things
like
net
here
hot
to
trot
and
get
that
implemented
and
go
out
the
door.
E
A
A
So
let
me
let
me
explain:
first,
if
you
still
have
in
that
1.0
artifact
the
metrics
part
which
break
then
you
don't
follow
semantic
conversions,
so
so
so
so,
in
order
for
you
to
achieve
this,
you
have
to
split
the
first
parts
that
you
want
to
put
into
1.0
into
a
specific
artifact
called
api
and
the
rest
of
them
called
experimental
api
or
whatever
a
different
artifact
and
then
for
different
packages.
E
Depending
on
like
your
language
right,
but
the
metrics
stuff,
if
like,
if
each
signal
is
going
to
be
its
own
vertical,
then
yes,
you
have
to
make
sure
the
metrics
work
doesn't
bleed.
The
experimental
work
in
metrics
doesn't
bleed
over
into
the
stable
packages
and
tracing,
and
likewise,
when
we
add
a
better
logging
interface
in
the
future,
it'll
be
the
same
deal.
We
have
to
do
that
without
bleeding
over
into
the
the
tracing
packages
and
risking
that
okay.
A
But
but
step
back
a
bit,
so
if
you
do
that,
once
metrics
becomes
stable,
you
don't
need
a
new
version
because,
because
if
you
release
1.1,
which
is
a
major
sorry
whatever
is
called
the
first
is
major.
The
second
is
minor:
if
you
do
a
minor,
you
can
put
the
metrics
api
there
yeah.
Why
do
you
need
to
do
2.0,
2.0.
E
Would
be
when
metrics
becomes
stable
so
in
this
scheme
here
I
know
energy
wouldn't
mind
scrolling
up
to
that.
E
My
proposed
solution
that
deviates
from
semver
is
to
say
the
major
version
bump
happens
when
a
signal
becomes
stable,
so
something
has
become
stable,
that
that
would
be
a
major
virgin
bump
if
we
did
break
one
of
our
guarantees
to
an
existing
stable
thing
for
some
freaking
reason,
we're
like
oh
horror,
behind
horrors
we
had
to
do
it.
E
That
would
also
be
a
major
virgin
bump
and
it
would
be
sad
but
a
major
version
bump
like
if,
if
we
did
2.0
to
announce
that
metrics
was
now
stable,
that
wouldn't
mean
oh,
we
also
are
allowed
to
now
go
break
tracing
because
we
said
this
is
a
2.0
like
we
wouldn't
have
that
kind
of
meeting
with
our
major
version.
A
But
why?
Why
is
this
required
2.0
by
the
way
for
goal
it's
going
to
be
horrible,
because
for
goal
a
2.0
means
means
you
have
to
put
v2
into
the
packet,
which
means
which
means
none
of
the
instrumentation
with
v1
will
work
anymore.
A
So
so
I'm
still
not
sure.
Why
do
we
want
to
call
it
the
two
when
metrics
are
ready,
so
for
me
that
will
be
1.1
or
whatever
1.3
and
we
bring
metrics
into
the
into
the
main
artifact.
So
so,
if,
if
you
really
want
to
start
calling
1.0,
what
you
need
to
do
is
the
the
package
or
artifact
that
right
now
is
going
to
be
named.
A
A
Yeah
but
but
that's
fine,
it's
already
experimental,
it's
moving.
It's
it's
breaking
and
also
you
can
make
it
you
can
make
it
to
not
be
breakable
except
you
need
to
import
a
different
pack.
So
so
you
can.
You
can
make
a
trick
that
when
it's
shipped
it's
shipped
in
a
different
package,
but
you
don't
change
the
the
the
the
the
namespace.
A
So
essentially
it
becomes
only
a
an
import.
Sorry,
a
dependency
change.
You
you
can
do
a
trick
to
become
a
dependency
change
only.
J
H
I
I
think
what
we
can
do
with
this.
We
release
1.0
with
tracing
only
we
don't
release
matrix
either
we
remove
that
or
move
that
to
a
different
package,
or
we
put
that
under
a
very
specific
name,
space
called
experimental
or
future,
and
then
after
the
1.0,
we
quickly
release,
for
example,
1.1,
alpha
or
beta
and
add
back
the
metrics
api
for
people
to
use,
and
we
polish
that
until
metrics
become
stable,
then
we
marked
it
as
1.1
stable
release.
A
I'm
I'm
I'm
very
confused
of
what
you're
trying
to
achieve.
Maybe
maybe
maybe
this
is
something
that
we
need
to
document
here
is
the
goals
I
mean
you
are
proposing
a
solution,
but
we
haven't.
We
haven't
clarified
on
the
goals.
That's
that's
my
that's
my
part
that
I
I
mean.
E
Totally
agree
we're,
I
think,
we've
we've
been
a
little
fuzzy
on
these
things
up
until
now,
and
I
think,
as
we
get
into
like
the
details
of
it,
yeah
stuff
is
coming
out
where
it's
like.
Actually,
we
have
to
be
kind
of
thoughtful
about
this
stuff,
and
it
may
be
the
case
that,
especially
around
the
api
packages,
we
may
look
in
certain
languages
at
how
it's
laid
out
with
metrics
and
tracing
and
other
things
and
realize
ooh
yeah.
E
This
is
gonna,
make
compatibility
tricky,
and
I
just
I'm
being
generic
about
that,
because
I
think
that
just
happens
to
be
how
it
maybe
got
laid
out
in
a
particular
language.
So
yeah.
We
absolutely
have
to
get
this
stuff
thought
through
and
then
in
each
language.
Looked
at
that
language
before
as
part
of
it,
1.0
and
being
like.
Now,
when
we
continue
to
change
this
other
stuff.
Is
this
going
to
be
a
mess.
A
Yeah,
another
approach,
maybe
simpler,
is
to
have
one
package:
slash,
artifact,
slash,
release,
unit
per
directory
or
per
signal
one
one,
four
contacts,
one
for
baggage,
one
for
trace,
one
for
metrics
and
one
for
logs
in
the
future.
If
we
have
that,
we
can
definitely
do
that
and
we
we
can
even
screw
a
bit
the
the
semantic
versioning
in
a
way
that
I
think
google
google
does
this.
A
So
google
client
libraries.
They
have
this
approach
where
they
have
a
0.17
release
for
for
something
that
is
not
stable
and
when
it
becomes
stable
that
will
be
released
as
1.18,
even
though
so
they
they
screw
a
bit
the
the
semantic
version
in
here,
because
they
don't
start
from
one
zero
because
they
want
to
keep
the
minor
in
sync.
So
it's
just
upgrading
the
the
from
zero
to
one.
They
do
this
trick
so
that
people
can
don't
get
confused,
that
they
do
this
kind
of
trick.
E
So
we're
coming
up
on
on
like
the
last
10
minutes
and
I
kind
of
want
to
make
a
request,
which
is,
I
think
these
are
good
ideas,
I'm
going
to
continue
to
try
to
hash
out
a
proposal
while
getting
feedback,
but
I
would
love
help
making
these
proposals
especially
around
how
we're
going
to
juggle
version
numbers
and
the
different
level
of
stability
between
the
different
signals.
So
you
have
an
idea
bogged
in.
I
would
love
to
see
that
written
down.
You
know
with
your
copious
free
time.
E
I
Also,
I
would
like
to
have
a
timeline
on
this
like
if
we
could
time
block
the
time
boxes
to
let's
say
wednesday
or
friday,
whatever
seems
comfortable
to
everyone
over
here,
that'd
be
amazing,
because
I
do
want
to
get
the
announcement
out
soon
enough.
E
E
Let's,
like
I,
it
would
be
great
if
we
could.
I
I
will
go
through
I'll,
try
to
make
an
updated
version
of
this
and
go
through
it
again
tomorrow
in
the
spec
meeting.
E
But
yes,
if
we
could
get
proposals
in
by
like
wednesday,
if
people
are
thinking
about
writing
a
thing
and
then
by
friday,
I
can
turn
this
into
an
otep
and
push
it
forward
from
there,
which
will
move
the
discussion
to
github
and
then,
if
we
can
stay
on
top
of
it,
maybe
the
week
after
next
right,
like
not
this
week,
maybe
end
of
next
week,
we'd
be
able
to
to
have
this
resolved
seems
like
a
couple.
More
meetings
may.
I
Well,
I
think
the
timeline
we
put
in
earlier
was
30th,
which
was
today
so
we
we're
we're
going
past
the
timeline
anyways.
That's
why
I'd
been
pushing
for
the
announcement
two
weeks
earlier,
so
I
I'm.
I
think
what
I
want
to
get
is
consensus
rather
than
making
an
one-off
announcement
and
pulling
it
back.
So
I'm,
okay
with
you
know,
taking
a
week
or
week
and
a
half
to
you,
know
polish
this
out,
rather
than
making
the
announcement
and
pushing
for
it.
So
we've
already
blown
past
the
38
days.
D
A
Ted,
would
you
mind
at
your
document
spending
a
bit
of
time
to
document
exactly
what
you
try
to
achieve
and
and
goals
that
we,
the
the
proposed
schema,
has
to
so
in
order
to
validate
the
proposed
schema?
We
need
to
have
some
kind
of
rules
to
check.
Is
this
possible?
Is
that
possible,
or
something
like
that?
Can
we
have
that
or
I
think
that's
that's
a
great
idea.
E
I
will
get
that
added
in
there.
It's
just
the
explanation
of
goals
claire,
I
think
there's
some
of
them
are
in
there,
but
I'll
try
to
clarify
them.
I
Okay,
yep
so
ted.
Can
we
set
a
target
target
date
for
11th
december?
I
I
don't
think
after
that
you
know
there'll
be
any
any
sort
of
attention
that
we
can
get
because
everyone's
going
to
be
off
on
vacation.
So
I
think
11th
is
the
last
call
and
then
I
can
publish
the
announcement
out
in
11th
if
everyone
agrees
to
that.
L
I
I
Yeah,
so
I
think
that's
what
we're
talking
about
and
in
terms
of
stability,
how
do
we
define
stability
if
metrics
is
not
stable?
Is
part
of
the
conversation
that
we
were
having
over
here
is
1.0,
actually
long-term,
supportability
stability
or
not,
is
what
I
want
to
get
consensus
on,
so
that
I
can
edit
the
title
accordingly.
E
Yeah
but
but
to
be
clear,
it's
not
just
we
make
an
agreement
and
say:
go
we
have
to
get
this
agreed.
We
have
to
actually
then
version
the
spec
right
like
check.
Spec
has
to
get
version
first,
and
then
you
can
release
a
dotnet
that
that
is
a
1.0,
and
that
seems
like
a
tall
order
to
get
all
of
that
okayed
and
through
by
next
friday,.
A
E
L
A
I'm
sorry
yeah,
I
was
trying
to
tell
you.
Can
you
point
that
dog
that
question
in
the
document?
I
I
heard
you
and
I
I
agree
with
you,
but
I
think
people
are
not
hearing
you
so
maybe
maybe
put
the
question
in
the
document
as
well,
because
it's
very
important
to
be
documented
in
that
document.
As
a
comment
you
can
put
that.
L
A
E
I
got
you
the
thumbs
up,
though
yeah
make
sense.
Please
follow
up
yeah.
I
I
would
definitely
appreciate
help
on
all
of
this,
and
I
want
to
make
sure
I
get
get
everyone's
insights
into
this
thing,
because
it's
a
big
deal.
We
like
everything.
We
should
have
done
it
earlier,
but
we
got
to
do
it
now
so
yeah
tyler,
I
would
love
feedback
or
if
you
have
any
ideas,
you
wanna
add
stuff
to
that
doc
or
make
a
counter
proposal.
Please
do.
L
Yeah
sorry,
it
was
like
20
things
running
through.
In
that
conversation
I
wanted
to
jump
in,
but
you
guys
were
hitting
a
lot
of
them
yeah,
I'm
really
interested
in
kind
of
reviewing
from
the
go
perspective.
Bogdan
pointed
out
a
lot
of
things,
and
I
want
to
make
sure
that
that's
good,
I'm
really
looking
forward
to
seeing
kind
of
your
design
goals
on
the
version
inc.
I
think
that
might
help
clarify
some
of
the
things
that
we
can
try
to
achieve
and
so
yeah.
L
E
Okay,
great
adding
a
note
in
here
about
this
yeah,
so
I'm
gonna
try
to
do
another
pass-through
today,
we'll
bring
it
up
again
at
the
meeting
tomorrow
and
then
we'll
go
have
to
go
asynchronous
after
that.
So.
A
Talk
to
you
all,
then
another
option
by
the
way
ted
may
be
to
create
a
pr
in
the
specs,
with
the
link
to
the
document.
So
then
peop,
you
get
more
attractions
from
people
that
follow
the
specs
repo
right.
E
A
Fine,
the
otep
has
the
problem
as
it's
harder
to
review
than
google
docs.
So
up
to
you
up
to
you,
I
don't
care.