►
From YouTube: 2020-11-23 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
C
Man
good
question:
I've
been
digging
the
honeycrisp
lately,
even
though
they're
pretty
common
they're
good
up
here.
B
You
you
chose
correctly,
that's
the
best
one.
In
my
opinion,
too,.
D
Nope,
there's
better
crimson
crisp
is
even
better
than
than
honeycrisp.
D
C
C
Good,
so
I
see
that
andrew
put
some
things
on
the
agenda
for
today,
but
I'm
not
sure
if
he's
here
at
least
he's
running
a
little
late,
and
I
know
that
morgan
is
out
on
vacation
this
week,
so
we'll
get
going
without
him,
but
we
could
probably
just
kick
it
off.
C
D
Something
got
weirded
up
with
the
meaning
notes
that
somebody
moved
the
30th
down
to
the
23rd.
C
C
Yeah,
that's
a
little
surprising
and
I
see
he's
listed
unable
to
attend,
so
I'm
gonna
share
the
meeting
notes
here.
The
main
thing
I
would
like
to
talk
about
is
a
versioning
proposal
for
open
telemetry.
This
is
something
john.
You
were
asking
for
us
to
take
a
pass
at
cleaning
up
our
language
around
ga.
What
does
any
of
that
mean?
C
What
does
the
timeline
look
like,
and
I
also
as
part
of
this
one
address
the
fact
that
we
were
originally
thinking
tracing
and
metrics
we're
going
to
ga
as
a
pair,
that's
just
to
let
the
cat
out
of
the
bag
initially,
I
think
we
could
still
do
that,
but
with
this
versioning
example
here,
if
it
turns
out,
I
would
like
to
suggest
if
it
turns
out
that
there's
going
to
be
a
gap
where
tracing
has
gone
through
its
rc
and
we
feel
like
it's
ready
for
ga
and
long-term
support
and
metrics
is
maybe
in
that
rc
stage,
but
not
there.
C
Yet
we
could
1.0
with
tracing
and
then
2.0
with
metrics,
so
just
to
warn
you
that
that's
an
option
here,
but
let
me
just
go
over
what
this
means
and
again.
This
is
just
throwing
this
out
for
people
to
get
feedback
on
so
just
covering
some
lingo
here
we
all
know
what
the
api,
the
sdks
semantic
conventions
and
contrib
mean,
but
other
people
might
not
so
defining
that
clearly
is
important
when
it
comes
to
talking
about
versioning
and
support
guarantees,
because
they
apply
differently
to
different
parts
of
this
project.
C
As
far
as
the
development
life
cycle
goes
open,
telemetry
is
broken
up
by
signals,
so
we
have
a
tracing
signal,
a
metric
signal,
a
logging
signal.
We
have
things
like
context,
propagation
that
are
fundamental
signal
that
these
other
things
are
riding
on
top
of,
and
so
the
development
life
cycle
is
signal
based.
C
Beta
means
that
it's
stabilized
to
the
point
that
we're
shifting
from
api
design
to
sdk,
building
and
productionizing
of
what
we
have.
Obviously
the
api
could
still
change,
but
it's
gonna
change
at
this
point
based
on
user
feedback.
C
After
that,
at
some
point
we
can
go
into
a
freeze.
Freeze
means
that
we're
no
longer
accepting
new
features
in
the
specification.
C
This
is
separate
from
a
spec
release
by
the
way,
so
spec
releases
follow
the
same
release
format
as
apis
do
or
any
other
package.
But
so
a
freeze
is
more
like
a
community
act,
we're
saying
it's
not
something
that
gets
written
down
as
part
of
like
a
release,
there's
no
release!
That's
the
freeze
release,
it's
just
a
social
act.
We're
saying
here
that
we're
no
longer
going
to
accept
new
features.
C
Release
candidates
can
come
out
release.
Candidates
are
expected
to
become
ga
if
no
problems
are
found.
The
only
difference
between
a
release,
candidate
and
a
ga
is
ga
comes
with
long-term
support
guarantee,
so
we're
tying
a
major
virgin
bump
the
term
ga
and
long-term
support
together
into
one
concept,
so
they're
not
separate
concepts.
C
Of
course
you
can
have
a
thaw
after
something
is
gad,
which
means
it's
possible
to
propose
features
once
again,
though
now
these
will
have
to
be
backwards
compatible
according
to
long-term
support.
Eventually,
a
signal
can
be
deprecated.
Deprecated
does
not
mean
that
we
no
longer
support
it
under
long-term
support.
C
It
just
means
it's
been
replaced
by
something
else,
and
so
you
should
use
that
something
else
and
we'll
always
go
in
the
format
of
completely
supporting
some
new
thing
for
a
long
time
and
well
simultaneously
supporting
the
old
thing
before
eventually
end
of
lifeing,
something
old.
We
don't
have
a
great
term
for
how
long
long
term
support
should
be
before
we're
allowed
to
go
from
deprecated
to
end
of
life.
C
But
I
will-
and
we
should
debate
that,
but
I
will
say
end
of
life
means
that
it's
removed
from
the
project,
so
things
are
either
kept
around
fully
under
long-term
support
or
they
are
eventually
removed.
But
there's
nothing
in
between.
C
For
versioning,
we
know
we're
doing
semver.
What
I'd
like
to
propose
here
is
that
we
tighten
up
what
the
definition
of
a
major,
minor
and
patch
version
mean.
So
a
major
version
bump
only
co
occurs
when
we
are
some
things
becomes
ga
or
something
is
end
of
life.
C
That's
it
there's,
no
other
reason
for
something
to
have
a
major
bridge
and
bump
in
open
telemetry,
at
least
as
far
as
the
spec
or
the
matching
language
releases
are
concerned,
everything
else
is
a
minor
version
bump,
so
that
would
be
backwards,
compatible
functionality
and
a
long-term
support
component
like
an
api,
any
breaking
change
in
an
sdk
component
or
non-long-term
support
component,
like
contrib
minor
version
bump
of
the
overall
release.
C
C
I
think
the
main
thing
here
we
want
to
look
at
is
things
like
pre-release
signifiers,
I'm
proposing
that
we
don't
use
anything
like
a
pre-release
signifier,
something
like
alpha
beta
or
rc,
because
it's
hard
when
these
things
are
in
mixed
mode,
where
you
have
different
signals
at
different
stages
to
slap
down
and
say
this
is
a
beta
release
of
open
telemetry.
C
So
having
that
in
the
actual
version,
numbers
seems
like
it's
open
for
confusion,
so
I'd
prefer
that
we
don't
use
those
people
think
that
there's
a
way
to
use
these,
then
okay,
but
to
me
it
seems
like
that
will
lead
to
confusion.
To
say
this
is
the
beta
release
of
the
specification.
C
C
C
But
the
overall
package
does
have
to
the
overall
release
does
have
to
follow
something
that
looks
like
these
rules.
D
D
C
Yeah
yeah,
so
that's
a
good
question.
So
the
the
way
this
scheme
ends
up
working
by
design.
If
you
just
follow
its
rules,
the
major
version
numbers
would
remain
in
lockstep,
because
the
only
time
you're
changing
a
major
version
number
is
to
ga
a
new
signal.
Essentially.
D
So
so
a
good
example
of
how
that
will
fail
to
swallow.
You
know
to
talk
through
yeah
is
language.
Xyz
releases
version
1.0,
along
with
the
1.0
version
of
the
spec,
and
then
realizes
they've
horribly,
made
a
mistake
and
they
need
to
rev
a
major
version
that
will
break
everyone's
apis
and
now
they
need
to
go
to
two.
C
Yeah
yeah,
it's
possible
that
these
things
could
get
out
of
lockstep.
I
think,
like
you
mentioned,
if
there's
some
massive
screw
up,
I
could
see
that
happening.
C
So
I
didn't
want
to
write
in
here
that,
like
it's
a
requirement
that
they
stay
in
lockstep,
but
it
seems
like
they
should,
unless,
like
you
mentioned
for
some
reason,
we
have
like
really
really
screwed
up
where
we
have
gone
all
the
way
through
a
release,
candidate
and
then
gone
out
the
door
with
something
and
only
then
discovered
that
we
need
to
make
breaking
changes.
D
But
I
think
I
think
a
less
catastrophic
example
would
be
okay.
We've
we've
released
gen
made
made
tracing
generally
available,
we're
working
hard
on
metrics
and
starting
to
work
on
logs,
and
we
realized
that
a
decision
we
made
in
building
the
tracing
apis
is
actually
making
it
impossible
to
correctly
build
the
logging
apis.
D
So
that's
that's
an
example
which
is
less
catastrophic
and
more
just
the
way
software
development
tends
to
work.
Yeah.
C
D
C
Case
we're
stuck
with
the
tracing
api.
We
don't
get
to
say
oopsies,
sorry,
guys,
we're
gonna
break
this
on
you.
What
we
can
do
is
deprecate.
It
continue
to
support.
It,
provide
a
bridge
to
a
new
api
that
we're
gonna
provide
much
like
we
did
with
open
tracing
moving
to
open
telemetry,
but
I
see
long-term
support
in
major
version
bumps
as
being
tied
together
or
at
any
rate.
We
have
to
have
a
concept
of
long-term
support
and
it
seems
weirder
if
it's
not
tied
to
some
versioning
concept.
C
C
Once
we've
told
people
it's
stable,
like
that's
like
that,
is
like
the
third
rail
of
this
project,
and
so
I
do
want
to
figure
out
what
is
what
can
we
do
to
to
to
lay
that
out
in
a
way
that's
cleanly
makes
it
clear,
but
also
like
you
say,
you
know,
explains
what
we
do
if
we,
if
we
screw
up-
and
we
do
end
up
having
to
do
it
so
if
we
did
make
a
breaking
change
to
an
existing
signal,
that
would
also
be
a
major
version
bump,
but
yeah.
C
I
I
feel
like
a
thing.
This
gets
into
is
not
going
to
something
like
a
1.0.
Rc1
kind
of
thing
like
release.
Candidates
would
be
point.
Nine
point,
ten
point
eleven.
You
wouldn't
hop
to
1.0
rc1,
because
for
that
very
reason
you
may
discover
like
in
that
release
candidate
phase
like
oops,
my
god.
This
is
totally
wrong.
We're
gonna
break
it,
and
so
then
you
would
just
do
point.
Twelve
point.
Thirteen
tell
people,
that's
release
candidate,
two
release
candidate
three
or
we're
going
back
to
beta
for
this
one.
D
Cool
next
next
question:
thank
you.
That
was
a.
I
think
it
was
an
excellent
approach.
Good
good
answer,
good
answer,
sir
you're
hired
so
next
question
next
question
is
so:
we've
released
1.0
of
tracing.
My
sdk
has
been
released.
My
api
is
there.
People
are
using
1.0
and
now
we're
adding
metrics
and
we've
we're
ready
to
say
ga
for
metrics
or
at
2.0.
Oh,
it's
2.0.
C
Yeah,
so
if
we
would,
we
would
go
to
2.0
as
a
major
version
bump
when
metrics
is
added,
because
that
would
be
a
signal
going.
Ga
and
gaining
long-term
support,
so
2.0
would
happen
once
metrics
gains
long-term
support,
whether
it's
completely
first
completely
finalized
and
spec,
and
gains
long-term
support
in
a
language
that
language
would
bump
to
2.0
and
again,
I'm
thinking
mostly
about
the
api
packages.
I
think
this
maybe
gets
a
little
squirrely
with
the
sdk
packages
or
other
things.
They
may
just
end
up
following
more
generic
semver.
C
D
So
does
that
make
sense?
I
think
my
question
was
slightly
different
and
that
was
when
we
hit
2.0
for
a
release
of
a
given
language
thing.
We
need
to
make
sure
that
we
don't.
We
aren't
also
allowing
breaking
changes
in
the
tracing
api
at
that
time,
even
though
it's
a
major
version.
C
Yeah
exactly
and
that's
getting
back
to
this
signal
development
life
cycle,
so
there's
no,
we
went
ga
and
then
you
know
break
it.
C
D
C
So
if
we
could
do
that,
that
would
seem
kind
of
nice,
but
it
seems
like
we
do
want
to
have
as
much
as
we
can
have
an
overall
release
version
number
for
the
spec
itself,
and
then
it
would
be
ideal
if
each
language
can
put
out
a
release.
That's
just
this
is
this
release
of
you
know
open
telemetry
python.
C
I
get
that
there
are
sub
packages
within
that,
but
if
it's
possible
for
that
overall
release
that
bundle
packages
to
have
a
specification
number,
it
would
follow
this
and
major
version
bumps
should
not
lead
to
a
breaking
change
in
the
existing
signal,
because
that
would
be
breaking
the
long-term
support
guarantee
for
that
signal.
So
just
shouldn't
happen.
D
I
guess
is
what
I'm
saying
according
to
this
so
okay.
I
think
that
makes
sense
next
question
and
I
hope
it's
okay,
that
I'm
probing
at
the
seams
here.
Fine
by
me,
I
mean
I
want
wanted
to
get
caught
at
yeah,
so
the
next.
G
I
mean
for
metrics
so
or
not
for
js,
so
we,
for
instance,
when
we
go
to
1.0,
we'll,
have
a
patch
a
package
named
open,
telemetry
metrics,
and
it
will
also
go
to
1.0
because
we
have
to
release
everything
at
the
same
time.
Even
if
metrics
is
not
stable,
there
will
be
a
metrics
package
with
the
1.0
signifier,
which
is
confusing
to
users
at
the
very
least.
D
Yeah
so
mike,
I
think
that's
a
good
example.
My
question
was
actually
thinking
more
about
the
sdk
and
breaking
changes
in
the
sdk,
because
we've
added
more
capabilities
or
we've
done
some
refactoring
in
the
sdk
configuration
story,
etc.
You
breaking
changes
in
the
sdk
need
major
versions,
or
this
is
where
things
start
to
get.
I
think
super
complicated.
C
Exactly
so,
I'm
in
in
this,
assuming
you
keeping
you're,
keeping
all
the
version
numbers
in
lockstep,
which
I
would
say
like.
Let's
keep
at
that
as
long
as
we
possibly
can,
because
that's
just
makes
things.
We
can't
keep
the
spec
and
language
implementations
in
lockstep,
but
if
we
could
keep
all
the
core
packages
in
lockstep,
that
would
make
things
so
much
easier
for
people.
C
You
know.
Otherwise,
it
people
will
start
mixing
and
matching,
and
it
will
be
hard
to
like
understand
so
to
accommodate
that
we're
saying
if
you
make
a
breaking
change
to
an
sdk
component.
That's
just
a
minor
version
pump
and
an
example
of
this
is
node
only
has
one
version
for
node,
but
in
each
new
version
they
have
experimental
features,
features
moving
to
stable
and
features
moving
to
deprecated,
and
so
this
kind
of
looks
at
that
model.
C
Where
there's
a
overall
version
number
and
you
can
come
out
and
say
like
this-
was
bumped
to
2.0,
because
you
know
metrics
has
now
attained
ga.
But
if
you
under
have
want
to
understand
under
the
hood
what
changed
in
a
release,
you
have
to
look
at
the
individual
signals
and
the
signals
use
this
this
development
life
cycle.
C
C
Community
rules
or.
E
C
Exactly
exactly
this
is
just
this
is
a
social
construct
that
we're
using
around
explaining
to
people
when
they
post
an
issue
or
make
a
pr
proposing
some
new
feature
we're
just
saying
this
backlog.
This
is
like
maybe
backlog
rules.
E
C
C
As
a
batch-
yes
exactly
so
these
would
all
be
basically
minor
version
bumps
for
anything
in
here,
except
moving
to
ga
for
a
signal,
and
so
you
have
a
set
of
packages
right.
You
have
an
api,
you
have
sdk
stuff,
you
might
have
contrib
things
related
to
a
signal,
but
you
have
a
blanket
way
of
describing
to
people.
C
Metrics,
rnga
or
sorry.
Tracing's
in
ga
metrics
are
in
rc
and
logs
are
in
alpha,
so
they
at
least
have
this
concept
of
a
vertical
called
a
signal
and
that
whole
vertical
is
in
a
development
life
cycle
phase.
E
But
would
you
ever
have
I
mean
again
just
to
make
sure
that
the
developer
velocity
is
never
consistent
right
across
sdks.
So
would
you
have
a
compatibility
matrix
in
terms
of
where,
where
each
sdk
is
in
its
life
cycle,
and
then
that
mapped
back
into
a
general
release
of
the
of
a
particular
signal.
C
Yeah,
I
think
the
compatibility
matrix
is,
can
be
used
for
incremental
minor
releases
right
like
if
you're
incrementally,
building
towards
a
version
of
a
spec,
then
you
could
say
you
could
use
a
compatibility
matrix
or
otherwise,
in
our
words,
describing
this
release
to
someone
and
in
our
documentation
and
everywhere
else.
We
want
to
start
focusing
that
by
signal,
and
then
you
know
using
these
these
labels
on
each
signal
to
get
people
in
the
habit
of
this.
So
it's
slightly
more
complicated
right.
C
We
have
both
an
overall
version
number
that
we're
using
and
then
each
signal
has
a
word-based
life
cycle
that
it's
going
through,
but
the
other
alternative
is
the
version.
Numbers
are
kind
of
all
over
the
place,
as
far
as
I
can
tell
there,
there's
isn't
a
great
way
to
escape
this
complexity,
other
other.
E
I
mean
what
is
lts
here.
Is
it?
Is
it
tagged
in
the
artifact
or
is
it
also?
Is
it
just
a
backlog
term.
C
So
long-term
support
needs
to
be
defined,
I'm
proposing
that
gets
defined
in
one
spot,
so
we
have
one
definition
for
long-term
support.
It
applies
to
both
the
spec
and
packages
that
are
called
api
packages,
and
this
is
tied
to
both
a
major
version
bump
and
the
term
api.
C
So
when
we
say
something's
an
api
package
versus
an
sdk
package
where
actually
that
actually
has
meaning
api
means,
it's
covered
by
long-term
support
guarantees
and
sdk
means
it's
not
covered
by
long-term
support
guarantees
from
the
perspective
of
backwards
compatibility.
C
So
that's
the
difference
between
these
api
and
semantic
conventions
are
covered
by
backwards.
Compatibility
under
long-term
support
and
the
sdk
and
contrib
are
covered
by
long-term
support,
but
not
backwards.
Compatibility
portion,
so
long-term
support
is
something
that
happens
when
a
signal
is
ga'd.
Ga
is
a
major
version
bump,
so
those
those
three
things
are
just
tied
together.
We
don't
have
a
separate
definition
of
ga,
a
major
version
bump
and
long
term
support
guarantee
just
trying
to
reduce
those.
A
E
Hit
trace's
trace,
ga
and,
and
then
a
major
component
is
refactored.
As
john
was
saying,
you
know
in
terms
of
just
the
architecture-
and
perhaps
you
know
even
otlp
protocol
changing
so
that
at
that
point,
they're
breaking
changes
past
ga,
because
there
was
a
major
architecture
issue
that
was
fixed
or
you
know
improved.
C
C
That's
what
that
would
mean
we're,
not
breaking
the
tracing
api
in
the
process
of
doing
this.
Even
if
we
change
the
otlp
protocol,
changing
the
otp
otlp
protocol
would
mean
you
know
you
have
like
an
exporter
that
can
run
an
old
mode
and
like
an
exporter
that
runs
a
new
mode
or
it's
a
setting
that
you
switch
between
those
two
things,
but
it
wouldn't
be
something
that
affects
that
would
break
long-term
support,
because
long-term
support
is
focused
in
terms
of
the
backwards
compatibility
guarantees.
E
I
mean
the
reason
I'm
bringing
this
up
is
because
you
technically
on
a
project,
don't
need
to
have
a
ga.
I
mean
that's
a
product
concept
and,
and
so
the
way
that
distributions
or
or
any
artifacts
are
released
over
time
is
lts
right.
That
is,
if
you
say,
you're
lts,
that's
long-term,
stable
support
for
a
particular
version,
and-
and
that's
that's-
you
know
the
definition
right
you
don't
you
never
say
you're.
Ga.
C
E
Long
term
support
automatically
comes
with
guarantees.
Where
you
know
you
have
stability
on
the
api.
You
have
stability
and
backwards
compatibility
for
the
api
and
other.
C
Yeah,
so
I
agree
that
term
generally
available
is
kind
of
vague.
The
main
thing
I'm
trying
to
avoid
is
some
situation
where
we
say
we
are
1.0
in
this
thing
right,
but
that
somehow
doesn't
mean
we've
added
a
long-term
support
guarantee
and
because
for
one
I
don't
think
we
I
think
we
should
be
circumspect
about
telling
people
we're,
never
gonna
break
it.
C
Unless
we
mean
we're
not
going
to
break
it
and
not
breaking,
it
should
be
well
defined
yeah,
and
if
we
don't
tie
that
to
a
major
version
bump,
then
when
something
gets,
long-term
support
becomes
a
little
nebulous
in
regards
to
the
overall
versioning
of
these
things.
So
that's
the
one
place
the
one
place
where
I'm
trying
to
get
some
amount
of
synchronization
going
is
major
version
bumps
and
long-term
support
and.
E
I
mean,
potentially,
you
could
run
multiple
rc's
one
after
the
other
until
stability
is
achieved,
and
at
that
point
the
you
know,
the
code
base
goes
into
lts.
C
Yeah,
this
would
kind
of
imply
that
these
projects
potentially
hang
out
in
a
release
candidate
stage
for
a
bit
right.
If
the
only
way
we
go
past
release
candidate
is
saying
like
okay,
this
is
really
truly
bait
and
you're
done
long-term
support.
C
H
Yes,
the
the
ga
versus
iot,
as
I
have
a
totally
different
understanding,
so
let
me
send
a
link.
This
is
how
node.js
defines
this
lts.
It
has
multiple
ga
versions,
but
only
the
even
versions
are
lts,
and
this
is
also
what
donet
is
using.
So
my
understanding
is,
people
can
always
ga
a
major
version,
but
they
can
mark
hey.
This
ga
version
will
only
last
for
six
months
and
we'll
have
another
ga
version,
which
is
a
long
term
support
for
three
years
or
five
years.
C
Yeah,
so
I
think
node
has
this
every
other
version
bit
and
they're.
Also
what
they're
trying
to
do
here
is
maintain
a
kind
of
long
term
support
where
they
are
back
porting,
yeah
bug,
fixes
and
security
fixes,
so
they're
saying
like
if
you're
all
the
way
up
on,
if
you're
still
stuck
on
10,
we
are
still
going
to
back
port
these
things
for
some
amount
of
time,
the
other
side
of
launch.
So
that's
an
important
concept
for
long-term
support.
C
C
This
could
be
totally
untenable,
but
the
idea
here
is
that
if
major
version
bumps
are
associated
with
no
backwards
incompatible
changes
to
the
primary
apis
that
our
end
user
are
touching,
there
should
be
no-
and
I
could
be
wrong
about
this,
but
I
believe
there
should
be
no
reason
why
people
would
stay
stuck
on
an
old
version
of
open,
telemetry
yeah.
That's
the
thing
we
we
don't
want
people
doing.
C
We
want
to
design
this
in
such
a
way
that
everyone
can
stay
up
to
the
latest
supported
version,
and
we
don't
have
older
versions
of
open
telemetry
that
we're
back
porting
patches
to
yeah,
because
that
would
get
into
some
skew
that
that
I'm
concerned,
I'm
just
concerned
about
trying
to
do
that
and
make
sense
of
it.
But
it
also
doesn't
seem
necessary
if
we're
not
going
to
break
the
apis
and
node
they
break
the
apis.
E
C
Yeah
so
go
the
way
go
went
about.
Defining
1.0
is
actually
fairly
close
to
the
spirit
of
what
to
me.
Long-Term
support
and
open
telemetry
means.
I
think
it's
more
aligned
with
how
they're
doing
it
with
thing
go
than
how
they're
doing
it
in
say,
like
debian
or
or
node,
where
what
they're
talking
about
is
long-term
support
being
basically
tied
with
api
stability
and
there
in
when
go,
is
released,
they're
saying
all
go,
1.0
programs
will
be
compatible
as
much
as
we
possibly
can.
C
C
Now
we're
trying
to
say
we
don't
ever
stop
running
your
old
thing
as
much
as
we
can
and
major
version
bumps
just
mean:
we've
added
a
whole
new
vertical
that
you
can
now
use
sweet
version
faster
than
go,
but
but
the
way
they
talk
about
long-term
support
is
focus
on
api
stability
and
to
me
that
that
seems
like
it's
a
little
more
in
line
with
what
meme
might
want
to
mean
with
long-term
support,
we
still
have
to
define
bug,
fixes
and
patches
and
like
are
we
gonna
support
old
versions
of
the
sdk
and
stuff
like
that.
H
C
It's
just
about
clarifying
this
long-term
support,
guarantee
to
me.
That's
that's.
The
main
thing
so
like
metrics
will
be
1.5.
1.6
1.7
will
all
be
things
with
metrics
in
it
it's
just.
It
won't
be
until
we
attach
a
long-term
support
guarantee
to
metrics
that
we
would
say
2.0
and
if
we
attach
the
long-term
support
guarantee
to
a
bunch
of
packages.
At
the
same
time,
then
that
would
just
be
one
version
bump.
C
So
if
we
attach
a
long-term
support,
guarantee
to
context
baggage,
tracing
and
metrics
all
in
the
same
go,
then
we
could
just
bump
to
1.0,
but
if
we
don't
want,
if
we
don't
want
to
delay
attaching
this
long-term
support
guarantee
to
tracing,
then
we
would
bump
it
just
for
tracing
context
and
baggage
and
then
bump
it
again
when
metrics
hits
long-term
support.
H
So
maybe,
like
I
misunderstand
the
intention
here
so
probably
coming
from
the
node.js
and
donate
award
where
people
use
iotis
but
iotis
is
not
a
stem
on
a
specific
version.
For
example,
the
release,
like
version
version
12
lts
and
people,
found
a
bug
and
they're
going
to
make
a
bug
fix.
But
it's
not
going
to
break
any
api.
Compat
that'll
be
like
12.1
or
something.
C
C
I
I
note
that
that
in
go,
they
they
kind
of
avoid
that
term.
So
they're,
basically
talking
about
what
kind
of
long-term
support
they
are
guaranteeing
for
your
go
programs.
They
don't
use
the
term
long-term
support,
and
maybe
it's
for
that
reason.
So
if
people
have.
E
C
C
Right
and
but
they
they're
they're,
their
terminology
also
covers
like
their
their
standard,
not
just
the
runtime
they're
saying
like
as
long
as
we
will.
A
major
virgin
bump
means
we
broke
your
go
programs,
but
that
includes
we
broke
the
standard
glib
and
as
long
as
it's
on
the
1x
branch,
that
means
you
can
upgrade
to
the
latest
version
of
go
and
not
expect
more
than
minor
inconvenience
trying
to
get
your
stuff
upgraded.
C
Obviously
they
can't
be
perfect
because
there's
like
it's
such
a
sprawling
thing,
a
language,
they
can't
make
perfect
guarantees,
but
yeah
we're
a
bit
more
tightly
focused.
So
hopefully
we
can,
but
maybe
this
this
should
be
a
better
term.
C
C
If
that's,
if
that
was
the
last
major
signal,
we
added
that's
where
we
would
stick,
you
could
imagine.
Eventually
we
go
like
okay,
okay,
we've
got
now
that
we've
added
all
this
stuff.
We've
figured
out
a
much
simpler,
cleaner
cooler,
better
api,
there's
more
research
out
there
in
the
world
now,
so
we
want
to
make
like
tracing
2.0
like
the
new
new
tracing
or
something
like
that
or
we're
not
calling
it
tracing
anymore.
There's
some
cool
new
term
and
we
want
it
to
work
that
way.
C
Conflicts
coming
in
from
open
telemetry
is
a
transitive
dependency,
so
that
could
maybe
be
spelled
out
in
here
a
little
bit
clearer.
But
that's
that's!
That's
the
the
focus
of
our
support.
The
other
aspect
of
long-term
support
like
bug,
fit
bug,
fixes
and
security
patches.
We're
saying
you
only
get
that
for
the
latest
minor
branch
you
have
to
stay
up
to
the
latest
implementation.
C
We
don't
support
old,
sdk
implementations.
You
have
to
upgrade
if
those
things,
if
you
want
security
fixes,
I
don't
totally
know
how
tenable
that
is,
but
it
seems
like
something
to
aim.
B
For
this
sounds
like
you're,
really
great
like
signal
is
a
new
signal
is
the
only
way
to
go
past.
3.0
is
a
good
end
goal
to
me.
The
node
lts
pattern
riley.
I
know
you're
familiar
with
it,
but
that
is
a
complete
anti-goal
for
me,
because
I've
seen
that
cause
a
lot
of
strife
in
a
couple
different
companies
that
I've
worked
with.
C
C
Yeah,
so
obviously
this
is
not.
This
could
be
clearer
right.
I
think
maybe
this
core
community
is
wrapping
their
heads
around
this,
but
we
have
to
clarify
this
even
further,
so
that
end
users
can
understand
what
we're
talking
about
and
so
that
we're
really
and
also
that
we're
really
all
on
the
same
page.
So
I
will
try
to
continue
to
clean
this
up,
but
I
would
love
help
from
the
community
feel
free
to
adjust.
This
there's
no
way
to
put
comments,
though,
on
the
dock
right
now.
C
C
Okay,
you
should
be
able
to
edit
so
big
suggestions
edit.
If
you
have
a
totally
different
idea,
you
could
just
fork
this
make
your
own,
and
I
can
also
turn
this
into
an
otep
if
we
prefer
to
to
do
it
in
that
forum
rather
than
than
here.
So
I
think
maybe
the
next
step
we
can
do
a
pass
in
word,
but
the
next
place
this
will
go
is
an
otep
seems
like
the
proper
way
to
then
get
it
added
to
the
spec.
E
Yeah,
I
think,
though
it
needs
some
more
detail
and
and
maybe
we
can
iterate
on
the
dock
until
until
we're
ready.
F
Definitely
do
you
think
we
we
should
edit
it
right
away
or
such
as
changes
so
that
it
can
be
discussed
separately.
I
would
say,
granted
editing
access
to
the
word.
C
Yeah
I
tend
to
not
limit
people
but
I'll,
try
that
if
this
turns
out
to
be
too
cumbersome,
then
I'm
happy
to
give
people
editorial
access
to
make
their
changes
in
another
way.
Sometimes
it's
easier
to
make
a
change
just
point
of
contact.
If
you're
getting
a
lot
of
little
changes,
you
could
always
just
like
copy
paste,
an
area
and
then
be
like
you
know,.
C
Okay,
so
that's
my
pitch,
hopefully
that
that
gets
us
in
the
ballpark.
It
is
definitely
a
tricky
wicket,
but
I
do
think
this
is
like
within
the
if
we
stick
to
it.
This
is
something
that
I
think
end
users
can
comprehend
fairly
easily,
which
is
when
they
go
to
use
a
signal.
They
just
need
to
understand
what
state
that
signal
is
and
beyond
that
they
don't
really
have
to
care
about
the
open,
telemetry
version
they
just
have
to
care
about.
C
C
So
it
I
believe
this
is
mostly
moving
over
to
metrics,
but
it
does
seem
like
there
is
some
tiny
bit
of
speck
of
trace
work
around
spec
stuff,
so
we've
got
this
renaming
windmill
over
here
and
then
otop
json.
C
C
D
C
Very
good
point
so
have
a
look
at
this
maintainer
people
we're
one
thing
that
we
haven't,
I
think
fully
hacked
out
is
like
protocol
versioning.
I
know
tigran's
been
been
managing
that,
but
json
is
super
important
for
javascript
in
particular,.
C
So
moving
along
morgan
temperature
check
on
the
metric
spec.
When
do
you
think
that
will
be
locked
as
the
tracing
spec
is
today?
I
don't
know
if
josh
is
on
the
call,
but
josh
has
been
hopeful
that
this
could
be
done
by
end
of
january
to
have
the
metric
spec
get
into
like
a
release,
candidate
phase.
So
that
is
what
I've
heard
from
josh.
C
So
that
was
a
question
asked
by
another
person:
who's,
not
here
today,
but
morgan.
If
you
watch
the
recording.
C
C
Does
that
mean
like
tracing
and
metrics
are
done
in
which
languages
are
they
done
that
it's
hard
to
have
like
one
big
balloon
that
we
pop
and
say
ta-da?
We
did
it
and
I
certainly
don't
want
to
delay
us
talking
about
this
project
and
doing
things
like
hitting
a
drum
beat
because
we're
waiting
for
one
big
moment
because
it
seems
like
the
tracing
stuff
will
be
good
to
go
in
q1
and
the
metric
stuff
probably
will
be
q2
before
we're.
Putting
long-term
support
guarantees
on
that
stuff.
Certainly.
D
Just
from
a
morgan
wanting
a
temperature
check,
I
would
say
aiming
for
end
of
january
sounds
great.
My
guess
is
it's
probably
going
to
be
more
like
end
of
february,
but
we
should
still
try
to.
We
should
shoot.
As
you
know,
we
should
work
as
hard
as
we
can
to
go
for
end
of
january,
but
we
all
know
how
the
end
of
the
spec
process
ends
up
working.
Oh.
C
My
god
yeah
so
yeah
and
on
a
related
note,
if
the
the
tracing
stuff,
I
think
andrew
mentioned
this
for
for
the
future.
But
if
we
can
say
that
tracing
is
mostly
in
the
bag.
C
I
don't
know
if
this
is
true
or
not,
but
we
could
fold
the
metric
spec
meeting
as
separate
from
the
generic
spec
meeting
and
we
could
either
fold
that
in
or
just
have
two
meetings
that
are
more
focused
on
the
metrics
side
of
the
fence,
because
we
kind
of
want
to
turn
everyone's
attention
to
the
metric
signal
once
we
get
tracing
in
the
bag
and
I'm
not
sure
when
we
want
to
do
that.
E
Yeah
sure
you
can
keep
this
up,
but
the
only
you
know
request
that
I
was
raising.
Is
that,
as
you
know,
we
prioritize
the
different
tasks
on
the
ga
burn
down
chart
again.
There
are
pr
reviews
that
you
know
we
need
maintainer
help
on
and
obviously
the
maintainers
are
split
between.
E
You
know,
working
on
the
tasks
that
are
prioritized
versus
pr
reviews,
but
again
just
want
to
have
a
general
understanding
of
what
is
the
balance
that
maintainers
should
have.
Because
again,
you
know
there
are
other
releases
in
flight
which
are
downstream
to
the
project
that
get
blocked
because
of
not
having
maintainability
either
either
we
figure
out
a
graduation
process
for
getting
more
maintainers
who
are
able
to
split
out
and
support.
C
Yes,
this
is
really
important.
This
is
the
classic
bottleneck
right
when
the
maintainers
are
the
people
who
are
both
reviewing
code
and
writing
a
lot
of
it
yeah.
I
would
encourage
every
maintainer
on
the
call
to
look
and
see
about
expanding
their
list
of
approvers
and
getting
more
approvers
who
are
capable
of
being
deputized
to
to
do
the
review
work.
If
you
feel
like
it's
hard
to
do
the
review
work
as
a
maintainer,
but
it
almost
ends
up
being
the
case.
C
E
C
F
E
What's
the
balance
between
you
know
maintainers
actually
having
to
do
reviews,
because,
again,
you
know
we're
in
this
sticky
situation,
even
with
and
and
no
offense
to
any
of
the
maintainers,
because
I
know
that
they're
multitasking
and
very
busy,
but
it
really
is
that
we're
not
maintainers
as
aws
today
and
and
we
are
blocked.
C
So
I
don't
want
to
take
everyone
on
a
journey
through
looking
this
up
right
now.
This
is
where
I
wish
andrew
is
here.
We
did
address
this
in
the
past.
We
do
have
a
concept
of
issues
going
stale
and
an
acceptable
response
line.
Before
you
know,
an
issue
is,
is
considered
stale,
so
that's
one
way
to
lock
it
down
and
say,
like
look
like
prs,
have
to
get
a
a
response.
C
C
I
think
there
is
a
a
tendency
for
the
maintainers
to
be,
and
the
technical
committee
as
well
to
be
also
the
people
doing
the
bulk
of
the
code,
writing
and
I
think,
sometimes,
that
code
writing
can
get
in
the
way
of
of
doing
reviews.
So
maybe
I
think
it's
going
to
be
a
different
situation
for
every
sig,
but
a
thing
to
look
at
is
like
as
maintainers.
C
Can
we
focus
more
on
the
reviews
and
issue
management
and
do
like
write
less
code?
Do
more
organizing,
like
organize
other
people
in
your
sig,
to
write
the
code
for
you,
while
managing
the
backlog
and
doing
the
reviews
of
that
code
that
potentially
works
better?
C
E
Yep
yep
exactly
so,
I
mean
again
just
want
to
raise
this
because
we
are
blocked
at
this
point
and
for
net
specifically,
for
example,
or
the
proto
prs.
These
are
prs
that
are
key
to
you
know
our
downstream
releases
as
well
as
but
they're,
not
you
know
the
the
maintainers
don't
have
bandwidth.
C
So
with
the
proto
issues,
it's
basically
like
tigran's
on
vacation
and
we
don't
have
enough
other
people
who
really
bottom
line.
E
Right
right,
because,
right
now
it's
very
centric
like
dotnet
is,
you
know
the
whole
microsoft
team
or
proto
and
collector
is
only
splunk.
So
there
there
is
no
division
of
you
know:
round-robining
of
maintainers,
okay,.
C
C
So
we've
identified
those
two
and
we're
we're
about
out
of
time
either.
Just
a
quick
shout
out
are
there
other
sigs
that
that
feel
like
they're
in
this
spot?
H
I
I
can't
clarify
this,
although
I'm
not
the
maintainer
for
doughnut.
So
what
my
understanding
is?
It's
not
the
maintainer
like
it's
running
out
of
capacity.
Is
they
look
at
the
pr
and
they
decided.
This
is
a
vendor-specific
feature
of
lower
priority
and
because
they're
doing
a
major
release,
so
they
try
to
communicate
and
see
this
pr
will
be
after
the
major.
C
C
Yeah
but
feel
free.
You
can
also
dm
me
anytime.
I
suck
at
checking
my
getter
because
it
doesn't
alert
me
very
well
I'll.
Try.
G
C
Better
be
good
and
so
yeah,
that's
maybe
another
thing
I'll
say
if
you're
feeling
like
you're,
getting
blocked
or
either
as
a
maintainer,
you're
feeling
like
I'm
kind
of
underwater
here
or
as
a
contributor
project.
You're
like
this
project
seems
like
it's
bottlenecked.
You
can
always
bring
that.
Please
bring
that
up
with
me
privately
if
you
don't
want
to
bring
it
up
in
one
of
these
meetings.
I
I
tried
to
go
around
and
track
these
things,
but
there's
so
many
sigs
and
so
many
meetings.
E
And
and
riley
thanks
for
clarifying,
but
I
think
that,
let's,
let's
follow
up
a
bit
more
yeah,
okay,
thank
you.
Thanks
ted.