►
From YouTube: 2021-04-26 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
Don't
everyone
speak
jump,
just
jump
on
that.
I
can't
take
the
notes
thanks,
riley
appreciate
it.
A
We'll
wait
a
couple
minutes.
This
meeting
usually
ends
early.
I
actually
have
a
hard
stop
around
9
30,
but
this
meat
usually
goes
pretty.
A
A
B
B
A
B
Spec
update
for
us
anything
interesting.
Nothing.
I
think
the
important
change
that
is
coming
is
the
one
that
that
you,
you
reported
regarding
the
default
name
for
get
tracer.
So
I
will
have
a
pr
tomorrow
and
the
plan
is
to
have
it
merged
this
week.
Hopefully,
and
we
will
be
doing
one
release
next
by
the
end
of
next
week
or
the
week
after,
because
we're
trying
to
do
the
monthly
release
other
than
that
just
usual
small
iterations.
A
I'll
report
from
java
nothing
to
report
just
kind
of
turning
along
small
changes
and
updates
here,
transparent
and
key
to
any
instrumentation
updates
for
java.
C
E
Vacation
yeah,
nothing,
nothing
interesting
that
I
can
think
of.
F
F
Yeah,
I
appreciate
the
review.
Sometimes
you
get
too
close
to
something
and
you
don't
even
notice
the
the
little
things.
A
Definitely
python
any
updates.
Anyone
from
python.
A
A
It
looks
like
an
update
from
cjo
you
all
can
read.
I
don't
need
to
read
it
to
you.
Anyone
else
from
dotnet
around
have
any
updates,
not
move
on
to
go.
G
Yeah
we
can
jump
into
the
go
stuff
as
listed
there.
Last
week
we
got
a
release
out
for
v020
and
we're
still
working
towards
the
rc.
I
have
a
lot
of
great
progress
going
forward,
13
issues
done
in
the
past
week
and
so
yeah
trying
to
keep
the
momentum
going.
G
H
Yeah,
so
we're
cutting
the
last
alpha
release
and
the
the
next
one
will
be
the
release
candidate.
We
might
call
this
alpha
release
beta
still
like
like
trying
to
figure
out
what's
the
proper
name,
but
the
idea
is
after
release.
Candidate
will
wait
for
a
month
to
get
feedback
and
also
go
through
the
review
with
the
tc
and
then
shoot
for
the
stable
release
by
end
of
june.
A
Swift
says
no
new
updates.
Anyone
from
collector
collector
group
here.
A
All
right,
so
that's
that
onto
the
agenda
that's
been
typed
up,
tyler
I'll
talk
about
code
codes.
G
Yeah,
so
I
definitely
in
asynchronous
slack
channels
talked
with
or
heard
from
other
maintainers
colleagues
about
the
kodkov
security
incident.
We
probably
should
have
had
something
from
the
the
tc
or
the
the
governance
committee
tracking
this.
But
since
the
reason
I
just
want
to
make
sure
it's
like
understood
like
for
the
maintainers.
Unfortunately
we
don't
have
a
lot
of
attendance
today,
but
if
you
are
in
charge
of
a
repository,
go
to
the
settings,
go
look
at
your
secrets.
G
If
you
have
secrets
there,
they
need
to
get
cycled
if
they
haven't
already
I'm
guessing
a
lot
of
people
on.
This
call
have
already
heard
this,
but
just
like
just
a
heads
up
on
that
one,
it's
actually
not
100,
that's
not
100.
True
tyler,
you
have
no
exposure
to
code.
F
Oh
sorry,
is
there
a
procedure
for
getting
updated
secrets
or,
as
the
maintainer
of
the
repository
should
I
have
enough
permission
to
just
generate
a
new
one.
G
I
think
that's
a
really
good
question
that
I
don't
have
the
answer
for
as
a
repository
owner
who
had
no
secrets.
I
don't
know
a
really
good
answer
there,
but
I
imagine
you
either
need
to
you
know,
coordinate
with
the
tc
to
generate
new
ones
because
they
would
probably
have
access.
I
see
carlos
is
on
the
call,
so
he
could
give
a
definitive
answer
there
or
or
maybe
you
have
access
to
sell
yourself.
A
So
for
java
we
have
secrets,
but
our
code,
none
of
our
code
actions
touched
or
are
exposed
any
environment
secrets
in
the
environment
at
all.
So
it
wasn't
an
issue
for
us,
but
that's
something:
you'll
have
to
understand
about
your
tool
in
your
tool
chain
and
if
you're,
using
github
actions,
maybe
just
verify
that
as
well,
but
to
be
on
the
safe
side
rotating
secrets,
if
you
aren't
100
sure.
D
Yeah
and
and
just
to
give
you
an
update
from
the
the
gc
discussion
on
thursday,
there
was
a
discussion
and
you
know
again.
I
think
that
the
action
items
were
twofold,
one
that
I'll
create
an
issue
for
requesting
the
tc
to
you
know,
have
a
more
formal
process
for
triaging
any
kind
of
p0
incidents.
You
know,
and
this
this
code
curve
outage
was
or
an
incident
was
a
security
incident,
so
at
least
having
some
form
of
a
process
coming
out
of
the
tc,
which
everyone
can.
B
D
D
All
right,
carlos
so
I
mean
I
think,
liz
was
going
to
follow
up
with
you,
but
again
I
can
I'll
also
ping,
you
endless
and
figure
it
out.
Yeah.
I
D
D
Usually
the
folks
who
are
cutting
the
releases
should
have
access
for
sure.
I
Yep
all
right,
so
if
there
is
anything
that
needs
to
be
rotated,
please
open
issue
for
that
in
the
community
repo
and
as
for
the
process,
I
I
guess
we
will
follow
up
in
the
tc
meeting
columns
right.
So
can
I.
G
Can
we
can
we
not
open
a
public
issue
for
potentially
compromised
secrets,
maybe
just
handle
that
in
slack
or
something
like
that?
So
it's
not
a.
I
mean
I'm
fine
with
like
doing
it
officially
at
the
end,
but
maybe
you
know
the
same
way:
we
don't
have
security
issues
being
opened
as
github
issues
as
well.
Maybe
try
to
address
this
a
little
bit
more
behind
the
scenes.
I
I
mean
in
in
that
case
it
would
only
it
would
not
like
say
publicly
that
this
token
is
is
available
somewhere,
but
only
indicate
that
it
needs
to
be
rotated,
but
yeah.
It's
like
should
work
just
as
well.
That's
also
fine
yeah.
I
guess.
B
And
we
we
are
getting
some
security
issues
directly
to
the
email
of
the
pc.
That's
the
other
operation.
J
Yeah
we're
experimenting
with
building
out
a
poc
for
the
for
android,
I'm
using
the
java,
the
java
sdk
and
we're
adding
some
instrumentation
we're
just
wondering
where
we
should
put
that
instrumentation
into
the
java,
instrumentation,
repo
or
somewhere
else,
because
it's
you
know,
android
specific
thoughts.
C
C
A
E
I
don't
know
anything
about
android,
but
yeah.
I
guess
so.
What
kind
of
instrumentation
are
you
thinking
high
level
like
android,
libraries
or
yeah,
something
more.
J
I
think
at
this
point
we're
putting
together
some
instrumentation
of
some
of
the
android
networking
libraries
like
okay
http,
that
sort
of
thing.
E
Yeah
I
mean
so
that
kind
of
thing
definitely
fits
in
the
instrumentation
repo.
Well
I
mean
we
already
have
okay,
http,
instrumentation
and
other.
You
know
libraries
and
I
would
say
nikita.
Let's
just
I
mean
until
we
split
out
for
the
as
of
today.
Everything
goes
in
the
one
repo
and
then
you
know
that
may
not
be
its
long-term
place,
but
it's
a
good
place
to
start.
D
Yeah,
I
was
just
actually
trying
to
raise
the
issue
that
you
know
the
collector
code
reviews
or
the
collector
can
trip
code.
Reviews
are
a
bit
backed
up
and
again,
you
know
we.
We
have
a
bunch
of
prs
these
ones,
specifically
that
are
around
the
aws
container
insights
extension
and
I'd
like
to
get
some
reviews
to
unblock
this.
D
I
think
none
of
our
maintainers
for
collector
are
here,
but
again
this
goes
back
to
the
you
know,
deficit
that
we
have
of
collector,
maintain
our
mind,
share
or
maintain
our
mind
share,
sometimes
where
code
reviews
for
kid
rip
seem
to
sit
for
a
while
before
getting
reviewed
and
merged.
K
D
Any
suggestions
on
you
know
what
what
as
maintainers
you
know
we
can
recommend,
because
we
have
had
this
issue
several
times
now
and
you
know
again,
individual
repo
maintainers
do
try
to
unlock,
but
this
this
specifically
now
is
blocking
this
extension
release,
which
we
were
hoping
to
do
this
week
downstream.
G
So
one
of
the
ideas
that
I
I
was
thinking
about
in
not
just
I
think
the
collector
can
trip
repo
but
like
a
lot
of
other
repos,
especially
with
contrib
repositories
as
well.
Is
that
we're
going
to
need
to
start
to
build?
I
think,
like
some
sort
of
trust
chain.
G
To
a
particular
part
of
the
project
and
you're
given
access
to
it
but
like
yeah,
I
think
I
think
that's
something
that
we
need
some
some
instruction
on
and
how
we're
going
to
build
that
that
chain
or
even
a
a
policy
direction
from
like
the
tc
or
I
guess
we
could
grasp
through
it
here.
G
But
I
I
don't
know
it
seems
appropriate
eventually
because,
like
the
project's
just
gonna
keep
growing
like
you're
saying
and
like
right
now
it's
working
quote-unquote
working
yeah,
but
you
know
I
think
we
could
do
better
and
I
think
that's
one
of
the
the
solutions
we
could
try
to
implement.
D
Yeah,
we
will
definitely
have
to
figure
out
some
kind
of
you
know,
divestiture
of
ownership
or
some
kind
of,
or
at
least
code
approvers
and
reviewers,
and
you
know
rights
which
are
limited
to
each
each
specific
component.
I
think
that
this
was
discussed.
You
know
now
multiple
times,
even
in
the
gc
and
the
tc.
D
D
I
mean
I'm
happy
to
take
a
crack
at
an
original.
You
know
an
initial
draft
and
then
maybe
get
you
know
everyone's
comments
and
feedback
on
the
draft
in
the
meet
in
this
meeting
and
then
introduce
it
to
the
tc,
for
you
know,
consideration
and
any
kind
of
modifications.
B
I
can
help
with
that
by
the
way,
so
we
are
maybe
we
can
coordinate
offline.
This
is
one
of
the
I
I
did
mention
this
to
the
tc
that
we
need
to
actually
spend
more
cycles.
Yeah.
B
D
I
mean
you
know
it's
like:
okay,
carlos,
I
mean
that'd,
be
awesome,
let's
work
together
on
it,
because
I
think
that
again
you
know
we
just
need
to
have
more
specialization,
perhaps
in
the
tc
or
the
maintainers
themselves.
It
doesn't
have
to
be
that
everybody
you
know
who
is
a
core
maintainer
has
to
constantly
review
the
contrib
components,
because
the
other
option
again
is
and
yuri
had
also
brought.
This
up
is
that
you
know
we
consider
a
different
org
and
then
morgan
has
brought
this
up.
D
Also
earlier
in
the
maintainers
meeting
that
we,
you
know
the
other
choices
that
if
we
don't
don't
have
a
more
sophisticated
way
of
you
know,
assigning,
focused
or
or
limited
rights
for
you
know,
code
approval,
review
and
merge.
Then
we
end
up
having
the
to
consider.
Maybe
a
different
org
that
can,
you
know,
contains
all
the
contrib
components
and
you
know
having
a
more
of
a
fragmented
approach
there.
So
we
do
need
to
address
it
sooner
or
later.
K
So
I'm
not
I'm
not
deeply
involved
at
all
in
open
telemetry,
but
if
there
was
a
lower
standard
for
who
can
be
a
maintainer
on
contrib,
then
I
think
two
ideas
that
you
brought
up
for
me
elliott
is
I'm
willing
to
be
a
someone
who
is
a
maintainer
on
a
computer
repository
and
also
as
an
example
of
something
you
maybe
just
mentioned,
is
if
there's
a
component
like
influx
data?
Has
a
couple
of
things
we'd
like
to
do.
K
D
K
D
Yeah
totally
jacob
and-
and
I
think
that
you
know
that's-
it
can
be
component
specific,
where
you
know
folks
have
specific
folks
are
willing
to
step
up
and
take.
You
know,
ownership
and
make
sure
that
they
follow
the
best
practices
that
you
know
the
core
maintainers
have
and
the
tc
recommends,
which
are
you
know,
in
keeping
with
the
standard
of
the
project.
D
But
again,
all
of
these
areas
are
still
quite
gray
in
in
the
project
and
they
do
need
to
be
defined
as
we
grow
so
fast
yeah.
K
D
D
I
D
I
Yeah
also
riley,
I
think,
already
tried
to
propose
something
for
the
specification
that
we
have
have
owners
for
for
certain
areas
so
that
we
have
like
dedicated
experts
for
certain
areas
of
the
specification.
But
there
was
no
agreement
on
on
that.
So
far,
right.
H
Yeah
you're
right,
there's
no
formal
agreement.
I
and
I
I've
been
like
hyper
focusing
on
the
metrics
part,
so
I
believe,
if
I
have
some
time
or
some
tc
member
can
work
with
me,
we're
able
to
make
progress
on
that
part,
but
coming
back
so
that
part
is
more
about
specific,
like
the
spec
ripple,
the
like
the
ownership
or
the
people
responsible
for
individual
documents,
it's
not
for
how
we
collaborate
on
the
country
report.
H
So
I
believe
it's
a
separate
thing
because
word
counts
back
you
don't
care
about
the
release
or
the
like
credential
management,
but
working
on
the
country
ripple.
You
might
have
the
need
that
you
want
to
access
a
particular
release
pipeline.
You
want
to
ship
a
new
version
of
this
specific
plugin,
so
it
might
be
separate.
D
D
Right,
because
really
I
mean
again,
it's
the
the
general
design
of
how
to
handle
you
know
specific
ownership
for
and
and
and
itemize
that
clearly
for
each
repo
and
each
component.
D
D
G
Yeah,
that
sounds
good.
I
look
forward
to
seeing
your
your
draft.
I
Going
twice
one
thing
for
those
two
prs
in
question:
in
particular:
those
are
both
aws
related
right
and
there
is
a
one
maintainer
or
an
approver
in
the
concrete
repo
from
aws,
and
it
would
probably
be
ideal
if,
if
he
could
review
it
from
an
aws
point
of
view,
so
that
the
remaining
approvers
already
have
a
feeling
as
if
and
that
this
is
all
right
from
from
your
end
and
can
then
focus
on
the
on
the
technical
details
before
having
it
merged.
D
I
Yeah,
we've
done
that
in
on
the
on
the
spec
creeper
already
when
there
were
vendor
or
or
cloud
platform
related
prs,
but
that's
only
by
by
by
incident,
actually
that
that
there
is
an
aws
approval.
In
this
case,
we
will
have
to
figure
out
the
formal
process
on
how
this
will
scale
in
the
future
anyway,
yeah
so.