►
From YouTube: 2021-09-20 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).
C
All
right,
we've
got
a
cold
foggy
morning
here
in
portland,
so
fall
has
arrived,
although
I
think
it's
supposed
to
be
actually
70
and
sunny
this
afternoon.
So
very
nice,
perfect
weather,
very
good.
E
Yeah,
actually
it
was
a
fair
amount
of
sun
just
here
in
bc,
on
the
west
coast,
but
yeah.
It
was
a
lot
of
fun.
A
E
A
Once
somebody
gave
me
a
really
sage
piece
of
wisdom
right
before
I
got
married
and
I'm
a
little
too
late
for
you,
but
the
the
piece
of
advice
that
I
got
was
make
sure
that
you
not
only
love
your
partner
every
day,
but
you
also
like
them
too,
which
is
it's
sage
wisdom,
because
there's
times
where
I
have
to
remember
that
I
need
to
both
love
and,
like
my
wife,.
E
Yeah
it
was
it
was.
It
was
good
fun.
I
did
miss
two
weeks
of
these
meetings.
I
think,
but
I
am
finally
back.
E
Well,
I
I
I
was
thinking
I
was
trying
to
remember.
If
I
was
here
two
weeks
ago.
No,
I
was
not
okay,
so
yeah.
I
did
miss
two
weeks.
E
All
right,
let's
get
started
so
welcome
back
to
the
maintainers
meeting.
Everybody
I've
been
gone
for
two
weeks,
but
I'm
back
now
so
we'll
start
with
our
usual
sig
check-in
and
we'll
move
into
any
topics
that
people
have
put
down,
starting
with
the
spec
sig
so
looks
like
1.7
has
not
been
released.
Yet
we
may
delay
it
a
little
bit
more,
as
we
have
a
pair
of
issues
to
decide
upon
about
gzip
compression
support
and
adding
resource
the
sampling
api.
E
So
if
people
have
opinions
on
that,
please
weigh
in
there.
Similarly
for
sampling,
oteps
last
week's
call
for
final
reviews
generated
some
actionable
feedback.
Josh
will
update
the
two
oteps
today
and
we'll
present
a
summary
of
the
current
state
of
proposal
in
depth
at
tomorrow's
specsic
excellent
josh.
Did
you
want
to
go
through
the
summary?
I'm
guessing
you
wrote
this:
do
you
want
to
go
through
the
summary
right
now
or
should
we
wait
till
we
finish
the
check-in.
D
E
All
right,
metrics,
experimental
version
of
the
sdk
spec
is
done
is
will
be
part
of
the
1.7
spec
release,
ooh
fantastic,
we're
making
progress
on
the
following
things:
getting
the
sdk
spec
to
feature:
freeze,
yep,
perfect
language
implementations,
the
goal
to
hit
beta
before
the
end
of
november.
So
we
can
declare
the
api
sdk
spec
as
stable,
excellent,
any
other
color.
You
want
to
add
to
that
josh
or
anyone
else,
nope,
okay,
no
update
from
logs.
I
was
in
the
log
sig
call
last
week
and
I
concur.
There
were
no
major
updates.
E
Php,
there's
still
17
large
issues
that
are
open
that
need
to
be
moved
towards
a
beta
release.
38
issues
remaining
to
move
towards
ga
release.
Some
new
contributors
are
trickling
in
woohoo,
still
need
more
intuit
acquisition.
E
A
Yeah,
so
there
are
still
a
lot
of
things
in
flux
with
that
that
I
don't
know,
I'm
definitely
going
to
continue
to
try
and
be
the
php
maintainer
even
after
that
acquisition,
but
I
don't
know
if
intuit
is
but
has
the
same
policies
yet
on
allowing
20
time
or
50
time
or
whatever
it
is.
So
I
will
keep
you
all
updated.
I
don't
expect
that
to
change,
but
I
just
thought
I'd
mention
it:
okay,.
E
Perfect
java,
metrics
sdk
work
continues
the
pace.
Okay,
job
instrumentation
1.6
was
released
working
hard
to
stabilize
the
instrumentation
api
cool
javascript
started.
The
1.0
process
last
week
hit
some
minor
snags,
but
nothing
that
can't
be
resolved
quickly.
That's
a
big
big
jump.
We've
daniel
on
to
talk
about
it.
F
Yeah,
I
am
it's
not
that
big
of
a
jump
I
mean,
we've
been
talking
about
the
1.0
for
a
while
now.
F
Some
cncf
policy
issues,
I
guess
more
than
anything
and
in
the
end
we
just
decided
to
change
our
tooling
to
you.
They
were
not
gonna
change,
so
we
did
fair
enough.
So.
F
Started
the
process
for
our
1.0,
we
opened
the
pr
and
in
deciding
which
packages
would
go
to
1.0
and
which
would
be
held
back
as
experimental.
We
discovered
some
dependencies
where
a
package
that
we
wanted
to
be
stable
depended
on
packages
that
we
wanted
to
still
be
experimental,
so
we're
working
on
splitting
those.
E
And
I
saw
python,
we
had
a
1.5
release
two
weeks
ago,
while
I
was
out
that's
great,
no
major
updates.
Since
then,
dot
net
metrics
are
releasing
alpha
four.
Today
higher
performance
in
other
tweaks,
starting
on
views,
be
real
to
be
part
of
the
next
release.
E
Yeah,
I
bet
that's
that's
fantastic.
E
C
plus
v
1.0.0
for
trace
was
also
released.
One
week
after
formal
closure
of
the
tc
review
start
planning
for
the
metrics
api
implementation
man,
we
are
rolling,
that's
great,
all
right.
Any
updates
for
ruby,
swift
or
the
collector.
E
All
right
keep
going
first,
topic
is
from
tigran,
should
otlp
or
grpc
or
otlp
http
be
the
default,
and
I
don't
know
if
I
actually
saw
tigran
on
the
call.
So
I
will
open
this
issue.
E
All
right,
any
there's
not
a
whole
lot
here,
any
opinions
over
which
should
be
preferred
or
which
should
be
the
default.
Like
I
have.
I
personally
understand
the
differences
I
didn't
realize.
We
were
still
discussing
what
should
be
default,
but
any
thoughts
that.
I
People
have
yeah,
I
thought
it
already
been
chosen
too,
but
since
it
hasn't
I'd
like
to
say,
I
think
it
should
be.
It
should
maybe
be
default
grpc,
but
with
the
caveat
that,
if
your
language
or
whatever
or
doesn't
have
a
decent
or
a
stable
enough,
grpc
client
that
it
can
use
http
as
the
default.
E
D
I
H
There,
maybe
that's
a
little
better.
That's.
H
Yeah,
I
was
gonna
say
like
I
think
we
had
this
conversation
before
and
what
tristan
said
I
thought
was
the
conclusion
on
that
was.
I
think
I
think
it
was
javascript
or
maybe
it
was
another
language,
but
they
did
not
have
a
good
grpc
implementation
and
it
made
more
sense
to
have.
E
D
C
F
E
Okay,
so
we'll
leave
this
feedback
here
for
tigran.
I
josh
correct
me.
If
maybe
correct
me,
if
you
disagree,
but
I
guess
what
I'm
hearing
is.
Maybe
it
does
make
sense
to
just
have
it
default
to
one,
because
there
will
be
there
will
be
cases
where,
for
whatever
reason
people
do
include
both
implementations.
E
Okay,
great
I'll,
add
that
to
notes
next
look.
C
E
E
E
All
right-
and
I
will
update
those
notes
in
a
minute,
but
the
next
discussion,
also
from
tigran
standardized,
the
name
of
the
logging
standard
out
exporter,
so
different
sdk
and
collectors
use
different
names
for
the
exporter
that
writes
to
standard
out
for
goes
standard
out
for
java.
It's
logging
for.net,
it's
console,
collector
is
logging
and
for
others
it
doesn't
yet
exist.
B
E
J
There
at
all,
going
to
align
the
name
might
be
hard.
For
example,
in
c
plus
plus
people
are
very
familiar
with
the
the
like
the
see
out
the
the
student
see
out
which,
like
in
c
plus
class
you
you
hardly
see
anything
like
console.
Everyone
call
that
standard
outstanding
error
or
something
in
dot
net.
It's
just
there's
a
system.console
class,
so
I
I'm
guessing
it
might
be
already
well
established
with
each
language.
So
trying
to
align
here
doesn't
seem
to
be
something
that
we
we
can
do.
E
Okay.
So
what
I
guess
what
I'm
hearing
is
is
from
riley
you're,
basically
saying
you
don't
think
we
can
standardize
it
and
from
john
you're
saying
that
also,
it
probably
may
make
sense
to
use
different
names
in
different
contexts:
yeah,
okay,
all
right
and
the
next
topic
that
I
know
we
had.
I
think
we've
got
two
so
I
was
I
have
one
just
for
introducing
a
new
person
and
then
josh.
That
is
that's
what
we
want
to
talk
about.
E
So
my
one
topic
is,
I
think,
we've
ouch
on
the
call
ounce
just
joined
our
team
at
splunk
as
a
pm
on
how
we
get
data
in,
but
he's
going
to
be
spending
a
big
chunk
of
his
time
on
open
telemetry.
So
you
may
see
him
on
this
call
or
other
calls.
So
that
works
for
me
and
we
don't
have
a
huge
number
of
product
managers
in
open
telemetry.
E
But
I
figured
it'd
be
nice
to
have
someone
who
can
also
work
with
various
sigs
and
help
keep
them
organized
and
generally
help
contribute
in
ways
that
I
have
in
the
past.
So
I
can
have
some
more
people,
basically
assisting
in
non-non
without
just
committing
code
and
doing
pure
engineering
things
so
much
if
you're
on
this
call,
you
may
want
to
introduce
yourself.
K
Yeah,
absolutely
hey,
so
it's
great
being
here,
I
think
I'm
very
excited
to
be
able
to
just
be
able
to
really
contribute
in
any
way
possible.
I
think
in
this
project
as
well
and
and
I
did
join
splunk
a
couple
of
weeks
ago
and
yeah-
I
think
it's
it's
a
it's
an
exciting
time
to
be
here.
I
think
just
looking
through
and
being
able
to
join
today
and
see
all
the
updates.
K
I
think
that's
that's
that's
been
great
as
well
so
yeah,
thanks
for
having
me
and
I'm
hoping
to
be
able
to
help
us
really
move
towards
our
goals
and
milestones.
I
think
that'll
be
exciting
to
look
at
it
thanks.
D
Hi,
if
I
just
thought
we
could
have
a
moment
for
open
q,
a
about
sampling
or
sampling
oteps
that
I've
been
working
on,
although
it
occurs
to
me
that
I
should
probably
disclaim
that
there's
a
discussion
going
on
about
resources
in
the
sampling
api,
and
that
is
not
one
I've
been
working
on.
I
have
commented
on
it.
If
that's
the
question,
it's
more
of
an
open
q,
a
for
everyone.
D
If
you
want
to
talk
about
probability
sampling,
I
have
been
working
on
these
oteps
for
the
past
month
and
they're
very
close
to
being
mergeable.
D
We
are
going
to
be
proposing
that
we
include
probability
information
so
that
the
parent
sampler
can
include
its
probability
as
well
as
the
consistent
sampling
spec
to
do
trace
id
ratio
sampling.
All
that
is
pending
and
ready
for
merging,
and
the
last
question
that
came
up
was
about
how
we
encode
this
information
in
span.
I'm
going
to
be
updating
all
of
my
oteps
today
and
then
I'm
going
to
present
a
pitch,
I'm
going
to
explain
it
in
one
walk
through
tomorrow.
D
If
not,
I
propose
that
I
speak
for
another
30
seconds
on
the
topic
of
resources
and
sampling.
So
there's
this
issue
number.
I
can't
remember
which
open
about
whether
we
should
add
the
resource
to
the
sampler
api.
It's
blocking
the
1.7
spec
release,
which
is
why
it's
been
hotly
debated
recently.
D
The
the
two
positions
are
samplers
should
be
the
the
one-stop
shop
for
configuring,
a
tracer.
So
therefore
they
need
to
be
able
to
do
anything,
including
sample
based
on
the
resource.
D
The
the
opposite
position
is
that
resource
should
be
a
immutable
record
once
the
sdk
is
up
and
running.
Therefore,
it's
constant.
Therefore
it
doesn't
belong
in
your
sampling
decision,
and
it
occurs
to
me
as
I've
been
thinking
about
this
in
the
past
few
days,
that
the
discussion
is
really
not
about
sampling.
It's
really
about
where
you
want
your
configuration
to
go
the
way
things
are
heading.
D
If
we
follow
this
proposal,
configuration
ends
up
in
the
sampler
anything
you
do
to
configure
how
you
view
your
spans
will
be
part
of
a
sampler
and
I'm
starting
to
feel
like
that's,
not
a
logical
outcome.
The
best
outcome
that
we
could
have
to
me
it
would
be
better
if
we
referred
to
sampling
as
a
sort
of
mathematical
exercise
for
estimating
how
many
spans
there
are
essentially
and
this
other
topic,
which
is
how
do
I
suppress
my
spans?
How
do
I
select
them
based
on
configure
my
my
tracer
based
on
resource?
D
Those
are
decisions
that
are
going
to
use
the
resource,
but
they
are
part
of
configuring,
an
sdk
when
I-
and
at
the
moment
the
hotel,
specs
just
don't
say
very
much
about
configuring,
an
sdk,
and
so
this
proposal
to
put
resource
into
the
sampler
is
effectively
pushing
us
away
from
configuring
sdks
and
pushing
us
towards
configuring
samplers,
and
I
don't
think
we
should
go
that
way.
But
it's
I'm
not
the
only
person
an
opinion
on
this.
L
Josh,
could
you
talk
a
little
bit
about
how
that's
different
from
ins,
the
instrumentation
library
name.
D
That's
also
related
here
and
it's
been
discussed
and
I've
put
this
into
the
thread.
The
question
is
okay,
we
have
two
concepts
here.
One
is
resource,
one
is
instrumentation
library
and
the
instrumentation
library
is
provided
statically
to
a
tracer
and
then
at
some
point,
when
you
call
your
sampler
api,
we've
already
put
merge
in
the
spec
for
the
1.7
release
that
the
instrumentation
library
will
be
part
of
the
sampling
input,
and
you
could
argue
that
that's
not
the
way
I
expected
this
to
go.
We
have
talked
about
these
names
tracer.
D
The
names
tracer
idea
was
so
that
we
could
have
each
library
get
its
own
configuration
or
its
own
behavior
or
its
own
suppression
or
whatever
it
was.
So
we
already
put
this
library
string
at
a
point
where
it's
statically
constructed
and
then
the
question
is:
why
would
you
go
and
use
that
in
your
sampler?
D
Wouldn't
you
instead
prefer
to
customize
the
sampler
for
each
instrumentation
library,
because
that's
where
we're
heading,
we
don't
really
want
to
be
making
a
dynamic
decision
based
on
runtime
or
sorry
based
on
resource
and
based
on
the
instrumentation
library,
because
those
could
have
been
made.
Statically,
so
the
sort
of
resistance
to
this
pr
this
proposal-
that's
blocking
1.7-
is
that
you
don't
need
to
change
the
spec
to
update
your
sampler
to
use
the
resource.
You
just
don't
need
to
do
that.
D
We
also
don't
need
instrumentation
library
in
there,
but
the
reason
why
the
spec
is
still
there
is
that
people
want
to
forget
about
tracers
and
just
look
at
a
record
which
has
resource
instrumentation
library,
plus
all
the
other
dynamic
attributes.
And
my
opinion
is
it's
pushing
us
towards
a
very
inefficient
sample
implementation,
where
you
actually
make
a
decision
based
on
resource
at
runtime
for
every
span,
and
you
shouldn't
do
that.
L
Yeah
that
that
makes
a
lot
of
I
mean
the
the
inefficiency
I
know
it
has
been
raised
and
we've
kind
of
seen
it.
I've
seen
it
actually
in
in
load
testing
of
the
the
java
instrumentation,
where
I
want
one
percent
sampling
to
be
like
way
less
overhead,
but
we
do
so
much
work.
Well,
I
guess
that
doesn't
help
that
this
that
doesn't
help
because
you
still
have
to
capture
the
attributes.
So
this
is
for
instrument,
library,
instrumentation
library
name.
L
So
if
from
the
direction
that
you're
proposing,
would
we
then
pull
out
instrumentation
library,
name
from
the
sampler
before
1.7.
D
I
mean
I
don't
have
the
energy
to
fight
for
that
myself.
But
yes,
I
think
that
would
make
sense
and
what
we
could
do
in
its
place,
maybe
would
be
to
specify
something
about
how
you
construct
an
sdk,
and
we
have
vague
statements
about
how
the
resource
must
be
attached
to
an
sdk,
which
must
then
therefore
be
applied
to
all
the
spans
right.
D
But
we
don't
have
anything
about
saying
how
the
sampler
gets
attached
to
the
sdk
and
if
there's
always
a
one-to-one
mapping
between
sampler
and
sdk,
then
you
could
create
a
new
sampler
api,
which
is
something
like
a
sampler
is
just
a
factory
for
sampler
instances
and
the
sampler.
First,
you
say:
I've
got
an
instrumentation
library
or
sorry.
First,
you
say
I've
got
a
resource,
give
me
your
sampler
builder,
and
then
you
say:
I've
got
an
instrumentation
library.
D
You've
got
a
no-op
tracer
right
there,
because
you
configured
that
tracer
for
no
op
and
then,
when
you
get
to
the
other
library
that
you
want
one
percent
sampling
on
you,
you
know
that
it
got
17
sampling
because
of
you
know
like
a
decision
that
was
made
based
on
the
resource
or
the
instrumentation
library
at
startup,
and
so
that
you
should
only
be
using
dynamic
attributes
that
are
things
that
are
actually
variable
at
the
time,
you're
doing
a
snapchat
decision
and
trust
you're
right
that
doesn't
necessarily
save
you,
the
entire
expense
of
constructing
a
spam,
because
you
had
to
produce
those
attributes
in
the
first
place.
D
My
proposal
is
sort
of
to
sidestep
this
lengthy
debate
and
to
allow
both
approaches
was
to
have
an
option
for
the
sdk
to
implement
a
fancy
sampler
api,
which
would
be
an
efficient
form
so
right.
Basically
the
spec
would
then
say
the
sampler
must
the
sample.
The
sdk
must
provide
a
stanford
api
that
that
acts
as
if
and
then
you
can.
You
can
modify
the
sampler
api
to
do
the
same
behavior,
but
to
pre-calculate
something
based
on
resource
or
instrumentation
library.
L
Right
so
what
what
do
people
think
about?
I
mean
that,
because
I
feel
like
the
instrumentation
library,
name
and
resource
should
either
both
go
into
the
sampler
or
need.
Like
I
hate
a,
I
would
hate
to
release
1.7
with
just
the
instrumentation
library
name,
because
that's
a
breaking
change
right
I
mean
we
have
to
add
a
new
overload
and
then,
if
we
do
add
resources
later
that's
another
overload,
I
mean
I
I
would
prefer
to
hold
on
both
of
those
till
we
decide
the
path
forward.
D
B
I
Yeah,
I
think
neither
should
be
in
there.
I
completely
agree
with
josh.
I've
been
working
right
now
on
this
tracer
provider
configuration
I
don't.
I
don't
know
if
josh
you
were
talking
about
sdk,
but
to
me
this
sounds
like
a
tracer
provider
configuration
type
thing
which
I
guess
could
be
involved
through.
That's.
I
Yeah,
so
this
came
up
because
the
users
of
the
yearling
and
elixir
library
were
wanting
to
configure
their
sampler
based
on
what
application
is
calling
is
creating
the
span
and
so
right
now
working
on
a
provider,
multiple
provider
setup
that
can
base
that
can
be
chosen
depending
on
what
application
is
in
use.
And
that
makes
I
if
we
start
adding
instrumentation
library
and
resource
into
the
sampler.
People
are
going
to
start
using
that,
instead
of
going
the
direction
of
creating
the
proper
trace
provider
and
generate
a
tracer
from
that.
M
M
D
Just
to
add
some
general
color
to
your
statement,
I
think
the
the
I
I've
hinted
at
something
which
is
called
configuration
interest
and
just
described
it
almost
exactly,
which
is
that,
like
you're
you're,
going
to
set
up
some
tracers
and
you
have
different
configurations
for
different
instrumentation
library,
different
behavior
based
on
resource,
which
is
something
at
startup
in
the
metrics
sdk,
which
I
wouldn't
blame.
Many
of
you
for
not
following
closely.
We
have
created
this
proposal
in
the
that's
in
the
feature.
Freeze
called
a
view.
D
Specification
and
views
are
all
about
choosing
the
behavior
on
a
per
instrumentation
library
basis
and
a
per
instrument
basis,
and
I
mean
resources
included
in
the
statement
there
as
well.
But
the
idea
being
that
you
you're
going
to
have
a
big
amount
of
configuration
handed
to
you
at
startup
and
you're,
going
to
configure
all
your
meters
and
how
each
instrument
behaves,
and
that
might
include
multiple
aggregations
for
some
instruments
and
so
on.
D
And
I
feel
like
that's
the
direction
that
we
want
to
go
for
tracing,
which
is
to
say
that,
given
a
re,
you
know
a
bunch
of
static
configuration
you're,
going
to
configure
an
sdk
using
your
resource
and
then
you're
going
to
configure
a
bunch
of
tracers
using
information,
free,
instrumentation
library
and
then
you're
going
to
have
a
behavior.
That's
based
on
span
name
and
then
you're
going
to
have
some
sampling
logic
and
there's
like
that's,
going
to
be
configured
and
then
we'll
be
talking
about
probability.
D
Based
on
the
silence,
I
think
what
I'm
hearing
from
two
people
now
is.
We
should
propose
to
revert
the
the
pr,
the
added
instrumentation
library
to
the
sampling,
api
and,
and
then
my
recommendation
is
that
we
as
a
group
talk
about
configuring
views
for
spams
and
having
that
include
the
configuration
based
on
resource
and
or
instrumentation
library
and
or
expand
name
plus
attributes,
and
so
on.
L
I
think
it's
a
good
idea,
even
if
we
come
back
to
for
some
reason
that
didn't
work
out
and
would
decide
to
come
back,
then
at
least
we
can
do
both
instrumentation
library,
name
and
resources
together
in
either
direction.
D
Not
split
them
up
right
and
I
think
it's
as
a
thought
experiment.
Just
imagine
that
you
had
a
sampler
that
did
not
include
the
instrumentation
library
you
could.
I
think
anyone
here
could
do
a
fairly
simple
exercise
to
construct
a
sampler
that
produced
one
additional
input
from
the
instrumentation
library
and
called
a
new
api
that
didn't
need
to
be
spec
exported.
D
So
you
can
implement
a
sampler
based
on
instrumentation
library
if
you
care
to.
But
the
reason.
Why
is
that
you
can
do
something
adaptive
like
I'm
going
to
do
a
fixed
rate
limit
over
all
my
spans
and
I'm
going
to
say
I
want
a
balanced,
instrumentation
library
or
something
like
that,
so
that
you're
going
to
end
up
with
an
average
number
equal
for
every
instrumentation
library.
That's
the
kind
of
sampling
that
would
use
instrumentation
library
and
that's
fancy,
and
I
don't
think
we
should
have
that
built
into
the
spec.
L
So
carlos,
why
do
you
mention
that
hold
one
seven
until
october
and
it
sounds
like
if
we
just
pull
out
this
one
pr,
then
then
you
know
we're
just
delaying
that
one
piece
to
1.8.
B
L
My
impression
was
that
christian's
main
concern
objection
was
he
didn't
want
to
release
the
ad
instrumentation
library
name
without
resource,
since
basically,
if
the
then
resource
would
never
get
added,
because
that
would
be
another
breaking
change,
so
I
would
imagine
pulling
that
out,
and
you
know,
making
the
decision
in
1.8
seems
good.
E
All
right
well
for
all
done
with
that
topic.
Are
there
any
other
topics
for
today.