►
From YouTube: 2021-05-24 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
Yeah
today
it's
we
have
spring
again,
it's
finally
drizzly
and
cloudy.
C
B
A
B
B
D
D
D
D
Okay,
I
guess
we
can
start.
Thank
you
so
much
for
joining
us,
always
yeah,
so
we
can
start
with
the
items
and
for
people
who
just
join,
don't
forget
to
add
yourselves
to
the
attending
list.
As
usual.
Let's
start
with
specification.
D
Most
of
the
schema
changes
related
to
semantic
conventions
are
in
everything,
as
far
as
I
know,
so,
thank
you
to
tigran
for
all
the
effort.
That's
gonna
be
interesting
because
the
next
release,
which
should
be
happening
in
one
or
two
weeks
maximum,
will
have
all
of
that,
so
languages
will
be
able
to
start
implementing
that.
The
second
thing
is
that
the
second
important
change
is
that
the
service
names,
the
service
name,
environment,
variable
and
siblings,
have
been
merged.
D
There
was
some
compromise
there,
so
I
think
we
we
did
the
correct
thing.
Finally,
there's
one
important
thing
regarding
said
status
on
spam
that
we
have
been
discussing
for
a
long
time
now.
There
has
been
some
last
minute
doubts
about
that.
Please
go
discuss
that.
We
will
be
talking
about
that
in
more
depth
tomorrow
for
sure
or
in
the
actual
specification
goal.
So
that's
all
from
or
from
the
specification
side.
A
Yeah
so
last
week,
in
the
specific
meeting,
I
brought
up
a
topic
that
has
been
talked
about
during
the
metrics
sake
meeting
that
we
think
the
api
spec
is
close
to
its
final
shape.
So
we're
looking
for
a
potential
schedule,
change
that
will
we
might
move
the
api
stability
three
months
ahead
of
the
previous
planned
date.
So
at
that
time
we
plan
to
release
the
apn
sdks
back,
both
by
the
end
of
november
this
year,
and
now
we
think
we
probably
should
be
able
to
get
the
stability
around
end
of
august.
A
So
I'm
working
on
a
proposal
and
we'll
get
that
ready
before
tomorrow's
meeting
and
regarding
the
actual
work
the
api
spec
is
almost
there.
We've
resolved
all
the
to
do
items
there's
one
thing
missing.
That
requires
to
do
some
sdk
experiment
before
coming
back
to
the
api,
which
is
the
hint
api.
It
has
a
dependency
on
the
on
the
view
part.
So
the
plan
is
working
to
make
progress
on
the
view
and
hint
this
week
and
and
we
should
be
able
to
get
to
the
experimental
release
on
the
api
by
end
of
may.
A
That's
the
plan
and
even
we're
now
putting
more
focus
on
the
api.
The
sdk
part
might
move
a
little
bit
slower
and
currently
I'm
I'm
reaching
out
to
more
people
and
see
if
we
can
help
so
so
far,
the
icdk
part
we
have
the
skeleton
of
the
spec
and
a
list
of
to-do
items.
So
if
people
can
help,
we
can
potentially
break
down
the
work
and
assign
to
different
people.
So
we
can
divide
and
conquer.
D
D
E
B
I
think
it's
also
worth
calling
on
nikita
that
the
the
proposed
instrumentation
api
that
will
be
published
as
a
part
of
the
instrumentation
project
is
moving
forward
and
all
of
the
existing
instrumentation
is
being
converted
over
to
use
that
new
api.
D
That
sounds
like
like
a
lot
of
work.
Well,
thank
you
and,
by
the
way,
yeah,
I
do
remember
back
in
open
tracing
days.
We
have
this
called
this
thing
called
special
agent,
and
this
is
this
was
indeed
one
thing
that
users
wanted
to
be
able
to
load
external
or
third-party
instrumentation
pieces.
So
thank
you
for
that.
D
Sweet,
javascript.
F
Yeah,
so
we
have
now
incorporated
all
of
the
changes
from
the
spec
review
that
you
completed,
except
for
one,
so
the
the
api
is
essentially
complete,
we're
just
updating
the
sdk
this
week
to
take
advantage
of
the
latest
api
and
then
we'll
have
a
release,
candidate
version
for
the
api
and
the
sdk
and
then
hopefully
a
1.0
release.
D
Nice,
fantastic
yeah,
if
you
need
any
help,
just
let
us
know,
but
the
plan
sounds
great.
D
G
Hey,
I
was
able
to
type
no
updates
but
looks
like
someone
made
some
change.
It's
basically
same
as
last
week.
Just
your
repeat
in
case
someone
missed
the
metrics
apa
part
which
is
being
part
of
the
dot-net
runtime
itself,
so
it
has
merged
and
it
it
will
be
released
as
part
of
the
preview
six
of
dot
net
six
coming
probably
next.
Two
weeks
parallelly,
the
open
elementary
group
is
working
on
the
sdk
implementation
based
on
the
available
api
from
dot
net
runtime.
G
So
that's
the
play
down
matrix
and
yeah.
We
haven't
released
the
1.1
yet
because
we
still
think
there
needs
some
more
polishing,
so
we
are
trying
to
iron
out
some
issues
and
release
1.1
towards
end
of
next
month,
probably
having
another
beta
or
like
the
release
candidate.
Two
weeks
before
that.
D
You,
okay,
what
about
goal.
H
We
are
still
actively
working
towards
our
rc
and
making
progress.
Oh,
we
have
two
open
issues
still
to
do.
Five
in
progress,
293
done
we're
getting
down
into
the
harder
ones,
so
they're
taking
a
little
bit
of
time
and
they're,
resulting
in
some
bigger
prs,
but
we're
actively
moving
through
them.
I
There
have
been
so
like
eight
open
issues
for
the
release
candidate,
one
of
them.
One
of
the
issue
is
basically
the
api
change
which
came
today,
so
we
just
want
to
look
into
that,
how
exactly
to
be
and
whether
that
can
impact
our
release
candidate,
but
I
think
I
don't
know
so
we
plan
to
do
it
to
release
it
by
this
month.
D
I
D
J
Ruby
released
the
the
1.0
rc
late
last
week,
I
think
on
friday,
so
we're
we're
collecting
feedback.
So
if
people
want
to
try
it
try
it
let
us
know,
we
may
also
reach
out
to
the
tc
for
a
a
formal
review,
but
yeah.
That's
what
I
have.
D
D
I
guess
I
guess
no
news
is
good
news
as
well
collector.
K
Hi
everyone
bogdan
did
you
want
to
give
a
quick
update?
I
can
I
at
least
from
an
you
know,
from
an
stats
point
of
view.
Again,
I've
been
triaging,
the
and
tracking
the
backlogs
that
we
have
for
1.0
tracing
stability,
which
bogdan
has
been
you
know
very
prolific
and
adding
to.
But
the
good
news
is
that
on
phase
two
we
have
68
complete.
All
the
issues
are
already
you
know
allocated,
so
people
are
working
on
it
and
phase
two
is
34
complete,
but
you
know
most
of
the
issues.
K
Are
people
have
picked
up
and
are
working
through
it
and
five
issues
are
still
open,
but
those
are
just
in
discussion
so
good,
at
least
maintaining
momentum,
but
there's
a
fair
bit
of
work
to
be
done
there
bogdan
did
you
want
to
add
anything.
K
D
For
your
information,
I
have
been
trying
to
review
more
prs
there.
I
know
that
when
you
guys
need
more
eyes,
so
I
hope
that
thanks.
D
Erlang,
okay,
everything
is
moved
there.
I
guess:
okay,
we
can
now
jump
to
the
rest
of
the
items
lalit
copyright
info,
please.
I
Yeah,
so
this
basically,
I
mean
in
c
plus
plus
we
have
started
looking
into
the
copyright
information
which
we
have
for
every
source
files.
So
we
do
have
some
inconsistencies
of
now
I
mean
some
of
the
files
does
not
have
the
copyright
at
all.
Some
have
the
older
apache
license
information.
Some
have
the
spdx
copyright
license
information
somewhere.
I
The
date
is
missing
data
in
some
of
the
files,
so
we
just
want
to
make
it
consistent
across
all
the
files,
but
before
that
we
wanted
to
check
whether
should
we
write
should
we
do
that
across
all
the
files
or
it's
okay
to
have
that
license
information
in
the
root
repo
and
that
should
basically
work
for
all
the
files
and
in
case
you
want
to
do
it
for
all
this
file.
I
D
Yeah
we
have
this
question
in
the
past
and
there's
something
in
the
community
repo,
but
essentially
I
think
that
every
file
needs
to
have
this
copyright
header.
Even
if
it's
only
a
small
one,
I
don't.
I
don't
think
the
generated
files
need
to
have
that,
however,
walk
down-
or
somebody
else
correct
me
if
I
am
wrong,
but
I
don't
think
protocol
of
generated
files,
for
example,
need
to
have.
L
Yeah,
I
don't
know
the
protocol
of
the
unity
files
will
have
it
by
default
because
the
profiles
have
it.
So
it
doesn't
matter
too
much,
but
I
I
don't
know
I
saw
gold
making
a
change,
they
have
a
tool
for
ad
licensing
and
they
made
a
change
to
not
add
to
auto
generated
files
license.
D
Yeah,
so
let's
follow
up
on
that,
so
I
would
suggest
that
the
actual
files
that
you
guys
write
in
my
hand,
just
put
the
small
notes.
I
I
will
look
for
a
linear
community.
You
don't
have
to
put
like
the
entire
big
one,
just
there's
a
short
version
and
let's
just
follow
open
community
for
the
other
ones.
Yeah.
I
K
K
Just
just
to
be
clear,
let
us
I
mean
I
saw
your
changes
in
terms
of
adding
copyright
copyrights
to
the
files
I
mean
so
typically,
the
standard
practice
is
to
have
you
know
the
license,
details
in
one
license.text
and
and
then
just
referring
to
that
with
a
short
header
in
the
in
the
files
themselves.
D
Thank
you
for
that
and
don't
forget
to
follow
to
fit
an
issue
in
the
community
repo
sure.
Okay,
very
good.
Next
item
lolita
all.
K
Right
so
lots
of
lots
of
you
know
my
some
minor
updates,
but
again
this
is
towards
the
goal
of
having
consistency
and
across
all
our
reapers.
So
one
of
the
things
that
we
had
started
earlier
was-
and
this
is
an
request
coming
in
from
the
incubation
process
and
the
toc
review-
there
was
a
request
for
adding
consistency
and
badges.
You
know
for
the
ci
builds
and
the
status
for
that,
as
well
as
a
code
curve,
status
and
and
requests
for
badges
there.
K
So
that's
something
that
we
have
been
adding
to
all
the
repos.
Again,
there
are
prs.
You
know
that
different
maintainers
have
been
looking
at
and
merging.
So
thank
you
to
everyone
and
also
so
bogdan.
In
response
to
your
question,
I
didn't,
I
think
code
cup
is
being
consistently
used
now.
What
was
deprecated
was
circle
ci
instead
of
github
actions.
Right
so
is
that
something
I'm
missing
or
it's
you.
K
Yes,
no,
I
understand
that,
but
it's
still
all
we
are
doing
is
here
just
instrumenting
the
status
from
wherever
it's
running
still
so.
K
Well,
it's
still
running
so
in
some
repo,
so
I
can.
I
can
definitely
give
an
update
on
you
know
which
reapers
it's
still
running
on.
K
Okay,
so
that
I
mean
that's
an
parallel
action
item,
so
I
think
we
should
probably
follow
up
on
that,
but
this
was
just
adding
the
badge.
Okay.
So
again,
you
know
we'll
make
sure
that
we
circle
back.
That's
a
good!
You
know
call
out,
though,
and
also
we've
been
adding,
so
my
team
has
been
adding
security
scan
workflows
for
all
the
repos
that
were
remaining.
K
We
had
started
this
work
last
year
late
last
year,
so
you
know
again
just
completing
out
the
remaining
repos
in
terms
of
having
a
security
scan
again
code
ql
out
of
the
box
does
not
support
all
the
languages
that
we
have
supported
on
open
telemetry
today,
but
that
said
again
for
the
languages
that
it
does
support.
You
know
that
we've
been
adding
those
scans
as
github
workflows,
actions
workflows,
so
just
just
fyi
for
everyone
and
then
again,
thanks
to
the
maintainers
for
taking
a
look
and
reviewing.
K
And
and
last
but
not
least,
I
just
wanted
to
give
an
update.
There
is
an
otep
that
I've
been
working
on
with
josh
surat
from
google
and
just
you
know,
making
some
suggestions
for
ramping
up.
You
know
and
I
plan
to
walk
through
this
with
tigran
and
others
and
carlos,
I
think
you
and
I
need
to
probably
think
up,
because
that
has
some
impact
on
the
instrumentation.
K
You
know
contribution
discussions
that
we've
had
so
I'll.
Take
a
look
at
your
pull
request
and
also
think
back
up
with
you.
D
Perfect
yeah
thanks
so
much
for
that
yeah.
Looking
forward
to
that
yeah,
the
last
item-
yeah,
perfect,
sorry,
my
internet
connection
is
probably
I
think,
it's
unstable,
but
I
would
try
to
keep
talking.
The
last
item
is
this
update
for
instrumentation
ecosystem
handling?
This
is
something
that
nikita
started.
It
has
enough
approvals.
D
We
have
a
last
minute
considerations,
but
it's
all
looking
great
in
my
opinion-
and
I
will
be-
I
will
be
using
that
by
the
end
of
the
day
honestly,
but
it's
against
that.
So
please
take
a
look,
otherwise
we're
cool
and
we
can
start
working
on
actually
making
this
part
of
the
specification.
K
K
I
just
had
a
question
on
the
metrics
roadmaps,
so
riley
you
had
mentioned
that
you
know
we're
ahead
of
schedule,
which
is
really
exciting.
Are
the
you
know
backlogs
you're
maintaining
or
the
roadmap
roadmaps
up
to
date?
Yes,
okay,
okay,
great
great,
because
I've
been
maintaining
the
prometheus,
you
know
items
in
flight
and
again,
I'm
not
sure
if
we
are,
if
we
have
a
more
comprehensive
end-to-end
roadmap
for
all
the
different
items,
should
we
be
having
that
someplace
or.
A
Yeah,
so
we
already
have
that
on
the
top
level,
open
telemetry
projects
and-
and
I'm
I'm
pretty
confident
that
we
covered
all
the
api
issues.
So
if
there's
any
remaining
api
work,
it
should
it
should
have
the
github
issues
and
it
should
show
up
in
the
board.
Well,
we
might
not
have
all
the
issues
for
the
isdk
because
we're
still
exploring
the
idk,
so
that
might
not
be
a
complete
list.
K
Okay,
and
and
what
about
the
collector
is
that
that,
because
that's
not
there
at
all
as
a
as
a
project
board
logged
in,
do
you
have
thoughts
on
that?
K
A
Right
right,
just
curious,
I
know
josh
has
been
maintaining
the
metrics
data
model
project
board.
So
how
do
we
think
about,
like
the
data
model
versus
protocol
collector?
Do
we
think
we
should
track
them
in
the
same
project
or
they
should
have
two
separate
or
three
separate
projects.
K
A
M
Yeah
yeah.
I
think
this
is
actually
something
that
josh
suret
is
going
to
bring
up
at
the
spec
meeting
tomorrow,
attempting
to
get
some
clarification
about
the
relationship
between
the
spec
repo
and
the
proto-repo
as
far
as
defining
protocol
stuff,
because
there
is
some
aspects
of
protocol
that
are
defined
in
the
spec
and
a
lot
of
that
work
seems
to
be
done
directly
through
the
proto
repo
and
it's
just
an
area
where
we
don't
actually
have
a
process
written
down
really
about.
If
you're
making
a
change
of.
M
Where
do
you
actually
go
to
make
that
change
and
have
that
discussion?
So
just
fyi
that'll
be
coming
up
in
the
spec
meeting
tomorrow.