►
From YouTube: 2020-12-04 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
So
I
got
this
thing
wrangled
into
an
otep.
B
B
If
there
are
other
things
like
that
we
can
put
in
if
there
are
other
processes
that
seem
confusing,
and
we
can
just
lay
them
out
like
that.
I
think
I'm
down
to
to
do
more.
That
was
the
one
that
that
seemed
the
most
simple
but
sounded
confusing
when
he
wrote
out
with
words.
B
B
I
know
everyone's
gonna
be
pissed
when
I
start
rolling
these
out.
They're
gonna
be
like
where
the
were
you,
but
I
was
busy.
That's
where
I
was
now
that
we're
we're
stabilizing
and
are
moving
into
like.
Let's
explain
this
to
other
people.
Phase
yeah,
like
johnny
infographics,
just
everywhere
totally.
D
B
Okay,
let
me
see
so
here's
here's
a
link
to
the
o
tab,
doc.
B
But
the
content's
not
not
super
different.
I
tried
to
clarify
things
more,
but
I
it's
not
like.
B
I
came
up
with
new
ideas
since
we
last
talked
so
I
suppose
I'm
trying
to
think
what
would
be
the
best
way
to
to
go
forwards
at
this
point-
and
I
think
my
first
question
is:
do
people
on
this
call
have
have
open
questions
that
that
they
want
answered
and
the
other
both
in
general
and
two
do
people
have
questions
and
concerns
about
their
language
in
particular,
because
I
think
we
have
to
get
into
language
specifics
and
get
those
added
to
this
thing.
B
E
Have
a
question
which
may
be
specific
to
my
language,
or
maybe
general,
I'm
not
sure
great,
so
in
your
otep
here
it
says
that
everything
will
be
versioned
together
in
lockstep,
which
I
completely
agree
with.
I
assume
this
means
the
api
and
the
sdk
share.
The
same
version
number
right.
B
E
E
That's
what
we're
already
doing
in
javascript
too,
so
that
makes
sense.
The
question
that
I
have
is
with
the
metrics
package.
Specifically.
B
That
this
is
this
is
the
thing
I
think
there's
been
two
suggestions
here,
and
I
think
this
may
be
language
specific,
because
I've
heard
from
tyler.
B
You
know
that
in
go
it's
kind
of
problematic,
maybe
to
have
these
experimental
packages
at
higher
than
the
xero.x
branch,
but
on
the
flip
side,
in
places
like
java,
where
you
have
all
this
stuff
in
one
repo,
it's
a
huge
pain
in
the
butt
to
give
those
things
different
version
numbers,
so
that
sounded
like
a
place
where
it
was
maybe
a
little
language
specific
which
which
option
created
more
trouble.
B
But
as
far
as
communicating
this
to
people,
I
think
there's
two
things
we
need
to
do.
One
is
communicate
it
clearly
in
the
docs.
B
This
is
how
node
and
other
things
where
there's
experimental,
stuff
sprinkled
in
with
everything
else.
You
click
just
make
it
super
clear
in
those
docs,
it's
experimental.
The
other
thing
you
do
is
because
stable
packages
can't
rely
on
this
thing.
It
seems
like
most
languages
are
providing
convenience
now,
including
some
kind
of
global
api.
B
We
haven't
written
this
into
the
spec,
but
you
know
it
seems
like
it's
convenient
to
have
some
package.
You
pull
in.
That's
just
got,
got
all
the
stuff
in
it,
so
you're
not
digging
around
a
bunch
of
sub
packages
and
that
thing
can't
pull
in
an
experimental
package,
because
that
would
be
a
stable
package
pulling
in
something
experimental
and
then
people
using
that
global
api
wouldn't
have
any
kind
of
compatibility
guarantees.
B
So
it
seems
like
that
was
part
of
what
that
infographic
was
trying
to
show
is
that
when
something's
experimental,
you
have
to
grab
it
directly
and
maybe
if,
as
time
goes
on,
we
move
to
a
pattern
where
end
users
are
generally
grabbing
like
a
higher
level.
B
Api
object
that
just
bundles
everything
up
that
thing
just
wouldn't
have
the
experimental
stuff
on
it.
So
that
would
be
a
way
to
just
keep
casual
users
from
accidentally
stumbling
into
it.
That's
all
I've
got
on
that
subject
so
far.
I
don't
know
if
that's
good
enough,
but
we
should
probably
write
that
down.
E
F
So
let
me,
let
me
tell
you
a
story
from
scala
that
josh
not
josh
from
lystep
another
josh
from
from
google
told
me
they
they,
they
tried
to
do
something
similar.
They
tried
they,
they
had
a
scala,
very
stable
package
with
a
bunch
of
scala
apis
and
they
added
what
they
wanted
to
be
an
experimental
api
and
that
experimental
api
was
marked
differently
with
text
with
even
an
annotation
and
stuff
like
that.
That
is
experimental.
F
F
E
Yeah,
so
as
a
potential
solution
to
that,
would
you
prefer
that
we
really
that
we
split
our
api
packages
into
api
baggage
api
context,
api
trace?
Or
would
you
prefer
that
we
have
the
api
package
we
already
have,
which
only
contains
stable
components
and
then
maybe
api
experimental,
which
contains
metrics
and
logs
and
whatever.
F
So
now
now
this
question
depends
on
the
end
goal,
so
both
of
them
are
solving
my
concern,
my
personal
concern
about
having
a
stable
package
that
contains
an
experimental
part,
but
now,
if
in
six
months,
let's
assume
metrics
become
stable,
do
you
want
to
be
with
one
artifact
or
do
you
want
to
be
with
four
artifacts,
because
both
both
solutions
that
you
proposed
are
valid,
but
it's
it's
a
matter
of.
Where
do
you
want
to
be
in
six
months?
F
F
Okay,
so
I
would
say
this
is
completely
dependent
on
the
language
and,
for
example,
it
depends
on
the
fact
that
are
you
able
in
javascript
to
create
an
api
dash
all,
for
example,
if
you
split
them
in
four
different
packages
right
now,
are
you
gonna
be
able
to
create
a
fake
umbrella
package
that
depends
on
all
these
four
and
user
can
include
only
that
all
ping?
B
So
I
think
that
works.
The
one
thing
I
want
to
flag
here
is
is
move.
That's
that's
the
other
thing.
I
have
not
work
in
the
past,
so
one
so
you
could
see
this,
for
example,
with
standardizing
headers
right
where
people
are
like
this
is
experimental,
so
we'll
start
it
with
x-header
name
and
then
you'll
know
it's
experimental
and
then,
when
it
becomes
stable,
we'll
drop
the
x
and
that,
like
never
worked,
everyone
took
a
dependency
on
the
experimental
thing
and
they
ended
up
having
to
support
that
anyways.
B
So
I'm
not
sold
on
the
idea
that
moving
the
packages
around
will
prevent
people
from
grabbing
them,
and
I
do
think
if
you
move
them
in
a
way
where,
right
as
the
package
becomes
stable,
right,
you're
like
okay,
this
is
like
our
final
release.
We
believe
this
is
finally
done.
You've
built
up
beta
testers
and
users
of
that
experimental
thing,
and
then
you
move
it.
Then
you
suddenly
break
everyone
right
at
the
moment
before
stability.
So
it's
like
you're
heading
towards
stability
and
then
there's
this
like
gap
that
happens
right
there.
Well.
D
Let
me
comment
on
that
because
in
fact
we
would
have
the
metrics,
let's
say
inversion.
It
can
be
version,
one
doesn't
matter,
but
it
has
also
the
api.
So
it
means
once
we
upgrade
to
two.
It
will
be
completely
different.
So
in
fact
the
version
two
will
have
the
api
of
the
metrics
in
the
api
package
and
the
new
metric.
So
in
you,
you
can't
use
like
matrix
one
with
the
api
too
and
the
opposite.
D
So
in
fact,
even
if
people
use
like
experimental
metrics,
they
shouldn't
have
this
problem,
in
fact,
because
this
all
should
be
like
as
long
as
you
use
like
with
one
fine,
but
once
you
move
to
the
to
the
next
version,
I
think
then
it
shouldn't
be
really
concerned,
because
the
api
will
be
back
to
the
api
and
the
matrix
will
be
the
metrics.
So
if
people
want
to
upgrade,
they
will
have
to
follow
the
rules
anyway.
So
you
are
not
breaking
like.
Suddenly,
we
are
releasing
something
and
everybody
you
know
just
explodes
now.
B
Yeah,
I
think
the
way
we
want
to
do
it
is
just
by
not
moving
things.
You
could
have
your
experimental
api
package
like
metrics,
and
if
you
want
to
use
that
thing,
you
have
to
haul
that
in
directly-
and
hopefully
you
know
that's
experimental
and
then
there's
a
point
where
it
goes
stable
and
when
it
goes
stable,
you
can
add
it
to
the
public
api.
B
Can
that
be
done
in
such
a
way
that
I
think
in
some
languages
that
global
thing
is
just
a
reference
to
these
sub
apis
right
it
just
it's
just
a
facade,
and
so
I
was
kind
of
hoping
that
approach
would
work
so
that
you
now
have
the
stable
thing
add
a
reference
to
extend
its
facade
to
cover
this
sub
package,
but
the
sub
package
continues
to
work,
so
that
would
be
my
hope
right.
B
Does
that
make
sense?
This
is
what
I
was
trying
to
draw
so
here.
Let
me
pull
this
up,
just
real,
quick
right.
B
So
the
idea
is,
you've
got
metrics
here,
it's
experimental,
you
have
these
other
apis
and
then
these
things
are
sitting
in
some
kind
of
global
api
container.
That's
either
a
facade
or
maybe
they're,
just
since
they're,
the
ogs
they're,
all
bundled
in
there
already,
but
the
experimental
stuff
is
not
accessible
through
that
when
it
becomes
stable,
it
just
becomes
stable
in
place
and
then,
whatever
global
api
or
facade
you're,
giving
to
your
stable
users
gets
extended
to
to
add
that
to
it.
So.
D
This
is
exactly
what
I'm
trying
to
tell
you
that,
because
currently
in
the
global
api,
we
have
the
metrics
also,
so
we
have
like
interfaces
in
the
global
api
of
the
metrics
and
we
have
the
package
which
uses
that.
So
I
want
to
just
move
the
all
the
interfaces
from
the
metrics
from
the
global
api
and
include
them
to
the
metrics,
and
we
will
keep
them
as
long
as
we
finally
say.
Okay,
this
is
stable.
Then
we
move
back
to
the
right
yeah.
D
D
This
problem,
in
fact,
so
whenever
you
use
itemetric
z102,
there
shouldn't
be
any
yeah.
I.
E
Think
you
guys
are
talking
across
each
other
here.
So
ted
I
think,
is
suggesting
that
we
have
a
separate
metrics
api
package
and
bart
is
suggesting.
We
move
the
metrics
api
into
the
metrics
sdk
package.
B
Yeah,
but
also
to
to
bart's
point
in
some
languages,
because
we're
kind
of
late
to
this
realization
that
we
may
want
that
tracing
and
metrics
are
going
to
go
stable,
potentially
far
enough
apart,
we
may
want
to
do
a.
We
want
we're
looking
at
wanting
to
do
a
stable
release
of
just
tracing
for
someone.
We
haven't
been
making
that
assumption.
B
So
in
some
languages
yeah,
the
metric
stuff
is
probably
already
entangled
with
tracing
and
things,
and
this
may
cause
in
those
languages
to
have
to
break
the
existing
api
right
like
if
you've
already
got
metrics
bundled
up
in
the
global
api,
and
now
you
need
to
take
it
out
of
that,
so
that
the
global
api
can
become
stable.
B
Then,
obviously,
that's
going
to
break
existing
beta
users
of
metrics
right,
yes,
and
we
are
in
that
position
yeah,
I
think
a
number
of
languages
would
be
honestly
it's
the
kind
of
thing
where
it
seems
like
metrics
is
close
enough.
I
kind
of
wish
we
could
stick
to
our
original
plan
and
just
1.0
after
metrics
is
there
but
we're
getting
a
huge
amount
of
pressure
to
release
tracing
and
we
do
have
tracing
stable.
It
seems
in
a
number
of
languages
right.
B
The
spec
is
stable,
the
the
language
apis
are
stabilizing,
so
I
think
it's
just
a
question
of
which
pain.
Do
we
want
to
feel
the
the
pain
of
having
to
move
metrics
out
of
the
api
and
then
move
it
back
in
in
a
couple
of
months
or
the
pain
of
trying
to
explain
to
to
users
that
it's
okay
to
rely
on
the
the
tracing
stuff,
but
we're
still
gonna
be
breaking
those
apis
in
general,
just
there.
E
Is
a
third
possible
option
for
pain?
If
you're
looking
for
options
yeah,
we
could
delay
1.0
until
metrics
is
ready.
I
don't
know
you
said
we're
getting
a
lot
of
pressure.
I
don't
know
where
the
pressure's
coming
from,
but
if
it's
external
pressure,
I
don't
feel
like
we
should
be
setting
our
deadlines
based
on
some
external,
like
aws,
wants
to
release
some
feature
and
they
need
us
to
be
stable,
and
you
know
I
don't
know
why
we
should
care
about
that.
Necessarily.
B
B
I
agree
we
shouldn't
rush
it,
but
the
thing
I'm
noting
is
like
we
we
also
may
get
if
tracing
is
actually
stable,
but
we're
telling
people
everything
is
unstable
for
another
quarter,
even
though
we've
actually
stabilized
a
portion
of
it,
then
it's
like
we're
kind
of
shooting
ourselves
in
a
foot
a
little
bit,
because
the
part
people
want
to
actually
rely
upon
is
becoming
stable
right
now.
So.
F
E
F
F
Yeah
nobody
has,
but
how?
How
are
you
gonna
add
logs,
let's
assume,
logs
or
other
things
we
we
discuss
about
logs
again,
it's
not
necessary
that
it's
gonna
happen,
but
let's
assume
logs
is
gonna,
be
one
another
vertical.
Okay
and
logs
needs
also
something
in
the
global
package.
So
how?
How
are
you
going
to
add
you?
You
don't
need
to
to
bump
to
zero
correct,
because
it's
just
adding
to
the
api,
you,
you
are
keeping
backwards
compatibility.
You
are
keeping
api
compatibility
and
everything
you
can
add
a
new
signal.
F
In
order
to
do
that,
you
you
have
to
follow
the
same
process.
You
you
have
to
develop
that
package
almost
up
to
the
stability
level
and
then
add
it
into
the
global,
because,
if
you
add
it
prematurely
and
then
you
do
one
to
1.2
with
with
the
version
of
logs
and
1.3,
with
breaking
changes.
Only
on
the
log
side,
you'll
have
the
same
problem.
Your
package
does
not
respect
api
compatibility.
E
Well,
I
I
understand
that
you
could
still
have
like
a
an
api,
experimental
package
or
whatever
all
I'm
saying
right
now
is
that
currently
we
have
languages
that
have
an
api
package
with
metrics
in
it
already
and
removing
it
as
a
pain.
None
of
them
have
lost,
so
we
could
move
forward
with
an
experimental
api
package
for
logs
pretty
easily
without
having
to
strip
it
out
of
an
existing
deck.
B
F
I
want
to
understand
this
because
I
may
be.
I
may
be
naive:
what
is
the
hard
part
to
break
this
api
into
a
different
artifact
to
to
remove
the
metrics
from
from
the
from
that
package?
E
F
B
E
B
F
And
we
we
no
longer
talk
about
moving
things.
We
I'm
I'm
trying
to
to
understand
these,
so
so
daniel.
My
my
my
honest
opinion
on
this
is
as
long
as
he's
not
stable.
That
package
doesn't
matter
if
we
extract
it
in
a
separate
package
or
do
anything
or
just
simply
break
one
of
the
methods
in
that
package.
F
B
Okay,
if
this
is
also
language
by
language
right,
it
may
be
the
case
that
java
and
net
want
to
go
like
meet
meet
in
the
middle
with
their
community,
and
maybe
it's
worth
it
to
have
some
short-term
pain
there
to
remove
metrics
and
put
it
back
later.
B
F
Yeah,
that's
another
approach
and
I
think
it
should
be
okay
for
languages
to
not
do
this
experiment
to
to
release
stable
that
part.
Honestly,
I
think
you
will
get
a
lot
of
pressure.
If
you
don't
do
it
from
the
community
and
they
will
say,
oh
look
at
go
in
java.
They
they
did
why
the
heck
javascript
is
not
doing
it,
but
yeah
it's
an
option.
I'm
just
saying
that
I
don't
think
I
would
expect
these
to
happen
in
c,
plus,
plus
or
languages
that
are
behind.
E
F
F
Exactly
exactly
you
will
have
entirely
separate
packages
for
sdk
as
well,
but
so
so
now
you
don't
even
need
an
api
that
all
because
if
you
depend
on
global
it's
equivalent
on
depending
on
all
right,
so
that's
why
I
said
I
prefer
this
having
like
five
packages
in
1.2.
F
With
this.
With
this
structure,
I
will
try
to
give
a
shot
in
java.
I
will
talk
to
john
and
give
a
shot
in
java
and
see
how
hard
it
is
when
it
comes
to
versions.
F
I
think,
when
it's
becoming
green,
for
example,
metrics
metrics
is
orange
in
the
previous
step,
I
would
prefer,
if
possible,
to
have
a
version
starting
with
zero
can
be
called
zero
point
whatever
number
and
then
and
then,
when
it
becomes
green,
to
inherit
the
same
version,
so
here
in
the
in
the
one
two
all
of
them
will
have
the
version.
One
two
so
metrics
will
skip
the
one
zero
and
will
become
directly
one
two
when
they
are
green.
So
then,
then,
when
they
are
green,
they
have
all
the
same
versions.
F
B
F
E
Yeah,
it's
it's
difficult
for
javascript,
just
from
a
tooling
perspective
that
the
tooling
we
use
assumes
that
all
the
versions
are
the
same,
but
then
also
if
you
have
in
javascript
a
a
dependency
which
has
a
sub
dependency
that
uses
a
different
version
in
your
node
modules,
directly
directory,
it
will
download
them
twice
and
store
them
twice
and
they
actually,
you
then
end
up
with
two
instances
of
a
global
package
which
is
not
desirable
at
all,
which
is
very
difficult
to.
E
D
That's
not,
but
this
is
only
happening
sorry,
but
this
is
only
happening
if
you
want
to
use
the
same
package
with
a
different
versioning.
C
Yeah,
can
I
can
I
jump
in
really
quick.
I
I
apologize.
I'm
gonna
have
to
cut
this.
I
have
to
leave
like
in
technically
one
minute,
so
I
just
wanted
to
ask
some
questions
because
I
did
want
to
get
some
clarification
on
some
things:
the
specification,
if
it
has
a
version
bump.
How
is
that
going
to
get
tracked
in
the
packages
once
they
go
1-0?
Is
that
also
going
to
be
a
one
like?
Are
they
not
going
to
be
in
lockstep?
At
that
point?
No!
No!
No!
C
I
think
I
think
it's
much
easier.
So
so
we
will
have
a
main
version
plenty
of
an
answer.
Sorry,
I'm
trying
to
make
this
kind
of
quick,
because
I
do
have
to
jump
off
then
the
other
thing
was
the
instrumentation
like
that
we
currently
have.
If
we
have
to
split
it
out,
because
you're
gonna
have
metrics
in
it,
we
essentially
have
to.
We
can
have
duplicate
interpretation
or
are
we
just
going
to
say
we
don't
support
any
experimental
instrumentation
in
the
main
packages
first
table
releases.
F
Well,
I
think
we're
behind
with
metrics
and
we
barely
have
some
of
the
metric
semantic
conventions.
So
I
don't
know
if
we
have
that
problem
yet
go
has
a
ton
of
instrumentation
that
has
metrics
metrics
and
traces
in
the
same
place
or
just
metric.
F
C
Good
point
I
don't
know
I
I
mean
I
will
need
to
think.
Okay,
all
right,
I'm
cool!
That
sounds
good.
I'm
going
to
task
you
with
thinking
about
again.
Okay,
sorry,
I
dominated
the
time
I
didn't
mean
no.
F
No,
I
think
I
think
both
are
valid
valid
reasons.
So
in
terms
of
syncing
with
specs,
I
would
say
if
we
end
up
with
having
all
these
api
artifacts
at
the
same
version
and
let's
say
1.2
and
even
the
sdk
equivalents
will
be
at
1.2
when
they
are,
we
can
just
have
a
only
one
simple
table
and
say:
1.2
supports
this.
Spec
version
1.3
supports
this
version
and
so
on.
F
So
it's
it's
going
to
be
very
easy
to
to
to
have
one
table
that
links
between
the
the
language
specific
version
with
the
specs
version.
B
Yeah,
there
is
another
option.
I
don't
know
how
wise
this
is,
but
just
to
point
it
out
for
the
contrib
packages
we
do
in
general
need
to
provide
some
guarantees
there
as
well,
one
of
the
guarantees
being
when
we
update
the
api.
B
You
know
when
we
release
core
like
we
simultaneously
or
shortly
thereafter.
Release
can
trip
right
like
we
can't.
B
We
don't
want
to
do
releases
where
it's
like,
hey
the
new
version's
out,
but
we're
going
to
just
trickle
out
the
instrumentation
that
supports
this,
and
so
what
I
wonder
is
if
you
do
have
experimental
apis,
but
just
in
our
contrib
packages
and
those
packages
are
kept
in
lockstep
with
you
know,
are
always
updated
so
they're
up
to
date
on
the
latest
api.
Is
it
a
problem
that
those
things
include
experimental
apis?
B
F
Yes,
remember
our
my
my
suggestion:
yes,
only
if
you
have
if
these
are
used
as
transient
dependencies,
so
so
the
the
problem
is,
if,
if
the
country
package
that
you
have
is
also
is
actually
a
helper
is
not
a
final
plugin
that
only
the
application
owner
installs,
then
you
have
this
problem
because
then,
then
another
third
party
library
can
depend
on
the
version
and
the
other
one
depends
on
the
other
version.
You
you,
you
create
a
diamond
problem
again,
so
so
you
you
create
the
fact
that
you
end
up.
F
So
as
long
as
in
the
final
application,
you
don't
end
up
with
two
versions
of
the
experimental
package.
You
are
fine
right,
but
if
there
is
a
possibility
to
do
that,
you
are
not
fine
and
the
classic
possibility
is
having
a
third
party
depend
on
version.
1.1
of
your
contrib
and
another
third
party
depend
on
version
1.2
of
your
contrib.
Then
you
have
this
problem.
B
B
B
B
F
Have
to
be
a
a
maintainer
best
judgment,
but
in
general
the
the
rule
should
be
if
this
is
used
only
by
the
final
application
owner.
You
can
still
have
that
experimental,
because
whenever
the
application
is
updated,
updates
all
the
packages
that
they
depend
to
the
same
version,
but
but
if,
if
this
can
come
as
a
transient
dependency
from
somewhere
else,
you
are
a
no-no.
B
What
do
you
think
about
that
daniel?
Does
that,
like
does
that
sound
too
risky?
I
agree.
We
have
to
figure
out
a
way
that
we
can
like
work
with
these
experiments
without
having
like
a
bunch
of
forked
instrumentation,
but.
B
E
E
B
It
just
seems
like,
if
we're
not
creating
transitive
dependencies
and
it's
frustrating
or
annoying,
to
remove
experimental
apis
from
that
instrumentation
like
you
can't
test
it,
it
just
seems
like
it
actually
wouldn't
be
a
problem
for
people
the
problems,
the
transitive
dependencies,
but
there
shouldn't
be
transitive
dependencies
on
instrumentation.
B
Only
the
final
application
should
depend
on
the
instrument
right,
but
I
agree
with
bogdan
that,
like
it's
a
slippery
slope,
I
think
it
would
be
when
you
have
these
bright
lines,
it's
easier
to
not
screw
up
and
something
like
these.
These
contrib
packages
are
okay.
These
other
contrib
packages
are
like
utils,
it's
they're,
not
okay.
To
have
this
stuff.
I
could
see
it
being
a
situation
where
someone
I
I
can
see
mistakes
being
made
or
us
not
understanding
how
people
are
consuming
things,
but
maybe
it's
okay.
G
So
I
just
want
to
point
out
that
in
practice
I
don't
think
dash
experimental
and
experimental
work
when
there's
a
great
command,
like
so
just
a
caveat,
I'm
coming
from
sorry,
I
shouldn't
turn
my
video
on
and
sorry
I'm
late
to
this
meeting,
I'm
coming
from
a
scholar
experience
where
we've
tried
to
make
a
new
language
feature
called
macros
yeah.
G
Your
microphone
breaks
a
lot.
I'm
not
here
my
internet's
really
bad
right
now.
So
I
apologize.
Is
this
better.
F
B
Yeah,
okay,
we
heard
we,
we
heard
the
scholar
tale
of
woe
earlier
and,
and
I
totally
feel
you
I
was
pointing
out
the
same
thing
about
headers
x,
dash,
headers
right
same
problem.
People
just
depend
on
them.
G
I
think
the
difference,
it's
all
about
expectation
and
need
right
like
if
somebody
absolutely
needs
this
and
feel
they're
forced
to
use
it,
because
there's
no
alternative,
they're
gonna,
take
it
and
they're
gonna
take
the
dependency
and
they
absolutely
need
it.
And
then,
when
you
break
them,
they're
going
to
be
pissed
off
and
they
might
leave
the
community
if
they
don't
want
to
accept
that
kind
of
breakage
in
the
future.
That's
the
risk
right.
G
If
we
think
it's
worth
the
risk,
we
can
set
a
good
expectation
and
find
ways
to
encourage
them
not
to
be
angry
when
this
breaks
that's
good.
But
if
there's
like
a
huge
demand
and
need
for
this
and
there's
nothing
else
out,
there
that's
stable
and
they
take
us
as
a
dependency
expecting
us
to
basically
be
stable
because
they
don't
believe
us
when
we
say
we
won't
be,
which
is
the
expectation
I've
seen
from
people
of
oh,
hey,
amazon
and
google
use
this.
They
they
won't.
E
Yeah
I
mean
we
agree
that
we
have
to
make
it
very
annoying
and
difficult
to
use
the
experimental
api
like
we
could
require
some
yeah
like
when
you
instead
of
saying
enable
experimental
features.
True,
maybe
you
say,
enable
experimental
features
in
a
version
number
and
then
every
time
you
update
it,
you
have
to
update
your
version
number
in
your
code
manually.
E
E
B
I
do
wonder
cam:
is
it
possible?
The
part
of
why
I
think
it
worked
in
places
like
node
is
because
very
very
early
on.
They
set
this
pattern
up
right,
and
so
it
was
an
expectation
that
was
baked
into
the
community
and
so
yeah.
I
think
at
the
end
of
the
day,
it
really
is
expectation
management.
If
we
can
bake
these
expectations
in
from
the
beginning.
B
G
Oh,
in
our
case,
it
was
the
expectations
of
the
community
from
java
that
was
coming
to
scala,
bringing
the
the
fact
that
chicago
didn't
change
at
all
for,
like
10
years,
did
noah
in
favor
in
the
sense
of
the
expectation
of
stability
was
like
perfect
stability.
Unchanging.
I
can
just
depend
on
this
whenever
and
it
will
never
break
behind
me,
whereas
I
think
the
node
community
is
the
opposite
of
that.
G
That
community
had
been
rapidly
kind
of
growing
and
building,
and
that
sort
of
thing,
unfortunately,
for
us
you
know
we
have
both
like
all
the
communities
right
we're
going
to
have
the
java
folk
who
might
they
should
be
less
that
way
now,
because
java
is
moving
quickly,
but
I
think
there's
still
some
that
lingering
from
what
I've
seen.
So
you
know
like
that.
G
It's
the
environment
that
you're
within
that
really
matters,
and
I
I'm
just
telling
you
things
that
I've
heard
from
people
that
have
me
nervous
and
I
think
we
need
to
account
for
that
environment,
because
I
don't
think
we
can
change
everybody's
opinion
as
much
as
we'd
like
to
try
right.
That's
just
not
something.
I've
been
successful
at.
B
G
Yeah
the
effectively
the
what
what
I
kind
of
suggest
is.
If
there's
any
way
we
can
understand
when
there's
a
demand
for
something.
So
I
think
in
this
case,
metrics
there's
a
demand
for
a
metrics
api
out
there
and
that's
why
people
are
pushing
for
stability
if
we
could
just
launch
something
we're
willing
to
keep
stable,
even
if
we
don't
consider
it
done
and
we
decide
to
migrate
forward
in
a
compatible
way.
I
think
we're
okay,
but
it's
more
like.
G
I
honestly
think
we
should
just
declare
stability
on
something
and
if
it's
a
pair
down
like
it,
only
supports
this
one
metric,
that's
fine,
but
just
to
acknowledge
that
the
community
is
kind
of
demanding
a
stable
metrics
api
from
us.
E
G
F
Josh,
that's
that's
a
good
approach
that
may
be
working.
Do
you
think
the
current
idea
that
we
have
is
completely
wrong
and
tell
me
blank
so
right
now
we
are
thinking
of
not
including
at
all
the
metrics
in
what
we
gonna
release
as
1.0
and
keep
metrics
as
a
separate
artifact
with
still
a
version
of
zero.
F
Do
you
think
that
for
like
two
three
months
and
then
move
that
to
one
point,
one
point
something
wherever
we
are
with
the
main
packages?
Do
you
think
that
is
unreasonable?
Do
you
think
that
will
cause
a
problem
or
do
you
think
it's
a
decent
trade-off.
G
Think
so
so
that
can
work
as
a
trade-off.
I'm
worried
about
keeping
the
artifacts
separate
in
all
the
languages.
I
I
believe
you've
already
had
that
discussion,
the
the
the
there's
two
things
that
you've
probably
already
talked
about-
and
I
missed
there
right.
One
is
the
perceived
velocity
of
the
project
right
and
the
second
is
the
cohesive
nature
of
open
telemetry
as
a
like
marketing
word
versus
us
fragmentizing
it
later
before.
G
If
you
read
the
description
of
open
telemetry
on
the
project
right,
it
says
that
it
is
a
unification
of
logs,
metrics
and
traces.
All
right
and
then
very
clearly
says
you
know
logs
will
come
later
cool.
I
can
kind
of
get
that,
but
now
we're
also
going
to
be
fragmenting
it
once
more
of
traces
and
metrics
coming
at
separate
times
and
my
fear
there
is
community
reaction
around
their
assumed
health
of
the
project
right.
That's
that's!
Basically,
what
we're
trading
off
of
like
you
know,
this
project
was
supposed
to
come
out
with
all
three.
G
Then
it
was
coming
out
with
two.
Then
it
got
delayed
and
now
it's
coming
out
with
one.
What
message
does
that
send
now?
It
could
be
that
we're
sending
the
right
message
of
hey,
we
paired
down
scope
and
everything's.
Fine
and
people
who
are
detractors
in
the
community
are
always
going
to
be
detractors.
You
can't
make
everyone
happy
whatever
everything's
great.
G
That
would
be
my
primary
concern
with
the
plan
to
kind
of
limit,
but
but
otherwise
you
know
getting
stuff
out
earlier,
and
if
it's
going
to
take
two
months,
no
matter
what
to
get
metrics
out
the
door,
I'm
fine
launching
something
first
and
then
launching
metrics
as
soon
as
they're
ready.
You
know,
okay,.
F
But
do
you
think,
do
you
think
if
we
have
a
different
package
for
just
for
metrics
mark
clearly
with
zero
version,
not
with
one?
Do
you
think
we
still
can
get
into
the
trap
that
you
just
mentioned,
which
is
people
start
depending
on
that
package?
Even
though
we
clearly
say
it's
a
zero
version?
It's
it's
not
stable
and
everything
do
you
think
we're
still
gonna
have
the
problem
that
you
had
in
scala
with,
with
that
experimental
thing,.
G
Yeah,
it's
it's
it.
The
problem
is
around
marketing,
blogs
and
kind
of
association
in
like
humans.
If
you
will
so,
if
you
make
a
blog
that
says
open,
telemetry's
1.0,
they
aren't
going
to
notice
the
tracing,
only
part
right
and
then
they'll
just
assume
that,
like
they
can
pull
in
everything
like
that's,
that's,
that's!
Basically
the
concern
that
you're
trying
to
fight.
If
you
make
it
very
clear
and
we're
very
clear
on
messaging,
I
think
we
could
definitely
limit
that
pretty
well.
G
You
just
have
to
make
sure
that
everybody
plays
game
right.
So
there
was
a
very
clear
you
know
tracing
his
ga
in
the
spec,
and
I
think
that
we
have
made
that
message
being
very
crisp
and
I
think
that's
actually
the
primary
thing
you
have
to
do
here,
but
the
the
problem
we
had
in
scala
too
was
the
messaging
from
the
community
itself.
So
this
is
like
people,
you
don't
control.
G
These
are
people
who
use
it,
who
then
blog
about
how
to
do
stuff
right
if
you
have
a
whole
ton
of
people
blogging
about
how
to
use
open,
telemetry,
metrics
and
opengl
entries
stable,
now
they're
going
to
link
to
the
open,
telemetry
stable
now
for
tracing
and
then
they're
going
to
have
a
blog
about
how
to
write
metrics
right.
That's
that's
more.
G
My
concern
here
is,
if
we're
not
crystal
clear
and
if
we
don't
actually
kind
of
like
correct
those
type
kinds
of
things
as
they
come,
that's
I
think
how
scala
got
into
a
bad
state
that
plus
expectations
like
previous
expectations.
G
So
again,
if
we're
crystal
clear
and
messaging
across
all
of
us
and
users,
I
think
that
can
help
mitigate
it.
But
that's
my
fear
is
that
people
glob
everything
together
when
they
think
of
open
telemetry
as
one
cohesive
component.
They
don't
even
think
of,
like
you
know,
open
telemetry
c
plus
plus,
is
not
gonna
launch
with
the
rest
of
open
telemetry.
G
F
Had
a
magic
wand
or
whatever-
and
you
have
these
two
choices-
reduce
metrics
api
as
much
as
possible.
The
things
that
we
know
for
sure
is
are
stable
and
release
that
in
1.0
versus
versus
do
the
approach
that
we
we
right
now
believe
which
is
delaying
for
two
months.
The
metrics
api,
which
one
would
you
choose.
G
Personally,
yes,
I
I've
become
a
very
different
engineer
as
I
get
older,
so
I
would
do
the
first
and
here's
why
I
don't
know
if
this
is
contentious.
I
think
that
us
providing
a
stable
api,
even
if
it
grows
as
hell,
is
more
important
right
now
than
than
us
having
a
really
really
nice
api,
and
I
think
we
can
build
a
nice
api
off
of
the
stable
api.
But
the
demand
I
see
across
the
industry
is
that
stable
api
that
you
can
rely
on
that.
A
G
That's
yeah
again,
that's
fine
like
if,
by
gross
I
mean,
if
I
have
to
do
weird,
weird
loops,
to
get
what
I
need
done
done
in
the
api.
Okay,
fine,
until
those
features
are
in
place,
the
stability
is
the
most
important
bit.
You
know.
B
Josh,
I
wonder
if
this
is
like
a
yes
and
scenario,
because
we
have
we
have
two
kinds
of
stability.
I
think
we're
looking
for.
There's
the
the
end
user,
not
wanting
their
api
broken,
and
you
know
you
have
this
natural
progression
as
as
any
kind
of
release,
whether
it's
part
of
a
larger
thing
or
on
its
own,
where
it's
like,
as
you
go
from
alpha
to
beta,
to
rc
to
1.0.
B
Your
stability
guarantees
have
to
steadily
ratchet
up
right,
and
so
we
want
to
be
able
to
do
that
with
metrics
be
able
to
like,
as
people
start
using
it,
we
do
have
to
become
more
and
more
stable
or
we'll
have
more
and
more
grumpy
users
there's
a
separate,
stricter
requirement,
which
is
that
in
languages
where
abi
compatibility
is
a
thing
and
things
of
that
nature,
that's
like
even
stricter,
and
I
think
the
people
you're
talking
about
are
not
necessarily
the
people
looking
for
that
abi
compatibility,
and
so
I
wonder
if
it's
kind
of
both
things
where
we
want
to
keep
this
stuff
separate,
so
that
we
can
start
working
on
our
abi
compatibility
guarantees.
B
G
So
I'm
wondering
if
we
just
have
to
do
both
yeah,
I
I
I
think
I
think
this
is
a
yes
end.
Yeah
yeah
I'll
give
I'll
give
an
example.
If
that
helps
like,
I
think
the
we
should
always
even
an
experimental,
take
a
big,
healthy
look
at
the
api
and
the
compatibility
of
that
api
layer,
the
sdk
itself,
if
that
breaks,
abi
and
whatever
I
think
we
can
be
more
loose
there,
but
even
for
experimental.
G
I
think
we
have
to
be
very,
very,
very
careful
at
that
api
layer
and
really
really
evaluate
if
it
shouldn't
break.
You
know
like
like.
Take
it
very
very
seriously,
I
understand
what
you're
saying
about
not
being
able
to
like
never
break
binary
compatibility.
G
I
I
think
we
can
be
pretty
clever,
so
I'd
rather
see
us
error
on
the
side
of
let's
pretend
like
we're,
never
gonna
break
it
yeah
and
then
we'll
break
it
when
we
absolutely
need
to,
as
opposed
to
we'll
break
it
like
we
we're
gonna
allow
ourselves
to
break
it.
You
know
what
I
mean
like
it's
just
a
different
mindset.
B
So
this
is
just
a
rule
for
us
and
we're
already
kind
of
in
this
mind
space
a
bit,
but
we
can
sharpen
it
up,
which
is
that
yeah,
even
if
it's
experimental
or
in
beta
we're
thinking.
This
is
something
that's
there
for
the
long
term
and
we
have
to
like
practice,
not
breaking
it
and
practice
being
circumspect
and
how
we
update
it.
We
can't
go
from
just
breaking
all
the
things
to
suddenly
stable,
so
so
we
have
to
to
to
ramp
our
way
up.
Yeah.
B
B
Yeah
yeah,
the
tracing
has
been
mostly
stable
for
a
while,
and
then
we
make
these
incremental
improvements
to
try
to
nail
the
the
last
bits
in
and
I
can
see
metrics
going
a
similar
route
where
yeah
the
basic
stuff
is
pretty
stable
or
can
become
pretty
stable,
pretty
quick
and
but
then
we
have
all
of
these
more
advanced
features
that
we
have
to
work
on,
and
so
maybe
it's
just
within
experimental
we're
also
messaging
alpha
beta,
what
not
and
for
metrics
we're
just
definitely
in
beta.
B
B
I
think
the
version
is
almost
like
a
language
dependent
thing.
I
think
the
the
the
lesson
of
the
story
is
actually
that
version
number.
I
don't
know
that
it
matters
too
much.
I
don't
think
people
what
josh
is
saying
is
people
aren't
going
to
generally
like
look
at
that
version
number
and
make
a
decision?
B
It's
all
about
the
the
messaging
we're
doing
around
this
thing.
So
if
you
can
put
these
in
a
zero
dot
version,
that's
great.
If
that's
like
super
painful
to
do.
I
don't
know
that
it
matters
personally.
B
But
but
these
are
the
big
thoughts
I
would
love
to
see
these
thoughts
transferred
to
the
otep.
I
would
also
really
encourage
pull
requests
against
my
branch,
I'm
actually
going
to
try
to
make
the
tc
collaborators
on
that
branch
as
well.
So
it's
not
just
gated
on
waiting
for
me
for
things
I
want
us
to
like,
like
feel
free
to,
to
make
proposals
against
this
otep.
I
guess
is
what
I'm
trying
to
say,
rather
than
trying
to
funnel
your
ideas,
just
through
my
writing.
So
hopefully
that's
helpful.
B
I
gotta
hop
off
the
call
now,
but
I'd
love
to
do
more
calls
in
the
future,
but
hopefully
we
can
switch
to
github
otep
process
at
this
point
so
that
we
can
be
a
little
more
public
and
have
this
stuff
recorded
properly
in
you
know
in
github,
rather
than
because
there's
a
bunch
of
other
people
who
aren't
joining
these
calls
right.
So
I
feel
like
with
the
otep
out
we
kind
of
have
to
move
this
discussion
now.
B
G
Internet
for
putting
this
together
by
the
way
yeah
absolutely
thank
you,
josh,
really,
I'm
mostly
a
talker.
Now
I'm
contributing
too.