►
From YouTube: 2021-08-30 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
B
B
Interesting
yeah,
let
me
put
it
in
the
chat.
Oh
looks
like
daniel
beat
me
too.
E
Weird:
okay,
let
me
real.
F
F
B
B
Let's
get
started
with
the
sick
check-in
all
right,
so,
first
up
the
spec
sig
had
its
1.6.1
release
without
saying,
don't
use
1.6.0.
It
has
a
broken
schema.
H
Yeah,
that's
correct.
This
was
reported
initially
by
john
watson.
Thank
you
so
much
for
that
we
did
a
code
release
which
corrects
some
stuff
that
was
released
broken.
I
don't
know
instagram
in
the
call
on
their
mind,
because
we
are
discussing
with
him
final
details.
H
We
still
need
to
publish
the
actual
schema
for
this
release.
Other
than
that
we
are
fine
but
yeah.
I
went
and
did
a
small
review
in
all
the
six
and
I
think
nobody
was
using
1.6.
H
But
if
you
are
not
aware
of
this,
please
don't
use
that
one.
You
go
for
1.6,
one.
I
So
the
api
spec
for
matrix
has
been
there
for
two
months
without
yet
any
issue
and
people
implement
that
during
the
prototype
seems
to
be
stable.
I
wonder
if
we
should
give
maintainers
some
more
time
just
to
do
more
implementation
or
release
now,
according
to
our
original
plan,
like
end
of
this
month,
would
be
the
matrix
api,
stable
release.
So
I'll
bring
this
up
in
tomorrow's
meeting.
B
I
feel
like
two
months
is
a
long
time
I
mean
we've
got
the
maintainers
on
the
call
like.
Are
there
any
objections
to
marking
us
this
table
this
week?
So
I
think
the.
F
The
only
concern
is
it.
My
guess
is
that
very
there
haven't
been
very
many
users
who
have
been
exposed
to
it
to
the
actual
implementations
and
without
actual
user
feedback.
We
might
be
back
where
we
were
when
we
thought
we
had
a
stable
api
before
so
I'm
really
hoping
we
could
get
some
feedback
and
some
input
from
like
some
folks
from
the
micrometer
community
in
java
on
and
possibly
some
other
metrics
communities
before
we
look
at
that
staple.
J
B
F
B
What's
the
riley,
what's
the
current
like
marking
or
status
that
we've
given
this,
is
it
just?
Is
it
already
a
release
candidate.
F
I
Fight
any
new
thing,
but
yeah
we
haven't
yet
promised
there
won't
be
any
breaking
changes
and
just
coming
back
to
the
feedback,
I
think
the
micrometer
community
has
been
working
closely
when
we
put
the
api
like
prs
and
we
got
the
pool
from
them.
So
I
I
think
the
only
outstanding
feedback
is
many
folks
would
want
to
have
a
timer
instrument
to
make
make
marrying
duration
a
bit
easier,
but
we
decided
that
can
be
added
as
a
non-breaking
change
after
the
initial
release.
So
to
me
there
is
no
outstanding
blocker
from
the
micrometer
community.
F
So
I
know
that,
right
now,
in
java,
contrib
there's
some
work
to
try
to
build
bridges
between
micrometer
and
open
telemetry
metrics
I'd
like
those
to
go
to
little
go
a
little
bit
further
to
flush
out
any
incompatibilities
and
understand
where
the
possible
breakages
are.
I
literally
just
started
this
weekend,
so
I
think
that
we
need
a
little
bit
more
time
there
yeah.
I
J
I
I
J
B
All
right
any
updates
on
logs,
I
wasn't
at
their
last
call
all
right.
I
will
take
the
action
to
get
the
update
on
that
php.
We
have
issues
marked
as
required
for
beta
and
required
for
ga
cool.
These
tickets
will
need
to
be
completed
before
we
do
an
official
release,
no
eta
and
we
haven't
had
nearly
enough
contributors.
Unfortunately,
that's
common
to
facilitate
these
tickets
being
finished,
okay,
but
bob
great
that
you've
started
tracking
these
I'm
just
going
to
quickly
switch
to
these
they've.
B
Yeah,
that's
actually
well,
actually
that's
a
fairly
big
list:
okay,
cool
java,
continuing
metrics
work
added
some
performance,
tweaks
job
instrumentation,
metric
cardinality
explosion
discovered
last
week
in
http
client
instrumentation
code
patch
was
released
to
address
it.
Okay,.
F
Yeah,
I
think
it's
also,
though,
worth
calling
out
that
this
really
highlighted
that
without
the
hint
api,
the
sdk
doesn't
have
a
real
good
way
at
the
moment
to
to
deal
with
this
and
sdk
specification
currently
doesn't
have
any
well-defined
way
to
protect
applications
in
the
when
they
when
exposed
to
a
metric,
cardinality
explosion.
Internally,
so
like
there
was
an
issue
logged
for
it.
We,
when
we'll
talk
about
it
more
in
metrics,
saying
I'm
sure.
B
F
The
hint
api
is
a
thing
that
is
exposed
will
be
exposed
in
the
api,
not
sdk,
and
would
allow
the
hdp
instrumentation
to
say
here
are
the
things
that
are
going
to
be
that
we
here
here
are
going
to
be
low,
cardinality
that
the
tags,
the
attributes
that
we
put
in
here
and
one
of
the
things
that
got
put
in
as
attributes,
was
the
the
http
url
for
the
client,
which
of
course
is
you
know,
essentially
infinite
cardinality
explosion.
So
the
sdk
didn't
know.
This
is
something
it
should
ignore
or
not
use
for
doing.
F
Yeah
anyway,
so
the
hint
api
would
have
made
this
issue
much
yeah
as
user
much
retractable
for
the
sdk
hasn't
been
specked
yet,
and
I
know
it's
not
planned
for
the
first
release
as
well.
At
least
I
think
that's
true.
Well,
if
the
api
is
going
to
be
stable,
then
obviously
it's
not
going
to
be
in
there
for
the
first
release,
but
this
is
something
that
I'm
sure
will
continue
to
come
up
as
google
metrics,
you
start
using
the
metrics
api.
B
Yeah,
okay,
cool
thanks
for
the
context,
javascript
cncf
issue
that
was
blocking
1.0
last
week
is
still
unresolved.
We
have
decided
to
work
around
it
by
running
our
release,
automations
on
a
fork
using
the
personal
token
of
one
of
our
maintainers,
but
there's
not
actually
a
long-term
solution.
Yeah
should
at
least
allow
us
to
release
1.0
this
week.
So
far,
the
give
action,
assigning
ownership,
sub
components
to
contribute
pro
has
been
very
successful.
Feedback
has
been
that
the
component
contributors
feel
that
they've
been
have
much
more
say
over.
B
D
I
don't
really
have
anything
to
say
beyond,
I
did
add
a
topic
for
the
you
know
after
the
check-in
to
talk
about
the
branch
protection
rules,
to
figure
out
what
other
people
have.
You
know
what
other
things
people
have
done
to
work
around
these
rules,
because
they've
been,
I
think,
causing
issues
for
other
cigs
too.
This
is
the
second
bullet
you're,
referring
to
correct
no.
D
L
Also
talk
about
that.
Okay,
we'll
get
that
at
the
end,
and
I.
J
Was
out
one
question
real,
quick,
yeah
daniel?
Do
those
component
contributors
show
up
to
the
js
meeting?
Can
I
find
them.
D
Some
of
them
do
some
of
them.
Don't
we
mostly
allow
them
to
work
asynchronously
since
they're,
only
contrib
components,
they're,
not
like
core
sdk
components
or
anything
like
that,
there's
a
sort
of
a
lower
barrier
yeah.
We
have
essentially
told
them
that
if
they
are
not
active
on
issues
that
are
automatically
assigned
to
them,
then
you
may
have
your
you
know:
component
ownership
revoked
at
the
discretion
of
the
maintainers.
J
Okay,
if
I
want
to
get
feedback
from
them
from
the
we're
starting
these
instrumentation
groups
to
to
focus
on
semantic
conventions
and
helper
functions,
and
things
like
that,
so
I'd
love
to
get
feedback
and
involvement
from
these
kind
of
component
contributors.
Do
you
think
slack
is
a
good
place
to
reach
out
to
them.
D
Yeah,
I
think,
that's
probably
a
great
place
honestly,
the
the
component
contributors
that
we
have
so
far,
even
though
we
have
no
requirement
to
join
the
meeting,
they
typically
do.
Okay,
you
can
also
find
their
github
names,
at
least
in
this
file,
which
I
will
put
in
the
chat
great.
So
if
you
want
to
reach
out
to
them
that
way,
I
believe
they're
all
on
slack.
Okay,.
B
B
Views
are
expected
next
act
for
alpha
3.
great
go
has
had
stable
release
pro
progress,
so
there's
one
to
do.
Seven
in
progress
and
51
done
plan
to
have
another
rc
out
this
week,
fantastic
and
c,
plus
tc
review
status
for
1.0.0,
trace
release
done
by
josh
total
of
eight
issues.
Six
are
closed.
Two
are
still
open,
estimated
release
date
six
of
september,
one
that's
made
fast
progress
there.
B
B
All
right
moving
down,
finally
collector
cork
and
trib
split,
is
almost
done.
A
few
fewer
than
five
of
pr's
left
to
split
from
the
main
issue,
a
few
items
left
to
the
collector
model
and
core
rc
quick
question
for
collector,
because
I
last
checked
in
validate
a
few
weeks
ago.
How
are
we
trending
towards,
like
I,
I
see
this
update
but,
like
generally,
how
are
we
trending
towards
the
1.0
release,
at
least
for
tracing.
K
B
Yeah,
but
for
the
rc,
is
it
really
just
the
the
cork
and
trip
split?
Is
that
just
getting
through?
That
is
the
main
thing
holding
us
up.
K
B
Cool
all
right
and
no
updates
from
erlang,
so
dan
we
already
have
some
context.
Do
you
want
to
take
it
away.
D
Sure
so
I
think
that
at
least
the
folks
in
the
collector
are
familiar
with
this
issue,
but
some
three
weeks
ago,
maybe
a
branch
protection
rule
which
applies
to
all
branches
was
automatically
added
to
all
repositories
that
blocks
any
non-cla
contributions,
which
is
fine,
except
that
it
also
blocks
pushing
any
branches
without
creating
a
pull
request
and
there's
obviously
no
way
to
push
a
branch
to
create
a
pull
request
from
without
having
a
fork
or
something
like
that.
D
So
what
that
means
is
like
any
release,
automations
or
anything
like
that-
are
basically
required
to
have
an
external
non
cncf
dependency
in
order
to
be
able
to
create
pull
requests
like
we
wanted
to
have
a
release,
automation,
create
release
poll
requests
and
we
couldn't
have
it
push
branches
on
our
repository
to
create
the
pull
requests
from,
and
it
seems
like
kind
of
a
weird
requirement
to
require
an
external
dependency
as
part
of
that
flow
yeah.
D
D
So
I
am
essentially
just
wondering
if
anyone
else
has
has
come
up
with
better
workarounds
than
than
what
I
have
the
gh
page
is
one.
I
really
have
no
work
around
for
other
than
begging
cncf
for
an
exemption
which
they
I
was
told
by
them
that
they're
having
internal
discussions
around
exempting
specific
branches,
but
no
feedback
on
like
what
the
timeline
for
that
would
be,
or
anything
like
that.
C
K
So
only
kubernetes
and
grpc
are
using
cla,
the
rest
are
using
the
the
peso
or
whatever
is
called
the
other
way
of
yeah.
Of
of
protecting
this,
I
think
it's
a
known
issue
and
cncf
is
trying
to
use
that
to
fix
that,
but
I
I
I
don't
have
any
I
mean
what
we
can
do
right
now
is
to
probably
make
some
special
rules,
for
example,
for
the
release
branches.
I
I
expect
you
daniel
you
name
them
release
something,
so
you
can
make
a
rule
that
matches
release
something.
D
Yeah,
so
that
definitely
works
for
those
that
don't
know
branch
protection
rules
are
applied
in
order
of
specificity.
So
if
you
have
this
catch-all
rule
any
rule,
that's
more
specific
than
that,
like
a
prefix
rule
will
override
it,
which
is
what
I
think
bogdan
is
referring
to
yeah.
D
G
D
M
So
the
problem
actually
is
a
little
bit
more
like
idiotic.
If
I'm
just
going
to
be
transparent
about
the
thing
like
you
can
open
a
pr
and
that's
fine,
but
then
it
will
run
the
action
on
that
pr
right.
You
can
no
longer
push
to
that
branch,
because
it's
a
established
branch
in
the
main
repository
unless
that
action
has
already
been
run
on
the
commit
you're
about
to
push.
M
Either
that
I
don't
think
is
actually
true,
like
the
the
creation
of
a
branch,
is
fine,
it's
just
it'll,
then
be
a
protected
branch.
I
haven't
validated
that
you
may
be
right
down,
but
like
based
on
what
our
our
bots
have
been
doing.
They
can
still
create
the
branch,
but
the
problem
is,
then:
they
can't
update
the
branch,
because
all
of
the
commits
they're
trying
to
push
to
that
branch
are
not.
They
don't
have
the
easy.
Cla
action
run
on
them,
yet
they
have
to
be
pushed
before
they
can
be
run.
M
That's
in
the
main
repository
like
even
you
know,
cncf
members
who
I
don't
know
they
could
they
can
give
themselves
carb
launch
like
they
can't
push
commits
because
those
commits
have
not
had
the
action
run
against
them
and
those
commits
do
not
have
a
validation
of
the
cla.
C
D
I
mean
I
guess
in
the
easy
cla
channel
it
might
be
helpful
if
someone
from
the
tc,
you
know
at
least
plus
one
my
my
comment
and
said
to
make
it
clear
that
I'm
not
the
only
person
running
into
this
and
that
this
is
kind
of
time
sensitive.
D
L
D
So
a
plus
one
from
someone
else
might
help,
there's
also
an
issue
on
their
tracker.
That.
D
Yeah
and
it's
if
you
support
63,
56
or
whatever,
but
I
don't
actually
have
permission
to
view
this-
I
don't
know
how
many
people
do.
Obviously
liz
does
that's
the
previous
one,
okay
so,
and
it's
actually
a
related
but
different
issue,
so
this
ticket
is
for
exempting
the
github
actions
bot
from
the
cla
check.
D
B
Okay,
bogdan
and
carlos,
could
both
of
you
go?
Follow
that
slack
link
and
just
reply
saying
I'm
on
the
hotel
technical
committee?
This
is
blocking
us
right
now
like
can
we
get
some
kind
of
exemption,
or
can
we
like
allow
list
our
bots
or
just
do
something
in
the
immediate
term,
to
unblock
everything.
K
D
Take
it
from
from
what
everybody's
saying
nobody
has
thought
of
a
better
workaround
than
use
a
fork
and,
like
a
personal
access
token
from
a
maintainer,
correct,
yeah,
okay!
Well,
unless
we
can
get
an
exemption,
that's
what
I'm
just
gonna
do
for
now,
because
we've
been
waiting
for
like
three
weeks
on
this
release.
Okay,
so.
M
I
think
it's
I'm
just
going
to
go
on
record,
saying
it's
a
bad
solution.
D
D
Like
I
don't
want
to
give
my
personal
access
token
to
anything
really
because
it
can
control
all
kinds
of
things
that
you
know,
I
don't
want
it
to
have
access
to.
J
I
mean
I
would
almost
suggest
going
ahead
and
doing
the
the
more
specific
release
branch
protection
rules.
D
Yeah
I
mean,
if
I'm
going
to
do
that,
I
at
least
want
like
an
official
thumbs
up
from
either
someone
at
the
cncf
or
you
know.
Maybe
we
have
a
gc
or
a
tc
vote
to
just
say
this
is
what
we're
going
to
do,
because
as
a
as
an
individual
maintainer,
I
don't
necessarily
feel
comfortable
breaking
one
of
the
rules
that
they
have
specifically
put
in
for
legal
reasons.
B
Just
do
anything
yeah,
of
course,
of
course,
let's
talk
about
this
on
thursday
and
maybe
use
that
as
I
work
around
instead
of
having
to
rely
on
people's
like
creating
external
reports
that
we
have
the
dependency
on
and
and
potentially
having,
you
input
your
personal
access,
token
yeah,
that
that
feels
like
almost
like
a
worse
legal
issue.
I
agree
legal
and.
B
Issue
at
that
point:
yeah:
okay,
okay,
any
other
discussion
points
on
this.
B
H
Yeah,
perfect
yeah,
it's
a
very
small
issue.
We
were
talking
in
dtc
about
finding
some
very
general
set
of
guidelines
when
it
comes
to
issues
and
prs
and
when
they
come
when
they
become
stale
and
they
can
be
closed.
The
initial
proposal-
and
it's
only
a
proposal,
is
that
we
have
a
minimum
time,
so
issues
would
require
one
year
without
any
activity
before
they
can
mark
as
stale
and
close
immediately
and
for
pr's.
H
It
would
be
seven
days
at
stale
seven
days
close
afterwards,
but
I'm
we
are
happy
to
discuss
the
options
there.
This,
of
course,
is
concerning
the
maintainers
here.
Chris
anomieler,
for
example,
says
that
he
thinks
that
specifying
some
timeline
for
this
is
probably
not
a
good
idea
so
happy
to
discuss
out
there.
Just
please
take
a
look.
J
Yeah
so
just
fyi,
there's
an
instrumentation
sig,
that's
been
meeting
informally,
but
it's
finally
getting
around
to
adding
some
formal
meetings
to
the
calendar.
I've
gone
ahead
and
put
these
meetings
on
the
calendar,
but
it
would
be
great
if
this
pr
could
get
approved
so
that
it
can
get.
C
J
To
get
added
to
the
community
repo
and
also
fyi
for
people
who
are
interested
in
semantic
conventions
or
instrumentation,
it
would
be
great
to
join
these
meetings
again,
that's
figuring
out
what
we
need
to
do
so
that
we
can
start
declaring
contrib
packages
as
stable.
J
That's
that's
the
ultimate
goal
for
these
meetings,
so
perhaps
in
your
sigs,
I'm
gonna
try
to
go
around
to
the
sigs
whose
meetings
I
can
make
it
to,
but
if
maintainers
wouldn't
mind
just
bringing
this
up
in
your
your
sig
meetings
and
just
raising
some
awareness,
this
is
happening
so
that
contribute,
maintainers
and
others
can
can
show
up
and
have
their
opinions
heard.
Be
great
awesome.