►
From YouTube: 2021-06-23 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
B
Hey
there,
how
was
your
vacation.
B
I
didn't
have
as
much
time
to
prepare
it
today,
as
I
normally
do.
So,
if
other
people
have
things
to
add,
we'll
probably
have
time.
C
B
Okay,
so
the
first
thing
I
wanted
to
talk
about
here
is
the
version
22
release
of
the
contrib
repository.
B
It
should
be
relatively
straightforward
because
it's
created
by
a
bot,
so
just
a
couple
of
reviews
on
this,
and
this
will
be
remember,
merged
and
released
this
afternoon.
B
I
did
see
that
there
are
a
couple
of
pr's
open
for
new
instrumentations
for
memcached
and
for
cassandra
driver
again,
I'm
just
asking
for
reviews.
I
know
I
haven't
reviewed
these
yet
myself,
so
reviews
are
always
helpful.
It
looks
like
valentine
did
over
the
weekend,
but
please,
the
more
we
can
get
reviewed.
The
more
we
can
get
released
seems
to
be
the
most
common
blocker.
B
There
are
also
two
pr's
that
add
more
or
less
the
same
feature
to
two
different
instrumentations,
so
this
response
hook
feature
which
we
already
have
in
some
other
instrumentations,
but
it's
just
a
hook
to
add
attributes
based
on
the
response.
B
So
I
think
we
already
have
these
for,
like
my
sequel
and
a
couple
of
others,
so
it
should
be.
B
I
was
going
through
prs
and
merging
ones
that
had
enough
reviews
this
morning,
and
there
are
a
couple
that
are,
I
think,
ready,
but
just
didn't
have
enough
reviews.
So
I
added
them
here.
It
looks
like
somebody
reviewed
this
today
just
now.
Thank
you.
So
these
these
few
pr's
here
are
mostly
just
looking
for
reviews.
B
I
did
want
to
talk
about
this
grpc
one,
mostly
because
I'm
not
sure
that
I
fully
understand
what
the
conversation
was
about
here
and
I
was
hoping
that
somebody
could
explain
what
that
what
the
issue
is
here,
because
it
seems
to
be
that
the
url
needs
to
be
in
a
certain
format,
but
that
the
http
protocol
is
somehow
accepted,
even
though
the
grpc
exporter
should
only
be
using
grpc,
and
I
thought
the
protocol
should
be
optional,
so
I'm
not
sure
why
it's
even
required.
B
Is
there
anyone
that
has
context
on
this,
or
is
this
just
a
bug?
That's
slipped
through?
Should
we
require
the
protocol,
or
should
we
just
remove
it.
B
So
I
think
it
was
introduced
in
the
the
pr
that
liz
made,
but
I
don't
think
she
was
trying
to
make
it
required.
I
think
that
she
was
like
she
was
trying
to
prevent
unnecessary
errors
from
when
people
copy
pasted
the
example
code
and
making
sure
that,
like
the
port
was
parsed
properly.
I
don't
think
the
protocol
was
a
problem
there
unless
I'm
misremembering
it.
B
Okay,
so
this
pr,
I
think,
just
changes
the
default
to
have
grpc,
I
think
in
the
protocol
right,
but
should
we
try
to
make
that
optional
because
I
don't
see
a
reason
to
require
it.
A
B
Okay-
so
I
don't
want
to
comment
here
without
I
haven't
looked
too
closely
at
it,
so
I
don't
want
to
stick
my
foot
in
my
mouth
but
I'll
I'll.
Take
a
look
at
this
and
maybe
suggest
that
we
we
make
it
optional,
because
I
I
just
don't
see
a
reason
for
it
not
to
be.
C
I
have
a
quick
question
on
that:
one
is:
how
does
it
interact
with
the
environment
variables
that
you
can
also
pass
for
these,
because
I've
seen
a
lot
of
discussion
that
it's
confusing
across
languages
like
some
of
them
have
grpc
some
of
them
don't
so
it
doesn't
just
go
straight
from
the
environment
variable
into
this
field.
B
It
does,
let
me
take
a
look
real,
quick
at
the
spec
for
the
environment
variables.
It
may
actually
state
whether
it's
required
or
not
in
here,
which
would.
C
Yeah,
it's
hotel,
underscore
exporter,
underscore
otlp
underscore
endpoint.
B
C
Since
do
you
I
mean,
do
you
know
if
the
http
applies
to
grpc
as
well,
though,
like
oh,
I
see
you
can
transport
protocol
yeah
like
like
if
you're
specifying
an
endpoint
in
grpc's
is
also
using
http
2.
It
would
also
use
that
scheme
right.
C
I
don't
think
that
since,
for
instance
like
in
javascript,
we
have
two
separate
packages
for
grpc
and
http.
C
C
B
So
it
says
right
now,
as
a
1.0,
there
is
no
specified
default
or
configuration
via
environment
variables
for
the
for
the
scheme
itself.
It's
just
the
so
they
have
these
three
like
protocol
environment
variables
reserved
for
future
use,
but
it
looks
like
they're
not
doing
anything
like
that
right
now,
so
they
just
want
us
to
have
the
the
scheme
in
the
url,
but
that's
it.
It's
not
actually
used
to
make
any
decisions
right
now.
B
There
is
on
the
gis
one,
I
don't
know
if
it's
specified,
but
we
do
have
like
a
an
insecure
option
for
for
grpc.
You
mean
right.
C
B
B
This
is
another
one
that
I
I
just
saw
this
this
morning.
Where
are
you
on?
The
call
today
looks
like
no,
so
he
has
a
an
internal
module
that
they
are
versioning
using
pre-release
tags
and
he's
trying
to
instrument
their
internal
module
and
the.
B
Semver
is
supported,
or
december
satisfies
function
always
returns
false.
I
guess
for
pre-release
tags.
I
don't
know
if
there's
an
option
for
that
in
december,
but
is
anyone
else
familiar
with
that?
I
that's
surprising
to
me.
I
would
have
thought
that
satisfies
would
have
worked
with
pre-release
tags
out
of
the
box.
B
B
B
B
I
think
that
we
should
probably
make
it
configurable,
because
I
think
if
you
have
like
version,
if
you
support
version
2.0
and
they
and
the
the
module
being
used
is
version
2.1
dash
beta,
then
I
think
that
we
should
make
sure
that
the
instrumentation
author
is
explicitly
opting
into
pre-releases.
I
don't
think
that
we
want
to
patch
beta
modules
out
of
the
box,
because
they're
more
likely
to
be
broken.
A
B
Well,
I
think
we
would
just
add
it
to
the
the
instrumentation
module
definition
right
where
we
have.
Oh,
it's
only
strings,
so
maybe
not
that
doesn't
work.
B
A
A
A
I
mean
I.
A
A
B
A
B
Yes,
he's
writing
an
instrumentation
and
he
can't
patch
the
beta
versions,
because
the
is
supported
always
returns.
False.
A
B
B
A
B
Correctly
this
next
one
was
again
just
a
pr
that
needs
approvals.
B
B
The
metrics
spec
is
moving
along
pretty
well.
Actually,
I
think
the
the
metrics
api
is
just
about
done
and
they're
working
on
the
metrics
sdk
spec
right
now.
B
B
Unfortunately,
I
did
want
to
let
you
guys
know
that
we
have
a
full-time
engineer
at
dynatrace
who
will
be
working
on
metrics
in
a
couple
of
languages,
but
they're
going
to
start
with
js,
and
I
don't
know
if
they're
going
to
start
attending
these
meetings
or
not
because
the
time
zone
is
difficult
for
them,
but
those
details
are
still
sort
of
being
worked
out.
I
just
want
to
make
you
guys
aware
that
there
is
a
person
that
will
be
joining
us
to
help
with
metrics.
A
B
The
I
think
when
we
go
to
1.0,
though
like
if
we
make
a
metrics
two
package
or
whatever
you
know,
a
new
metrics
package,
whatever
we
call
it,
I
think
when
we
go
to
1.0,
we
will
want
to
rename
it
to
be
metrics
at
1.0
right.
I
think
you
know
having
open
telemetry
slash.
Metrics
is
the
most
obvious
name
to
have
moving
forward,
and
I
don't
want
to
have
some
weird
name
just
because
we
were
trying
not
to
break
compatibility
with
the
whole
specification
version
that
never
even
got
to
1.0.
A
B
B
Aaron
I
see
that
you
added
another
a
message
here.
I
assume
this:
is
you
don't
appearing
to
be
an
approver.
C
Oh
no,
no,
no,
I
was
gonna
call
that
out
specifically
not
I
haven't.
I
don't
feel
like.
I've
contributed
enough
to
the
actual,
like
actual
pr's,
to
offer
myself
up,
but
I
I
just
noticed
that
there's
like
a
lot
of
approvers
who,
who
I
haven't
really
seen
around,
and
there
are
a
good
number
of
folks
on
this
call,
and
I
was
wondering
if
maybe
some
of
them
would
be
more
appropriate.
C
C
Yeah
yeah
actually
you're
right.
I
don't
think
it
assigns
somebody
to
the
assignees,
but
it
can.
It
can
like
take
people
from
the
approver's
list
and
assign
them
specifically
to
the
reviewer,
so
they
won't
be
in
the
assignee
section,
but
it
will
choose
two
or
three
or
whatever
people
to
review
a
given
pr.
B
C
I
think
so
because,
because
we're
able
to
you
know
somebody's
specifically
interested
in
a
pr
because
they
worked
on
it
before
it
and
then
they
might,
you
know,
swap
themselves
out,
but
I
think
it's
good,
because
we
sort
of
if
there's
a
pr,
there's
and
we're
going
through
it
during
the
sake,
it
has
two
names
on
it.
We
know
exactly
who
to
ask
to
take
a
look.
B
Yeah
interesting
yeah
yeah
I
mean
I
I
like
that
idea.
I
think
they
yeah
we'd
have
to
figure
out
their
previous
list,
though
yeah.
The
short
answer
here
lit
to
your
question
is
yes,
we
are
always
looking
for
more
approvers,
and
I
am
aware
that
our
approvers
list
is
a
little
bit
out
of
date,
because
we
don't
have
any
round
robin
assigning
thing
like
that.
It
doesn't
matter
as
much
if
it's
out
of
date,
it's
not
hurting
anything
to
just
have
a
couple
of
extra
people
assigned
on
the
reviewers
list.
B
If
we
do
go
to
something
more
like
what
python
does,
we
will
need
to
make
sure
we
keep
that
list
more
up
to
date,
which
is
fine,
it's
something
we
should
be
doing
anyways,
but
it
just
adds
a
little
bit
more
pain.
If
it's
not
up
to
date,
I
guess
yeah
definitely
assigns
a
random
person
and
that
person's
not
active,
then
that
can
be
an
issue
or
even
if
they're,
just
on
vacation.
C
Yeah
yeah:
it's
a
good
point
about
the
vacation,
but
yeah.
I
guess
a
separate
issue
would
be.
If
any,
does
anybody
want
to
be
an
approver
who
would
be
appropriate.
B
Yeah
that
so
the
way
we've
sort
of
handled
that
in
the
past
is
the
the
maintainers.
B
You
know,
we've
just
approached
people
that
we
see
our
regular
contributors
and
we'll
just
approach
them
and
ask
them
if
they
want
to
be
an
approver.
We've
never
really
had
an
application
process
or
anything
like
that.
B
C
Yeah,
I
think
there
may
be
some
official
requirements,
if
I
remember
correctly,
for
you
know
like
you-
have
to
submit
x
number
of
pr's
and
review
x
number
before
your
ad
or
something
like
that.
I'm
not
sure.
D
B
Requirements,
yes,
reviewer
for
at
least
a
month,
reviewer
of
at
least
10
substantial
pr
is
nominated
by
a
maintainer
yeah.
So
I
I
think
that
that's
a
relatively
straightforward
requirement,
but
even
for
so
there
are
probably
people
that
fulfill
these
requirements
that
are
not
reviewers
right
now,
just
because
we
haven't
asked
them
to
be
yet.
So
I
think
that
if
someone
wants
to
be
a
reviewer
and
they
fulfill
these
requirements,
then
maybe
we
should
have
like
a
github
issue
template
for.
B
I
would
like
to
be
a
reviewer
and
in
the
template
we
could
say.
Yes,
I've
been
around
for
at
least
a
month
and
here's
my
10
pr's
that
I've
reviewed
and
then
we
would
have
you
know
the
maintainers
essentially
thumb
up
on
it
or
here's
the
maintainer
that
I've
already
talked
to
or
something
like
that.
Would
that
sound,
reasonable.
B
It's
similar
to
the
to
the
issue
where
you
apply
for
community
membership
it
would.
It
would
be
similar
to
that.
C
Yeah,
it
seems
reasonable
to
me-
or
I
don't
want
to
you-
know,
copy
your
style.
If
you
guys
like
to
reach
out
to
people
specifically,
it
might
be
good
and
then
there's
no
chance
of
hurt
feelings
too.
I
don't
know.
B
Yeah,
so
let's
I
think
myself
and
the
other
maintainers
need
to
talk
about
this
separately.
Probably
I
don't
think
that's
a
decision
that
we
necessarily
want
to
make
publicly
and
the
one
of
the
maintainers
isn't
even
here
today,
so
I
would
certainly
want
his
input
also,
but
I
am
generally
in
favor
of
anything
that
streamlines
the
process
of
not
only
adding
new
approvers
but
making
sure
that
prs
are
approved
more
quickly
and
that
kind
of.
C
C
Oh,
I
I
did
it's
just
that
it's
just
a
link
so
that
it's
here
for
everybody
to
see.
B
Okay,
yeah
yeah,
I
mean
it's,
it's
certainly
interesting.
I
think
that
we
need
to
talk
to
that.
The
you
know
amongst
ourselves
as
maintainers
and
and
see
what
we
want
to
do
here,
though,.
B
F
F
You
know
we
are
starting
or
we
have
some
projects
in
products
already
producing
metrics
in
custom
format,
our
own
format,
but
we
are
looking
to
kind
of
maybe
export
some
of
these
in
the
hotel,
matrix
format
right
and
then
we
are
also
starting
a
new
project
to
kind
of
create
metrics
to
begin
with,
in
a
note,
help
format
right.
F
So
I'm
kind
of
curious
about
the
you
know,
metrics
up
to
date,
project
that
you
mentioned.
F
You
know
we
may
be
able
to
even
help
out
a
little
bit
on
that
and
and
so
on.
The
back
end
collector
side
right.
Is
there
a
version
of
the
backend
collector
that
has
you
know
some
metrics
version
that
we
are
we're
going
to
be
supporting
on
the
front
there
I
mean.
Does
the
back
end
collector
already
have
the
you
know
latest
matrix
implementation,
so
I
think.
B
So
the
major
changes
are
in
the
sort
of
collection
and
aggregation
in
the
api
in
the
sdk,
but
I
think
the
export
format
is
mostly
the
same
as
it
was
before,
so
that
shouldn't
have
changed
too
much,
and
I
believe
that
the
the
collector
is
using
the
most
recent
data
model.
But
honestly,
I'm
not
the
right
person
to
ask
for
collector
questions,
especially
as
it
relates
to
metrics.
B
I
know
that
there's
a
collector
sig
and
I
know
that
there's
a
metric
sig
separately,
so
those
might
be
good
places
to
ask
questions
like
that.
But,
as
far
as
I
know,
the
answer
is
that
the
the
export
data
model
itself
is
mostly
the
same
as
it
was
before,
and
the
collector
is
using
the
latest
version.
F
B
Js
everything
is
in
typescript,
we
don't
have
any
components
that
are
not
typescript
right
now
and
if
we
were
going
to
add
non-typescript
components,
we
would
need
a
very
good
reason
for
doing
that.
F
B
F
Yes,
is
there,
I
mean
the
metric
says
it's
all
in
the
hotel,
js
right,
the
repo.
F
Okay,
yeah
so
well
I
mean
this
is
my
first
meeting
in
this
one,
so
I'm
just
gonna
dive
into
a
little
bit
more
and
ask
you
know
more
smarter
questions
or
even
contribute
in
the
future.
So
we'll
see.
Okay,.
B
Oh
okay,
yeah
yeah
bart,
actually
wrote
most
of
most
of
the
metrics
stuff
that
we
currently
have.
I
think
so
that
doesn't
spread.
A
B
Yeah,
it's
definitely
more
complex
and
there's
a
lot
more
like
historical
baggage,
with
with
previous
metrics
implementations
like
statsd,
and
things
like
that,
where
everybody
wants
compatibility
and
if
tracing
we
didn't
really
have
that
issue,
there's
only
a
few
tracing
public
tracing
implementations
and
they
all
mostly
work
the
same
way.
So
it
was
relatively
easy
to
to
fit
the
data
model
together.
A
I
mean
the
good
thing
is
that
the
final
export,
the
data
that
is
being
exported,
won't
trade,
as
you
mentioned
so
we'll
have
to
work
on
our
internals.
Basically,.
B
F
B
Yeah
right
now
the
sdk
is
almost
exactly
the
same,
except
that
some
of
the
obviously
the
instrumentations
are
different
and
the
instrumentation
loading
is
different,
but
other
than
that
everything
is
identical
across
web
and
node
as
much
as
we
can
possibly
make
it.
E
All
right
is
that
a
100
true
when
it
comes
to
context
propagation,
don't
the
node
and
the
browser
packages
use
different
things
for
that,
async
hooks
on
the
node
side
and
zone.js
on
the
browser
side.
B
Yes,
that
is
true,
yeah,
okay,
but
the
context
api
itself
is
the
same.
The
same
way,
you
just
use
a
different
context:
manager.
B
Okay,
well,
if
that's
everything
we
have
anyone
else,
have
anything
they'd
like
to
bring
up.
B
Sounds
like
no,
so
thank
you
everybody
for
your
time
and
I
will
talk
to
you
next
week.
Please
review
prs
thanks
bye.