►
From YouTube: 2022-03-08 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
B
A
I
think
we
can
start.
I
have
a.
I
have
the
first
two
items
in
the
agenda,
so
the
the
first
one
is
about
defining
the
what
it
means
for
instrumentation
and
for
semantic
conventions
to
be
stable.
The
versioning
and
stability
document
that
we
have
in
the
spec
currently
does
not
define
these
two
things.
A
They
are
tbd
in
the
spec.
So
this
pr
that
I
linked
here
tries
to
do
that.
I
had
to
define
what
it
means
for
for
an
instrumentation
to
be
stable
from
the
perspective
of
the
telemetry
it
produces,
and
also
how
do
we
think
about
the
stability
of
the
semantic
conventions,
how
the
semantic
conventions
change
over
time.
A
So
this
this
uses,
the
the
concept
of
the
telemetry
schema
schemas
that
were
introduced
and
and
defines
two
categories
of
instrumentations,
one
unstable,
the
other
stable
again
from
from
the
perspective
of
the
telemetry,
the
aim
right
and
then
for
the
for
the
stable
ones.
It
further
defines
sub
two
subcategories
there.
One
is
where
the
telemetry
shape
is
fixed
and
the
other
where
it
is
governed,
essentially
by
telemetry
schemas
and
which
then
allows
this
this
shape
to
change
over
time.
A
According
to
the
schema
files,
so
the
pr
is
there,
it
has
more
details
about
how
all
these
things
work.
Please
please
review
and
comment
on
it.
I
think
it's
important
that
we
have
these
definitions
in
respect.
They
they
are
currently
again.
As
I
said,
they
are
tbd
right,
but
we
need
this
to
be
properly
and
precisely
defined
in
the
specifications
so
that
the
implementations
know
what
to
do,
how
to
behave.
D
So
I
have
a
question
that
I
raised
on
the
pr
about
unstable,
instrumentation
not
being
able
to
emit
a
schema
version.
I
think
that
restriction
might
be
a
little
onerous.
A
A
A
If
that's
the
case,
then
I
I
can
change
the
pr
to
account
for
that.
The
only
complication
that
arises
from
that
is
that
I
used
the
the
fact
of
the
the
presence
of
the
schema
url
in
the
in
the
emitted
telemetry
as
the
indicator
that
that
the
schema
sorry,
the
fact
of
the
absence
of
the
schema
url
as
an
indicator
that
the
emitted
telemetry
is
unstable
right.
Somehow
you
want
to
know
what
to
expect
right.
A
A
Now.
If
we
do
what
you
suggest,
then
we
need
a
different
indicator
essentially
for
that
right,
the
unstable
instrumentations,
if
they
want
to
record
the
schema
url
in
the
emitted
telemetry,
if
we
want
to
allow
the
unstable
instrumentations
to
do
that,
I
think
we
can
do
that,
but
we
need
a
different
flag
essentially
to
say
that
this
telemetry
was
emitted
by
an
unstable
instrumentation,
don't
count
on
it.
A
It
may
change
in
a
way
that
that
is
unpredictable
right,
as
opposed
to
the
instrumentations
which
properly
declare
that
they
are
stable
and
they
will
only
change
in
a
way
that
is
prescribed
by
telemetry
schemas
and
that
they
will
evolve
according
to
schemas,
with
with
particular
versions
of
the
schema,
etc,
etc.
Right,
I
don't
know
if
this
is
that
particular
subset
of
the
unstable
instrumentations
is
really
necessary.
D
D
A
Okay,
yeah,
let
me
think
about
it,
maybe
maybe
I
just
leave
it
as
a
to-do
there
or
because
it's
an
experimental
document,
if
I
remember
correctly,
so
we're
still
allowed
to
make
changes
to
that
yeah
anyway,
I'll
I'll
think
about
it.
I'll
try
to
do
some
adjustments
to
the
pr
or
maybe
we
just
just
do
it
in
a
follow-up
pr.
C
You
tigrin,
can
you
explain
what
the
the
use
case
or
the
problem
that
the
unstable
indicator
is,
is
solving.
A
Yeah,
it
was
essentially
a
comment
from
from
the
reviewers.
They
wanted
an
ability
for
the
back-end
to
know
whether
the
particular
telemetry
comes
from
a
source
which
is
unstable.
Essentially,
it
provides
no
guarantees
about
the
shape
of
the
telemetry.
It
is
emitting
that
whether
it
will
continue
emitting
the
telemetry
with
the
same
shape
or
it
will
not,
and
I'm
guessing
you
could
use
that
in
the
back
end
as
a
way
to
maybe
just
show
it
as
in
in
the
ui
right.
This
is
coming
from
somewhere.
If
you're
going
to
save.
A
A
E
On
a
related
note,
tigran
sean
marciniak
and
maybe
some
other
people
over
at
atlassian
are
interested
in
helping
to
implement
a
schema
translation
in
the
collector.
I'm
not
sure
if
there's
any
prior
work
or
ongoing
work
on
on
actually
like
implementing
these
schema
translations.
E
A
That's
great,
there
is
prior
work.
I
have
a
a
draft
implementation
of
it,
which
is
in
my
personal
repository,
not
in
the
collector,
which
I
used
when
I
was
developing
the
schemas,
the
the
concept,
just
as
a
as
a
proof
of
concept
which
can
be
used.
It
contains
the
logical
translations.
It
needs
to
be
reworked
to
to
to
work
in
the
collector
code
base,
but
that's
great
I
will.
I
will
ask
I:
will
I
will
contact
sean
to
see
whether
he
can
help
with
that.
E
Yeah
yeah
we're
we're
interested
in
the
instrumentation
groups
of
of
helping
to
shepherd
that
work
to
completion
as
part
of
declaring
things
stable,
because
it
seems
a
little
dangerous
to
collect
things
stable
without
the
ability
to
to
do
these
things.
A
A
Okay,
let's
move
forward
to
the
next
one,
so
this
one
is
about
the
recent
work
we
did
on
clarifying
or
or
expanding
the
notion
of
instrumentation
library
to
become
the
scope
where
instrumentation
library
is
one
of
the
possible
types
of
the
scope,
and
the
specification
was
changed
to
reflect
this
understanding.
A
So
we
renamed
a
number
of
things
to
say:
scope
name
instead
of
instrumentation
library
name
in
the
specification,
and
this
pr
is,
is
a
follow-up
for
that
to
rename
the
things
the
instrumentation
library
to
become
a
scope,
essentially
in
the
protocol
as
well.
A
In
tlp,
this
renaming
does
not
so
we
could
do
a
let's
say,
a
straightforward
renaming
of
the
messages
in
the
in
the
product
in
otlp
directly,
but-
and
I
did
that
initially
in
the
pr-
but
I
heard
feedback
from
from
a
number
of
people
that
they
would
prefer
to
handle
this
in
a
more
graceful
way
where
we
don't
break
in
particular,
two
things:
one
is
the
json
output,
where
these
names
actually
are
part
of
the
are
part
of
the
wire
and
the
other.
Is
we
don't
break
the
names
of
the
generated
code?
A
So
this
pr
takes
into
account
this
feedback
and
tries
to
to
make
this
transition
gracefully,
where
old,
senders,
let's
say,
can
continue
emitting
the
data,
particularly
json
data,
and
also
pro
buff
data,
the
old
way
and
the
new
new
recipients,
which
now
know
that
the
concepts
have
changed
its
name
now.
A
Scope
name
instead
of
instead
of
library
name,
can
handle
the
the
old
format
and
the
new
format
as
well
essentially
tries
to
make
sure
that
the
interoperability
of
old
and
new
senders
and
receivers
of
otlp
is
is
ensured
both
for
protobuf
and
for
json,
and
also
the
transition
of
the
code
bases
which
which
import
the
generated
code.
The
generated
otlp
protobufs,
is
also
made
easier.
It
preserves
the
old
and
new
names
of
the
fields
and
messages
and
and
explains
and
provides
the
recommendations
about
how
you
do
the
transition.
A
I
think
it
hopefully
solves
the
the
the
problems
with
the
traceable
transition
problem
and
I'm
looking
for
feedback
and
approvals
here.
Essentially,
please
take
a
look.
C
B
Can
you
see
my
screen,
okay,
cool,
so
the
the
first
thing
for
people
who
haven't
realized
this,
so
we
started
to
have
the
friday
triage
meeting
on
the
pacific
time
early
morning,
so
you
can
check
the
calendar
and
if
there's
a
certain
thing
you
believe
is
blocking
issue.
B
I
stress
that
you
join
that
meeting
and
we
did
the
the
first
metrics
crash
meeting
last
week
we're
using
this
board
to
track
what
are
the
required
for
ga
items?
What
are
the
allowed
4g
items
similar
like
what
we
did
for
the
tracing
part
and
for
the
required
4k?
So
we
we
need
to
address
all
these
problems
before
we
can
mark
the
related
part
of
the
sdk
spec
as
stable
for
allowed
4ga.
B
B
So
if
you
see
any
data,
because
it's
against
your
understanding
or
you
think
this
is
very
important
to
like
your
scenario,
I
highly
suggest
that
you
call
that
out
we're
trying
to
control
the
scope
in
order
to
get
the
very
first
stable
release
and
now
coming
to
the
issue.
B
Actually
you
mentioned,
there
are
several
non-blockers
that
you've
been
working
on.
If
you
want
to
quickly
give
people
a
brief.
F
Yeah,
so
we
have
been
there's
this
pr
and
there's
an
issue
filed.
The
issue
is
now
23
2403..
The
first
attempt
at
that
pr
was
shown
on
your
board.
It
was
number
2314..
This
is
where
the
problem
that
we
have
discovered
is
that
vendors
who
are
interested
in
delta
temporality,
there's
a
little
bit
of
text
in
the
spec.
F
That
says
how
to
configure
a
preferred
temporality,
there's
a
lot
of
language
saying
that
exporters
or
readers
or
the
sdk
authors
have
freedom
to
do
what
they
want
with
temporality,
and
this
comes
from
a
place
of
good
intention.
But
when
it
comes
to
the
otlp
exporter,
which
many
of
the
vendors
just
want
to
use
out
of
the
box,
there's
no
control
there
at
all,
and
I
don't
think
that
we
need
to
block
the
stable
release
on
having
that
particular
control
specked
out.
F
But
what
I'm
concerned
about
is
that
the
current
language
in
the
spec
leads
you
to
believe
something
may
be
supported
that
doesn't
do
what
anybody
wants.
So
we
discovered
this
over
the
last
few
weeks.
The
idea
that
having
a
preference
called
delta
would
unconditionally
tell
you
to
put
all
of
your
instruments
that
can
into
delta
temporality
is
an
isn't
a
notion
that
we
don't
want
and
actually
will
cause
harm
for
many
vendors.
F
F
I
don't
really
consider
either
of
these
to
be
a
blocker,
but
if
we
release
a
stable
release
without
merging
one
or
both
of
these,
the
otlp
exporter
is
not
clearly
well
defined
in
my
opinion,
and
it
will
be
okay
for
me
if,
if
we
would
just
cut
pull
back
the
specification
and
remove
things
that
are
ambiguous
or
potentially
leading
to
features
that
nobody
wants
and
to
me
that's
the
second
pr
is
the
smallest
scope
I
could
find,
which
is
to
remove
the
concept
of
preferred
temporality.
F
We
can
put
it
back
in,
but
we
have
to
put
it
back
in
in
a
way
that
actually
serves
the
vendors
who
want
it,
and
it's
currently
formed
it's
not
doing
that.
So
I
would,
I
would
recommend
or
urge
us
to
merge
the
second
of
my
prs
before
we
call
it
stable,
which
just
removes
stuff,
because
the
first
in
my
prs
is
the
ideal
or
a
solution
that
I
think
we
can
agree
to,
but
we
can.
F
We
can
have
that
out
over
the
few
weeks
ahead
of
us
and
that
can
be
a
required
for
gi
item.
The
point
being,
I
think
we
should
remove
preferred
temporality,
since
it's
not
doing
anything
that
people
want,
and
it
would
be
okay
with
me
if
we
released
the
first
stable
version
that
said,
otlp
will
only
do
cumulative
and
there's
no
way
to
control
it.
That's
okay
with
me,
but
if
you
say,
there's
a
way
to
control
it
to
delta
and
it
causes
all
my
up
down
counters
to
become
deltas.
F
So
please.
I
think
that
we
are
struggling
right
now,
because
not
enough
people
are
giving
us
attention
on
these
pr's
week
to
week.
Over
week
I
mean
I've
probably
got
three
people
who
have
had
this
conversation
with
me
in
the
last
week.
So
what
are
we
waiting
for?
I'm
not
sure
that
enough
people
are
giving
us
our
the
attention
that
we
need.
B
So
the
the
actual
remove
is
that
mixed
with
any
additive
hinge
or
it's
the
pure
remove.
F
B
This
is
removing,
if
I
remember
this
comes
with
two
parts.
The
first
one
is,
it
removes
the
preferred
temporarily
wording,
the
second
one
is
it
added
the
per
instrument
aggregation.
F
F
F
F
F
F
Was
correct,
the
title
was
was
missing
that
clarity,
but
the
word
preferred
leads
me
to
think
that
this
is
not
a
specific
instrument.
I
mean
you
would
be
saying,
define
the
temporality
for
a
specific
instrument,
say
the
preferred
temporality
for
an
instrument
kind,
but
I
I
can
change
the
pr
title
and
the
change
log
text
and
actually,
when
you
go
back
to
the
text
of
that
pr
right
now,
this
is
important
and
I
think
we
could
be
done
with
our
metric
spec
stabilization
if
we
could
all
just
like
move
faster.
F
F
Okay,
so
I've
removed
so
now
at
the
bottom
of
the
screen.
You
see
that
this
otlp
exporter
had
an
environment
variable
in
a
section
that
was
ambiguously
stable
or
not
because
it
refers
to
parts
that
are
unstable,
saying
the
preferred
output
temporality.
I'm
removing
that,
because
I
don't
think
that
we
agree
on
how
to
make
it
useful
and
then,
if
you
scroll
up,
I
want
to
point
out
the
other
change.
That's
happening
here,
so
that
big
paragraph
that
I
moved
open,
telemetry
offers
may
choose
the
best
mac
design.
F
I've
moved
that
into
the
exporter
section
it
was.
It
was
in
the
reader
section
and,
and
the
point
is
that
we've
not
given
enough
specification
to
say
how
a
reader
or
an
sdk
should
do
that,
but
the
exporters
are
the
ones
who
actually
know.
So.
I
think
I'm
just
correcting
what
looks
like
ambiguity
with
this
pr.
F
You
that's
my
other
pr,
and
that
is
that
that's
much
more
of
an
additive
change.
I
agree
to
that,
but
I
don't
want
us
to
delay
stable
on
that.
So
if
we
take
this
approach,
we
will
be
releasing
a
stable
version
where
you
can
only
produce
cumulative
temporality
from
otp
exporters,
which
doesn't
actually
help
the
vendors
who
have
delta
only
systems
and
then
we're
going
to
say
it's
for
it's
allowed
for
ga
to
add
that
feature
right.
So,
okay,
so.
I
H
H
Okay,
so
so
just
just
just
wanted
to
confirm
that
this
would
mean
that
we
do
not
have
any
way
of
producing
deltas
in
the
initial
version.
G
Yeah,
thank
you
for
that
clarification.
I
I
think
that
that
would
definitely
harm
new
relic.
I
mean
in
the
sense
that
we
do
need
things
shifted
to
delta.
I
understand
like
if
people
were
able
to
use
the
collector,
maybe
they'd
be
able
to
do
something,
but
we
definitely
have
customers
today,
who
are
using
the
otlp
exporter
as
is
and
successfully
getting
us
metrics.
G
The
notion
of
preferred
temporality,
and
what
do
you
get
for
your
up
down
counters
I
correct
and
that
that
that's
a
that's
a
been
a
problem
more
recently,
as
the
some
of
the
runtime
metric
work
has
changed
from
using
gauges.
Specifically,
the
java
community
has
done
a
lot
of
great
work
recently
for
the
their
runtime
metrics,
so
they
were
using
gauges
previously,
and
then
they
changed
up
down
counters
and
that's
a
a
late
realization
that
we
had
on
our
part
for
up
down
counters.
F
I
think,
and
and
yet
I
I
feel,
that
the
vendors
who
are
interested
in
delta,
temporality,
of
which
there
are
three
they're
all
in
this
room
right
now.
We
all
want
to
fix
here
and
I
and
I'm
and
I'm
frustrated
that
we
can't
agree
to
fix
it.
But
I
also
am
willing
to
let
us
call
it
stable
without
fixing
it.
G
J
G
To
rally
behind
it,
though,
with
the
notion
of
preferred
temporality,
even
in
its
imperfect
state,
it
at
least
the
way
that
it
worked
for
new
relic.
Putting
my
umbrella
cat
on
here
was
that
folks
would
set
delta
temporality,
but
then
they
would
have
to
use
views
to
change
up
down
counters
to
a
gauge.
B
Let
me
ask
this
question
alan.
So
what
if
we
don't
take
this
pr,
we
just
leave
the
spike,
as
is
we're
saying
you
can
use
preferred
temporarily
and
and
in
the
up
down
counter
case,
will
give
you
something
which
is
not
ideal
today,
but
we'll
fix
that
soon
after
the
initial
release,
I
I
think
that
might
work
better
for
you
other
than
this
pr
is
trying
to
remove
everything
you
have
today.
B
Yeah,
so
so
it
seems
we
have
two
options.
One
is
with
this
pr.
We
remove
the
flexibility
at
all
and
work.
Maintenance
will
quickly
add
that
later
there
seems
to
be
a
no
to
many
vendors
like
you,
you
understand
that
there
is
a
high
order
bit
of
releasing
the
initial
version,
so
we
can
iterate,
but
meanwhile
it
seems
you
got
nothing
in
it
and
on
the
other
side
we
might
say
you,
you
have
everything
you
have
today.
B
F
I've
given
two
pr's
that
fix
this
problem
and
I
just
don't
feel
like
we
have
any
attention
or
willingness
to
to
choose
an
outcome
so
one
the
first
pr
was
to
enhance
the
notion
of
preferred
temporality
to
include
something
called
stateless
so
that
you
could
actually
control
what
you
want
and
then
the
the
second
approach
is
to
just
put
it
into
the
views
and
remove
preferred
temporality.
B
Either
or
here
will
work
I
I
would
recommend
I
would
go
with
the
first
approach.
We
try
to
improve
the
preferred
temporality,
knowing
that
this
is
allowed
for
ga,
but
not
necessarily
a
blocker.
F
So
there
was
already
a
words
in
the
spec
saying
that
that
the
sc
k
authors
have
a
way
to
provide
default
aggregations,
that's
actually
not
specified
how
or
where
that
happens
right
now,
and
so
there's
this
notion
that
sdk
authors
are
putting
together
the
whole
package,
but
really
we're
trying
to
specify
individual
pieces
of
it
how
they
perform.
So
it's
the
otlp
exporter
that
needs
to
have
this
preference,
and
I
I
feel,
like
my
request
for
a
stateless
preferred
temporality,
was
was
way
over.
The
top
people
were
thinking.
This
is
crazy.
Josh.
F
You
like
there
are
two
kinds
of
temporality
here
and
we
we
know
that
delta
temporality
is
not
going
to
universally
be
correct,
and-
and
we
also
know
that
not
everybody
wants
universally
cumulative,
so
I
think
there's
a
choice,
but
if
you
say
that
there's
a
preferred
temporality
like
single
value
of
preferred
temporality
you're,
ignoring
the
fact
that
the
sdk
already
has
to
specify
a
preferred
aggregation
for
every
type
of
instrument
and
we
haven't
specified
where
the
preferred
aggregation
comes
from
either.
F
That's
why
I
like
my
my
proposal
in
2404:
is
it
actually
pins
down
both
the
preferred
aggregation
and
the
preferred
temporality
come
from
the
exporter?
When
you
bind
together
the
view
and
the
reader
and
the
exporter,
you
will
get
both
the
choice
of
aggregation
and
the
choice
of
temporality
that
you
care
about.
I
don't
think
that
we
need
a
preferred
aggregation
temporality.
Therefore,
we
should
just
have
defaults
be
provided
by
the
exporter.
That
is
where
the
preferred
aggregation.
Temporality
comes
from
not
from
an
environment
variable,
of
course,
then
someone's
going
to
say.
F
B
Okay,
so
if,
if
I
can
summarize,
I
I
I'm
hearing
most
of
the
vendors,
they
would
be
okay
with
the
current
spec
like
without
this
pr,
although
they
like,
we
all
believe
by
having
some
clarification
and
additive
change
in
the
preferred.
Temporality
would
help
to
make
the
otlp
exporter
better
when
it
comes
to.
How
do
we
handle
outbound
counter
in
the
delta
behavior?
F
B
F
B
B
No,
it
means
delta
right.
What
we're
going
to
add
is.
Maybe
we
have
another
state
saying
if
you
have,
if
you
have
cumulative
to
delta
conversion,
maybe
we
have
another
flag
saying
this
is
what
we
recommend
you
to
do.
G
Riley
and
that
like
yes,
technically
it
wouldn't
be
a
breaking
change,
we
could
make
an
additive
change,
whether
that
be
you
know,
a
different
preferred
temporality
setting
of
some
sort,
but
I'm
also
hearing
the
the
thing
that
I'm
hearing
from
you
josh
is
like
yeah
sure
people
if
we
default
to
a
preference
of
cumulative,
given
that
the
delta
preference
setting
so
again,
the
the
the
new
relic
statement
that
that
we're
giving
to
folks
now
is
hey
set
delta,
because
that
sets
most
of
your
stuff.
G
The
way
that
you
want
it,
except
for
this
one
thing:
hey,
you
got
to
go.
Do
this
other
thing,
but
once
we
once
we
do
come
back
and
we
make
this-
we
improve
this.
We
make
these
additive
changes,
then
our
statement
would
probably
not
involve
setting
or
recommending
setting
preferred
temporality
at
all.
I
would
guess
because
it
would
be
either
all
done
based
off
of
views,
or
you
know
you
toss
out
the
idea
of
various
different
environment
variables
per
instrument,
something
like
that.
It
would
be
like
a
different,
a
totally
different
solution.
G
G
G
B
I'll
I'll
go
back
to
the
other
topics,
so
so
please
reveal
the
pr
and
and
see
if
it's
good
to
you,
I
I
feel
we
we
need
the
vendors
to
be
more
involved
like
if
you
see
this
is
going
to
be
a
blocking
issue
for
your
rally
called
dynatrace.
B
B
F
And
so
the
summary
that
I
just
heard
was:
if
we
keep
what
we
have
then
new
relic
can
have
the
correct
temporality
on
three
out
of
five
instruments
or
four
out
of
five
instruments
and
that's
great.
But
if
we
keep
the
current
temporal
the
current
nothing
which
is
everything's
cumulative,
you
also
get
the
correct
temporality
on
four
out
of
five
instruments,
so
either
way,
you're
getting
mostly
correct,
and
I
think
we
should
remove
something
that
gets
us
mostly
correct,
but
not
all
the
way
correct.
F
Once
all
cumulative
they're
going
to
get
the
right
values
without
anything
being
done
and-
and
we
should
say
I
mean
correctness-
is-
is
hopefully
not
affected.
You
know
the
the
data
is
correct
in
any
temporality
form,
but
the
receiver
needs
to
know
what
they're
going
to
get.
F
And
right
now
we
just
have
no
way
to
say
I
want
delta
for
the
things
that
are
monotonic
and
not
otherwise,
and
that's
that's
that's
another
way
we
could
fix.
It
is
to
say
that
the
preferred
temporality
only
applies
to
the
histograms
and
the
monotonic
instruments,
because
that's
the
one
there
it
makes
sense,
but
I
think
in
the
long
run,
we're
gonna
we're
gonna
want
to
configure
this
through
views
and
different
exporters
are
going
to
have
different
preferences,
and
so
I
don't
know
I
I
just
feel
like
we're
getting
ahead
of
ourselves.
G
F
Well,
this
this
topic
came
up
originally
for
me,
because
I
I
don't
support
the
idea
that,
as
an
sdk
should
support
cumulative
to
delta
conversion,
it
doesn't
seem
like
a
very
smart
move,
but
then
some
vendors
pointed
out
that
that
your
your
asynchronous
counters
are,
you
know
like
there's
just
they
want
to
have
those
in
delta,
because
that's
the
way
their
system
works,
and
I
accepted
that
now.
I
really
need
a
way
to
control
so
that
you
can
perform
both
cumulative
delta
and
delta
to
cumulative
inside
the
sdk.
F
It's
at
that
point
where
the
the
notion
of
preferred
temporality
broke
down
to
me
because
before
if
we
were
going
to
say
that
you'll
never
do
cumulative
to
delta
conversion,
then
preferred
temporality
was
fine.
You'd
say
preferred
temporary
delta
and
you'd
get
delta
for
the
things
that
were
already
delta
and
you
wouldn't
do
any
cumulative
delta
conversion,
because
that
doesn't
always
make
sense
to
me.
But
I
I
see
how
other
vendors
make
it
work,
and
so
now
I'm
I'm
supportive
of
the
idea
that
you
can
do
a
cumulative
delta
conversion.
F
F
Seems
like
I'm
in
the
minority
position
here
if
we
were
to
just
merge
the
stable
pr
that
riley
wants,
and
we
had
this
notion
of
preferred
temporally
doing
what
alan
admits
is
not
quite
correct
for
a
new
relic.
F
I
just
don't
feel
like
I'm
going
to
want
to
recommend
that
to
my
users
until
we
get
the
fix
in
so
allow
for
ga
is
fine,
because
I
expect
to
continue
pressuring
us
to
do
this,
and
but
but
I'm
I'm
wary
of
efforts
to
end
this
debate,
to
say
that
what
we
have
is
fine
and
we
should
stop
and
just
continue,
because
I
don't
think
it's
fine.
H
I'll
have
to
look
into
the
issues
again.
I
like
yeah
got
going
to
yeah.
I
don't
know
so
it's
not
we
would.
We
would
definitely
prefer
a
way
of
of
exporting
deltas
right.
That's
that's
what
I
can
say
and
yeah.
I
don't.
H
H
It
just
seems
like
whichever
direction
we
take.
This
nobody's
that
somebody's
gonna
be
unhappy
right.
So.
C
All
right
thanks,
so
my
understanding
is
that
that
the
stakeholders
will
read
the
proposals
once
again
and
then
comment
on
the
issues
right.
C
C
If
that's
not
the
case,
then
I
just
want
to
point
out:
there
will
be
the
cube
con
in
valencia
in
spain
in
may.
So
if
any
of
the
hotel
contributors
are
are
interested,
take
a
look
at
the
agenda,
I
think
it
will
be
posted
tomorrow
and
a
few
maintainers
will
be
there
I'll
be
briefly
addressed
in
the
maintainers
call
yesterday.
C
There
will
also
be
an
hotel
maintainers
track
with
at
least
four
maintainers
on
stage
discussing
all
things
open,
telemetry
and
as
for
the
for
the
accepted
toxin,
I'm
not
sure
yet,
but
this
this
will
be
cleared
up
tomorrow.
E
I
have
a.
I
have
one
last
minute
issue,
I'd
like
to
throw
on
the
agenda.
I'm
sorry
I
had
to
put
the
finishing
touches
on
the
pr.
I
added
it
to
the
the
bottom
of
the
agenda,
but
I'll
put
it
in
the
chat
as
well.
E
So
this
is
a
pr
to
further
describe
the
specification
process
and
how
to
make
changes.
This
came
out
of
a
discussion
with
bogdan
about
the
spec
groups
that
we
have
spun
up.
E
So
we
have
a
couple
instrumentation
groups
as
well
as
like
a
rum,
client,
instrumentation
group
who
were
spun
out
to
do
work
on
the
spec,
but
were
composed,
like
entirely
of
of
basically
like
what
you
might
call
non-core
contributors
like
people
who
aren't
on
the
tc
number
and
stuff,
and
just
to
help
those
groups
when
they
get
stuck
through
the
pull
request
process
or
to
help
ensure
that
they
don't
do
a
significant
amount
of
work
before
they
like
propose
a
specification
change.
E
It
would
be
good
to
have
sponsors
assigned
to
these
groups,
as
well
as
for
any
otep
before
a
complex
or
significant
otep
gets
started
to
clarify
that
a
person
should
create
an
issue
and,
if
approved,
get
a
sponsor
assigned
assigned
to
them.
So
the
idea
here
is
basically
you
know.
We.
E
We
have
kind
of
a
process
written
down
for
how
changes
get
made
to
the
spec,
but
in
honesty
like
it
is
kind
of
a
complex
process
and
when
an
issue
something
gets
stuck
or
it's
a
little
confusing
as
to
how
to
move
forwards
outside
contributors
or
people
who
don't
have
you
know
personal
relationships
with
tc
members
and
stuff
like
that,
can
just
get
kind
of
confused
about
what
the
the
next
steps
are.
E
So
this
pr
tries
to
to
clarify
one
that
people
should
get
get
a
sponsor
before
they
start
significant
work.
So
you
have
someone
to
talk
to
who
can
help
shepherd
you
through
the
process
and
then
also
if
an
issue
becomes
stuck
that
you
should
talk
to
your
sponsor,
as
well
as
the
person
who's
assigned
to
that
particular
pull
request.
E
It
also
clarifies
that
if
a
pr
is
stuck
not
because
the
not
because
we
haven't
sorry
if
a
pr
is
stuck
because
a
code
owner
has
requested
changes
but
hasn't
responded
to
any
further
discussion,
so
it's
like
actually
stuck
as
opposed
to.
We
haven't
decided
what
we're
gonna
do.
What
is
the
the
escalation
process
like?
Who?
Should
you
ping
to
kind
of
help,
get
it
unstuck
so
happy
to
discuss
this
concept
briefly
here
to
people
what
are
curious?
What
people
think
about
this
idea
of
sponsors.
E
In
particular,
as
part
of
this,
it
would
be
great
to
to
get
sponsors
for
all
of
our
existing
spec
sigs,
just
in
general,
if
someone
from
the
tc
could
start
attending
those
those
spec
meetings,
in
particular
the
the
two
instrumentation
meetings,
the
one
this
afternoon
at
4
p.m:
pacific
the
one
thursday
morning
at
8
a.m,
pacific
and
then
8
a.m,
pacific
thursday
and
then
the
rum,
client
rum,
sig.
That's
8
a.m,
pacific
on
wednesday.
E
Those
three
meetings,
I
think,
would
benefit
from
having
a
tc
member
present
just
to
help
them
resolve
some
of
the
issues.
They're
working
working
through,
for
example,
try
to
define
how
links
should
work
and
some
other
stuff.
E
So
yeah
anyways,
that's
that's
pr.
Please
have
a
look
at
it
and
comment
on
it.
C
All
right
extent,
I
already
added
the
proposal
to
tomorrow's
tc
meeting
agenda
and
will
certainly
discuss
it
there
as
well
great,
I
think
yesterday,
in
addition
to
the
ones
you
just
mentioned,
you
also
brought
up
the
the
ebpf
working
group.
I
assume
they
also
reached
out
to
you
for
for
getting
a
sponsor
or
some
guidance
right.
E
Actually,
I
haven't
they've
they've
reduced
down
to
having
one
meeting
a
month,
so
I
haven't
talked
to
that
group
recently,
but
just
as
part
of
like
all
false
kind
of
like
spec
work
or
large
changes
going
forwards.
Like
that's
a
group,
you
know,
that's
that's
ostensibly
doing
that,
so
they
probably
would
benefit
from
having
a
sponsor
kind
of
for
the
same
reasons.
C
I
Just
for
maybe
some
context,
the
way
the
kubernetes
community
does
this
is
that
enhancements
are
sponsored
by
the
sig
itself,
so
a
particular
sig
would
come
forward
and
say
we
sponsor
this.
I
guess
that
may
help
with.
If
someone
decides
to
step
down
from
the
tc
or
you
know,
there's
it
doesn't
get
lost
because
someone
else
from
the
sig
can
pick
it
up
and
shepherd
it,
and
it
also
maybe
helps
a
sig
like
budget
time
in
terms
of
how
many
things
are.
Are
their
leaders
taking
on.
E
Yeah
yeah,
the
sig
in
question,
in
this
case,
I
would
say,
is
like
the
spec
sig,
which
is
basically
the
the
project
being
maintained
by
the
the
tc.
You
know
so
yeah
this
doesn't.
This
work
doesn't
necessarily
pertain
to
like
how
the
the
java
sig
works.
E
Just
the
the
spec
sig
in
particular,
has
a
you
know,
complex
enough
process.
That
contributors
who
are
trying
to
put
in
meaningful
work
can
get
a
little
a
little
lost
along
the
way.
That's
just
some
consistent
feedback.
E
We've
had
is
like
when
things
when
things
do
get
stuck
or
a
proposal
gets
gets
a
lot
of
work
put
in
and
then
kind
of
gets
has
to
get
kind
of
like
reproposed
and
re-put
together
after
it
hits
the
pr
stage
just
trying
to
to
smooth
that
process
out
for
for
all
the
work
that
isn't
someone
just
coming
in
out
of
the
blue
with
you
know
a
fully
fledged
otep,
which
you
know,
we
can't
really
do
anything
out.
A
C
Than
just
addressing
the
the
like
virtual
body
of
the
the
tc
and
asking
them
for
help,
yes,.
E
E
Yes,
yes,
exactly
it's
it's
partially,
just
like
a
human
social
thing
right
like
if
you
don't
know,
if
you
don't
have
a
personal
relationship,
you
know
with
someone
who's
core
in
the
project.
People
can
be
like
shy
about
just
like
pinging
people,
on
slack
or
otherwise.
E
Knowing
who
to
talk
to
and
because
yeah
the
tc
is
like
a
group,
and
they
may
not
even
be
that
familiar
with
like
that,
there
is
a
tc
or
or
who's
on
it.
E
You
know
this
is
just
kind
of
to
prevent
for
prevent
contributors
from
having
to
do
a
bunch
of
investigation
on
their
own
and
having
to
like
figure
out
how
our
whole
project
works
just
in
order
to
navigate
it
if
they
just
have
like
a
point
of
contact
who
they
know,
you
know
they
can
reach
out
to
about
this
issue,
and
you
know
that
person
will
be
familiar
with
it
and
happy
to
talk
to
them
about
it
and
happy
to
you
know,
review
things
along
the
way
I
think
that'll
smooth
things
out
and
like
likewise
for
ziggs,
when
we
have
these
like
ongoing
spec
working
group,
it's
just
helpful
to
make
sure
the
tcs
kind
of
like
integrated
into
those
groups,
and
if
we
don't
have
enough
bandwidth
to
do
that,
then
that's
maybe
a
way
for
us.
E
That's
like
a
flag
for
us
that
we
maybe
don't
want
to
be
taking
on
some
particular
piece
of
work
right
like
if
we're
going
to
spit
up,
want
to
spin
up
a
spec
sig
but
like
there
doesn't
seem
to
be
bandwidth
from
the
tc
to
to
pay
attention
to
it
or
someone's
proposing
like
a
big,
complicated
otep,
but
there
doesn't
seem
to
be
like
bandwidth
to
help
shepherd
it
through
this.
E
E
So
I
think
this
would
also
be
helpful
for
resolving
those
situations
telling
people
like
we
can't
get
to
this
at
this
time.
You
know
come
back
in
six
months.
We
we
might
be
more
available,
then.