►
From YouTube: 2021-05-17 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
D
A
A
Okay,
let's
get
started
so
it's
probably
someone
had
noted.
It's
probably
going
to
be
a
very
small
meeting
this
week,
just
because
of
the
oli
fest
conference.
That's
occurring
right
now!
That's
okay!
So
we'll
probably
get
through
this
pretty
quickly,
so
we'll
go
through
the
sig
check-in.
I
don't
think
we're
gonna
get
too
many
people
here,
but
it
looks
like
we
already
had
some
notes
left.
So
first
update
is
from
the
specification
sig
some
important
things
to
check
out
our
clarification
for
current
status.
Schema
related
changes.
A
note
about
that.
A
E
E
Question,
I
don't
know,
I
guess
I
can
look
through
the
edits.
Oh,
but
synonymous.
A
I
don't
know
if
the
person
who
asked
the
questions
on
the
call
they
can
ask
now,
but
otherwise
I
don't
think
any
of
us
have
context.
B
D
F
Them,
but
I
think
it,
but
I
think
it
should
be
good
to
have
at
least
some.
You
know
some
advice
to
users.
What's
the
preferred
way,
and
actually
I
have
a
question
for
you
guys
I
mean
this
is
like.
Usually
we
discussed
that
in
specification,
but
I'm
curious.
I
think
that
the
java
team,
the
java
of
this
regulation
team,
are
the
ones
that
used
to
create
a
few
tracer
providers
and
I'm
wondering
how
often
you
do
that
and
if
you
have
to
create
many
of
them,
we.
G
F
F
Auto
instrumentation
doesn't
do
that
nice,
it
could
be
nice
if
other
language,
maintainers
could
also
say
or
dimension
in
case
they
are
using
many
thresh
providers
as
a
common
scenario,
because
if
not,
that
means
that
we
can
probably
just
say,
hey
it's
possible,
but
it's
not
we.
We
don't
want
you
to
please.
Please
don't
do
that
if
possible,
you
know,
and
in
that
case
it
would
be
nice
to
say.
F
E
B
Yeah,
if
you
want
to
actually
prevent
sharing,
then
you
have
to
have
some
mechanism
for
identifying
that
it's
the
same
one
and
enforce
that
and
that
seems
to
add
moving
parts
that
aren't
there.
If
you
just
say,
don't
don't
share
if
they
can't
be
shared,
the
user
knows
best
what
the
exporter
and
the
the
sampler
can
and
can't
do,
and
if
there's
a
sampler
that
has
some
internal
state
that
really
can't
be
shared
across
tracer
providers.
That's
up
to
the
user
to
know.
F
No,
I
sure
I
agree
with
that.
I
agree
with
that,
but
I
think
that
most
users
they
won't
have
to
so
it's
like
you
know
like
I
could
have
to
have
a
guideline
saying.
We
recommend
that
if
you
have
more
than
one
provider
to
create
one
sample,
an
exporter
per
provider
instance
and
of
course,
under
advanced
scenarios,
yeah
go
ahead.
E
F
The
users
do
whatever
they
want
yeah,
but
this
came
out
recently
with
christianoin
mueller's
change
for
exposing
tracer
provider,
associates
provider,
resource
and
instrumentation
library,
to
the
samplers,
and
bogdan
mentioned
that,
if
you
know,
what's
your
resource,
a
tracer
provider
creation
time,
you
just
expose
it
directly.
Instead
of
having
to
specify
it
first
shoot
sample,
call.
E
F
E
B
Can
be
shared
again
right,
the
the
user
still
asked
the
question.
Do
I
really
want
this
sampler
sharing
this
resource
across
these
tracer
providers,
if
they're
setting
up
multiple
tracer
providers,
but
I
would
expect
a
situation
where
there
are
multiple
tracer
providers
being
configured
to
be
an
advanced
scenario
that
the
user
hopefully
knows
what
they're
doing
in
that
case,
because
I
don't
think
that
there's
anything
in
the
general
case,
that's
going
to
lead
a
user
towards
having
multiple
tracer
providers
and
it's
actually
probably
quite
dangerous,
because
I
don't
think
anything
in
the
span
context.
B
F
Traces,
okay,
yeah,
I'm
fine
with
that.
I
think
that
it's
a
trade-off
just
allowing
users
to
do
whatever
they
want.
In
that
case,.
G
G
I
mean
what
we
are
doing
is
so
the
end
user.
They
may
create
from
samplers
exporters,
but
once
they
create
the
tracer
provider,
we
enforce
them
to
pass
the
ownership
of
these
samplers
and
exporters
to
the
tracer
provider,
so
they
can
use
those
samplers
only
with
one
tracer
provider
once
they
have
transferred
the
ownership,
they
cannot
use
it
for
anything
else.
F
Users,
in
any
case,
I
think
that
I
guess
that
my
point
is
that
whatever
works
as
long
as
it's
clear
and
we
stayed
that
in
the
specification
that's
good
to
go
bogdan,
are
you
in
the
call,
maybe
because
I
suspect
that
mukdan
may
he
could
say
something
interesting
against
or
in
favor
of
this?
F
In
any
case,
let
me
put
a
comment
on
what
we
discuss
here,
that
yeah
it's
probably
dangerous
and
or
advanced
what
we
should
allow
users
to
to
do
whatever
they
want.
By
having
you
know,
tracer
providers
share
samplers
and
exporters,
and
it's
on
it's
on
them
to
verify
that
this
works
as
expected,
and
then
we
will
poke
box
then
to
comment,
if
he's
that,
with
with
that
or
not,
and
then
we
can
create
a
pr
to
to
clarify
this.
F
B
A
So
any
updates
from
the
metrics
or
log
specifications.
A
I'll
take
that
as
a
no
okay
php
bob,
I
think
I
saw
you
on
the
call
yep
I'm
here.
We
we
are
doing
us
a
0.002
alpha
release
this
week,
we're
making
slow
and
steady
progress.
Good
news
elita
mentioned
that
her
aws
folks
are
going
to
actively
help
participating
with
the
development,
so
that
should
really
help
yeah.
B
A
Perfect
java,
no
updates
of
significance,
java
instrumentation
1.2.0
released.
A
Python
no
significantupdates.net
cjo
said
he's
not
able
to
join
but
he's
showing
these
updates.
Uh.Net
runtime
has
made
the
initial
hotel
metrics
api
ready
to
release
the
part
as
a
part
of
net
6
preview.
5.,
that's
so
cool
hotel,
sdk
work
is
progressing
in
parallel.
Awesome.
B
Discussed
at
the
metric
safety,
I
said
a
few
weeks
back
and
they're
they're
going
to
be
shipping
a
preview
of
the
current
state,
they're,
not
shipping,
a
final
version
of
net
six
until
december,
or
something
like
that
so
they're
just
looking
to
gain
some
user
feedback
on
some
of
the
options
that
have
been
discussed
in
the
api
sig.
A
Okay,
good
question
john
go
working
towards
rc3
looks
like
we've
got
three
items
to
do
two
in
progress:
that's
great
and
292
done
wow
we're
getting
really
close
there
chugging
along
it's
awesome,
c,
plus
1.0
rc
milestone
is
planned
for
may
end.
Okay,
we've
got
12
open
issues.
28
closed,
fantastic
ashley
masks
from
the
last
meeting.
Support
for
dynamic
loading
of
vendor
sdk
is
not
fully
supported
and
is
not
planned
for
ga
all
right.
Any
comments
about
that
from
anyone.
So.
G
Yeah
this
was
a
question
from
ted
young
at
last
in
the
last
meeting,
so
just
just
a
confirmation
that
we
do
have
implementation
for
this
for
loading
the
windows
sdk
at
run
time,
but
it's
a
kind
of
hard
big
solution.
I
mean
the
configurations
cannot
be
dynamically
loaded,
it's
just
the
sdk
which
can
be
loaded.
We
haven't
yet
evaluated
the
security
implications,
so
we're
not
targeting
it
for
the
ga
we'll
be
seeing
it
afterwards.
A
Got
it
cool
all
right?
I
tagged
ted
here
so
he'll
get
notified
about
the
about
that
all
right,
ruby
we've
got
rc
one
coming
soon
cool
and
no
updates
from
the
swift,
collector
erlang,
because
it's
a
small
meeting
today,
all
right.
So
this
first
item
we
already
discussed.
That
was
just
my
notes
from
that
discussion
and
the
only
other
update
is
the
grafana
a
gpl
license.
A
So
we
talked
about
this.
This
is
a
I
added
this.
We
talked
about
this
at
the
governance
meeting
last
week,
so
grafana
the
open
source
project
has
changed
their
license
from.
I
think
it
was
apache
to
a
gpl
which
has
implications
for
any
project
or
company
or
really
anyone
who
references
that
code.
This
only
applies
to
it's,
not
retroactive,
so
this
only
applies
to
new
releases
that
they
have.
A
We
rely
on
one
grafana
protocol
buffer
bogdan
had
pointed
this
out
during
the
call,
so
bogdan
and
elite
are
going
to
reach
out
to
griffana.
There's
some
possible
solutions
here.
Maybe
we
get
an
exemption
for
open
telemetry.
A
Maybe
we
move
the
existing
graffana
exporter,
which
is
the
only
thing
that
references
this
into
the
grafana
github
org
instead
of
in
ours,
which
solves
most
the
licensing
issues
for
the
project,
or
we
ask
grafana
to
change
the
license
of
this
one
particular
file
back
to
apache
anyways
they're
on
it.
We
just
need
to
be
cautious
about
taking
future.
B
Polls,
my
understanding
was
that
they
were
going
to
continue
using
apache
as
their
library
license.
So
I
would
really
hope
that
we
can
get
this
into
that
third
option.
Okay,
the
the
first
one
would
kind
of
scare
me,
because
would
that
exception
be
transitive
to
users
of
open
telemetry
and
people
who
make
modifications
to
telemetry
and
the
like,
and
the
second?
They
would
like
to
avoid
fragmentation.
So
I
would
say
that
the
third
option
is
really
the
best,
especially
considering
they've
said:
apache
should
be
their
library
license.