►
From YouTube: 2022-03-04 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
C
5
30
yeah
almost
starting
to
get
dark
now.
Oh
5
30.,
yeah,
yeah.
D
Is
this
the
first
metrics
burn
down
meeting
this.
A
But
I'm
going
to
open
up
the
stuff
that
he
presents
at
spec
meeting
every
week.
A
He
did,
I
didn't
explicitly
add
him
to
the
invite,
though,
which
I
realized
was
probably
a
mistake.
I
just
sent
it
to
the
main
mailing
list.
Let
me
just
add
him
now
and
maybe
he'll
get
the
invite.
A
If
I
have
his
email
handy
and
I
don't
anyone
have
his
have
riley's
email
address,.
A
Yeah,
I
actually
don't
have
his
email
address.
That's
funny
he's
joining.
Okay.
Are
you
looking
for
her
riley's
email,
but
we
found
him
on
slack.
A
Hey
sorry
about
that
riley
I
added
the
open,
selementary
mailing
list,
but
I
realized
just
now.
I
didn't
explicitly
add
your
email
address
and
then
I
realized
they
don't
actually
know
your
email
address.
I
see,
I
said,
no
worries.
I
can
add
you
right
now,
though,
what
what
is
your
email
address.
A
Okay,
awesome.
Okay!
So
yes
welcome
to
our
first
metrics
burn
down
meeting,
so
we
used
to
run
some
equivalent
for
tracing
back
in
the
day
when
we
were
pushing
tracing
to
ga.
A
I
think
it
makes
sense
for
us
to
use
this
as
a
form
to
push
the
metrics
work
very
hard
and
triage
things
very
aggressively
and
keep
track
of
what
needs
to
be
done
to
be
clear.
Riley
has
already
been
doing
a
lot
of
this
every
week
on
his
own
and
has
been
giving
updates
at
the
specification
meeting.
A
But
those
are
time
boxed.
We
generally
don't
want
to
go
too
much
into
the
weeds
on
certain
issues
during
the
specs
call,
and
it's
not
necessarily
the
right
form
to
like
triage
things,
especially
if
they're
related
to
say
sdks
or
non-spec
issues.
So
I
created
this
riley.
You
have
the
most
context
on
everything,
and
so
I
was
wondering
first
off
is
there,
like?
I,
I've
pulled
up
everything
with
the
spec
metrics
tag.
Do
we
already
have
some
kind
of
list
tracking
like
the
necessary
items
like?
B
F
F
A
F
So
my
current
proposal
is:
let's
shift
the
sdk
spec
as
a
mixed
state
with
all
the
other
sections
as
stable,
but
exemplar
still
as
a
feature
freeze,
so
we
might
be
able
to
see
something
related
to
exemplar
here,
which
is
a
priority
for
stable,
but
not
the
top
part.
For
now,
I
would
suggest
for
now,
let's
focus
on
everything
in
the
current
feature.
F
A
F
G
Yeah,
I
I
agree
with
morgan,
because
I
think
that
riley
exemplars
can
be
added
later
after
1.0
it.
You
know
again
there's
enough
flexibility,
at
least
in
my
discussions
with
josh
surat.
Also
earlier
there
is
enough.
You
know,
flexibility
in
our
specification
to
be
able
to
add
that
you
know
later
after
1.0.
F
I
I
guess
it's
doable.
Actually
in
donna,
we
don't
add
example,
but
we
I
believe
we
do
have
some
places
where
we
leave
the
space.
So
later
we
add
example,
it
will
be
additive
change,
but
what
I
want
to
say
is
at
this
stage,
I
I
don't
think
we
we
have
good
understanding.
If
we
can,
we
can
ship
the
isdk
is
stable
by
removing
exemplar
100
percent.
A
F
And
this
is
exactly
why,
if
you
go
go
back
to
the
board,
you
can
see
the
the
second
item
here.
What
I'm
basically
saying
is,
except,
for
example,
everything
should
be
ready
to
move
to
stable,
and
I
want
to
use
this
to
measure
like
basically
asking
everyone.
If
you
see
anything,
that
is
a
blogger,
we
should
call,
and
I
I'm
happy
to
facilitate
the
work.
What
I
I'm
currently
saying
is
it
seems
there
are
still
a
lot
of
folks
thinking,
hey.
It
would
be
nice
to
catch
the
trend
and
put
additional
features.
F
G
A
So,
let's,
let's
are
there
any
disagreements
that
we
should?
We
should
declare
it
that
that,
like
we
should
and
then
let
me
just
clarify
what
I'm
thinking
and
riley
limit.
Let's
let
me
just
clarify
that
maps
with
what
you're
thinking
so
by
saying
that
we're
going
to
move
it
to
mix
we're
basically
saying
this
core
set
of
the
specification.
The
sdk
specification
that
does
not
include
exemplars
probably
doesn't
include
a
bunch
of
the
things
here.
Either
we're
going
to
mark
as
stable
as
1.0
and
sdk
developers.
Please
go
or
sdk
maintainers.
A
H
I
have
a
quick
question
yeah
if
this
is
not
marked
as
stable
and
we've
implemented
it
in
a
language
sdk.
Does
that
mean
that
the
spec
is
going
to
change
and
like
that
our
implementation
could
break,
or
does
that
just
mean
that
it's
not
required
for
the
stable
release
of
an
sdk.
A
G
H
It's
just
really
hard
to
express
in
a
lot
of
languages
in
terms
of
like
versioning
right.
A
H
F
I
guess
right
yeah,
so
so,
if
you're
going
to
do
a
stable
release
of
the
isdk,
I
would
suggest
that
you
only
release
the
parts
that
are
stable
in
the
spec.
Anything
in
the
spec
that
is
not
stable,
for
example,
in
markets
feature
freeze.
It's
just
indication
that
we're
we're
controlling
the
bar,
we're
not
going
to
add
a
new
feature
yeah,
but
we
might
decide
okay,
this
is
feature
freeze,
but
we
decided.
This
is
a
bad
idea,
we're
going
to
change
the
design
or
we
might
even
say
we
don't
need
this
feature.
F
H
Right
so
I
think
and
and
other
languages
can
correct
me,
but
I
think
java
and
javascript
already
have
exemplars
and
we
are
planning
to
do
it
in
python.
I'm
not
sure
about
go
or
dot
net.
F
In
dot,
I
have
a
prototype,
but
I'm
not
ready
to
merge
it,
because
I
I
see,
I
see
performance
issues
just
by
having
the
very
basic
example
I
have
to
sacrifice
50
of
the
performance.
So
this
is
why,
if
you
go
to
go
to
the
the
board,
the
first
question
we
have
is:
should
that
be
enabled
by
default.
I
I
think
eventually
we
might
change
the
position,
but
at
least
for
now
it's
going
to
be
a
very
challenging
thing
and
I'd
rather
not
to
think
about
this
problem
before
we
can
shape
the
very
first
version.
F
G
Riley
that
that's
in
line
with
you
know
our
thinking
that
if
we
say
exemplars
is
not,
you
know
a
part
of
1.0,
even
if
there
is
support
for
it
in
specific
languages,
we
can
still
say
that
you
know
we
are
still
optimizing
for
performance
and
we'll
declare
it.
You
know
stable
later
right.
G
A
F
Yeah
so
my
suggestion
for
java
or
javascript
you,
you
have
multiple
choices.
You
can
shape
the
sdk
by
putting
the
example
in
some
special
place,
and
you
called
these
are
not
stable,
maybe
like
in
some
languages
that
are
released
in
the
source
form.
You
can
have
some
conditional
compilation
flag
if
it's
a
same
assembly
or
like
java
is
a
class
file.
Maybe
what
you
can
do
is
put
something
a
very
special
namespace
and
clarify
the
policy
in
the.
I
think
I've
seen
python
doing
this
python
has
a
future
namespace
right.
H
It's
just
the
way
that
so
I
think
I
don't
remember
if
we
marked
exemplars
as
off
by
default,
but
since
they're
since
they're
on
by
default.
That
would
be
tough
and
then
the
way
you
configure
them.
Is
you
put
exemplar
sampler
or
something
like
that
right,
yeah
you're,
suggesting
hide
that
behind
like
a
private
namespace
or
something.
F
Yeah,
okay
yeah-
or
there
also
I
heard
from
john
watson
before
that
in
java
he
did
something
so
certain
feature
can
be
released
as
a
separate
class.
H
Yeah,
okay
I'll
see
what
we
can
do
for
python.
G
F
Cool
given
like
we're
we're
spending
a
lot
of
time
here,
maybe
we
should
come
back
to
the
triage,
so
I
can
quickly
explain
how
we
were
charging
the
tracing
issues
so.
F
If
we
go
to
the
issues
list,
this
is
the
board.
This
is
the
the
the
understanding
after
the
triage.
So
after
judge
we
basically
decided
these
are
the
only
things
we're
going
to
focus
on
right
now,
anything
else.
It's
a
low
priority.
It's
not
going
to
stop
us
doing
this,
and
if
we
see
anything
that
should
stop
this
effort,
we
need
to
call
it
explicitly
and
the
triage
meeting
is
for
that.
F
So
if
we
go
to
the
spike
repo
and
look
at
the
issue
list,
maybe
more
than
you
can
open
a
separate
tab,
yep
yeah
go
to
the
spec
repo
and
look
at
the
issues.
So
so
one
thing
is:
we
only
look
at
the
issues
that
are
tagged
as
spike
metrics
and
for
specs
matrix.
There
are
issues
around
the
data
model.
I
I
think,
given
this
model
is
already
stable,
there
will
be
additive
changes,
but
that's
not
the
purpose
of
this
meeting.
F
So
we
only
look
at
the
the
spec
issues
that
are
either
related
to
the
sdk
or
related
to
the
exporter,
and
so
the
api
is
already
stable.
We're
not
looking
at
any
api
related
problem,
we're
not
going
to
look
at
any
premises
related
thing
because
with
premises
is
is
feature
freeze
we
like
we.
We
don't
want
to
focus
on
that
right
now.
So
after
we
reveal
each
matrix
item,
we
need
to
tag
it
either
saying
this
is
api
sdk
both
or
this
is
exporter,
or
this
is
data
model
and
for
data
model
for
premises.
G
G
I
would
like
to
better
understand
that,
because
that
you
know
when
you
say
that
prometheus
is
that
future
phrase.
That
only
applies
to
the
pull
exporters
right,
because
we
have,
as
a
project,
decided
to
have
the
only
pr
you
know
remote
right
exporter
in
the
collector
and
the
sdks.
Have
the
pull
exporter
right.
F
Yeah,
so
we're
not
doing
push
exporter
for
permissions
at
all
right,
maybe
in
the
later
we
we
can
change
the
mind,
but
currently
it
is
we're
not
even
talking
about
it
right.
The
reason
permissive
exporter
is
tricky
because
in
the
data
model
we
have
three
layers.
We
allow
different,
like
streams
under
different
meter,
to
have
the
same
name
in
premises.
We
don't
have
this
concept
of
a
name
space
or
like
meter,
so
we
have
to
do
some
mapping
and-
and
for
this
one,
my
understanding
is.
D
I
found
this
issue
about
allowing
different
readers
to
have
different
view,
configuration
which
I
think
solves
that
problem
that
you
just
talked
about.
That's
that's
the
reason
that's
been
filed,
at
least
I
I
think
we
could
resolve
that.
One.
F
I
I
don't
think
so,
but
anyways
my
my
take
is
promising
six
fault.
Her
will
take
more
time
and.
D
I
don't,
I
don't
believe
that
that's
true
I
mean
so
so.
The
the
reason
why
I
support
views
which
I
did
not
always
support
is
that
they
give
us
a
mechanism.
That's
been
fully
tested
and
specified
to
overcome
ambiguity
of
the
sort
that
you
just
described:
okay,
so
a
legacy
exporter
that
doesn't
support
metering,
meter,
name,
okay,
you
better
put
some
views
together
to
make
sure
you
don't
have
conflicts,
that's
your
solution
and
we
have
to
support
prometheus.
D
D
G
A
F
Should
be
they're
they're
nice
to
details
that
we
have
to
spend
time
to
hammer
out,
for
example,
we
encounter
some
special
character
in
the
instrument-
name,
yeah
and-
and
we
have
to
explore
that-
but
premises
don't
allow
some
special
character
like
adults.
We
need
to
do
something.
How
are
we
going
to
escape
that
someone.
D
F
D
G
F
F
The
result
should
be
the
same
as
if
you
use
the
sdk,
plus
the
premises
full
exporter
and
given
the
collector
part,
is
already
fairly
stable.
I
think
someone
has
to
just
look
at
how
it
is
done
and
document
that
in
the
premises,
exporters
back,
but
my
question
is:
do
we
think
we
want
to?
We
want
to
bundle
the
promises,
power
and
isdk
in
the
same
release,
or
we
can
separate
my
take
is
if
we
cannot
release
a
single
piece.
I
I'd
rather
not
work
on
two
things.
D
I
I
think
you're
setting
the
bar
too
high.
It's
not
a
breaking
change.
If
we
have
some
detail
of
the
of
the
sdk,
I
mean
the
spec.
The
spec
that
you
just
stated
is
the
two
paths
should
produce
the
same
data
and
yeah.
We
can
release
that
state.
Call
it
stable
it's
a
bug
until
it
gets
there
like.
I
don't.
Oh.
F
Yeah
yeah
make
it
break
is
fine
with
me
too.
My
my
this
is
more
from
empathy,
so
I
feel
like
if
we
release
the
spike
like
this.
A
lot
of
folks
would
just
reach
out
to
like
ping
us
and
ask
hey
I'm
doing
this,
and
how
should
I
do
that?
It's
basically
like
the
spike
is
saying:
do
the
right
thing
and
you
figure
out
how
to
do
the
right
thing,
but
I
I'm
not
seeing
a
problem.
A
A
F
So
so
originally
I
was
thinking
permissive.
Six
power
has
a
lot
of
details
that
someone
has
to
spend
energy
to
document
and
given
we
all
have
limited
energy.
I
want
us
to
focus
on
getting
the
isdk
and
after
that
we
know
the
languages
are
unblocked.
They
can
implement
the
ick.
Then
I
I
can't
spend
my
energy
to
document
permissions.
Actually,
that's
why
I
spend
time
to
implement
the
premises
with
polar
indonesia
like
all
by
myself,
but
I'm
hearing
from
josh
and
alolitas.
F
We
can
shape
the
permissive
exposure
as
stable
by
putting
some
principle
here,
saying:
hey
if
you
use
permissive
power
or
use
otlpx,
powertrain,
central
collector
and
then
to
permissive.
The
results
must
be
the
same
regarding
how
you're
going
to
do
that.
We
haven't
got
energy
to
to
document
that
out,
but
consider
this
as
a
bug
it
will
fix.
That's.
G
I
mean
we
had
done
tests
and
we
can
you
know
I
can
share
the
details
on
that,
but
that's
something
that
isn't
known.
You
know
as
long
as
we
communicated
that.
Clearly
that
should
be
fine
yeah.
F
D
I
I
feel,
like
people
get
a
little
hung
up
on
this
instrumentation
library
thing
which
or
the
resource
they're
both
the
big
questions
right,
but
we
have
actually
written
specs
on
each
one
of
those
you
I
think
we
dropped
the
instrumentation
library.
These
are
data
model
questions.
You
drop
the
instrumentation
library
and,
at
this
point
within
my
most
recent
change,
that
talked
about
duplicate
instruments
and
duplicate
streams
like
we,
we
know
what
happens
when
you
drop
the
instrumentation
library
and
write
the
same
metric
name.
D
You
have
duplicate
conflicts
and
we've
actually
specified
how
to
treat
that
and
how
to
think
about
that
now.
So,
if
you,
if
the
worst
case
was
that
you
end
up
with
prometheus,
is
doing
the
obvious
thing,
which
is
what
we
should
be
doing
and
you're
getting
these
conflicts
they're
passing
through
to
prometheus
just
like
we
would
pass
the
conflict
through
to
otlp,
like
we
just
specified,
so
I
feel
like
we
can.
Just
you
don't
have
to
get
a
great
solution
here.
You
just
have
to
get
compatibility,
that's
what
yeah.
G
A
Oh
okay,
sorry
I
understood
that
backwards.
Okay,
all
right,
so
we're
all
aligned
on
this.
If
I
go
back
to
our
open
issues,
right,
we
have
the
one.
That's
actually
flag
is
required
for
ga.
Are
we
saying
that
like
so
so
someone
needs
to
do
like
someone
needs
to
put
that
statement
out
there.
That
just
says
hey
we're
gonna
get
to
prometheus.
We're
gonna
specify
some
more
things
later,
but
data
coming
in
must
look
the
same
as
data
coming
out.
Do
we
need
a
task
or
issue
to
track
something?
Yes,.
F
D
D
Well,
I
mean
to
say
that
riley
is
probably
right.
We
can
mark
the
sdk
stable
with
the
otlp
exporter.
Stable
first
got
it
yes
and
say:
the
prometheus
export
feature
is
stable,
not
be
is
maybe
I
want
to
say
something
like
the
apis.
The
interfaces
to
it
are
stable,
but
the
data
path
is
not,
and
so
that
like
we,
so
that
a
bug
fix
where
you
change
an
underscore
to
a
dot
or
a
dot
to
an
underscore
or
a
question
mark
or
any
other
weird
character,
translation
to
solve
some
sort
of
prometheus
and
compatibility.
D
That's
a
data,
that's
a
data
bug
fix
and
it's
neither
a
breaking
change
or
any
api
or
interface
involved
in
setting
up
an
sdk
or
using
the
api.
It's
just
spec
for
how
the
exporter
should
behave,
that
we're
changing
and
that's
still
not
stable
as
well.
G
G
A
D
D
The
sdk
is
an
api
that
someone
in
a
main
function
somewhere
is
going
to
use
that's
well,
some
people
want
that
to
be
stable,
so
they
can
start
building
code
and
and
if
we
change
a
like
a
bug
in
the
exporter,
they're
they're
not
going
to
mind
and
there's
a
different
group
who
says
I
need
to
start
doing
industrial
monitoring,
and
I
can't
let
you
change
that
after
I
start
exporting
that
data,
because
I'm
going
to
set
up
alerts
or
whatever
and
that's
a
different
sort
of
stability,
and
so
maybe
we
should
be
clear
about
which
stability
we're
after
I
think
that
we
are
features,
feature
stable
and
therefore
we
could
be
interface
stable,
but
we're
we're
like
still
getting
to
the
details
of
of
what
the
data
correctness
stable
is
and
we're
still
getting.
D
A
F
G
G
So
again,
I
let's,
let's
be
very
clear
on
what
we
communicate
for
prometheus.
E
I
just
just
I
know
we're
over
time,
but
I
just
wanted
to
jump
in
really
quickly
so
from
the
red
hat
perspective,
we're
looking
to
ship
metric
support
as
soon
as
we
can
and
we've
got
another
release
coming
up,
and
basically
people
have
been
asking
me:
what
is
the
status
of
metrics
and
whether
we
can
you
know
hold
off
for
a
couple
of
weeks
and
get
something
out
in
as
part
of
this
cycle
or
whether
we
should
mark
it
as
tech
preview
for
now
and
go
to
the
next
cycle?
E
What
I'm
hearing
today
is
that,
essentially,
we
should
be
marking
as
tech
preview
josh's
comments
about
about
prometheus,
because
so
many
of
our
customers
use
prometheus
as
something
they're
going
to
export
from
that
those.
Those
conversions
and
data
path.
Issues
probably
indicate
that
this
should
be
marked
as
take
preview.
For
now
is
that
is
that
a
reasonable
summary
of
of
the
current
situation.
G
Yeah
yeah
ben
I
mean,
but
but
again
the
discussion
here
is
focused
on
you
know:
what's
part
of
1.0,
right
and
and
or
stable
if
you
will
and.
A
G
E
A
Fine,
thank
you
yeah.
Okay,
we
will
follow
up
next
week.
We
have
our
action
items
just
very
quick
question
before
we
drop
josh.
The
issues
you
flagged
here
are
these
mostly
those
those
sort
of
spec
cleanup
issues
that
you
mentioned.
D
Yeah
there's
one
that
was
discussed
on
tuesday
morning
and
riley.
I'm
not
sure
if
you
wanted
to
to
take
that,
but
I've
I'm
also
starting
to
think
that
there's
just
kind
of
still
some
confusion
about
who
owns
a
reader
or
what
is
a
reader
yeah
yeah.
What
is.
F
F
A
B
Just
posted
that
yeah
yeah
sorry,
so
we
talked
a
little
bit
in
the
spec
meeting
about
the
issue
that
jack
raised
on
that
yeah.
I
saw
that
yeah
we
hadn't
resolved
whether
that
was
going
to
be
a
blocker
or
not.
We
feel
it
should
be
blocker
myself,
jack
and
but
we
want
to
know
other
people's
opinions.
Basically.
D
And
yeah
I
can,
I
was
going
to
say
I
mean
if
everyone
has
time
for
another
10
minutes,
we
can
keep
talking.
I've
made
a
proposal
here
that
maybe
we
can
just
get
done
quickly.
I
can
also
cut
it
back,
so
I
don't
need
this
stateless
term.
Stateless
is
something
I
could
add
later
it's
what
lightstep
wants,
but
the
structure
of
the
current
pr
is
now
in
a
place
where
it
accommodates
that
future
expansion
allen
seems
to
have
sort
of
approved
it
or
at
least
agreed
to
it.
D
According
to
some
conversation,
we've
had,
but
it
does
add
something
completely
new,
so
we
got
to
review
it
again.
We
got
to
discuss
it
next
week
on
the
specs
there's
something
here
called
a
strategy
that
lets
us
solve
this
problem.
It's
a
real
problem,
though
I
haven't
been
advocating
for
this
to
to
be
considered
a
blocker,
because
the
current
language
is
so
vague
and
it's
okay
to
have
us
like
a
we
have
nothing
normative
is
said
about
what
the
preference
is
actually.
F
Yeah
happier
my
my
take
is
this
is
a
new
feature
given
like
we're
already
feature
freeze,
I
I
I
would
suggest
that
we
don't
add
additional
things.
I
understand
how
important
this
is,
and
I
I
do
see
the
benefit.
D
H
G
D
G
D
D
We're
well
it
really
matters,
because
in
our
for
example,
in
our
system,
once
you
choose
the
type
of
a
stream
like
it's
going
to
be
a
breaker,
if
you
try
to
change
the
type.
So
all
this
configuration
is
the
initial
type
of
the
stream
that
you're
going
to
see
and
whether
it's
a
delta
or
a
cumulative.
D
We
all
understand
what
that
means.
But
we
know
the
up
down.
Counter
is
the
special
case
here
and
we
and
we
we
all
agreed
now
at
the
end
of
this-
that
there
had
been
some
misunderstanding
earlier-
that
delta
preference
doesn't
necessarily
mean
delta
for
everything.
It
means
delta,
where
it
makes
sense,
and
it
doesn't
quite
make
sense
for
an
up
down
counter.
Therefore,
we
don't
want
a
delta
preference
to
mean
change
up
down
counters
to
deltas,
because
that
kind
of
destroys
the
data.
D
Unless
you
really
know
why
and
what
you're
doing
with
that
particular
transformation,
and
so
since
it
was
just
a
preference
and
the
way
it
was
stated
was
you
can
just
use
this
preference.
However,
you
want
I'm
saying
the
correct
interpretation
of
the
preference.
Was
we
ignore
the
preference
for
up
down
counter
and
this
pr
now
kind
of
formalizes
that
and
we're
adding
a
new
mode
or
a
configuration
parameter
on
all
the
things
that
have
a
temporality?
D
E
B
I
agree
and
that
this
could
be
an
additive
feature
as
the
pr
currently
stands.
I
would
approve
it,
as
is,
if
it
were
to
go,
go
in
prior
to
stabilization.
If
it
made
it
after
stabilization,
then
I
think
it
needs
to
be.
B
B
D
A
F
F
D
Look
but
you're
creating
this
notion
of
a
preference
which
is
a
single,
essentially
flag
right
now
and
and
what
alan
is
saying
is
that
you,
if
you,
if
we
create
a
preference
named
delta
right
now,
we
can't
change
what
it
means
and
it
doesn't.
We
don't
even
say
what
it
means
right
now.
That's
that's
the
problem
we're
having
so
where.
D
D
I
don't
want
the
preference
and
the
way
I
propose
to
fix
it
is
to
have
an
option
on
the
aggregation
to
say,
ignore
the
preference
and
the
other
option
is
is
to
say,
ignore
the
preference
and
choose
cumulative
and
the
option
that
allen
pointed
out.
That's
like
hypothetical
that
no
one
is
asking
for
is
ignore
the
preference
and
choose
delta
and
and
that
those
are
those
are
strategies
we
could
add
and-
and
this
there's
a
there's,
a
preference
that
we
could
that
I
proposed,
because
I
think
it's
natural
and
easy
called
stateless.
D
F
D
D
F
D
No
you're,
not
understanding.
It's
like
the
this
that
we're
trying
to
use
the
existing
view
mechanism
to
do
more
here.
There's
only
two
choices
of
temporality.
D
So
currently
we
have
a
preference
which
says
what
the
exporter
feels
and
we
already
have
a
view
mechanism
that
says
what
the
aggregation
should
be.
So
the
the
the
fix
that
I
don't
need
to
add
this
new
notion
of
stateless
preference,
although
I
want
it,
I
just
need
to
add
a
way
to
disregard
the
preference
for
up
down
counters.
That's
what
we're
talking
about
right
now.
F
D
The
compromise
that
I'm
willing
to
take
is
that
I'll
remove
the
word
stateless
from
my
pr
it'll
just
add
the
strategy,
but
we
need
to
make
a
name
for
this
concept
and
people
need
to
agree
to
it
and
that
I
don't
think
we
can
do
that
in
under
a
week.
So
the
the
the
mechanism
by
which
you
ignore
a
preference
is
part
of
the
views
now
and
maybe
that's
additive
as
well,
but
only
if
you
don't
actually
give
meaning
to
the
preference.
D
D
D
Yeah,
okay,
so
I'll
pair,
that
back
in
the
next
half
hour
and
because
it
because
it
was
a
it's
a
pretty
small
change
and
it
was
suggested
by
alan
and
jack.
I
hope
jack
comes
back
and
likes
it.
I
mean
I
put
the
name
together,
but
please
review
it
I'll
I'll
ping
it
in
half
an
hour
thanks
for
staying
late.
Everybody.
D
Riley
I'll
dm
you,
I
have
questions
and
thoughts
about
the
rewordings.
I
would
like
to
help
as
well.