►
From YouTube: 2020-08-25 Spec SIG
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
Okay,
so
so
far
we
have
john
justin
anthony
irmin
riley.
Take
it
around
me:
okay,
that's
not
bad!
Let's
wait!
Two
or
three
more
minutes.
A
A
A
A
B
B
To
our
project
board
that
attached
to
this,
what
is
it
called
project
bot
to
move
things
from
column
to
column?
So
we
don't
have
to
do
so
much
manual
stuff
with
the
help
of
tigran
digra
is
using
this
on
the
collector
repo.
B
I
might
need
some
help
on
permissions
later
if
this
is
not
actually
working,
but
it's
supposed
to
just
like
bring
things
into
the
needs
triage
and
then
once
it's
tagged
for
respond4ga,
it
puts
it
in
this
column.
So
those
are
some
things
in
order
to
help
with
what
we're
working
on
the
next
two
items,
their
time
box.
Seven
minutes
each
we'll
go
over
the
status,
as
I
usually
do
so,
for
I
think
I
pulled
this
up.
B
Maybe
last
night,
so
stuff
might
be
a
little
bit
updated
since
then,
but
we
can
double
check
and
see
whether
there's
any
issues
that
have
been
open
since
a
week
ago
that
need
required
for
ga
or
not
required
for
ga.
So
I
think
see.
We've
got
one
two,
three
four
five,
six
issues
that
we
need
to
choose
a
label
for
dictionary.
C
So
I
propose
this
my
goal
here
is
actually
a
small
amount
of
refactoring.
Well,
maybe
it's
a
large
amount
of
reactoring
in
the
spec
that
will,
I
hope,
really
speed
up
subsequent
prs
and
spec
changes.
D
The
way
that
is
done
currently
is,
I
think,
the
different
areas
refer
to
each
other.
The
labels
metric
labels,
for
example,
contain
links
to
the
corresponding
spam
attributes.
C
Yes,
exactly
the
thing
you
mentioned
that
that
metric
labels
refer
to
span
attributes.
What
we've
seen
is
that
it
generally
kind
of
devolves
into
like
a
circular
discussion
about
whether
it
makes
sense
to
link
from
metric
labels
to
span
attributes.
C
D
Makes
sense,
I
guess
it
will
add
clarity
over
what
we
have
currently
probably
not
a
must-have,
in
my
opinion,
more
like
an
improvement
nice
to
have
a
thing.
A
Yeah,
I
agree
with
that.
I
agree
with
that.
I
think
it's
something
nice
to
have,
but
it's
mostly
like
an
improvement
for
for
newcomers
and
for
a
clarity,
of
course,
but
yeah
this
can
be
done
after
because
we
won't
be
changing
the
content
itself,
just
things
to
be
better
organized
so
yeah,
I
would
say:
release
rtj.
E
Quite
some
work
to
get
this
through
one
note
from
me:
justin
regarding
the
title
of
the
issue
for
many
readers.
It
will
sound
like
if
you
wanted
to
introduce
a
new
data
type
or
something
like
that,
since
it
says,
introduce
label
dictionary
there
that
might
be
misleading.
E
C
F
G
My
thinking
is
like
consolidating
the
existing
semantic
convention
itself
is
not
required
for
ga,
but
having
this
like,
where
the
status
where
in
some
places,
we
have
the
same
response
called
http
response,
called
as
a
string
and
other
places
have
integer,
it's
going
to
be
a
big
problem
for
us
and
later,
if
vga
with
that,
will
regret.
A
D
I
B
Five
more
to
triage
in
the
remaining
minutes
so
see.
If
we
move
on
the
next
one,
sdk
sampler
should
be
able
to
modify
electricity.
G
For
that
sampling,
something
my
my
question
is:
if
we
do
that
after
ga,
would
that
be
a
breaking
change?
I
agree.
I
I
think
we
can.
We
can
always
add
additional
functionality
like
any
additive
change
is
not
considered
as
a
breaking
change
right.
If
we
remove
something
or
we
change
the
existing
behavior
by
saying
previously,
you
can
do
something,
but
now
you
cannot
that's
a
breaking
change
so
riley.
If
you.
J
A
D
A
A
J
I
mean
I
mean
let's
I
I
don't
understand
that
there
is
an
issue
and
we
should
review
that.
There
is
a
pr,
but
I
think
in
terms
of
priority
I
would
say
this
is
after
g.
J
I
would
say
if
I
have
two
hours
per
day
allocated
to
this,
I
would
start
with
things
that
are
required
for
ga
and
if
I
still
have
time
I
will
look
up
for
after
g.
If
I
don't
know
if
that
makes
sense
for
everyone,
but
it's
still.
I
have
a
certain
amount
of
time
in
the
day,
so
yeah
that
makes
sense.
B
Is
this
one
really
a
question?
Is
this
kind
of
construct
supported
in
the
current
sampling
trace.
B
J
This
would
be,
this
would
be
a
property
or
an
option
in
our
sdk.
Do
not
generate
ids
on
every
request.
If
user
doesn't
want
to
do
that,.
B
J
J
Can
be
added
after
g,
because
the
api
that
we
created
supports
that,
but
I
would
put
a
note
that
we
need
to
to
investigate
if
there
is
anything
breaking
that
we
need
before
ga.
Let's
put
this
way,
that's
the
minimum
effort
that
we
need
to
put
into
this.
I
don't
think
I
don't
think
it
is,
but
I
would
double
check
that.
I
I
think
one
problem:
if
you
give
us
only
a
spank
context
as
parent
you
might
lose
baggage,
for
example,
or.
J
J
B
I'm
running
a
few
minutes
into
it,
so
I
think
I'll
only
spend
like
five
minutes
on
this
one,
which
is
an
update
for
our
ga
spec
burn
down
of
issues
overall
to
do
90.
Let
me
see
whether
this
was
up.
Okay,
yeah,
I
think.
B
Last
night
there
was
some
movement,
so
it's
a
little
bit
we're
down
to
88.,
but
in
general
to
do
has
been
trending
downwards
in
prom
in
progress
has
about
seven
and
the
items
that's
been
closed
have
shot
up
at
least
17,
so
we're
now
up
to
45,
so
we're
making
solid
progress
there
for
the
issues
that
we're
trying
to
track
for
all
p1
issues.
B
I
think
34
total
13
closed
out
of
34.,
and
so
this
one's
trend
up
a
little
bit,
but
this
is
what
we're
trying
to
shoot
for
by
the
first
week
of
september
goal
p1
spec
trace
issues
which
we
have
five
remaining.
B
From
the
previous
triage
meeting,
I
like
to
call
out
that
this
was
determined
as
the
longest
poll
in
terms
of
risk
for
these
remaining
five
issues
so
being
able
to
tackle
this
issue,
remove
spam
status
from
api
will
go
a
long
way
towards
the
progress
of
closing
out
these
remaining
issues.
B
J
I
andrew,
I
think
we
can
do
that
offline.
We
are
pretty
good
at
merging
things
right
now
I
mean
if
people
are.
H
J
H
A
B
Should
I
take
it
off
the
standing
agent
item
or.
J
H
A
Oh,
thank
you
thanks.
So
much,
then,
okay,
great
fantastic
okay,
so
we
have
a
few
items
that
I
put
in
the
first.
One
is
initial
requirements
for
integration,
testing,
riley
yeah.
Thank
you.
I
think
you're
here
so
yeah.
I
was
wondering
if
there's
any
update
on
this,
yes
or
if
you
yeah.
G
G
A
Perfect,
okay,
we'll
we'll
do
after
after
the
call
great
thanks
for
the
update.
The
next
item
is
get
their
keys.
You
know
you
just
I
added
this
keys
operation
together,
it
looks
like
we
will
be
emerging.
A
A
F
Yeah,
I
can
still
hear
you
carlos
I
I
agree.
I
think,
there's
something
pretty
bad
with
zoom
looks
like
vodka
is
still
having
issues.
A
Yes
and
the
the
eco
it
can
get
is
getting
very
bad
at
some
points
anyway.
This
is
something
that
already
blocked.
That
knows
it's
about
getter
keys
operation.
It's
a
small
addition.
We
need
to
support
jagger
properly
or
fully.
It
will
most
likely
emerge,
and
this
is
for
the
la
for
the
sick
maintainers.
A
Just
I
will.
Of
course
I
will
let
you
know
if
that's
okay,
so
just
that's
just
for
your
information,
then
removing
spanish
status
yeah.
We
have
enough
reviews
for
your
tip
thanks
nikita,
for
that.
I
don't
know
if
it
is
here,
but
thank
you
for
that.
But
yeah
just
wanted
to
mention
that
this
is
important.
Math
math,
where
are
you
yeah?
I
see
you
here.
A
There
was
a
mention
about
trying
to
get
your
pr
with
the
european
part
done
and
merged
before
we
can
remove
spanish
status.
We
already
have
something
we
don't.
You
know,
have
nothing
after
spanish
status.
K
Yeah,
my
pr
is
open.
I
think
we're
talking
over
the
record
exception
api.
I
think
that's
the
only
controversial
part.
I
was
just
typing
up
a
comment
there,
but
yeah.
I
think
I
think
we
would
like
to
get
that
in
as
long
as
we
can
agree
as
to
what
we
should
do
for
the
span
record
exception.
Api.
A
Yeah
make
sense
to
me:
okay,
fantastic,
and
the
final
thing
is
that
how
should
resources
be
exported
from
jagger
you've?
This
is
yours
as
well.
I
think.
K
Yeah
I
opened
that
like
ultimately,
because
open
telemetry
effectively
allows
like
multiple
resources
per
process.
It
makes
mapping
resources
in
jaeger,
not
exactly
straightforward.
K
Looking
at
like
the
go
and
python
implementations,
I
see
that
they
merge
resource
attributes
to
span
attributes
to
kind
of
get
around
this.
I
think
another
approach
would
be
to
group
your
spans
by
resource
and
then
export
in
batches
for
each
resource
ice
is
looking
to
see
if
there
should
be
a
standard
way
to
do
this
across
open
telemetry,
and
if
so,
if
we
should
document
that,
I
did
notice
that
there
is
now
a
jaeger
spec.
D
K
Yeah,
I
think
that
resources
are
most
most
related
to
process
tags
from
from
jaeger.
It's
just
a
little
more
complicated
to
have
to
bash
by
resource
merging
them
into
span
attributes.
I
think
it's
like
the
easy
way
out,
but
maybe
not
the
most
efficient
or
maybe
not
the
most
accurate
mapping.
K
K
Per
per
export,
because
it's
not
like
otlp,
where
you
can
have
all
of
your
batches
in
one
request.
D
K
That
tracer
providers
can
share
the
same
exporter
correct.
I
kind
of
wrote
up
a
comment
yesterday
on
another
issue
that
describes
all
of
this,
because
I
feel
like
we've
had
this
conversation
this
or
this
conversation
keeps
kind
of
coming
up,
because
I
think
the
multiple
tracer
provider
use
case
is
not
100
clear
to
everybody
all
the
time.
I
D
J
Yeah,
so
we
did
in
java.
In
java
we
did
a
support
attaching
to
multiple
things
and
we
ended
up
having
to
construct
a
map
to
map
the
resource
to
map
by
resource
java
gives
you
some
nice
things
with
the
with
the
hash
code
for
for
equality
and
stuff.
So
so
it
was
not
that
bad
even
for
performance
and
stuff,
but
yeah.
Maybe
maybe
this
is
something
that
we
should
consider
simplifying
and
maybe
just
say
that
the
exporter
is
attached
to
only
one
trace
provider.
J
K
I
just
pasted
a
link
where
I
just
kind
of
like
typed
up
what
I
know
about
multiple
tracer
providers
and
how
they
affect
the
export
pipeline.
K
Personally,
I
have
not
been
like
a
huge
fan
of
this
use
case,
because
I
I
don't
understand
how
it
would
work,
at
least
in
some
of
the
projects
that
I've
seen
where
say,
I
have
multiple
tracer
providers.
I
can
only
have
one
global.
I
manage
one
off
the
books,
but
I
have
my
sql
instrumentation
and
I
have
I
want
each
tracer
provider
to
be
able
to
use
that,
but
attach
a
different
resource
like
I
haven't,
been
able
to
reason
through
how
they
both
can
share
like
a
my
sequel,
auto
instrumentation,
for
example.
K
K
But,
as
I
started
writing
that
comment,
I
have
been
interested
in
jay
mcnee's
resource
scopes
and
think
that
there
is
some
potential
to
be
able
to
manage
resources
in
your
context
and
have
multiple
resources
come
from
context,
as
kind
of
like
a
future
extension
of
this
idea
and
kind
of
an
improvement,
perhaps
around
the
multiple
tracer
provider
use
case,
and
ultimately,
I
kind
of
realized
all
of
the
things
that
we
have
to
do
to
the
export
pipeline
to
accommodate
multiple
tracer
providers,
what
you
would
have
to
do
to
multi
to
accommodate
resource
scopes.
K
So
I'm
now
kind
of
thinking
that,
if
we're
okay
with
what,
if
with
the
accommodations
that
we're
making
in
the
export
pipeline
for
multiple
tracer
providers,
then
it'll
allow
some
future
extension.
I
guess,
but
if
we
feel
like
this
is
not
like
a
useful
use
case,
it
does
complicate
things.
No
doubt
like
there
are
some
complications
that
are
added
into
the
export
pipeline
and
I
try
to
kind
of
just
lay
those
out.
G
Anyways
so
one
one
thing
I
have
observed
in
the
open,
telemetry
c,
plus,
plus
and
down
that
is
we're
taking
different
approaches,
because
I
want
to
experiment
like
I
see,
which
one
is
better.
In
c-plus
plus
we
use
reference
content,
so
exporters
can
be
shared
by
multiple
processors
and
the
same
processor
can
be
shared
by
multiple
tracer
providers
and
that's
creating
a
lot
of
like
scenario
issues
for
us.
G
So
if
multiple
tracer
providers,
they
share
the
same
batch
processor,
which
means
underlying
the
share
the
same
queue
and
if
people
want
to
flash
doesn't
mean
they
flash
the
queue
that
contains
data
from
multiple
tracer
providers
and
what's
the
right
behavior
for
that
and
in
dotnet
we
decided
to
go
with
a
simpler
approach
and
later,
if
we
figure
c
plus
plus,
is
making
better
progress,
we
might
change
so
in
dotnet
we
make
it
very
simple.
Exporters
are
owned
by
the
single
or
batch
processor
and
the
processor
is
owned
by
the
tracer
provider.
G
So
the
tracer
provider
could
safely
assume
that
the
underlying
processor
and
the
exporter
is
not
shared
with
any
other
providers.
In
this
way
they
own
the
entire
life
cycle
and
the
semantics
cleaner.
I
think,
in
order
to
get
into
a
better
status
either
we
need
to
like
clarify
the
semantic
like
what
does
it
mean
by
sharing
and
what's
the
responsibility
for
resource
management,
shutdown
flash
or
we
decided
not
to
get
that
clarity
in
the
spec
in
this
way
probably
take
a
simpler
approach
just
to
separate
things.
J
Yes,
my
opinion
is:
do
the
simplest
thing
right
now
yeah
and
if
the
complicate
is
too
much
this
multi,
this
sharing
of
exporter
between
trace
provider
and
stuff
complicates
too
much.
I
would
always
go
for
simpler
things.
J
I
would
always
go
with
with
maybe
maybe
reconsider
this
thing
and
say:
hey
an
exporter
instance,
and
the
spam
processor
instance
is
always
associated
with
only
one
trace
provider
and
because
that
will
most
likely
simplify
a
lot
of
the
things
in
terms
of
even
concurrency
problems
and
and
all
of
these
things,
so
multi-trading
problems
may
be
simplified
by
this.
So
that
being
said,
let's,
let's
most
likely
try
to
do
that.
So.
K
Yeah,
that's
my
my
two
cents
on
this.
I
feel
like
going
that
way.
Does
kind
of
paint
paint
yourself
into
a
corner
where,
if
you
wanted
to
like
do
something
such
as
resource
scopes,
I
don't
think
you
would
be
able
to
by
doing
that.
That's
kind
of
a
future
thing.
I
guess
we're
not
talking
about
adding
that
to
open
telemetry,
but
if
you
wanted
to,
if
that
was
on
anybody's
wish
list
tying
a
single
exporter
to
essentially
like
a
single
resource
kind
of
rules
that
out.
J
J
K
Yeah,
okay,
so
when
you
were
talking
about
simplifying
things,
I
was
imagining
that
you
were
simplifying
it
to
the
point
where
there's
like
you
know,
a
single
tracer
provider
attached
to
an
exporter,
ultimately
so
through
all
that
there's
only
one
resource,
but
I
think
that's
not
what
you
were
saying:
no,
not
what
I'm.
J
Seeing
and
even
if
there
is
only
one
resource
which
is
the
the
the
provider
resource,
but
we
may
also
add
in
the
future
another
resource-
and
you
will
do
you'll-
have
to
do
a
merge,
correct
like
even
this
scope.
This
scoping
thing
that
josh
wrote
some
times
ago
was.
J
The
idea
was
like
you,
have
a
static
resource
which
is
one
per
exporter
in
this
one
trace
provider,
and
you
may
have
this
scope
resource
called
scope
resource,
but
you
do
have
to
do
a
merge,
some
at
one
point
and
you
you
probably
have
to
pass
them
differently
to
the
exporter.
You
will
pass
one
resource,
which
is
the
trace
provider
resource
and
probably
with
every
with
every
span.
There
is
another
resource
associated
with
that.
K
A
Great
okay,
great
everything,
it
was
a
good
discussion
and
going
forward
just
small
two,
very
small
vrs,
for
your
information.
The
first
one
is
about
moving
version
convention
or
sember
from
versions.
Just
please
take
a
look.
It
looks
simple
enough.
I
think
it's
right,
but
if
you
are,
if
you
don't
agree,
just
comment
there
or
something
and
the
second
likewise
links
can
only
be
added
to
spam
creation.
A
I
think
this
is
what
all
six
are
doing,
but
if
you
are,
if
you
think
that
your
c
is
not
applying,
this
behavior
feel
free
to
comment.
The
change
is
basically
just
trying
to
clarify
that
this
is
the
case.
Still
I
wanted
to
get
other
people
to
look
at.
A
It,
okay,
I
think
I
think
we're
done
only
somebody
wants
to
raise
any
other
point.
G
So
quick
question:
I
wonder,
like
if
folks
like
see
any
like
clarity
on
the
flash
behavior
because
currently
like
I've
seen
like
in
the
open
times
with
c
plus,
plus
downlight
and
python.
Those
are
the
projects
I've
I've
become
like
approver
or
maintainer.
I've
seen
people
have
different
interpretation
of
what
flash
mean
and
doesn't
mean
like
after
flash
succeeded,
you
can
kill
the
application
and
believe
that
the
data
is
already
handed
somewhere
else.
It's
no
longer
owned
by
the
ick
and
people
have
different
beliefs.
G
D
Was
was
originally
introduced
in
the
context
of
the
shutdown
of
the
application
right
precisely
for
for
what
you
said
that
so
that
we
guarantee
that
data
is
not
lost.
I
don't
know
if
there
is
a
good
use
case
for
flashing
during
the
application
execution
like
yeah.
Do
you
do
you
want
to
do
that?
Do
you
want.
G
Yeah,
I
have
one
example
like
you're
doing
some
transactional
operation
and
you
want
to
send
auditing
logs
or
like
important
traces,
and
in
this
case
you
know,
if
I
cannot
guarantee
the
log
is
stored
somewhere
outside
the
process.
I'd
rather
not
do
the
work.
I'd
rather
like
stop
doing
things
and
blame
the
telemetry
system,
things
like
a
transaction
of
a
bank
or
like
insurance,
yeah.
I
I
think
the
use
case
that
flush
was
originally
introduced
for
was
aws,
lambda
and
other
function
as
a
service
providers
that
suspend
a
function
after
a
request
is
done
and
you
get
no
callback
before
you
are
suspended.
So
you
don't
know
for
sure
if
you
are
suspended
or
if
you
will
immediately
get
the
next
request
and
if
you
are
suspended
for
too
long,
I
think
they
just
throw
away
your
container
and
you
never
wake
up
and
never
get
the
chance
to
shut
down
properly.
G
E
Actually,
the
function
is
a
service
use
case
is
even
mentioned
in
the
sdk
specification,
where
it
says,
should
only
be
called
when
absolutely
necessary,
such
as
when
using
fast
providers
that
may
suspend
the
process
after
invocation
yeah.
The
motivation
is
already
there
actually.
G
E
G
Yeah,
but
currently,
when
we
look
across
the
isd
case,
it
doesn't
seem
to
be
the
case
like
I
have.
I
haven't
seen
a
like
an
example
that
I
think
guarantees
a
success.
Return
from
flash
will
make
sure
like,
even
if
you
kill
the
application,
the
bit
is
still
there
so
that,
like
just
a
hint
for
people
to
feel
free
to
implement-
or
this
is
a
guarantee.
E
G
E
That
there
is
a
timeout,
for
example,
or
that
the
end
point
which
is
exported
to
might
not
be
available.
I
don't
think
that
there
can
be
a
any
guarantee
taken.
So
a
telemetry
system
is
not
a
replacement
for
a
audit
logging
system
or
something
like
that
or
something
where
the
data
is
not
not
ever
allowed
to
be
dropped
or
anything.
G
E
My
interpretation,
yes,
okay,
yeah
thanks.