►
From YouTube: 2020-07-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
So
it
looks
like
Evans
on
the
call
I'm
gonna
call
it
quorum,
I've,
no
idea
where
Josh
is
but
I
know
that
Anthony
said
that
he
was
not
gonna
be
able
to
make
at
least
the
first
half.
So
we
can
probably
get
started
I,
don't
imagine
this
taking
too
long.
I
don't
have
some
video
items
and
some
of
them
were
kind
of
conditional
on
Josh
mid-year,
so
probably
go
really
fast.
But
the
main
thing
is
the
next
milestone.
I
guess
a
good
shirt
start
sharing
the
screen.
A
A
Yeah,
so
the
main
thing
is
this
specification:
I'm,
sorry,
the
milestone
for
the
v-0
six
specification
looks
like
we're
pretty
much
there
with
PRS
for
all
of
their
remaining
outstanding
issues
included
in
the
milestone.
So
it
should
be
good.
They
all
have
a
single
review
if
I
remember
correctly,
so
they
could
use
another
review
or
two
if
you're
on
the
call.
Even
if
you
are
not
a
approver
of
the
project,
please
take
a
look.
A
We
love
to
have
as
many
eyes
on
there
as
possible
and
different
opinions,
as
oh,
it's
awful,
but
yeah,
probably
prioritize.
These
PRS
in
particular
I
think
are
really
helpful
to
get
the
project
progressing.
Most
of
them
are
pretty
simple
and
then,
after
that,
the
next
one
would
probably
give
us
a
trace.
Instrumentation
spend
name.
This
is
to
address
a
issue
where
our
spendings
are
actually
coming
in
with
a
leading
slash.
This
is
based
on
the
upstream
chair.
A
If
you
see
the
library
that
we're
using
so
just
fixes
that
additionally,
also
with
recent
v-0
six
specification,
the
service
tag
or
the
service
name,
tag
that
gets
shipped
up.
Attributes
should
also
include
the
package
name,
which
is
kind
of
a
change
from
the
ambiguously
defined
service
name
beforehand.
So
that
also
addresses
that
so
yep
should
be
pretty
straightforward.
As
a
review,
that's
the
majority
of
the
PRS
I
was
looking
at
getting
reviewed.
A
B
A
B
B
A
Yeah
I
kind
of
glossed
over
that
tonight
in
the
back
of
my
head,
I,
was
kind
of
just
assumed
that
the
moment
the
milestones
done,
we
can
release
it.
In
fact,
I
actually
probably
have
enough
for
our
release
right
now,
but
I
was
hoping
to
kind
of
just
along
that
when
we
get
that
mouse
on
him
so
I'm
guessing
today
or
maybe
tomorrow,
get
the
release
out.
There's.
B
A
Fair
amount
included
also
thanks
everyone
for
really
jumping
on
board
the
changelog.
It's
been
looking
great,
but
yeah
there's
been
a
lot
going
on
in
the
changelog
for
things
that
are
added
and
changed
or
removed.
Most
leave
was
the
p3
stuff
that
was
going
through
and
a
lot
of
restructuring
than
that
propagator,
but
there's
also
addition
of
all
the
stuff
included
in
the
mouse
as
well.
That
I
think
would
be
a
useful
release,
so
yeah.
A
A
The
next
thing
after
that
would
be
the
next
milestone
and
I
see
Morgan's
got
a
lot
of
stuff.
This
is
probably
related.
What
do
we
need
I
think
is
the
next
major
target
of
the
project
and
then
maybe
after
that
kind
of
talked
about,
the
GA
planning
looks
like
I
think
the
milestone
I,
don't
really
have
anything.
In
particular,
I
know
that
there's
a
lot
of
bigger
issues.
Maybe
we
can
probably
plan
our
next
milestone
around.
Maybe
what
we
talked
about
Morgan
here
in
the
GA
finding
next,
maybe
afterwards.
C
Yeah
I
had
two
topics.
The
first
is
GA
planning,
so
Tyler
I
think
you're
already
could
looped
into
this,
but
I
don't
know
about
the
others.
Just
like
beta
we're,
starting
a
ga
planning
process
for
Oakland
telemetry
GA
will
take
place
later
this
year
and
we're
gonna
have
sort
of
release
candidates
for
each
SDK
and
the
collector
that
will
lead
up
to
GA,
you
know,
might
beat
up
the
first
release.
Can
it
becomes
the
GA
release?
C
It
might
be
that
we
have
multiple
release
candidates
for
certain
components
before
we
get
there
we're
targeting
the
first
wave
of
GA
s
to
include
the
collector,
as
well
as
the
go
Java
JavaScript
and
Python
SDKs,
as
well
as
possibly
dotnet
and
Erlang,
and
possibly
to
the
Java,
auto
and
Python.
Auto
instrumentation
I
just
have
to
check
in
if
those
SIG's
and
see
where
they
are,
we've
started
the
planning
process
already
for
the
spec,
sig
and
so
I.
C
Some
links
here
that
you
can
look
at
the
first
is
for
just
the
general
GI
project
planning
doc,
that's
very
similar
to
what
we
had
for
beta.
Give
it
a
look,
but
the
second
and
probably
more
important,
is
the
spec
Kanban
board.
So
if
you
want
to
present
that
the
Kanban
boards,
what
we've
done
in
the
spec
sig
as
we've
got
unlabeled
every
single
issue
with
a
label
called
release,
:
require
for
GA,
and
we've
done
that
for
every
issue.
We've
done
it
also
for
every
PR
that
is
required
for
GA.
C
So
some
of
this
much
of
these
describe
work,
that's
already
in
flight
or
about
to
be
merged
into
the
spec,
but
we've
also
filed
issues
for
work
that
hasn't
even
started.
Similarly,
we
want
on
each
cig
people
to
file
issues
for
remaining
work
that
they
know
they
haven't
already
knows
required
for
GA,
as
well
as
any
work
that
will
be
required
based
off
of
the
spec
work
that
is
now
required
and
called
out
in
this
Kanban
board
and
associated
with
this
label.
So
with
with
that,
we
can
then
build
similar
boards
for
each
cig.
C
This
spec
board
is
a
little
unique.
It's
tied
to
the
open,
selamat
reorganization,
github
projects,
which
is
the
github
brand
for
these
camp
Bend
boys.
It
can
be
tied
to
either
orgs
or
repos.
Specs
were
unique
just
because
specs,
repo
or
specs
it
effectively
covers
two
repos.
Both
the
specification
repository
as
well
as
Oh
tips,
the
actual
SIG's
that
exist
instead
of
open
telemetry
are
generally
repo
specifics.
So
it's
probably
easier
just
to
create
these
boards
tie
them
to
your
repos
instead
of
having
multiple
tied
to
the
org
anyways.
C
So
the
requests
coming
out
is
to
first
like
go
file
issues
that
you
offer
things
that
you
think
are
still
required
to
be
done
for
the
go
SDK
before
it
hits
GA
and
then
assign
the
release
required
for
GA
label
to
those
once
that's
done,
then
build
one
of
these
Kanban
boards.
It's
really
simple
takes
a
few
clicks
and
he's
got
a
dragon.
The
issues
that
are
heavily
required
for
GA
tag.
C
Once
the
issues
are
in
the
board,
the
board
will
automatically
propagate
things
left
and
right,
depending
on
their
status
like
if
for
an
issue,
if
it's
open
versus
closed
and
for
PR,
depending
on
where
it
is
in
the
review
pipeline,
it'll
move
them
through
github
has
that
kind
of
automation.
It
doesn't
have
automation
to
bring
in
items
based
on
their
label
when
they're
newly
filed.
A
C
A
C
Have
a
second
unrelated
topic:
Janna
at
Google
jbd.
She
had
some
like
just
like
random
sort
of
minor
sort
of
feedback
items
for
the
go
SDK
she
was
wondering.
Would
she
be
able
to
present
those
next
meeting
like?
Are
you
interested
in
hearing
them?
She's
got
a
dong
cos.
She
wrote
off
as
well
absolutely.