►
From YouTube: 2021-09-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).
B
A
Doing
all
right
can't
complain,
can't
wait
for
this
short
week
to
be
over.
B
B
I'm
just
updating
the
project
board
status
right
now,
but
we
could
probably
start
just
a
little
bit
if
you
haven't
already,
please
be
sure
to
add
your
name
to
the
attendees
list
and
anything
you
want
to
talk
about
in
the
agenda
we'll
just
get
started
once
I
fill
this
out.
E
B
Oh
okay,
yeah,
as
you
may
have
noticed,
I
was
quickly
scrambling
to
get
them
up
right
before
this,
so
yeah
they're,
pretty
straightforward
cool.
Let
me
see
if
I
can
get
the
attendees
list
and
just
double
check
that
we're
meeting
quorum
here
for
six
yeah.
I
think
that's
pretty
pretty
standard
for
us.
Okay,
cool
yeah,
let's,
let's
jump
into
it,
welcome
everyone
for
joining.
If
you
are
just
joining,
please
make
sure
you
add
your
names
to
these
indies
list
any
agenda
items
you
want
to
talk
about.
B
Let's
add
them
here
and
then
I'll
also
give
some
time
at
the
end,
just
to
ad
hoc
talk
about
things
but
yeah,
jumping
in
pretty
quick
overview.
I
think
of
the
project
boards.
It's
it's
mostly
in
just
maintenance
mode.
I
just
added
some
remove
the
deprecated
package
or
deprecated
function.
Types
right
before
the
meeting
as
cleanup
before
we
actually
get
the
standard
or
the
next
rc
or
a
stable
release
out,
would
include
these.
I
think
also.
B
We
probably
want
to
include
the
fix
that
anthony
submitted
to
adjust
the
map
or
adjust
attributes
that
can
be
map
keys
as
well
retroactively.
Might
you
know?
I
think
that's
part
of
the
project,
but
otherwise
this
looks
pretty
straightforward.
B
Things
are
moving
across
the
board
as
joshua
proves
things,
but
otherwise,
like
the
only
open
ones,
are
deprecation
packages,
so
those
should
be
pretty
quick,
easy
to
go
and
if
you
didn't
catch
it
last
friday,
anthony
was
able
to
get
the
release
of
open
telemetry
go
out
rc3,
it's
looking
really
good.
Definitely
I
think
there's
like
one
or
two
minor
bugs
that
came
in
but
yeah.
I'm
super
excited
about
this.
B
I
think
that
I
think
we're
on
the
cusp
of
getting
getting
a
stable
release
up.
D
I
think
he
said
packages
were
released
this
morning
as
well.
If
you
didn't
notice.
D
My
next
took
slightly
longer
to
get
those
ready
because
of
the
the
metric
test
changes,
but
thank
you
josh
for
helping
get
that
across
the
line.
B
Yeah
awesome
thanks
a
bunch
for
everyone
just
getting
that
across
the
line.
Yeah
super
exciting,
making
progress
cool.
I
think
with
that
we
can
jump
into
the
agenda
unless
somebody
else
wanted
to
talk
about
some
of
the
project
board
ideas.
Here
I
guess
I
didn't
pause
on
that.
One.
B
Okay,
yeah,
I'm
hoping
maybe
give
it
a
week
or
two,
and
then
we
can
start
this
project
to
get
some
feedback,
I'm
actually
working
on
some
other
things
right
now,
so
I
don't
have
the
time
to
really
get
into
this,
but
I
would
like
to
I
think,
let
it
soak
and
see
if
we
can
get
some
organic
feedback
before
we
explicitly
ask.
I
think,
is
kind
of
my
goal
here,
but
other
than
that,
I
think
that
was
this.
Is
it
like?
There's
nothing,
there's
nothing
else.
B
I
think
blocking
us
from
stable
release,
as
as
is
known
now,
cool
awesome,
so
jumping
into
the
agenda.
I
had
just
an
idea.
I
wanted
to
kind
of
run
by
other
people
and
it's
a
very
loose
proposal,
and
maybe
even
some
it's
a
contrarian
proposal
just
to
garner
some
opinions,
but
I
was
thinking
about
the
instrumentation
guidelines
that
we
have
in
the
contrib
repository
for
those.
I
don't
know
everyone
on
the
call
has
seen
the
control
repository.
B
It's
got
a
lot
of
stale
pr's
that
are
just
sitting
there
for
a
lot
of
instrumentation
that
I
think
some
people
wanted
or
organically
asked
for,
but
it's
it's
kind
of
become
a
backlog,
and
I've
been
thinking
about
this
a
little
bit
more
from
a
bigger
picture
perspective,
which
is
easy
to
lose
the
details
in
so
you
know
this
is
just
a
proposal,
but
the
idea
is
as
if
we
have
such
a
hard
time
actually
approving
and
getting
instrumentation
in
with
the
current.
B
You
know,
group
of
people
that
are
on
this
call,
most
of
whom,
who
are
the
active
participants
in
this
community?
It
seems
like
a
really
unfathomable
idea
to
try
to
maintain
all
this
instrumentation,
and
I
guess
it's
just
like
how
do
we
provide
some
sort
of
strategy
to
handle
that
I
think
in
in
the
long
term,
just
to
make
sure
that
any
user
of
this
instrumentation
is
going
to
be
happy
as
well
as
if
they
find
issues
you
know
coming
across.
Hopefully,
like
security
issues
are
dealt
with
really
fast,
but
even
performance
or
just
usability.
B
Issues
like
having
some
sort
of
feedback
to
like
interact
with
some
sort
of
development
community
for
each
part
of
the
instrumentation
right
now.
I
don't
think
that
that
exists,
especially
a
lot
of
the
instrumentation,
was
submitted
by
people
who
are
no
longer
in
this
project
or
or
no
longer
a
part
of
like
open
telemetry.
So
it's
tough
to
you
know
have
this
group
of
developers
come
by
and
essentially
relearn
the
instrumentation
every
single
time.
B
That
being
said,
like
there's,
definitely
some
core
instrumentation
there
that
I
think
that
all
of
us
may
have
some
familiarity
too.
So
this
may
not
be
100
applicable.
B
But
with
a
lot
of
that,
like
problem
space
in
mind,
I
was
kind
of
thinking
that
we
should
make
some
sort
of
proposal,
probably
in
the
contribution
docs
for
the
contrib
library,
saying
that
we
would
recommend
instrumentation
be
built
in
this
order,
and
that
would
be
that
it's
native
to
any
package
that
you're
instrumenting,
ideally
if
you're
the
owner
of
that
package
or
you're,
the
owner
of
whatever
you're
trying
to
submit
instrumentation
for
you,
would
just
natively
do
that.
B
I
know
there's
an
example
of
this
for
a
redis
client
that
was
submitted
last
summer,
not
by
the
authors,
but
by
aws
interns.
They,
instead
of
submitting
instrumentation
to
the
contributory
post,
submitted
it
directly
to
the
package
which
caused
them
some
churn
because
they
tried
to
put
some
metrics
in
there
and
it
wasn't
100
stable
on
the
metric
side
of
thing.
I'm
sorry
on
the
tracing
side
of
things,
but
as
we
go
to
make
a
stable
release,
I
don't
think
that
that's
a
blocker
anymore.
B
B
So
thanks
again
for
the
database
instrumentation
that
you're
hosting-
and
I
think
that's
a
really
successful
package
that
you're
seeing
a
lot
of
users
use-
and
I
think
that's
a
really
good
example
of
having
them
host
it
at
the
same
time
also
means
that
xam
maintains
it
and
from
what
I've
seen
does
a
really
good
job.
B
Maintaining
it
as
xm
has
a
vested
interest
in
in
that
instrumentation,
and
I
think
that,
if
it
was
in
the
contrib,
repo
xm
probably
would
still
be
maintaining
it,
as
I
think
that
they
would,
you
know,
find
some
ownership
on
it.
But
I
think
this
is
a
really
good
organic
way
to
try
to
say
like
if
you
have
really
good
instrumentation
for
this
one
off
bespoke
library.
B
A
good
example
would
be
to
maintain
it
yourself
and
we
have
a
place
where
it
can
be
discovered
and
that's
the
open,
telemetry
dot,
io
registry,
which
I
I
think
is
you
know
if
we,
if
we
try
to
move
users
and
direct
users
towards
the
strategy
registry
it'll
become
more
useful,
I
think
is-
is
kind
of
the
the
problem
that
exists
right
now.
B
It
is
not
that
usable
pretty
much
everything
listed
here
for
instrumentation
is
is
in
the
contrib
repo
itself,
which
I
think
is
a
shortcoming,
because
I
think
this
is
you
know
we
were
looking
at
this
last
time,
there's
over
400
and
something
dependencies
on
the
main
repo
a
lot
of
them.
I
imagine,
are
going
to
be
instrumentation
that
should
be
listed
here
and
if
that's
the
case,
we
can
start
directing
users
here
the
discoverability
for
other
side
projects,
I
think,
is
a
really
good
thing.
B
If
we
try
to
prioritize
that,
so
I
think,
if
that's
kind
of
like
what
I
would
propose
being
the
second
option
and
then
the
third
option,
as
far
as
I
can
see,
would
be
hosted
in
the
contribute.
I
I
thought
you
know
if
there's
some
sort
of
internal
company
instrumentation
that
you
know,
maybe
a
company
doesn't
want
to
host
themselves,
but
would
like
open
to
be
in
open
telemetry
or,
if
there's
some
sort
of
licensing
issues.
B
Maybe
that's
a
really
good
reason
to
have
it
in
the
contribute,
but
essentially
what
that
is
doing
is
it
adds
a
burden
onto
all
of
us
and
we
aren't
able
to
develop
the
rest
of
our
telemetry
when
we're
maintaining
instrumentation,
which
I
don't
think
is
a
problem.
If
we,
you
know
had
10
times
the
number
of
developers,
but
we
don't
and
the
amount
of
development
activity
that
I
have
seen
in
the
project.
It's
it's
hard
for
me
to
think
that
we
could
actually
support
everything.
B
So
that's
been
six
minutes
straight
to
be
talking,
so
I'm
just
going
to
pause
on
that
one
and
see
if
there's
other
ideas
here.
F
Hey,
I
had
a
couple
of
other
examples.
I
wanted
to
cite
for
cases
where
I've
I
faced
this
kind
of
registry
idea.
One
of
them
is
for
some
reason,
there's
this
proliferation
of
jwt
libraries
right
so
there's
that
site.
I
think
it's
jwt.io
that
publishes
a
registry
of
such
packages
where
you
can
select
which
language
you're
interested
in
and
if
I
remember
it
correctly,
it's
been
a
couple
years
since
I
looked
at
it.
I
think
that
it
jwt.
F
Yeah,
so
they
they
they
kind
of
rate
them
by
their.
I
don't
know,
features
and
conformance,
which
is
really
useful
when
you're
scrolling
through
here.
If
there's
some
aspect
of
this
standard,
that's
important
to
you.
You
can
very
quickly
disavow
or
disregard
a
library
that
hasn't
conformed.
F
So
I
found
this
to
be
useful
when
I
was
in
this
business
another
one,
I'm
pretty
sure,
there's
a
registry
for
sql
libraries
for
like
database
libraries
for
go,
I'm
trying
to
remember
where
I
found
that,
but
it
similarly,
it
says
you
know
like
to
what
degree
it
they
can
form.
F
F
It
could
be
very
frustrating
to
grab
some
libraries
that
you
know
instrumented
an
http
client
and
it
turns
out
that
it
has
its
own
idea
of
which
attributes
to
use
when
there's
opportunities
to
use
one
of
the
semantic
conventions,
another
one
might
be
at
what
what
dependency
level?
Which
version
is
it
brought
up
to
if
it's
maintained
independently?
I
know
right
now
you
guys
are
doing
some
heroic
work,
trying
to
upgrade
all
of
the
things
in
the
contrib
repo
to
to
match
whatever
the
latest
releases.
F
But
one
thing
that
I
think
is
is
really
hard
with
like
or
the
broad
contributor
repo
is
kind
of
like
what
you
see
with
these
helm
chart
repositories
where
you
go
and
you
look
at
the
issues
or
you
go
with
the
releases
and
you're
in
this
kind
of
flattened
soup.
It's
really
hard
to
find
you
know,
I'm
interested
in
god,
forbid
the
helm
chart
for
x
y
z.
F
How
do
I
just
narrow
down
and
find
that,
even
though
it
has
a
distinguished
directory
tree
in
the
repository
the
issues,
the
pull
requests,
the
releases
they
usually
are
not
segregated?
In
a
way
that's
easy
to
find.
So
I
find
I
lose
a
lot
of
time.
Dealing
with
you
know,
like
usually
github,
hosted
repositories
that
are
like
that
kind
of
grab
bag
of
maintenance,
there's
a
few
of
them
in
the
kubernetes
project
that
come
to
mind
so
to
the
degree
that
that
we
can
avoid
that.
F
I
you
know,
I
think,
pushing
pushing
things
out
of
the
repo
or
just
not
accepting
more
stuff
is
probably
the
way
to
go,
because
I
just
don't
see
how
it's
tenable
to
think
that
we
can
drag
along
an
ever-growing
set
of
stuff
that
might
not
be
maintained
by
the
people
who
wrote
it
originally.
Every
time
there's
a
release.
You've
got
more
and
more
stuff
to
comb
through
to
figure
out
what
needs
to
be
updated.
F
It
is
sorry
and
if
there
was
a
registry
that
was
able
to
assess
some
of
those
things
automatically,
I
know
I'm
inventing
infrastructure
here,
but
users
would
just
be
able
to
see
like.
Oh
this.
This
library
is
six
releases
behind.
Clearly
it's
been
abandoned.
You
know
it's
fallen
out
of
the
ratings.
Somehow.
A
So
I
like
that
idea
that
could
be
its
own
project
in
general
of
like
having
a
registry
that
attracts
a
lot
of
that
automatically.
What
I
would
recommend
us
do
is
kind
of
create
a
path
to
get
to
the
different
things
like
what
does
it?
A
What
does
a
project
need
to
do
to
satisfy
our
requirements
to
be
able
to
include
and
contrib,
and
maybe
we
need
to
set
it
a
little
bit
higher
than
we
have
where
there's
really
nowhere
else
for
it
to
go
or
there's
promise
like
there's
support
that
that
has
been
available
and
yeah.
That's
not
going
to
be
incredibly
yeah.
That's
not
going
to
be
there
forever,
but
we
can
at
least
then
start
saying
like
hey.
This
is
the
person
who
was
contributing
to
it
and
we
don't
like
collectively.
B
Yeah,
I
think
it's
that
that's
yeah,
I
was
just
gonna
say,
like
I,
don't
think
that's
kind
of
exactly
the
problem
I'm
trying
to
highlight
both
of
you
kind
of
touched
on
just
like
developer
resources
as
well
as
just
like
is
the
bar.
I
think.
Currently
the
bar
is
way
too
low.
Well,
actually
I
don't
think
there
is
a
bar.
B
I
think
is
also
another
problem
that
that's
kind
of
why
I'm
getting
this
proposal
up
is
because,
like
people
there's
really
nothing
saying
like,
when
should
you
be
submitting
proposals
or
instrumentation
or
even
how
to
submit
requests
for
instrumentation
to
the
contributing
bow
so
guidance
there,
I
think
would
be
ideal.
I
think
that
we
want
to
try
to
make
sure
that
that
bar
that
we're
defining
is
at
the
appropriate
levels.
I
think,
is
critical.
D
I
think
one
concern
I
have
with
how
we're
currently
structured
is
that
people
are
creating
pull
requests
and
submitting
them
to
the
contrib
repo,
but
we're
not
accepting
them,
and
thus
that
instrumentation
sits
there
in
a
pull
request
and
isn't
usable
because
it
isn't
living
in
some
other
repo
somewhere
else
where
people
can
just
refer
to
it
and
use
it.
Like
we
eventually
said
x-sam
should
do
with
the
the
db
sql
instrumentation.
D
Maybe
we
should
simply
say
we're
not
ready
to
accept
instrumentation
into
contrib
at
all
for
a
while.
Please
go
host
this
somewhere
else,
link
it
in
the
registry,
and
we
can
reassess
at
a
later
date
if
it
should
be
folded
into
contrib
or
if
it
should
continue
to
live
on
externally,
as
it
does.
B
Yeah,
I
completely
agree,
I
think,
that's
exactly
what
I
want
to
do.
I
want
to
create
documentation,
saying
like
here's,
the
barrier
here,
we're
not
going
in
and
then
going
for
that
you
know
like
that's,
definitely
the
goal.
I
do
think
it's
actually
worse
than
what
you're
saying
though
anthony
is
because
people
were
actually
using
the
branch
of
x-sam
for
that
pr,
even
though
it
like
wasn't
in
maine,
and
it
was
like
even
more
confusing
at
that
point.
G
Yeah
I
was
just
looking
around
at
two
things:
the
collector
contrib
repo
has
a
nice
how
to
contribute
things.
The
steps
you
follow
and
it
has
to
have
you
know,
maybe
this
sort
of
coverage
and
has
to
pass
these
tests
and
if
it
breaks
any
tests,
you're
out
completely
we're
just
turning
you
off,
I
think
that's
great
to
have
the
how-to,
but
I
do
like
your
idea
of
having
having
the
contributors
actually
host
it
themselves.
That's
pretty
great
because
you
can
be
quickly
overcome
by
meekness.
G
The
other
thing
I
was
looking
at
was
the
java
the
java
team
has
they
have
their
own
approvers
and
maintainers
for
their
contributory
po.
It
looks
almost
like
a
separate
project
that
that
seems
like
the
other
way
of
doing
it
right,
instead
of
leaving
it
to
the
responsibility
of
a
developer,
we're
just
going
to
take
care
of
it.
We're
going
to
have
our
own
team,
it's
going
to
last
forever.
No
one
will
ever
leave
and
it's
going
to
be
great.
G
A
So
what
I
would
suggest,
if
we
go
down
honestly
either
route
is
say
here
is
the
path
to
get
it
to
get
into
the
trip
like.
Maybe
it
start
with
host
it
somewhere
else
on
github
and
generate
some
community
interest
in
that
that
it's
worthwhile,
preserving
with
the
rest
of
the
code
and
maybe
as
part
of
the
requirements
are
like
there
is
a
volunteer
at
least
initially
to
shepherd
the
maintenance
of
it
and
like
that,
could
help
alleviate
some
of
this.
This
problem.
B
Yeah,
I
think
that's
actually
touching
on
kind
of
a
good
point
I
wanted
to
to
you
know
say:
I
think
it's
in
the
back
of
my
mind,
but
like
the
proposal
as
is
written
here,
has
the
potential
for
having
another
kind
of
problem,
and
that
is
to
have
you
know
a
very
large
number
of
instrumentation
for
the
same
package
and
maybe
some
overlap.
You
know
another
thing:
yes,
you've
was
mentioning
other
registries,
one
that
really
stuck
out
to
me
was
puppet.
B
I
remember
back
in
the
day
like
that
the
puppet
forge
had
like
tons
and
tons
of
packages
for
puppet,
and
most
of
them
were
just
forks
of
themselves
like
oh,
I
want
this
one
feature,
so
I'm
going
to
fork
this
and
then
it's
like
the
same
thing.
So,
all
of
a
sudden
you
had,
like
you,
know,
20
50,
100
different
things
for
like
these
really
small
libraries,
and
so
like.
I
I
think
that
could
be
confusing,
especially
as
a
new
user.
B
Either
but
I
think
that's
that's
a
good
point,
like
that's
the
point
when,
like
the
things
that
kind
of
aaron's
talking
about
were
like
okay,
there's
justification,
this
should
be
in
the
contrib
there's
500
different
things
here
like
we
should
have
a
standard
one
that
we
recommend
from
the
hotel
community
at
that
point,
but
like
when
there's
one
like
I
go
host
it
yourself
right
and
like
if
you,
if
it's
really
successful
and
then
there's
contention
as
to
which
one
you
should
be
actually
using,
I
think
that's
something
that
we
can
address
at
that
point.
D
That
think
one
other
thing
to
consider
is
that
right
now,
I
believe
a
chunk
of
the
burden
of
maintaining
code
and
contrib
is
dealing
with
breaking
changes
that
we're
introducing
we're
at
a
point
where
we're
vastly
reducing
the
the
break
changes
we're
introducing
with
traces
but
we're
ramping
up
with
metrics
right
we're
breaking
that
more
frequently
and,
as
we
add
more
instrumentation
that
uses
metrics
the
the
workload
there
is
going
to
increase.
D
So
perhaps
saying
we're
we're
we're
going
to
pause
on
accepting
new
things
into
contribute,
contrib
for
for
now,
until
we
have
stability
through
traces
and
metrics
and
logs,
and
then
at
that
point
we
can
look
at
what
the
community
has
coalesced
around
in
terms
of
instrumentation
for
libraries
or
where,
where
there
is
a
feature,
split
that
we
think
that
having
something
in
contrib
could
provide
a
place
for
everything
to
coalesce
around
a
single
implementation
of
instrumentation
can
be
useful,
and
then
we
don't
have
the
burden
of
dealing
with
the
the
instability
of
an
experimental
baseline
that
we're
working
against.
B
Okay,
I
don't
see
any
other
hands.
I'm
cycling
through
video
right
now
see
what
he's
waving
at
me.
They're,
not,
but
I
think
we've
kind
of
touched
on
some
things.
B
What
I'm
hearing
from
this-
and
I
was
going
to
take
in
as
an
action
item,
is
to
create
an
issue
to
build
this
proposal
into
docs
for
the
contrib
repo
and
then
eventually
turn
that
into
a
pr
itself,
unless
there's
some
other
feedback
that
people
wanted
or
there's
outright
saying
I
haven't
heard
from
anybody
saying
like
this
is
a
really
bad
idea
either.
B
Okay,
cool
that
sounds
good
I'll,
take
it
as
an
action
item
and
we
can
move
on.
Okay,
josh,
I'm
gonna
hand
it
over
to
you
and
talking
about
the
metrics
sdk
and
xpr
steps.
Yeah.
Thank
you.
Can
you
hear
me?
I
don't
often
use
these.
E
Just
a
reminder
that
I
had
this
fairly
heavyweight
pr
that
I
made
every
effort
to
keep
my
minimal
as
possible
and
readable,
so
it's
fairly
mechanical
and
just
to
say
that
I
think
this
is
the
best
way
to
make
the
progress
we
need
and
I'd
appreciate
a
review
as
you
have
time
to
do
so
when
this
gets
closer,
I
will
begin
working
on
another
pr
to
continue
reforming
the
sdk
to
get
closer
to
a
the
current
specification.
E
The
though,
as
you
see
the
the
current
thing,
is
we've
been
moving
things
into
this
sdk
api
directory.
So
it's
just
further.
Consolidation
will
come
after
this
and
I'm
not
it's
not
urgent
for
me,
but
I'd
like
to
keep
going
as
quickly
as
time
permits.
B
Great
yeah,
thanks
again
for
putting
together.
Sorry,
it's
been
a
delay
on
this.
It's
my
list
is
ever
growing.
I
gotta
make
sure
that
priorities
prioritize
things
correctly,
but
yeah
thanks
again,.
E
Also,
I'm
happy
to
to
help
with
other
work
as
needed
to
help
this
project
move
forward,
which
is
why
I
jumped
on
the
go
contrib
stuff
and
please,
if
I
can
help.
Let
me
know.
B
Awesome
josh:
have
you
ever
designed
vlogging
solutions.
B
I
know
right:
that's
that's
actually
really
funny
that
I'm
sure
there's
millions
that
you
could
use
and
the
one
that
you
actually
want
to
use
is
locked
away
from
you,
but
yeah
cool
all
right.
So
that's
everything
for
the
agenda.
That's
on
our
dock!
If
anybody
else
has
something
else
they
wanted
to
talk
about.
Please
jump
in.
B
Onto
user
stories,
yeah,
which
is
actually
one
of
my
favorite
parts,.
B
B
If
you
have
some
time,
definitely
take
a
look
at
josh's
pr.
If
you
have
some
more
time,
try
to
do
some
really
cool
things,
then
report
back
to
us
and
maybe
get
some
bugs
or
some
issues
with
the
rc
out,
but
otherwise
I
think
we
could
probably
end
it
early
unless
there's
anything
outstanding
once
twice
three
times
the
charm.
Okay,
everyone
we'll
see
you
all
virtually
or
next
week's
meeting
bye.
Thank
you.
Tyler
bye,.