►
From YouTube: 2021-12-08 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
Yeah,
okay,
I
assume
that's
a
yes
valentine
has
limited
time
today,
so
I
would
say:
let's
actually
start
with
this
last
item,
since
I
think
it's
the
most
important
one
we
have
today,
if
everyone's
okay
with
that,
we
have
a
couple
of
prs
in
the
api
repository
that
add
new
features
and
will
require.
A
Minor
version
updates,
according
to
the
versioning
and
stability
document,
in
the
specification
we
have
to
back
our
backboard
all
bug
fixes
to
all
minor
versions.
So
it
once
we
release
a
1.1
version.
That
means,
if
we
ever
have
any
bug
fixes
we
have
to
make
sure
to
backport
them.
A
So
I
I
guess,
I'm
looking
for
either
ideas
or
a
volunteer
to
take
this
on,
to
come
up
with
a
branching
strategy
and
and
document
it.
If
not,
I
can
do
it
or
we
could
do
it
manually
where
we
would
just
use
the
same
automatic
publishing
that
we
have
today
and
then,
when
we
needed
to
backport
fixes,
we
would
just
create
a
branch
for
each
minor
run.
A
We
may
be
able
to
find
a
way
to
automate
them,
but
for
now
we
don't
have
that
many
versions
so
manual.
Isn't
that
big
of
a
deal,
but
we
all
know
how
those
things
grow.
How
you
say
it's
not
a
big
deal
now
and
two
years
down
the
line
you
find
yourself
doing
10
manually.
A
So
I
guess
I'm
looking
either
for
a
volunteer
or
if
anyone
has
any
ideas
other
than
what
I
just
mentioned,
and
if
there
are
no
volunteers
I'll
just
start
working
on
that
this
afternoon,.
E
I
was
just
gonna
ask
what
the
wording
in
the
spec
is,
because
I
don't
think
we've
been
doing
any
backboards
in
python.
We've
just
been
doing
minor
version
releases.
E
D
Because,
actually,
I
think
we
discussed
that
in
this
in
this
jsc.
I
think
it
was
like
two
months
ago
because
we
already
had
the
issues
for
the
the
when,
if
we
released
the
the
context
pr
that
daniel-
and
I
think
we
discussed
that
and
at
the
time
I
think
it
was
just
we
don't.
We
don't
know
exactly
what
the
thing
was
we
are
doing
and
we
wanted
to
know
a
little
bit
more
about
what
others
doing
to
avoid
like
doing
stuff
on
our
own.
That's
maybe
different
than
others.
A
I
know
so
we
did
talk
about
this
while
ago.
Sorry
I
was
trying
to
read
here.
While
you
were
talking
so
I
only
I
apologize,
I
was
only
half
paying
attention
there.
Do
you
mind
repeating
that.
D
That's
so
that's
fine.
I
was
just
saying
that
yeah,
the
last
time
I
think
we
discussed
about
this,
was
that
we
needed
to
see
how
other
things
where
doing
it,
whoever
like
doing
something
different
than
other
things,
it
may
have
been
added
on
the
spec.
I
believe
so
seeing
your
screen,
but
yeah,
that's
the
thing.
I
think
we
we.
A
Yeah
so
obviously
aaron
just
said
that
they're
not
backboarding
fixes,
I
don't
know
if
matt
is
on
the
call.
I
think
he
is
do
you
know
what
what
ruby
is
doing?
Matt.
F
A
E
A
Additional
feature
development
is
not
recommended.
I
guess
I
have
two
thoughts
on
that.
One
is
that
this,
the
pr
in
question
is
not
really
a
feature.
It
is
additive.
It's
adding
the
the
schema
url
to
the
to
the
get
tracer
call
it's
required
by
the
specs.
So
it's
not
like
it's
not
like
we're
going
off
on
our
own
and
doing
something
here.
A
I
think
additional
feature
development
not
recommended
to
me
not
recommended,
doesn't
mean
prohibited,
and
I
think
this
just
means,
like
large
features
like
not
trying
to
add
new
api
methods
and
stuff
like
that,
that
that
introduce
new
functionality
where
this
is
really
just
an
iteration
of
functionality
that
we
already
have.
A
A
So
I
I'm
not
gonna
worry
too
much
about
it.
We
can
reach
out
to
the
tc
and
make
sure
that
we're
not
doing
anything
that
they
are
really
upset
about,
or
anything
like
that,
but
I
just
don't
see
how
the
project
can
move
forward.
If
we
never
have
a.
E
Minor
version
increase
right,
I'm
not
saying
that
we
shouldn't
do
minor
version
increase,
I
think
so
so
like
if,
if
we
make
this
change
and
back
port
it
to
a
patch
version,
it's
a
little
confusing,
because
if,
if
you
say
like
okay,
this
for
people
who
want
to
have
this
change,
they
can
pull
in
this
minor
version
or
this
patch
version
and
later
it
kind
of
doesn't
work.
Oh.
A
So
it
would
be
in
order
to
get
the
feature
you
must
use
1.1
or
later,
but
if
we
have
a
bug
fix
after
that,
the
bug
fix
needs
to
be
backported
to
1.0
right
right,
okay,
gotcha
gotcha,
so
we
just
need
a
branching
strategy
that
allows
us
to
do
that.
This
is
super
common.
It's
not
it's
not
a
complicated
problem
to
solve
or
anything
like
that.
It's
just
something
that
we
haven't
done
yet
and
we
need
to
do
it
and
it
needs
to
be
documented
so
that
we
do
it
the
same
way.
E
Sorry
yeah
I
misunderstood
you
then
we
haven't
had
to
do
had
to
do
that
because
we
haven't
had
any
like
security
stuff
or
things
that
we
considered.
I
guess
severe
enough
bugs
that
was
worth
backboarding
over
python
yeah.
A
So
I
think
the
way
that
I
read
this
document,
I
think
all
bug
fixes
need
to
be
backboarded,
not
just
security
fixes.
A
A
I
know
that
at
least
java
has
released
a
few
minor
versions.
They
may
have
done
something
I
I
know
that
that
they
tend
to
be.
You
know,
follow
the
spec
pretty
closely
and
stuff
like
that.
So
maybe
we
can
look
at
what
they're
doing,
but
I
think
for
now
just
creating
a
creating
a
branch
for
each
minor
version
run
when
we,
when
we
increment
the
minor
version,
creating
a
branch
for
the
old
one
should
be
sufficient.
So
when
we
create
a
1.1
version,
a
branch
for
1.0.8.
F
I
think
that's
fine.
I
I
had
one
more
question
about
this,
because
this
is
the
pr
we're
looking
at
it's
not
really
like
a
bug,
it's
kind
of
like
a
feature.
It's
like
something
that
came
in
after
1.0
of
the
spec.
I
don't
know
exactly
what
version
of
this
spec,
but
it's
been
kind
of
like
it
has
been
chugging
along
and
kind
of
adding
some
things
and
incrementing
like
the
spec
miner
version.
F
So
like
yeah,
I'm
just
curious
how
the
spec
versioning
is
oh
like
what
the
interplay
is.
I
guess
with
the
js
libraries-
and
I
feel
like
this-
is
something
we
haven't
figured
out
in
ruby,
either
like
how
to
actually
like
indicate
what
what
version
of
the
spec
is
implemented
or
tied
to
you
know
the
different
versions
of
the
ruby
sdk.
A
Yeah,
so
that
I
mean
the
versioning
story
is
a
headache
in
general,
so
that
there's
no
there's
no
guarantee
of
which
spec
the
api
is
implementing
and
then
there's
no
easy
way
to
know
which
version
of
the
api
you
need
in
order
to
use
or
which.
A
The
sdk
you
need,
in
order
to
run
a
specific
version
of
the
api
right
now,
because
there
only
is
one
version
of
the
api
we
just
have
1.0
and
all
the
bug
fixes
should
be
100
backwards
compatible.
So
that's
no
problem,
but
once
we
release
a
1.1,
we
will
have
some
versions
of
the
sdk
which
implement
that
feature
and
older
versions
which
don't
so
we'll
have
like
a
minimum
sdk
version
for
the
api
miner
version
and
we'll
have
to
be
very
clear
about
that.
We'll
probably
have
to
document
it
in
both
readmes.
A
So
in
the
api
readme,
we'll
have
to
say
to
use
api
1.1,
you
must
use
a
minimum
sdk
version,
one
dot.
You
know
whatever
and
in
the
sdk
we'll
have
to
say
this
sdk
implements
api
version,
one
dot,
something
or
another.
I
don't
think
we
have
to
explicitly
document
which
spec
version
we
follow
at
least
not
for
our
users,
but
we
probably
should
document
it
for
our
maintainers
and
and
contributors
so
that
they
know
what
version
of
the
spec
they
should
be.
Looking
at.
F
A
So
this
won't
need
to
be
backported,
but
what
it
will
do
is
when
it
merges
we'll
have
to
release
it
as
a
minor
version
change.
So
then
we'll
have
1.1
and
1.0
sort
of
released
and
and
in
use,
which
means,
if
we
have
a
bug
in
the
future,
it'll
it'll
need
to
be
backported
to
both
lines.
I'm
not
saying
this
particular
feature
needs
to
be
backported.
A
I'm
saying
it
creates
a
new
minor
version
that
we
would
then
need
to
backport
bug
fixes
to
the
old
one
when
they
come
up.
F
A
B
Although
being
additive,
you
could
get
away
as
a
patch
version
like
I
do
this
all
the
time
with
app
insights,
we
add
new
functional
features
as
patch
releases
and
we
just
say:
okay.
Well,
the
next
version
of
component
y
needs
at
least
that
that
version
of
the
main
core
component-
and
I
just
use
simver-
to
rely
on
on
keeping
that
in
in
tone
like
if
it
was
complete,
replacement
and
changing
the
api.
You
definitely
have
to
change
the
minor
version,
but
there's
a
an
additive
patch.
A
According
to
semver,
if
you
have
an
additive
change,
it's
if
you
change
behavior
at
all
you're
supposed
to
bump
the
minor
version.
If
you
replace
something
you'd
have
to
bump
the
major
version,
any
breaking
change
would
require
a
major
version
bump
and
then
the
patch
should
only
be
bug
fixes.
So
that's
according
to
like
december
documentation.
A
B
A
So
if
we
release
this
as
a
patch
version
and
have
not
yet
updated
the
sdk,
will
the
sdk
fail
to
build.
B
Because
it's
missing
an
older
sdk
trying
to
use
the
new
new
api,
it
will
complain.
Yes,.
A
Yes,
so
then,
in
my
mind
we
have
to,
we
would
have
to
make
that
as
a
minor
version.
A
B
Then
it
will
still
work,
it
is
not
okay.
So
let's
see
yeah.
A
A
Yeah,
so
what
we
have
is,
if
we
go
to
like
trace
node
the
dev
dependency
patch
version
and
then
the
pure
dependency
allows
anything
up
to
1.1.
A
A
It's
not
a
problem,
we
can
do
it.
It's
just
that.
We
have
to
be
aware
that
every
time
we
do
this
and
release
it
means
that
we're
creating
a
new
branch
that
needs
to
have
bugs
backboarded
to
it
right
now.
We
don't
have
to
backport
any
bugs,
because
we
don't
have
any
previous
versions,
but
once
we
release
a
minor
version,
we
will
have
previous
versions
that
bugs
need
to
be
backported
to
for
bug
fixes.
D
I
think
what
would
be
interesting
for
this
is
to
look
at
what
the
core
nodejs
is
doing,
because
they
are
literally
the
same
problem,
and
I
think
they
must
main
branch
is
just
the
the
it's
not
just.
It's
not
a
release
branch,
and
I
think
I
think
it's
interesting
to
see
because
I
think
they
actually
everything
is
done
manually
for
them,
and
it's
a
huge
time,
sync
of
course,
but
I
think
that
they
may
have
reason
to
to
just
didn't
automate
it
for
now
so
yeah,
which
take.
Is
that
sorry?
D
I
said
that
this
was
the
node.js
project.
It
said
like
for
the
oh,
yes,.
D
Yeah,
I
think
so
because,
for
example,
if
we
have
like
2pr
that
need
to
be
made
as
a
a
new,
not
a
patch,
I
mean
a
minor,
a
new
minor
version.
We
can
still
release
like
a
new
patch,
a
child
pick
new
patch
from
from
the
main
branch
to
to
release
branch,
so
that
that's
a
thing
that
need
to
be
accounted
of
when
doing
the
watching
strategy.
I
think.
A
I
got
it
so
you're
saying
if
we,
if
we
merge
this
pr,
for
example,
yeah
and
then
we
have
a
bug
fix,
but
this
is
not
released
yet
then
we
need
do.
We
have
no
way
to
release
just
that
bug
fix.
D
Yeah,
well,
I
think
I
I
mean
you
could
still
like
do,
do
a
break,
do
a
different
branch
and
then
revert
the
commit
and
still
do
the
release,
but
I
think
it
it's
just
way
complicated.
To
do
this,
I
mean
I'm
not
actually
sure,
because
I
didn't.
I
didn't
experience
this
kind
of
flaws,
but
I
think
it's
interesting
to
see
how
they
did
it
and
I
think
they've
been
documented
somewhere.
So
it
might
be
interesting
to
look
it.
A
I
I
I
see
the
problem
there.
I
just
don't
think
that
we're
likely
to
run
into
it
and
if
we
do,
I
can
manually
cut
a
release
if
we,
if
we
absolutely
need
to,
I
think
that
that
makes
more
sense
for
a
project
like
node
that
has
you
know
hundreds
of
pr's
in
between
releases
and
bug
fixes
coming
in
all
the
time.
A
I
don't
think
we
need
to
worry
too
much
about
being
able
to
release
bug
fixes
on
their
own
after
features
have
been
merged.
D
A
Okay,
I
guess
I'll
do
that
I'll
I'll
create
a
pr
with
a
a
branching.
A
You
know
I'll
document
the
branching
strategy,
probably
in
the
contributing.md
of
the
api
repo
I'll,
try
to
get
that
open
today,
so
that
people
can
look
at
it.
But
for
now
I'm
just
gonna
go
with
a
very
basic
branching
strategy.
I
think
we'll
we'll
release
from
maine
the
way
we
have
been
doing
and
every
time
a
new
minor
version
is
released,
I'll
just
create
a
branch
for
the
old
minor
version
and
back
back
ports
will
need
to
be
done
manually.
A
So
when
we
create
bug
fixes,
we'll
just
have
to
cherry
pick
them
back
if
it's
possible
and
if
not
we'll,
have
to
just
create
a
new
update
to
backboard
them,
we
don't
have
enough
old
versions.
I
think
to
worry
about
the
burden
of
that.
Quite
yet,
and
I
we
don't
have
that
many
changes,
so
I
don't
think
it
should
be
that
big
of
a
deal.
A
Speaking
of
bug
fixes,
I
did
want
to
pull
out
this
pr.
This
is
a
bug
fix
for
the
grpc
instrumentation.
It
looks
like
valentine
approved
it.
So
if
nobody
has
any
issues,
I
will
merge
this.
A
The
aggregators
pr
is
still
under
review.
I
realize
it's
taking
kind
of
a
long
time
to
get
it
merged,
but
it's
a
big
change.
I
think
at
this
point
everything
has
been
basically
resolved.
I've
approved
it.
I
know
that
valentine
approved
it
this
morning,
but
I
just
wanted
to
give
people
a
you
know
a
last
call
to
review
the
aggregator
pr
and
raise
issues
with
it.
If,
if
nobody
raises
any
problems
with
it,
I
will
probably
merge
it
at
the
end
of
the
day
yeah.
A
At
some
point
we
need
to.
We
need
to
move
on
the
exemplars.
Pr
is
open,
it's
fairly
separate,
so
it
should
be
easy
to
review
on
its
own,
and
it
generally
seems
pretty
good
to
me.
I've
I've
already
reviewed
it
once,
but
it
would
be
nice
to
get
more
eyeballs
on
it
and
I
did
want
to
bring
people's
attention
to
a
new
action
in
the
contribute
which
is
running
the
test,
all
versions
script
in
all
of
the
contrib
packages.
A
It's
not
working
quite
yet,
but
I
know
this
is
something
we've
talked
about
doing
for
quite
a
while,
so
I
just
wanted
to
let
people
know
that,
hopefully
pretty
soon,
we
will
have
that
working.
A
That
was
all
I
had
for
the
agenda
today.
Did
anyone
have
anything
else
that
they
would
like
to
bring
up.
E
Quick
question:
I
remember
there
was
some
discussion
about
like
a
design
dock
for
the
yeah.
A
E
A
That
right
here,
thanks
for
reminding
me.
A
So
I
think
I
know
some
people
have
already
seen
this.
I
think
valentine's
already
seen
it,
but.
A
It
was
mostly
written
by
or
was
essentially
completely
written
by
legendicus,
who
is
the
person
that
made
the
aggregator
pr
and
has
been
very
active
on
the
metrics
sdk
so
far,
you
know
give
it
a
look
over.
I
definitely
make
a
comment
if
you
find
any
issues,
but
it
should
also
help
when
reviewing
prs,
to
have
an
idea
of
his.
You
know
the
design
in
mind
when,
when
he
was
making
the
pr.
C
A
Yeah,
I
think
we're
generally
moving
along
pretty
well.
The
api
is
essentially
complete.
There's
a
couple
of
minor
things
and
the
sdk
is
coming
along
each
each
pr
has
been
pretty
big,
so
they're
taking
a
while
to
merge
because
they're
hard
to
review,
because
they're
so
big.
I
had
been
hoping
that
as
we
move
further
along
and
get
more
of
the
features
implemented,
the
the
prs
will
become
smaller,
but
at
this
point
we're
still
in
fairly
early
development
for
it.
So
I
guess
it
is
what
it
is.
A
I
guess
I
feel
moderately
confident
that
it
will
be
at
least
usable
by
the
end
of
the
year.
I
think
I'd
like
to
release
an
alpha
version
of
it.
Essentially
as
soon
as
it's
usable.
A
And
then
I
would
say,
shooting
for
stability
by
the
end
of
february,
maybe
depending
on
how
the
alpha
release
goes,
I
don't
know
it
it's
hard
so
hard
to
predict
the
timelines.
It
turned
out.
All
of
my
predictions
for
the
tracing
were
were
pipe
dreams
and
it
took
a
year
longer
to
release
than
I
wanted
it
to
so
you
never
really
know,
but
I
would
hope
that
metrics
is
fairly
stable
in
the
next
three
months.
A
Anybody
else
have
comments
or
questions
for
today.
A
Okay,
thank
you
everybody
for
your
time
and
I
will
talk
to
you
next
week.