►
From YouTube: 2021-08-09 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
Okay,
let's
jump
into
the
action
it's
five
minutes
after
starting
time,
so
yeah
okay
agenda
seek
check-in
specification.
Yeah,
we
did
release
1.6
last
friday,
so
it's
filled.
It's
ready
there
for
you
to
review
yeah.
We
had
to
hold
a
pair
of
pr's
like
this
nikita
nikki
spr
that
he
had
regarding
effort.
What
was
that
anyway,
but
yeah?
Hopefully
now
we
can
merge
more
prs.
Now
we
we
had
the
release
metrics
api
spec,
reach,
future
freeze.
A
Ioc
riley
nor
j
mcd,
john
john
watson-
maybe
did
you
you
have
any
update
there.
Are
you
up
to
date
what's
happening.
C
A
Yeah
so
yeah,
as
you
can
see,
there's
basically
the
api
expect
that
for
each
feature
freeze,
so
that's
good
news.
Okay,
moving
on
logs
no
updates
this
week,
php-
probably
nothing
yeah.
I
don't
see
anybody
here
from
that
sea.
Okay,
jabba,
john,
now,
you're
your
turn.
C
Yep,
just
as
I
wrote,
we're
probably
going
to
be
releasing
1.5
later
this
week
and
we're
continuing
to
do
the
metrics
rewrite
led
by
josh
service.
So
that's
that's
where
we
are.
A
Okay;
okay,
thanks
for
that
java
instrumentation,
I
don't
see
trask
here
so
an
update.
I
guess
that
they
will
be
releasing
1.5
after
the
java
1.5
releases
on.
D
Yeah
so
we're
preparing
for
the
sdk
1.0
release.
I
know
that
I've
said
in
previous
meetings.
We're
making
tooling
changes
so
we're
just
wrapping
that
up
and
then
we're
also
going
to
be.
I
added
it
later
as
a
topic,
but
I'd
like
to
talk
about
a
github
action
that
I
wrote
that
we're
going
to
be
using
to
manage
ownership
for
our
contributory
bill.
But
we
can
talk
about
that
later.
A
B
Yeah
we
are
making
some
steady
progress
towards
disabled
release,
taking
off
items
additionally,
gmacd
has
jumped
in
he's
been
working
with
us
on
matrix
api
and
sdk
refactors,
so
yeah
a
lot
of
good
progress.
There.
A
Nice
pretty
smooth
thank
you
c,
plus
plus.
E
Yeah,
so
we
had
a
release
candidate
for
last
week.
This
was
a
big,
bigger
release.
We
had,
I
mean
quite
a
few
important
memory
and
performance
issues
got
picture
and
I
think
it
looks
into
a
good
shape
and
probably
something
which
can
be
a
candidate
for
1.2.
E
So
I
think
we
want
to
propose
this
for
review
by
technical
community
or
gc.
I
mean
as
a
candidate
for
v
1.0,
so
yeah,
and
apart
from
that,
I
think
there
was
a
basil.
We
needed
basal
expertise,
so
there
are
some
components
where
basal
build
is
missing
or
not
complete.
So
I
think
we
will
like
to
take
that
as
exception,
because
that
is
not
going
to
change
even
though
you
get
implemented
after
1.0.
I
think
that
will
be
still
good.
A
Yeah
I
was
wondering
whether
he's
back
from
holidays
or
not,
if
he's,
let's
sync
up
with
him,
if
he's
back,
let's
ask
whether
he
can
help.
If
not,
somebody
else
will
have
to
help
on
the
front.
G
A
Have
been
yeah,
I
just
want
to
say
that
I
have
been
doing
reviews
myself,
I'm
happy
to
have
josh
do
that
if
he
can't,
I
would
try
to
do
that.
I
will
sing
with
you
lalit
after
the
call
later
today.
A
Thanks
so
much
ruby,
no
updates!
I
guess
swift.
G
Yeah
yeah,
I'm
here,
yeah
we're
doing
another
release
tomorrow,
just
with
the
network
spec
update.
So
that's
coming.
A
Okay,
collector.
F
We
had
a
release-
I
don't
know
if
that
was
noted
like
a
week
and
a
half
ago
that
will
move
to
to
the
new
matrix
to
the
zero
eight
actually
not
to
the
zero
nine.
We
are
actively
working
to
move
to
zero.
Nine
alex
is
doing
a
bunch
of
work.
F
Other
things
we
are
super
close
to
to
finish
the
first
phase
of
tracing
items
for
for
making
a
release
candidate
for
that
part
of
the
collector.
That's
probably
gonna
happen
this
week
next
week
to
finish
the
items
and
make
the
first
rc
for
that.
A
A
C
So
this
is
something
that
came
up
during
the
metrics
sig
meeting
this
week,
that
you
know
bogdan
just
you
know
mentioned
a
little
bit
about
working
on
getting
to
0.9.0
for
the
collector,
but
I
think
the
bigger
question
for
maintainers
and,
for
you
know,
the
maintainer
of
maintainers
of
the
collector
and
otlp
proto
is
how
are
maintainers
supposed
to
know
when
they
are
then
should
upgrade,
just
as
a,
for
instance,
java
upgraded
to
0.9.0
like
two
months
ago,
when
it
was
released.
C
We're
trying
to
really
be
you
know,
keep
up
to
date
when
they're
new
releases
of
the
proto,
you
know,
get
the
get
the
sdk
up
to
date
with
it
and,
of
course
the
collector
doesn't
actually
support
9.0
at
the
moment.
So
the
big
question
is
how
are
maintainers
like
what
is
the
process?
How
are
maintainers
supposed
to
know
when
they're
supposed
to
upgrade
the
proto
in
their
sdk
to
ship
them.
F
F
Yeah
john
to
to
be
to
be
a
bit
picky
here.
I
think
we
will
not
have
another
case
like
this,
because
matrix
is
stable,
tracing
is
stable,
so
even
if
we
don't
upgrade,
nothing
will
be
a
problem
from
this
moment.
This
was
indeed
a
big
problem
for
java,
because
couple
of
users
who
try
to
use
that
we're
not
getting
the
right
output.
D
Well,
there's
at
least
one
other
change,
the
the
port
changed
for
the
otlp
http
and
that's
already
done
for
us
yeah,
but
it
had
the
same
problem.
The
specification
went
in
before
the
collector
actually
supported
it
and
js
had
almost
the
same
problem.
We
changed
the
default
port
and
it
didn't
work
with
the
latest
collector.
F
I
know
I
know
I
think,
that's
a
that's
a
very
interesting
point.
I
I
would
say
that
if
we
want
to
do
something
like
this,
especially
when
it's
a
breaking
change,
I
I
think
the
right
way
to
do
by
the
way
I
think
now
to
give
a
bit
of
a
feedback
to
to
john,
for
example,
I
think
which
java
should
have
sent
the
old
and
the
new
data,
because
the
receiver
may
be
changed
or
not
similar
for
you,
daniel.
F
You
should
have
tried
the
new
port,
but
if,
if
not
able
to
connect,
you
should
have
tried
the
the
old
port
well
yeah,
to
be
clear.
We
never.
D
F
Yeah,
but
but
to
be
clear,
how
would
you
do
this
if
it's
a
backwards?
If
it's
a
breaking
change
like
this,
you
have
to
do
it
in
a
backwards
compatible
way
correct.
So
you
should
your
library
should
be
able
to
work,
even
though
the
the
receiver
updated
or
not.
Even
if
I
make
the
collector
a
change,
the
user
may
still
use
the
old
version,
so
your
library
still
still
should
be
able
to
to
send
data
to
the
old.
F
D
F
H
It
definitely
sounds
like
I
mean
in
general
backwards,
incompatible
changes
should
be
avoided,
and
if
we
are
going
to
put
something
like
that
in
there,
it
seems
like,
along
with
that,
should
be
some
kind
of
migration
plan.
Right,
like
I
think
what
you're
saying
bogdan
is
probably
like
a
correct
course
of
action,
but
just
a
triaging
here
it
seems
like
that's
the
kind
of
thing.
Maybe
we
should
have
put
into
the
the
spec
as
we
were,
making
these
changes
so
there's
some
clear
expectations.
H
It
also
seems
like
in
general,
the
collector
should
probably
be
implementing
the
latest
version
of
proto
changes
before
clients.
Release
right,
like
that
should
probably
be
an
expectation,
would
be
my
guess.
The
collector
should
be
first.
There.
H
Shearing
changes
like
backwards
incompatible
changes
where
there
it's
not
feasible
for
a
collector
to
support
both
but
sorry
for
clients
to
support
both
the
new
and
the
old
version
like.
I
think
those
really
need
to
be
avoided
like
we
should
never
actually
introduce
a
change
like
that,
but
that
doesn't
seem
to
be
the
case
this
time.
This
time,
it
just
seems
like
we
didn't
actually
write
down
what
the
what
the
backwards
compatibility
course
of
action
was.
F
Correct
and,
for
example,
in
the
collector
we
do
our
best.
So
if
we
receive
the
old
data,
we
transform
them
into
the
new
data
and
stuff
like
that.
So
so
we
do
our
best
to
to
to
keep
backwards,
compatibility
and
and
try
to
to
to
not
break
things.
But
indeed
again,
this
was
a
problem
in
the
collector
that
we
were
behind
on
that.
F
But
in
general
I
think
as
a
rule
of
thumb,
we
should
not
rely
on
the
fact
that
user
may
upgrade
to
the
latest
collector
immediately,
so
everything
even
in
the
library
should
be
implemented
with
a
with
a
mindset
that
it
should
work
with
the
older
version
of
the
collector.
Even
though
the
collector
is
upgraded
to
the
new
yeah.
B
We
also
have
multiple
signals
coming
down
the
pipeline
as
well,
like
I
don't
imagine
like
tigran's,
really
methodical
so
logs,
maybe
not
won't
have
as
many
like
issues
but,
like
you
know
what
happens
when
we
do
profiling
or
events
or
some
other
thing
coming
down
the
the
pipeline,
and
I
think
this
kind
of
gets
it
like
just
dismissing
and
saying
like
we
are
going
to
do
it
again,
may
not
be
like
the
best
approach
for
the
long
term.
Health
of
us
actually
like
doing
this
development.
B
I
I
would
like,
as
well
with
like
what
john's
asking
for
you
know,
go
upgraded
to
the
latest
as
well,
and
we
were
fielding
a
bunch
of
questions
from
users
saying
like
I'm,
not
getting
metric
data
showing
up
correctly
and
after
disentangling
a
lot
of
things
we
realized
like.
It
was
like
this
proto-incompatibility
thing
that
was
actually
happening
was
just
like
we
upgraded,
but
the
collector
wasn't
actually
supporting
those
new
versions,
and
so
like
I
I
you
know,
we
would
have
just
not
have
upgraded,
and
I
think
that
would
have
been
really
helpful.
B
You
know
it's
also
like
an
unstable
signal
so,
like
I
also
like,
don't
have
that
much
empathy
as
well
like
you're,
gonna
kind
of
deal
with
these
sort
of
things,
but
I
do
think
like
we
need
to
like
kind
of
like
actually
address
the
unknowing
issues.
So,
like
you
know,
should
we
have
released
the
proto
as
a
pre-release
and,
like
you
know,
put
a
little
bit
more
burden
on
like
the
ghosts
to
go
and
investigate
when
they
should
upgrade
it
or
or
is
there
some
other
like
communication?
F
I
I
see,
I
see
your
point
and
I
think
yes,
indeed,
it's
probably
going
to
happen
again,
maybe
even
with
logs,
if
if
there
is
something
bad
in
logs
there's
something
right
upgrade
that
needs
to
happen.
F
B
Yeah
is
there
like
a
way
that
we
can
update
like
the
release
process,
or
I
don't
know
like?
Is
there?
Are
there
things
that
come
to
mind
that
are
like
really
easy
that
we
could
just
start
implementing
right
now,
bogdan,
like
I
feel
like
you
might
have
some
good
ideas
like
you
have
multiple.
It
sounds
like.
F
That's
my
first
question
that
I
don't
know
the
answer
and
how
we
want
to
handle
that
case,
because
the
answer
is
different.
Based
on
the
that
question,
if.
F
No,
no!
No,
but
what
I'm
trying
to
say
is:
if
that's
the
the
thing
that
we
want
to
tell
users,
then
the
process
can
be
as
simple
as
everyone
should
follow.
The
should
upgrade
the
proto
after
the
collector.
Oh
okay,
I'm
sorry!
I
see
what
you're
saying
yes,
if
that's
not
the
answer,
then
I
think
we
should
come
up
with
a
better
plan
and
better
migration
plan
for
every
library,
like
example,
with
the
port.
I
think
the
right
implementation
could
be.
B
I
think
that
that's
probably
the
best
way
forward
because
I
don't
know
of
anybody
who's
using
well.
I
think
that
the
only
other
people
that
are
using
the
otlp
are
to
send
directly
to
vendors
right,
and
I
guess
then,
it's
kind
of
on
to
the
vendor
to
make
sure
that
they're
going
to
support
the
latest,
but
I
think
that
from
the
open,
telemetry
standpoint
in
the
project,
I
think
that's
a
really
good
protocol
that
we
should
try
to
implement.
Is
you
know,
make
sure
that
the
collector
is
supporting
something?
B
F
That's
that's
reasonable
and
I
think
that
should
be
tracked
in
the
in
the
repository
that
adds
the
the
breaking
change
so,
for
example,
for
proto
changes.
We
can
track
that
in
proto-repo
for
specs
changes
like
the
protocol
or
the
port
number.
We
should
track
it
there.
Okay,
that
sounds
good
to
me.
C
C
Yep
yeah
yeah,
we're
in
java
is
now
shipping,
both
labels
and
attributes
at
this,
both
at
the
same
time,
so
hopefully
collectors
would
support
either
will
will
work
with
that,
but
I
think
there
was
a
there
was
another
issue,
more
subtle
with
0.7,
but
now
that
i8
is
in
the
collector,
that's
good.
So
I
think
that
should
just
be
labels.
Attributes
should
be
the
only
yeah.
F
So
zero
eight
two
zero
nine
is
labels
attributes,
that's
the
only
you
can
change,
so
you
should
be
fine
if
you
send
both
right
now,
we
are
working
only
on
labels,
but
sooner
very
soon
we
are
upgrading
to
attributes
as
well.
Yep
should
be
good.
C
D
Yeah,
I've
added
a
few
links
in
here,
and
I
posted
about
this
on
slack
last
week.
Some
people
have
responded
there,
but
in
the
js
sig
we
particularly
contrib
had
a
bunch
of
components
that
we
wanted
to
be
able
to
assign
some
level
of
ownership
to
people
who
don't
have
right
access
to
the
repo
so
similar
to
code
owners
where
you
own
a
subdirectory
but
like
most
people
here
know,
code
owners
requires
you
to
grant
right
access
to
a
repository.
D
What
this
does
is
just
a
configuration
file
that
says
if
any
files
in
this
path
have
changed,
then
assign
this
user
these
users
and
request
reviews
from
them
and
that
way
in
the
contributory
bow.
If
somebody
can,
you
know,
contributes
an
instrumentation
library
or
something
like
that.
They
can
have
some
ownership
over
it.
D
They
review
the
changes,
approve
it
and
then
once
they've
approved,
the
maintainers
can
go
ahead
and
merge
and
release
those,
and
we
did
this
in
order
to
help
speed
up
our
our
merge
and
release
process
in
contrib
and
to
satisfy
some
concerns
that
we've
had
from
instrumentation
maintainers
that
want
to.
D
So
this
provides
essentially
a
process
for
them
just
for
them
to
still
own
the
component,
even
though
it's
in
our
repository,
I
would
say
right
now,
it's
sort
of
in
the
proof
of
concept
phase,
although
we
did
merge
it
into
the
js
repo
and
we
are
starting
to
use
it.
But
if
you
know,
if
we
still
need
to
make
behavior
changes
and
stuff,
it's
not
too
late
to
do
that.
But
I
I
didn't
know
if
this
would
be
useful
for
other
people
or
if
other
sigs
have
had
similar
problems.
D
I'm
one
of
them
actually,
when
the
dynatrace
exporter
has
a
change
on
it,
I'm
in
the
code
owner's
file,
but
because
I
don't
have
write
access,
I
don't
get
a
notification.
F
D
Is
just
easier
parsing
the
code
owners
file?
It
was
you
know
that
there
are
built-in
yaml
parsers.
I
was
not
able
to
quickly
find
a
a
library
that
parsed
code
owners
and
I
didn't
feel
like
writing
it
myself.
At
the
moment
it
makes.
B
Yeah,
this
looks
really
good
by
the
way
awesome
job
I
think
go,
could
also
really
utilize
this
so
yeah.
Thanks
for
sharing.
D
D
F
Okay,
not
a
problem.
We
can
open
a
new
repo
for
this.
I
was
just
curious
because
I
like
more
compact
things
but
yeah.
I
can
look
into
it
and
see
if
that's
possible
and
don't
spend
more
than
20
minutes.
Okay,
it's
it's
just
not
that
important,
but
if
in
20
minutes
we
can
come
up
with
something
will
be
better.
G
D
F
I
don't
know
if
you
want
to
mark
it
as
a
donation
or
you
just
put
the
code,
it's
up
to
you
but
yeah.
If,
if
it's
a
donation,
you
go
for
the
community
and
definitely
is
not
something
that
we
need
to
do
too
much
to
accept.
A
Yeah,
I
think
that
this
is
good
because
to
create
a
repo,
and
we
give
you
access
great
access
to
your
spirit.
Pr,
you
know
the
story
honestly
sounds
good,
perfect.
Okay!
Let's
sync
up
with
about
that.
Thank
you
so
much
for
that.
That's
all
in
our
agenda
today
does
anybody
want
to
raise
something.