►
From YouTube: 2020-11-03 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
E
B
G
Did
you
want
to
do
your
agenda
item
first,
or
should
I
move
my
stuff
to
the
top.
H
D
There's
actually
two
issues
I
wanted
to
talk
about.
One
is
just
this
user
research
and
dog
fooding
guide,
so
I
put
this
together
I'll
be
spreading
this
through
the
sigs,
but
I
want
to
spread
it
here
first,
this
is
just
since
we're
closing
down
on
the
spec
being
frozen
for
tracing.
We
now
are
reaching
a
stability
point
where
it's
be
very,
very
good
for
us
to
review
the
actual
user
experience
on
the
tracing
side
for
new
users.
D
So
I
put
together
a
user
research
guide.
It's
very
easy,
step-by-step
guide
for
people
to
follow
through
with
what
you
do
is
you'll.
Take
this
document
create
your
own
copy,
walk
through
it
and
then,
when
you're
done,
submit
your
copy
to
this
form
here.
D
So
so
that's
the
exercise
and
all
it
is-
is
about
creating
a
very
simple
client
and
service
with
hello
world,
stepping
through
the
installation
and
configuration
automatic
instrumentation
and
then
the
basic
features
of
manual
instrumentation
that
an
end
user
would
be
interacting
with
so
accessing
the
current
span.
Creating
child
span
testing
some
baggage,
very
straightforward,
but
just
fill
in
your
feedback
as
you
go.
You
want
to
just
use
this
to
kind
of
get
in
the
mindset
of
what
our
end
users
are
feeling.
D
So
please
spread
this
to
your
special
interest
groups
to
fill
out.
If
you'd
like
to
do
this
for
an
implementation.
D
That's
not
yours,
put
yourself
more
in
the
new
user's
seat,
that's
also
great,
and
if
you
can
gather
people
who
are
not
us
to
go
through
this,
ideally
people
who
are
potentially
maybe
someone
else
at
your
company
who
hasn't
touched
this
stuff
so
much
so
if
we
could
do
an
internal
drive
within
each
of
our
organizations
to
try
to
stuff
out
just
as
much
feedback
as
we
can
get
at
this
point
and
if
you're
a
language
maintainer,
if
you
could
come
in
here
and
add
your
language
here
or
otherwise
adjust
this
list.
D
I've
only
put
the
languages
on
here
that
people
have
said
are
in
a
stable
enough
place
for
this
to
go
so
goes
not
on
here
at
the
moment
looks
like
java.
Maybe
you
will
want
to
wait
for
0.10
to
get
out
the
door.
D
So
that's
that's
my
big
pitch
and
I'll
be
going
around
and
pushing
this,
but
if
maintainers
and
sig
leaders
could
be
proactive
around
getting
people
to
fill
this
out,
so
don't
have
to
chase
people
down.
That
would
really
be
great.
F
You
can
put
you
can
put
go.
I'm
I've
been
working
on
instrumenting
the
collector,
with
the
go
more
advanced
than
what
it
is
here,
but
I
yeah-
I
probably
not
gonna-
have
time
to
fill
this
document
that
you
want,
but
I
provided
feedback
on
that.
D
Great
yeah,
I
would
had
go
on
here
and
then
yesterday,
maintainer
requested
that
it
it
get
removed
temporarily,
because
I
think
they're
they're
doing
a
bunch
of
rearranging
around
the
api.
Potentially.
F
D
Right,
let's,
let
me
just
add.
I
D
Okay,
good
feedback.
Okay,
so
that's
my
big
pitch.
If
people
want
to
help
with
this,
some
people
have
already
volunteered
to
help
organize
some
of
this
and
try
it
if
you
don't,
if
you're
interested
in
doing
that
as
well.
I
want
to
add
your
name
here
just
like
follow
up
with
you.
That's
also
great,
but
you
don't
have
to
do
that.
Please
just
try
the
user
research
and
spread
this
to
other
people
and
convince
them
to
do
it.
D
I
will
go
on
twitter
and
ask
the
internet
to
do
this
at
some
point,
but
I
want
to
give
us
like
a
first
stab
at
it
before
I
do
that,
just
so,
we
don't
get
flooded
with.
Like
you
know
the
same,
I
can't
find
the
documentation
question
so
that'll
be
round
two
okay.
So
that
was
the
first
issue
and
if
you
don't
mind-
because
I
have
to
go,
josh
asked
me
to
address
this
other
issue
around
renaming
label
to
attribute
for
consistency
here.
D
D
I
know
you,
you
have
some
reservations
in
so
if
we
could
spend
a
couple
minutes,
maybe
just
digging
into
this
issue,
because
I
think
this
is
a
just
important
cleanup.
We
could
do
if
we
can
get
away
with
it.
F
I
think
I
mentioned
in
that
my
my
problem,
so
anyway,
my
two
cents
here
I
I
I
do
like
consistency
of
naming,
but
if
that
comes
with
per
package
restrictions
and
separate
in
different
semantics,
it's
a
problem
so
so
for
for
metrics.
So
far
we
haven't
found
a
good
reason
to
use,
let's
say
int
as
labels
attributes
and
if,
if
we
just
rename,
but
we
put
restriction
on,
you
know
what,
for
for
labels,
only
strings
make
sense
the
rest
of
the
other
things
don't
make
sense.
It's
a
bad
state
to
be
so
anyway.
D
That
that
I
agree
with
so
I
actually
encountered
this
with
baggage.
I
can't
actually
remember
which
language
it
was
where
I
was
trying
to
attach
some
baggage
and
it
just
nothing
was
happening,
and
it
was
because
I
was
using
an
end
right.
I
was
trying
to
do
project
id
one
two
three
and
flow
that
I
don't
think
there
should
be
a
restriction
on
that
front.
D
If
we
need
to
convert
to
string,
you
know
in
order
to
serialize
it
it's
fine,
but
I
think
there
are
plenty
of
examples
where
I
certainly
want
an
int
here,
project
being
able
to
segment
out
by
by
project
or
account
or
something
like
that
is
one
such
example.
It's.
F
It
is
fine,
but
we
can
either
ask
the
user
to
do
the
conversion
where
we
can
do
the
conversion
anyway.
So
what
I
my
questions
here
is:
I'm
completely
against
just
renaming
and
adding
per
package
restrictions.
H
F
D
D
F
Again,
we,
we
did
have
a
very
good
explanation
and
separation
of
concerns,
because
we
said
okay,
labels
are
just
key
key
values
with
during
string.
Attributes
are
key
values
and
value
can
be
a
lot.
So
we
did
have
this
good
separation
and
we
said
okay,
and
maybe
maybe
maybe,
if
we
standardize
on
two
terms.
That
was
my
idea
like
if
we
standardize
on
two
terms
with
clear
semantics
that
one
means
you
can
put
everything
you
want.
F
D
Yeah,
I
I
have-
I
do
agree
with
you
in
in
practice.
Having
used
this
there's
two
things
I
noticed
one
is,
you
may
want
to
be
putting
these
things
in
multiple
places
and
having
to
think
about
you
know
the
type
tying
to
what
specifically
you
want
to
use
it
with
later
is
like
extra
overhead
and
there's
also
just
what
I
would
kind
of
call
type
fatigue
with
with
new
users
like
open
telemetry
does
require
like
a
lot
of
different
packages,
especially
for
some
languages
where
you
know
the
labels.
D
Are
it's
not
just
like
a
map
of
things
right?
You
need
to.
Actually,
you
know,
use
some
label
types
for
all
this
stuff,
and-
and
so
these
are
just
kind
of
like
speed,
bumps
that
I'm
watching
new
users
run
into.
J
With
this
stuff,
yeah
yeah,
can
I
make
a
quick
comment?
Sorry
so
bogdan
your
argument
about
like
the
different
like
having
having
two
things
that
mean
something
that
meaning
is
really
only
relevant
to
like
spec
owners
and
implementers
of
open
telemetry,
not
necessarily
users
right
like
if
I'm
a
user-
and
I
want
to
know
when,
should
I
use
an
attribute
and
when
should
I
use
a
label?
J
If
the
answer
is
the
same
like
it's
just
one
happens
to
be
tracing
and
one
happens
to
be
metrics,
then
I
don't
think
it's
a
useful
distinction
to
the
user,
and
so
that
that's
where
I
think
the
argument
here
that
I'm
keep
hearing
is
about
like
let's
look
at
what
the
user
thinks
about
and
a
user
is
asking
you
know,
should
I
be
using
a
label?
Should
I
be
using
an
attribute?
J
If
the
answer
is
almost
always
the
same
time,
then
I
think
those
concepts
should
be
blended
to
not
confuse
the
user,
whereas
the
spec
of,
like
you
know,
does
this
thing
turn
into
a
string
or
not.
That's
that's
a
different
story,
that's
more
of
an
implementation
concern
and
if
there's
a
way
to
kind
of
hide
that
from
users
that'd
be
good.
J
D
D
Just
fine
and
again,
like
I
literally
ran
into
this
using
baggage
for
like
a
totally
legitimate
reason
of
trying
to
to
flow
an
attribute
called
project
id,
because
I
wanted
to
be
able
to
get
my
traces
and
metrics
segmented
so
that
I
can
tell
if
they
were
localized
like
a
problem
with
just
a
handful
of
projects
or
if
there's
a
problem
happening
everywhere
and,
of
course,
the
value
there
was
an
end
and
then
it
just
like
silently
threw
it
away
so
that
that
experience
in
particular
was
pretty
poor.
D
H
D
Like
that,
that
wasn't
great
but
at
the
same
time
I'm
finding
valid
reasons
to
use
these
these
other
types.
D
So
I
think
if
we
just
simplify
it
and
say,
like
you
know
your
attributes,
and
you
know
you
pass
attributes,
you
know
these
label
values
or
whatever
we're
calling
them,
and
that's
that's
that
I
think,
would
just
would
help
for
end
users,
especially
if
they're
going
to
end
up
building
these
things
up
somewhere
else,
which
I
suspect
they
may
do
and
wanting
to
apply
them
consistently
across
multiple
packages.
D
F
Yeah,
so
if
you
read
by
the
way,
if
you
read
this
proposal,
the
as
these
cases
are,
there
are
a
couple
of
cases
with
the
list
and
the
map,
and
the
solution
proposed
is
to
turn
that
into
an
unrepresentable
string,
which
is
not
good,
because
that
means
we
don't
we
don't
support
actually
at
least
and
map
here
in
this,
so
so
I
think
it
needs
the.
It
needs
a
bit
more
thoughts
on
this.
F
D
Think
that's
fair
and
yeah.
You
have
pointed
out
the
tricky
ones
which
are
the
the
the
multiple
values
of
any
form
right.
That's
gonna
make
you
know
parsing
trickier
than
if
you
didn't
have
that,
but
I
you
know
I
I
think
we
should
tackle
that
one
way
or
the
other.
D
You
know
it
could
be
that
if
you
serialize
those
things,
maybe
they
come
out
as
everything
comes
out
of
baggage
as
a
string
or
something
like
that,
but
I
don't
know
we
could
figure
that
out
so,
but
as
long
I
just
wanted
to
to
take
the
first
step
of
like.
Can
we
get
agreement
that
like
this
is
something
we
should
tackle.
F
F
As
one
of
my
proposal
like
we
have
a
standard
concept
called
label
which
is
string,
string,
an
attribute
which
is
string,
multi-value
stuff
or
and
and
make
it
clear
when
we
use
one
or
the
other,
or
we
just
standardize
on
one
of
them
and
for
for
edge
cases
and
stuff.
We
define
what
is
going
to
happen
with
that.
D
And
I
think
that's
that's
what
I'm
hoping
to
to
maybe
get
here
is.
If
we
can
agree
that,
like
let's
just
simplify
this
down
to
one
type,
then
we
can
move
the
discussion
forward
to
like
okay.
How
do
we
handle
some
of
the
educations
and
issues
with
doing
that?
I'm
just
a
little
concerned
that
the
conversation's
gotten
stuck
in
like
should
we
have
one
type
of
two
types.
K
And
I
think
those
are
totally
separate
so
right
now
the
the
use
case,
the
issue
that
you
mentioned
about
trying
to
put
an
integer
in
baggage
and
it
just
not
showing
up.
That's
like
that's
a
pretty
awful
user
experience
and
that
needs
to
get
solved
regardless
of
how
whether
we
collapse
into
one
type
here,
yeah
and.
L
I'd
like
to
add
the
same
is
true
for
for
resources.
If
you
set
an
integer,
valued
resource
and
then
somebody
in
a
pipeline
says,
I
want
to
turn
that
resource
value
into
a
label
on
my
metric
export
in
a
sort
of
legacy
protocol
that
doesn't
support
other
values,
you're
going
to
support
you're,
going
to
turn
that
into
a
string,
and
I've
actually
said
everything
I
can
on
this
already
in
the
issue.
I
don't
believe,
there's
a
meaningful
distinction,
so
we
should
not
call
it
a
semantic
distinction.
F
I'll
I'll
take
my,
I
think
I
think
josh.
That's
that's
a
very
good
point
and
I
think
maybe
that's
we
where
we
should
start.
We
should
start
with
the
fact
that
there
is
a
clear
need
of
marshalling
attributes
into
strings
attribute
values
into
strings.
Let's
define
that
agree
on
that,
and
once
we
have
that
in
place,
we
can
say:
okay
now
we
can
drop
the
label
from
metrics
and
follow
the
same
pattern
of
transforming.
L
Great,
so
that
means
that
we're
going
to
talk
about
how
to
represent
values
that
are
converted
from
resource
attributes
or
baggage
activities
into
metric
exported
labels.
L
So
we're
going
to
talk
about
those
list
and
map
values.
I
just
want
to
add
that
I
don't
believe,
there's
a
thematic
problem
with
listing
that
value.
It's
a
performance
problem.
You
could
have
a
label
value
that
was
uniquely
list
valued
or
not
valued,
and
we
could
make
it
work.
It's
just.
Nobody
wants
that.
It's
too
fun.
F
D
F
L
Yeah,
it
means
that
we're
going
to
end
up
with
a
specification
that
says
your
attributes
may
be
coerced
into
a
string
value,
especially
when
we're
exporting
them
over
a
metrics
protocol
and
calling
it.
What
used
to
be
known
as
a
metric
label
is
now
called
an
attribute.
When
you
call
it
metric
attribute,
it
may
be
coerced
to
a
string
because
we
have
strong
beliefs
about
performance
and
because
we
don't
believe,
there's
a
meaningful
distinction
between
string
and
other
value
in
the
places
where
we're
using
them.
D
F
F
D
Yeah,
I'm
I'm
just
gonna,
combine
this
into
this
first
one
here,
okay,
great!
So
we
have
this.
Do
I
capture
this
correctly.
M
C
F
No,
I
said
I
was
thinking
to
use
the
value,
the
attributes
for
the
tree
state,
but
it
doesn't
make
any
sense
because
the
tree
state
is
a
pack
value.
So
we
we
don't.
We
cannot
convert
it
in
any
types.
D
C
Yeah,
it
has
special
manipulation
rules.
That's
true.
D
F
By
the
way
you
you,
you
drop
something
especially
important
for
baggage.
We
haven't
agreed
that
we
use
attributes
in
baggage,
so
anyway,
somewhere
has
to
be
that.
C
I
think
package
might
be
similar
to
trace
date
because
for
both
we
follow
some
w3c
spec.
I'm
not
sure
if
package
is
typed
in
everything,
3c.
D
O
We
made
a
lot
of
important
decisions
on
a
baggage
protocol
based
on
the
fact
that
in
opencemetery
we
mostly
need
string
string
and
we
like
over
long
discussions.
Nobody
came
up
with
a
proper
need
for
other
types.
D
I
I
think
it's
fine.
If
we
do
that,
I
think
we
just
these
are
the
things
we
have
to
decide
if
we're
going
to
unify
these.
If
we're
going
to
unify
these
attribute
types
and
honestly,
just
I
think
just
I've
encountered
in
some
languages
while
we're
dropping
stuff
so.
L
I
wonder
if
this
means,
I
wonder
if
this
means
that
we
should
have
some
sort
of
high
level
guidance
for
implementers
to
say
that
when
you
are
implementing
filtering
and
grouping
behaviors
over
things
that
might
be
called
attributes
that
you
should
like
capital.
Letters
should
coerce
values
into
string,
forms
to
implement
your
filters
so
that,
if
you
have
a
spam
with
an
integer,
valued
label
attribute
sorry-
and
you
have
another
span
with
a
float
value
label
attribute
they
they
come
up
in
the
same
search.
L
If
you
have,
you
know
that
that's
what's
really
important,
the
end
user,
if
you
do
a
group
by
that
same
label
key
and
you
have
an
integer
value
or
a
floating
point
value
and
they're
the
same
roughly
I
mean
like
they're,
all
both
1.0
or
one
they
should
group
together.
They
should
not
be
considered
separate
groups
just
because
one
of
them
was
integer
and
one
of
the
most
floating
points,
and
we
might
use
that
type
of
reasoning
to
help.
L
D
Yeah
how
to
coerce
so
we're
saying
we
need
guidance
for
how
to
coerce
types,
not
just
for
serialization,
but
also
when
you're
doing
more
complicated
metrics
operations
with
them
right.
Yep.
O
And
again,
if
we
really
need
types
and
baggage,
let's
come
up
with
scenarios
and
try
to
change
the
protocol.
There
is
still
time
on
w3c
we
just
putting
type
information
on
top
of
protocols
that
we
have
now
is
more
expensive
than
changing
the
protocol
together.
D
B
See
you
andrew
this
was
your
turn
well,
the
previous
one
anyway,.
G
Okay,
I
I
will
go
over
the
status.
Actually,
I
do
a
quick
status
and
then
I
we
have
some
new
issues
to
triage,
but
from
the
spec
burn
down,
showing
just
the
p1
issues
for
what
we're
targeting
for
ga
we've
got
12
in
the
to
do
six
with
prs
associated
with
them.
G
This
issue
actually
doesn't
have
a
pr,
but
it
is
progressing.
It's
a
p1
for
resolving
ports
and
48
resolved,
and
let
me
see
I'm
jumping
around
a
little
bit,
but
I'd
like
to
first
go
over
some
triaging
of
new
issues.
G
We've
got
only
a
handful.
That's
come
in.
I've
created
a
a
bunch,
that's
just
for
high
level
tracking.
So
I'm
going
to
skip
these
because
I'll
talk
about
what
they're
for,
but
the
stuff
that's
coming
over
the
past
week
starts
from
here.
C
To
signal
when,
when
a
context
becomes
the
parent
context
in
some
execution
context,
right,
don't
know
if
we
want
this,
but
if
we
want
it,
we
can
edit,
after
ga.
F
G
B
Christian,
I
don't
think
that
christians
change
his
own
editorial.
Christian
probably
can
explain
it
to
you.
Yeah.
C
I
think
yeah,
the
the
non-editorial
part
is
that
it
also
changes
the
guideline
from
trace
to
tracing
for
their
folder
names
yeah.
I
have
no
strong
opinion
on
that.
Probably
we
can
we
can
close
it
if
no
one
else
has
a
strong
opinion,
because
it's
yeah,
probably
links,
will
break
yeah.
E
Might
be
too
much,
I'm
fine
with
changing
the
wording,
the
content,
but
I
I
feel
strong
about
breaking
the
links
so
renaming
the
holders
kind
of
problematic.
In
my
opinion,
I
prefer
not
to
do
that.
B
C
C
B
So
I
think
it's
too
late,
sadly,
and
as
I
mentioned,
we
had
the
discussion
a
few
times
in
the
past.
There
was
no
agreement.
It
was
hard
to
find
a
solution
that
would
make
everybody
happy,
and
I.
C
C
C
I
would
say
p2,
even
because
if
someone
clicks
on
the
wrong
link
and
gets
to
and
work
in
progress,
newer
version
of
the
spec-
you-
wouldn't
you
probably
wouldn't
even
notice
right-
that's
a
good
one.
It
doesn't
look
at
you.
A
G
That
was
me
I
was
just
making
half
noise.
I
saw
carlos
you
already
allowed
for
ga.
Do
we
just
need
to
decide.
B
Yeah,
my
impression
is
that
this
is
an
editorial
change.
I
think
that
my
my
understanding
is
that
actually
what
he
posted
is
incorrect.
I
think
we
are
also
embarks,
are
not
having
you
know
higher
precedence
in
java,
so
they
work
like
javascript,
so
we
need
a
clarification
there.
B
Probably
we
will
also
need
to
mention
that,
and
I
don't
know
if
this
is
part
of
this
issue,
specifically
that
some
of
the
values
are
expected
to
be
implemented
by
instrumentation
for
ga
only
only
by
israel
up
to
instrumentation
so
yeah.
But
I
don't
know,
that's
that's
my
impression
if
somebody
has
a
different
opinion
or
additional
context,
please
please
go
ahead
and
mention
that.
B
B
In
that
case,
I
would
say
in
I
could
say
priority
two,
because
it's
creating
confusion
so
yeah,
let's
go
for.
K
G
Sounds
good
okay,
and
this
is
last
one
on
the
specs
we
got
like
one
and
oh
tap,
one
in
proto.
C
There
is
a
bit
contradictory
spec
here.
I
guess,
if
you
notice
back
enough,
you
can
work
out
what
this
really
meant.
B
B
H
Sandra
this
is
following
up
on
the
discussions
where
bogdan
had
also
requested
that
you
know
we
kind
of
at
least
start
thinking
about
some
consistent
guidelines
on
where
the
vendor
components
sit
and,
and
so
this
is
the
first
of
the
two
proposals
I
want
to
file
at
least
for
starting
a
discussion.
H
E
I
guess
this
is
more
about
clarifying
the
already
existing
policy,
because.
H
I
mean
in
this
case
specifically,
you
know
when
we
logged
and
reviewed
the
6v4
code
earlier.
There
was
a
discussion,
so
it's
just
following
up
with
a
clear
guidance.
There.
H
H
Yes,
absolutely
I
totally
agree,
and-
and
you
know
there
should
be
an
sunset
policy
or
an
labeling
policy
of
some
kind-
that
that
clearly
flags
those
components.
E
H
Yeah
I
mean
I
would
push
for
having
it
sooner.
Andrew
sounds.
G
Okay,
I
think
that's
as
far
as
we
get
on
that
that
labeling
and
that
repo
there
is
one
more
I
saw
in
the.
E
F
L
Zero
value
for
start
time
creates
trouble
because
some
somewhere
down
the
line
you're
going
to
ask.
When
is
this
time
series
reset
and
you
you
can't
tell
when
it
resets,
so
you
end
up
having
to
do
a
heuristic
like
media
server?
Would.
L
F
Yeah,
that's
that's
the
thing.
The
other
thing
is
jay's
comment
and
the
issue
was
you
know
when
we
receive
these
from
from
prometheus
that
they
don't
have
this
start
time.
What
do
we
do?
Do
we
start
using
a
reference
point,
for
example,
that
was
something
that
stackdriver
did.
They
were
keeping
the
the
previous
point,
the
the
first
point
they
see
and
every
time
they
calculate
the
delta.
F
Since
that
point,
or
things
like
that,
so
so
it
has
some
implications
when
we
convert
or
when
we
scrape
metrics
from
external
third
party,
apps
or
or
libraries
that
don't
have
this
concept.
I
think
that's
what
he
is
more
interesting
in.
L
I
see
so
you're
interested
in
there
being
a
like
a
should
statement,
but
perhaps
not
a
must
statement
about
zero
values.
Yes,
I
think,
that's.
I
understand
the
issue
about
state
in
the
prometheus
receiver
and
it
I
mean
another
solution.
It
would
be
to
recommend
the
use
of
a
label
for
start
time
that
could
be
that
could
solve
the
problem.
Perhaps
yeah
we
should.
L
We
should
talk
there
about
this
and
and
then
there's
a
whole
separate
topic
about
agent
configuration
where
you
know
that
there's
a
single
destination
point
like
you're,
like
you,
are
writing
to
one
specific
endpoint,
because
and
that's
the
case
where
this
works-
the
prometheus
like
technique
of
keeping
a
map
with
your
start
time
to
to
detect
resets
correctly,
but
if
you're
sending
to
a
horizontally
scaled
pool.
This
does
not
work,
and
so
I've
wondered
if
at
the
highest
level
in
hotel
whether
we
have
a
way
of
saying
I'm
about
to
configure
an
export
type
client.
L
L
P
G
Okay,
there's
just
one
last
thing
I
want
to
highlight
as
to
our
p1's
for
the
ones
that
are
not
related
to
metrics,
that
is
blocking
our
ability
to
conclude
the
trace.
Spec
freeze.
We've
got
two
open
pr's,
I
think,
there's
a
line
item
in
order
to
talk
about
one
of
them.
They've
had
progress,
but
it
I'm
not
sure
whether
they
need
more
reviews.
B
G
So
getting
to
the
freeze
or
getting
to
conclude
our
freeze
activities
is
what
we're
trying
to
target
as
the
next
immediate
one.
So
this
specifically
is
the
tracking
issue
for
it.
Tigran.
As
I
said,
I
I'd
be
willing
to
help
with
these
three
tracking
items.
G
If,
if
you
need
help
with,
then
I
can
help
coordinate
in
order
to
get
towards
a
way
of
tagging
the
repo
I'm
assuming
that's
the
end
point
in
order
to
be
able
to
say,
hey,
let's
now,
move
on
towards
metrics
but
related
to
that
is
also
the
spec
compliance
table.
I
saw
that
java
and
rust
got
updated.
Quite
recently,
so
java
has
like
been
cleared
with
the
latest
scrubbing
watson's.
Take
a
look
at
this.
I
saw
two
minus
signs.
One
of
them's
got
a
linked.
G
I
think
a
linked
pr
towards
it,
which
is
great
here.
It
is
right.
So
what
I'm
looking
for
is
for
is,
for
the
other
language
six
to
be
able
to
update
this,
so
we
can
get
a
status
as
to
where
we
are
in
terms
of
implementation
and
across
the
different
languages
that
we're
targeting
for
ga
from
the
maintainers
meeting
on
october
26th.
That's
just
over
a
week
ago,
there
were
estimates
on
the
two-week
three-week
four-week
implementation
for
java
javascript
python
go
erlang.net
and
collector.
G
In
order
to
be
able
to
implement
the
specification
trace,
table
baggage
table,
I
guess
context
propagation
table
and
was
wondering
whether
these
are
still
realistic
timelines
for
the
language.
Six.
G
Not
sure
whether
we
have
a
lot
of
representation
across
all
the
different
languages.
K
Sorry,
I
just
I
just
jumped
on,
can
you
what
was
the
timeline
that
you're,
referring
to
here?
Sorry.
G
I
was
just
citing
the
initial
estimates
from
the
maintainers
sig
meeting
back
on
october
26
in
terms
of
implementing
the
spec
compliance
table
towards
the
trace
table
backstable
context
propagation
table,
whether
the
timelines
are
are
reasonable,
whether
some
more
has
to
be
done
in
or
whether
we
need
to
adjust
the
timelines.
G
I'm
just
looking
forward
towards
like
the
road
map
planning
for
what
the
next
milestone
should
be,
and
blog
posts
and
whatnot
in
order
to
be
able
to
promote
such
activities.
K
I
gotcha,
I
think
I
might
have
been
out
on
the
26th.
Do
you
know
what
the
go
timeline
was
if
we
gave
one.
A
K
I
think
I
think
most
of
the
timelines
were
four
weeks.
If
I
remember
correctly,
I,
like,
I
think,
bogdan's
ready
for
some
sort
of
executive
leadership
is
what
I'm
getting
from
that
yeah
two
weeks.
Okay,.
K
I'll
definitely
take
a
look
at
this.
I
don't
think
that
we're
definitely
not
ready
for
yesterday,
but
I
think
that
I
think,
maybe
two
weeks
out.
If
that's,
if
that's
still
reasonable,
then
that
seems
a
track
in
track.
G
Andrew
it
was
an
estimate
from
one
week
ago,
so
I
mean
technically
it's
like
one
week
out
from
now,
but
I
know
people
can't
estimate
to
the
hour,
but
this
is
what
our
our
next
focus
is
for.
The
next
milestone
is
what
I
want
to
highlight
and
updating
the
spec
compliance
table
would
be
the
way
to
help
with
visibility
towards
tracking
that
and.
K
So
do
you
know
for
the
spec
compliance
table?
I've
got
that
as
an
action
item
to
really
try
to
get
done
this
week.
I
there
was
a
little
bit
of
confusion.
I
think,
but
I
think
that
it's
pretty
straightforward
I'll
try
to
do
that
for
the
ghost
side
of
things.
I
think
that
maybe
we
could
try
to
prioritize
doing
these
sort
of
things
in
the
maintainers
meeting,
maybe
the
first
half
hour,
something
like
that
go
over
some
timelines
from
each
one
of
the
sigs.
K
G
G
Okay,
so
I'll
move
on
from
there.
There
is
one
last
thing
as
fyi
before
we
get
into
media
stuff.
G
This
is
a
new
project
that
sergey
created
to
help
track
with
high
level
ga
items
and
I've
seated
it
with
11
items
in
the
to
do
which
I
literally
just
took
from
our
google
spreadsheet.
Now
I
put
this
big
red
notice
at
the
top
that
this
spreadsheet
is
now
obsolete,
we're
going
to
track
everything
in
the
project,
but
I
didn't
change
anything.
I
didn't
try
to
move
the
goal
post
or
anything.
I
just
literally
copied
what
I
could
from
here
and
assigned
the
owner.
G
So
that's
the
context
of
these
issues,
that's
being
filed
in
the
spec
repo,
and
as
a
result
of
that,
let
me
see
how
I
should
do
ga
tracking
I
created
a
special
tag
to
only
track
the
high
level
items,
every
ga
tracking
that
will
not
have
prioritization
but
we'll
either
have
a
required
for
j
or
allowed
for
ga
based
on
the
items
that
were
in
the
google
spreadsheet
that
were
decided
upon
us,
oh
yeah,
we
really
need
this
for
j
or
not.
G
No,
it
would
be
nice
time
for
j,
so
these
are
not
changes
necessarily
to
the
spec,
but
things
that
we
really
want,
for
example,
performance
testing,
integration
testing
and
such
and
such.
P
H
Yeah
I
mean
andrew,
would
there
be
like
stories
or
tasks
related
to
this
epic?
In
one
sense,.
G
So
I
wanted
to
keep
this
lightweight
is
just
to
have
at
least
a
link
across
repositories.
Yes,
because
we
got
a
lot
of
different
links
repository,
so
all
I
did
was
create
like
a
checkbox
of
all
the
languages.
I
think
this
needs
to
be
updated.
I'm
not
sure
whether
we're
necessarily
going
for
every
single
one
of
these
different
languages,
but
I
just
literally
took
it
from
the
spreadsheet
which
had
a
matrix
of
languages
up.
Q
Here
and
andrew
their
expectation
that
individual
sdk
owner
should
create
a
an
issue
and
update
the
the
spec
issue
here
to
put
the
link,
or
they
will
ping
you
back
and
put
it.
So
what's
the
expectation
here.
G
I
think
the
status
right
now
is
this
is
my
first
seed
of
the
issues,
I'd
like
to
firm
it
up
and
talk
about
what
I
would
like
to
ask
every
single
language
to
do
at
the
next
maintainers
meeting,
whether
we
keep
all
the
languages
or
not
or
whether
I
need
to
adjust
some
of
the
issues
or
delete
some
of
them
and
merge
them.
I
think
some
like
one
or
two
might
be
duplicate,
so
no
action
right
now:
okay,
everyone,
the
language
six.
G
All
I
did
was
copy
it
over
from
the
excel
spreadsheet,
but
I'll
bring
this
up
as
a
gender
item
for
the
maintainage
meeting.
Thanks.
Q
G
To
be
honest,
I
literally
just
copied
it
from
this
line
item
which
was
entered
in
months
and
months
ago.
So
not
sure
whether
lts
is
the
best
description
for
it,
I'll
change
the
title
as
as
required,
and
then
I
think
the
most
important
thing
is
that
a
proper
definition
of
none
in
the
issue.
Q
Okay,
so
I
I,
I
guess
the
lti
thing
might
be
valuable.
For
example,
if
you
look
at
the
node.js
like,
even
if
they
have
the
latest
one
marked
as
ltis,
they
will
give
you
a
clear
expectation,
for
example,
they're
saying
after
five
years
by
end
of
like
2025
we're
going
to
duplicate
this
version.
So
for
us
like,
do
you
see
a
need
to
clarify?
When
are
we
going
to
stop
supporting
1.0
or
it's
just
something
we
can
leave
up
to
the
air.
G
I
think
that
needs
to
be
clarified
across
the
board
for
all
the
different
languages.
I
don't
have
an
immediate
answer
right
now
as
to
what
the
number
of
years
are,
but
I
think
some
warning
has
to
be
done.
That
is
specific
towards
what
stability
a
user
could
could
expect.
K
I
think
you
raise
a
really
good
issue
riley.
I
think
that
lts
originally
had
some
meaning
behind
it
on
the
kickoff
of
open
telemetry
and
I'm
looking
at
people
who
were
here
for
the
obsession
of
open
telemetry,
who
would
know
better
than
I
would,
but
it
had
something
to
do
with
like.
I
think
it
was
along
the
lines
of
like
two
years
back,
which
compatible
support
through
open
census
and
open
or
open
tracing,
and
then,
after
that,
that
kind
of
support
would
drop
off
within
the
1.0
release.
K
I
think
was
fully
supported
for
something
like
a
year
or
two
after
that,
but
I
I
don't.
I
think
that
was
initial
thoughts.
I
think
that
what
you're
saying
is
a
really
good
point
and
that
maybe
the
technical
committee
or
the
governance
committee,
I
don't
know
where
this
would
fall,
should
should
be
very
clear
as
to
like
what
our
goals
are
for.
K
Lts
are
because
I
think
that
saying
that
to
the
community
is
a
much
more
effective
way
to
drive
adoption,
rather
than
leaving
it
open,
which
is
what
ken
said
with
the
alternative.
Yeah.
K
Q
G
I
have
to
really
finish
my
time
to
the
like.
There
are
some
really
meaty
items
here,
all
right:
it's
okay,
I'm
happy
to
keep
sharing
carlos.
If
that's
helpful,
yeah,
please,
is
there
a
specific
order?
You'd
want
to
start
on
or.
B
Yeah,
I
actually,
I
will
follow
up
offline,
but
I
will
be
contacting.
Oh
sorry,
I
yeah
we
already
discussed
the
germany's
issue:
okay,
yeah.
Basically,
I
just
was
wondering,
and
literally
you
have
an
update.
We
can
talk
offline,
of
course,
about
this,
about
the
additional
propagators
living
in
country
or
what
so
there's
a
pr
holding
that,
as
as
I
mentioned,
I
will
be
stealing
tickets
pr
and
open
telemetry
something
probability.
B
I
have
a
question
regarding
utmp.
I
will
follow
one
with
tigran.
Basically
long
story
short,
I
wonder
if
we
it's,
if
it's
valid
for
otlp
to
send
in
some
or
double
sum
with
empty
points.
Probably
it's
too
otlp
specific.
So
I
will
just
following
your
balance
at
the
ground,
so
yeah
yeah.
B
I
One
was
already
addressed
by
andrew
regarding
the
vendor
code,
location
proposal.
So
that's
fine,
the
second
one
regarding
the
summary
metric
proto
pr.
It
only
needs
one
more
approval
from
somebody
in
that
group
that
I
put
specs
metrics
approvers.
So
if
anybody
in
this
meeting
is
from
that
group,
if
you
guys
could
take
a
look
at
that,
that
would
be
greatly
appreciated
and
then
the
last
one
I
guess,
is
kind
of
about
a
scope
of
this
meeting.
But
we
have
some
pr's
and
the
collector
repo.
G
Sorry,
carlos
there
was
one
more
I
had
as
a
carryover
from
matt
weirhead.
N
Yeah,
I
think
we
probably
make
this
quick,
I'm
curious
if
any
language
segs
are
adding
kind
of
framework,
specific
attributes
that
aren't
part
of
the
semantic
conventions
and
I'm
generally
under
the
the
same
mindset
as
armin
and
his
comment
there,
where,
if
they
are
applicable
to
multiple
languages,
you
should
probably
add
them
to
semantic
conventions,
but
we
occasionally
run
across
things
that
really
don't
make
sense.
A
specific
example
was,
with
rails,
instrumentation,
adding
the
controller
and
action
name.
I
think
those
are
kind
of
like
pretty
like
rail,
specific
terminology
and
concepts.
N
I
was
just
wondering
like
what
what
the
general
opinion
is
as
for
for
adding
those
attributes
on
a
span.
Do
it
don't
do
it.
N
A
I
mean
in
in
theory
even
for
race,
which
only
applies
to
ruby.
There
could
be
two
or
even
more
instrumentations
doing
the
same
thing
and
leaving
users
a
choice
to
pick
from,
and
even
those
should
be
aligned
with
each
other,
so
that
backhands
can
make
sense
of
the
data
that
they
get,
and
so
it
would
be
beneficial
if
they
very
light,
and
that
makes
most
sense
to
just
have
it
in
respect.
Nevertheless,
even
if
it's
just
for
race,
it's
what
I
think
if
everyone
agrees.
N
Okay,
ultimately,
this
ended
up
becoming
a
non-issue
because
we're
going
to
use
these
for
the
span
name
but
yeah,
I
think,
for
for
future
purposes.
I
think
my
instinct
will
be
open
a
pr
for
semantic
conventions
and
if
it
gets
turned
down,
then
maybe
just
make
a
decision
with
the
sig
from
there.