►
From YouTube: 2020-12-02 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
A
A
A
A
B
A
Yeah,
well,
hopefully,
people
are
in
the
pacific
time
zone
are
able
to
keep
up
to
date.
If
the
attendance
is
low
on
this
one
yeah.
But
if
it's
actually
being
a
problem,
let
me
know
so.
I
can
poke
the
tc
and
other
people
to.
A
Yeah,
have
you
had
a
chance
to
look
at
any
of
this
versioning
stuff
I've
been
pushing
on
people.
B
A
Yeah
so
it,
but
it's
in
a
google
doc
right
now
and
on
friday,
I'll
submit
it
in
whatever
state
it's
in
as
an
otep.
A
So
I'm
trying
to
just
between
now
and
then
get
a
lot
of
this
locked
down,
and
it
seems
like
the
trickiest
part
of
this-
is
version
numbers
there's
some
hashing
out
of
like
what
our
stability
guarantees
actually
are
once
something
is
declared
stable
and
how
do
we
deprecate
things?
So
that's
like
the
support
part
of
it,
but
then-
and
that's
I
think,
pretty
straightforward,
but
the
versioning
part
has
been
tricky
because
it
seems
like
we
want
to
do
a
lot
of
different
things
with
that
version
number.
A
We
want
to
have
people
be
able
to
say
I'm
using
open,
telemetry,
1.8
1.8.4
in
python,
and
have
that
like
mean
something
so
the
releases
have
to
be
versioned,
but
then
those
releases
are
made
up
of
a
bunch
of
packages.
A
Some
of
these
packages
have
strict
support.
Guarantees
like
the
api
packages,
have
strict
backwards
compatibility
like
avi
compatibility
as
a
requirement
the
rest
of
the
packages.
We
want
to
retain
backwards.
Compatibility
on
a
best
effort
basis
like
the
stuff,
the
end
user
touches
there.
We
want
them
to
stay
up
to
date
on
the
latest
version,
so
we
want
it
to
be
one
of
those
projects
where
people
just
automatically
upgrade
to
the
latest
thing
to
get
the
security
patches
and
stuff,
and
don't
worry
that
we
broke
a
bunch
of
stuff.
A
So
we
need
to
do
best
effort,
but
there's
still
gonna
be
like
technically
things
break
in
those
packages
like,
even
if,
like
we
broke
a
plug-in
api
but
then
fixed
all
the
plugins
to
work
with
the
new
api.
So
when
you
go
to
the
new
version,
you
don't
notice
as
an
end
user
that
was
still
stuff
that
broke,
so
the
question
then
becomes:
how
do
we
increment,
if
we're
going
to
have
one
version
number
that
represents
the
release?
A
How
do
we
increment
that
version
number?
Does
it?
Is
it
the
case
that
every
sdk
change
every
breaking
change,
increments,
the
major
version
number
or
do
we
want
to
reserve
major
version
changes
to
mean
things
like
different
signals,
gaining
stability
or
being
deprecated.
A
So
there's
a
this
is
a
thing
we
have
like
a
couple
version
numbers
there's
the
version.
It's
not
realistic!
That
implementations
stick
to
that
number
yeah,
but
we're
trying
so
far
to
at
least
just
not
increment
the
major
version
number.
Yet
on
anything
yep.
We
had
really
figured
out
what
that
meant,
but
so
the
spec
has
its
version
and
we
want
it
to
kind
of
increment
in
a
similar
fashion.
But
really
this
is
about
the
implementations
so
like.
A
A
That's
what
I
originally
proposed,
but
people
were
pushing
back
and
saying
that
isn't
simver
and
a
lot
of
package
managers
yeah
presume,
send
there
and
might
automatically
roll
people
forwards
and
stuff,
but
I
kind
of
want
them
to
automatically
roll
forwards.
So.
B
A
A
A
A
Get
bumped
where
there's
something
changed
in
that
particular
package.
Yeah
and
that's
like,
I
think,
confusing
some
people
right
like
there's
some
people
who
have
like
a
more
strict
definition
of
sender
and
how
one
should
do
things
and
like
well.
Every
package
should
just
follow
its
own
simver.
That
gets
pretty
insane
yeah,
but
then.
A
B
Confusing
because,
as
you
say
like
it's
very
nice
to
know
that
this
plugin
is
definitely
compatible
with
this
api
and
because
I
think
even
when
we
say
we
want
people
to
be
able
to
roll
forward,
we
might
still
expect
breakages.
If
the
versions
don't
match
up
right.
But
we
expect
no
breakages
as
long
as
they
update
all
their
version.
Numbers.
A
Yeah-
maybe
that's
it,
maybe
it's
like
we
want
to
be
we,
since
we
want
people
to
to
update
as
fast
as
possible,
we're
saying
like
we're,
making
a
commitment
to
you
to
to
stay
up
to
date
and
the
reason
I.
A
Want
to
do
that
is
we
don't
want,
I'm
concerned
about
situation
where
users
end
up
camping
on
some
old
version,
or
we
have
some
kind
of
compatibilities
like
incompatibilities
that
get
in
there
and
means
like
all
this
stuff
can't
compose.
So
no,
we,
if
we
are
committed
to
avoiding
that,
then
then
I
think
the
idea
that
package
managers
might
automatically
move
people
forwards
is
fine.
A
Sometimes
it
won't
be
a
hundred
percent
fine
everywhere,
because
we
can't
possibly
guarantee
that,
but
we
can
say
like
that's
our
intent.
B
A
You
should
just
upgrade,
and
if
there's
an
issue
upgrading
you
should
let
us
know,
and
it
shouldn't
be,
it
shouldn't
be
more
than
maybe
having
to
change
a
bit
of
configuration
to
upgrade,
but
so
it
should
either
be
nothing
or
something
that
we
hope
is
like
simple
enough
that,
like
you
know
as
the
operator
or
the
developer,
you
can
just
do
it.
A
B
A
I
think
it
all
sticks
together.
I
I'm
almost
tempted
to
say
contrib
should
do
the
same
thing,
but
I
don't
know
it
might
be
a
bit
much.
I
do
think
we
need
to
make
a
commitment
to
say:
contrib
is
always
up
to
date
and
released
with
or
right
after
core
is
released
like
we
shouldn't
have
a
situation
where
we
shouldn't
be
doing
a
thing.
We
say:
hey,
there's
new
version,
but
we
changed
some
internal
apis
and
none
of
our
instrumentation
or
plug-ins
work.
B
A
Sdk
plug-ins
and
I
my
experience
with
frames
in
general,
is
it
is
harder
to
maintain
those
plug-in
interfaces
without
breaking
things
right
right,
just
because
the
way
they
work
but
like
we
should
try
to
avoid,
because
we
want
people
to
upgrade
as
fast
as
possible,
but
we're
just
saying
like
we
can't.
B
B
Those
are
the
two
repos.
Those
make
a
lot
of
sense
to
be
separate
if
we
had
the
plugins
also
separated
out.
That
would
make
things
more
annoying
than
less.
I
think
so
like
there
was
an
idea
we
might
copy
this
stuff
out.
I
was
like
I
was
talking.
John
is
like:
do
we
get
anything
by
copying
this
stuff
out
like
no?
Not
really?
So
we
just
didn't
do
that
yeah.
I
think.
A
B
A
Yeah
here
that
people
in
other
languages,
you
know
it
makes
a
little
more
sense
to
move
that
stuff
out,
but
just
to
make
the
issue
backlog
be
a
little
more
sane
like,
even
even
with
all
the
contrib
stuff
in
the
same
repo.
It's
still
annoying
like
I'll.
A
A
A
B
A
Yeah,
well,
I'm
going
back
on
the
semver
actually,
because
what
we
just
described
is
what
I
had
in
there
earlier
like.
If
you
look
down
at
the
bottom,
if
you
scroll
the
very
bottom
of
the
stock,
I
have
like
an
older
proposal
and
that's
looking
more
like
what
we
were
just
talking
about,
where
a
major
virgin
bump
only
happens
when
a
major
change
to
the
api
happens,
aka
like
the
instrumentation
api
but
and
then
sdk
changes
or
minor
version
pumps,
but
that's
different
from
simvar.
A
Yes,
so
if
we
release
so
the
way
I'm
proposing,
this
is
like
when
something
when
a
signal
becomes
stable
when
something
moves
from
beta
to
stable,
that's
a
major
function,
maybe
that's
wrong.
Maybe
that
is
wrong.
Maybe
it's
just
major
version
bumps,
or
only
when
we
break
it.
A
But
I
kind
of
felt
like
it
made
a
little
more
sense
to
be
like
1.0
tracing
is
stable
when
we
add
this
whole
new
thing
like
metrics,
we
would
announce
that
as
as
a
2.0,
because
there's
this
whole
new
thing
added
onto
it,
but
maybe
that's
unnecessary.
That's
kind
of
a
way
of
sort
of
thinking
about
and.
A
You
know
other
things
can
happen
when
you
do
2.0,
maybe
that's.
When
we
batch
up
any
deprecations,
we
were
going
to
make
and
other
things
like
that,
yeah,
but
and
then,
when
we
did
logging
that
would
be
3.0,
and
if
we
came
out
with
like
a
new
version
of
tracing,
then
when
that
became
stable,
that
would
get
mega
4.0
and
then,
but
that
would
be
new
packages.
It
would
be
like
a
whole
new
tracing
system.
A
B
A
Just
like
they're
stable
until
they're
gone,
and
they
can't
go
until
like
the
new
thing
has
been
stable
for
years.
So
I
I
struggled
to
pick
a
number
of
years
like
it
doesn't
seem
like
there's
any
standards
on
that
front
around
like
what
people
expectations
are
but
yeah.
I
think
these
things
the
apis
should
be
stable
for.
B
A
B
A
A
Yeah
I
mean
it
could
be
that
we
just
only
bump
the
major
version
when
we
deprecate
something.
So
not
even
when
we
add
something
everything
is
just
minor
version
numbers.
B
A
B
A
Years,
yeah
and
we're
that's
just
how
it
works,
everything's,
a
minor
bump-
and
you
know
the
only
disadvantage
of
that-
is
that
it
just
takes
that
major
version
number
like
out
of
play
right.
Yeah.
B
A
The
only
question
is
like
do:
we
want
people
to
notice
when
something
like
metrics
comes
out
and
like
look,
but
it
may
like
be
confusing
to
people
and
imply
that
we
broke
yeah
exactly.
A
A
B
So
tricky
yeah
but
yeah,
so
my
vote
is
still
for
some
verb,
but
we'll
definitely
comment
on
the
hotep
or
whatever,
when
that's
there.
So.
A
A
But
but
we're
saying
it's
not
strict
sender,
there
may
be
some
breakage
to
sdk
packages
that
only
count
as
that.
B
A
B
A
Yeah,
if
it
says
like
tracing
2.0
or
something
2.0,.
A
B
A
Yeah
there's
another
argument
there,
where
we
originally
saying
1.0
was
tracing
and
metrics,
so
I
have
to
convince
some
people,
but
I
think
we
we
have
to
move
away
from
that
because
we
want
to
like
tracing
is
becoming
stable,
so
we're
going
to
confuse
people
the
other
direction.
If
we
don't
do
a
1.0
announcement,
because
people
are
baking
it
into
stuff
and
expecting
it
to
be
stable,
yeah
spring.
A
Up
like
dot
nets
also,
you
know
they're
they're
hot
to
trot
so
yeah
cool
man,
okay!
Well,
this
is
some
helpful
feedback.
I'll
do
another
pass
on
the
version
numbers
that
says
it's
simver,
but
but
with
this
minor
change,.
B
A
And
we
were
thinking
about
something
he's
talking
about
with
david
ash
pull
is
maybe,
even
though
all
the
packages
will
have
the
same
version
number
packages.
If
we
have
like
this,
a
life
cycle
like
signal
life
cycle,
where
we're
saying
like
a
signal
goes
from
alpha
beta,
you
know
stable
whatever.
A
That
could
be
marked
in
the
virgin
number
on
each
package,
as
I
forget
what
you
call
it,
but
you
have
an
addendum
or
something
you
can
put
at
the
end
like
dash
beta
right,
like
dash
alpha
dash
beta,
so
we
could
potentially
be
like
dash
experimental.
A
You
know
dash
beta
dash,
stable
dash
deprecated,
like
every
package
could
have
that
on
it.
So
they
all
have
the
same
version
number,
but
you
can
look
at
the
import
right
there
and
be
like
I'm
importing
something
that's
still
in
beta.
So
at
least
people
could
look
at
their
dependency
graph
and
not
have
to
go,
read
a
manual
somewhere
to
figure
out
which
things
they
should
be
touching.
B
A
B
A
B
A
But
I
was
just
thinking
like
that
might
be
a
way
to
at
least
inject
some
stability
information
into
version
number
when
people
do
when
these
packages
do
spit
their
version
number
out
to
somebody
for
whatever
reason
like.
If
that
includes
beta-
and
I
don't-
maybe
it
doesn't
need
to
include
stable,
but
it
could
be
deprecated
so
that
that
might
be
helpful.