►
From YouTube: 2021-07-27 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
B
B
B
Yeah,
it's
two
minutes
past
11,
so
I
think
we
can
start
now.
So
if
you
have
anything
to
be
discussed,
please
you
can
add
it
to
the
agenda.
I
have
like
very
few
updates,
so,
like
we
mentioned
last
week,
we
are
cutting
support
for
net
four
six
and
older
in
the
1.2.
That
is
without
a
major
version
pump.
I
think
we
got
like
thumbs
up
or
comment
from
all
the
maintainers
at
least
three
of
them,
so
it
should
be
good
enough.
B
I
don't
see
like
any
major
reason,
so
that's
one
update
and
I
think
the
second
update
was
we
had
an
upper
bound
on
the
microsoft
extensions
package.
We
only
allowed
like
up
to
six,
not
including
six
so
people
who
were
using
the
six
preview
were
not
able
to
use
the
open
elementary
sdk.
B
The
main
reason
why
we
had
that
upper
bound
was
there
was
no
like
information
from
the
dot
net
team
that
these
packages
would
maintain
backward
compatibility
just
like
the
assistant
or
techno
sticks
package.
So
I
made
a
pull
request
and
asked
the
dot
net
team
to
come
and
donate
and
we
got
approval
from
them.
So
we
are
basically
removing
all
upper
bounds
for
microsoft,
dot
extension
packages
so
assuming
they
would
always
be
backward
compatible
so
that
changes
merge
and
should
be
part
of
the
1.2
release.
B
Okay
and
yeah,
like
we
did
release
the
alpha
one
with
like
the
very
basic
metric
support.
It
has
only
a
synchronous
version
of
the
counter
and
has
one
instrumentation
and
we
did
not
release
prometheus
because
prometheus
was
like
way
too
basic
to
be
even
shipped,
so
we
will
likely
add
that
in
the
1.2
alpha
2,
which
is
coming
like
I
think,
august
6
is
when
the
so.
That's
all
the
updates.
I
have
and
have
a
few
topics
to
be
discussed.
B
So
let
me
come
back
to
matrix
after
I
discuss
this,
so
this
should
be
a
relatively
short
one.
So
michael
and
I
was
discussing
this
yesterday,
there
is
this
package
we
have
in
the
main
repo
called
extensions.hosting.
It's
not
a
package
which
is
required.
It's
a
very
useful
and
nice
to
have
addition
for
di-based
configuration
and
for
like
having
this
like
one
liner
based
configuration.
People
would
just
add
things
to
the
da
and
things
just
gets
picked
up
automatically
by
the
provider.
B
So
the
question
is
like:
do
we
have
any
strong
reason
to
keep
it
in
the
main
ripper,
or
should
we
lift
it
and
shift
completely
to
the
contrib,
repo
and
ship
it
from
there?
We
never
released
a
one
daughter
version
of
it,
and
even
if
we
did
release,
I
don't
think
like
shifting
the
source
code
matters,
because
we
don't
plan
to
have
any
name
change.
B
So,
even
though
it
will
be
shipped
from
the
contrib
repo,
it
will
not
have
any
name
like
open
elementary
dot.
Contribute
will
still
be
named.
The
same
thing,
in
fact,
I
think
like
we
should
remove
the
name
contrib
from
all
the
other
packages
in
the
contrary
paper,
because
the
repo
name
should
not
be
part
of
the
package
name
thing.
I
briefly
asked
about
this
like
some
time
back.
I
don't
think
I
followed
up
on
that.
So
this
would
be
a
good
time
to
like
do
it
like
across
all
the
packages.
B
I
don't
know
about
the
aws
one
because
aws
already
shipped
1.0,
but
all
the
other
packages
are
like
in
alpha
or
beta,
which
means
we
can
do
a
renaming
without
breaking
anyone.
So
it
should
be
possible.
So
first
question
is
like
do
we
have
any
strong?
Anyone
has
any
strong
reasons
for
keeping
this
in
the
main
ripple,
because
it's
kind
of
like
a
old
man
out.
It's
not
part
of
the
spec.
It's
not
blocked
by
the
semantic
invention.
So
it's
not
falling
in
the
instrumentation
library
category
either.
B
B
Okay
seems
like
no
objections,
I'll
mark
it
here,
and
I
don't
think
I'll
have
that
time
to
like
do
the
actual
shifting
this
week,
because
we
would
still
be
spending
more
time
on
the
metric.
So
we'll
come
back
to
this
and
do
it
and
there
are
two
key
pr's
which
are
waiting
on
this.
One
is
the
thing
which
I
made
a
few
weeks
back
by
copying
several
previous
peers
on
that.
That's
one
thing
which
is
improving
the
configuration
part.
B
Basically,
we
are
trying
to
block
multiple
providers
being
added
all
those
things,
and
then
there
is
another
pr
about
adding
a
login
like
it's,
basically
a
different
version
of
self
diagnostic.
We
have
a
feature
in
the
hosting
package
which
reads
the
internal,
even
source
and
pipe
it
through
the
I
logger.
So
these
two
are
coming
and
we
don't
want
it.
B
It's
not
ready
for
one
dot
zero.
Yet
so
we'll
move
it
to
the
counter
purpo
and
like
deal
with
it
separate
from
the
main
ripple,
so
that
that
two
should
be
like
addressed
before
we
even
release
one
rocker,
the
main
report
so
yeah,
since
there
are
no
strong
objections.
I
will
start
the
work
like
probably
like
next
week.
It
won't
be
this
week.
A
B
Yeah
I
mean
it's
technically
like
we
can
move
everything
apart
from
the
spec
mandated
components
that
would
be
like
apa,
sdk,
all
the
five
exporters,
and
there
is
one
thing
called
the
compatibility
shim
for
open
tracing.
So
apart
from
that,
everything
can
be
moved
into
the
counter
repo.
It's
it's
just
that,
like
we've
never
had
the
time
to
like
actually
do
the
actual
work,
so
we
can
do
it
and
yeah
I
mean
based
on
best
of
my
knowledge.
B
The
seminary
conventions
are
still
not
marked
stable
and
I
don't
see
that
happening
anytime
soon
either.
So
it
would
be
quite
some
time
before
we
can
call
it
like
really
stable.
There
is
an
alternate
option,
not
really
an
alternate.
It's
like
something
which
we
want
to
do
in
the
next
dot
net
cycle,
which
is
to
support
the
notion
of
schemas,
so
pandel
material
already
introduced.
This
notion
called
schema.
B
So
even
if
the
semantic
conventions
changes,
the
schema
would
offer
a
transformation
back
and
forth
so,
but
we
haven't
done
the
work
for
that
yet
so
we
cannot
really
do
anything
right
now,
so
I
mean
my
best
guess.
Is
we
wait
for
the
semantic
conventions
to
be
stable
before
we
release
one
dot
out
of
it?
Irrespective
of
that
we'll
still
support
the
schema,
but
it's
unlikely
to
happen
in
the
dot
next
six
time
frame
so
because
we
need
like
some
changes
in
the
dot
net
itself
to
make
that
happen
right.
B
So
it
would
be
a
good
candidate
for
the
next
year
release,
and
I
mean
I
don't
see
like
specs
moving
the
semantic
conventions
moving
at
all.
It's
still
same,
and
I
don't
reflect
like
anyone
like
actively
working
on
that.
So
it's
quite
likely,
as
I
mentioned,
it,
won't
be
stable
any
time
soon.
So
we
have
like
all
the
time
to
like
lifting
it
and
shifting
it
to
the
contrap
repo.
B
Yeah
great
yeah-
and
I
maybe
like
something
which
we
haven't
checked
like
I
think
contributor-
has
a
streamlined,
release,
ca
and
everything
set
up.
We
did
release
like
all
the
other
like
packages
from
there
like
several
times
now,
so
I
think
it's
in
a
shape
which
can
be
used
to
release
all
these
packages.
So
there
is
a
good
advantage
if
we
move
them,
because
it
will
make
our
releases
easier
from
the
main
ripper,
because
you
just
do
the
like
one
round
of
release
rather
than
doing
two
rounds,
because
they
are
version
differently.
B
So
it
means
like
you
have
to
do
like
some
manual
work
to
avoid
conflicts
and
also
it
would
make
it
like
much
more
easier
if
you
move
those
packages
out
so,
but
I
think
it's
okay
to
wait.
At
least
we
reach
like
some
betas
in
the
matrix
before
we
do
like
any
major
work.
A
Also,
just
another
note:
I'm
also
a
fan
of
removing
contrib
from
the
from
the
namespace
yeah
that
I
think.
B
I
asked
it
like
sometime
back
and
I
did
check
with
python,
so
they
are
also
not
having
the
contrib
name
in
the
package.
B
And
I
think
the
package
itself
will
point
you
to
the
source
report,
rightly
so
it's
pointing
to
the
right
ripple.
So
that
should
be
good
enough
to
tell
that
this
package
is
coming
from
a
country
repo,
not
the
main
repo.
So
we
don't
need
to
like
have
the
name
here.
Yeah
thing
we
can
do
it
like
whenever,
like
you
have
free
time,
it's
not
like
top
priority,
because
it's
not
going
to
be
like
stable
anytime
soon.
B
So
we
have
like
plenty
of
time
to
what
okay,
let's
discuss
the
metrics
part,
one
thing
which
I
wanted
to
ask
like
that,
so
just
before
the
alpha
one
like
few
hours
before
the
alpha
one
release,
I
added
like
a
not
one,
like
probably
like
two
logs
in
the
hot
pot.
So
I
want
to
like
see
whether
this
can
be
avoided
in
the
next
alpha.
B
So
that
was
something
which
we
never
discussed
as
the
scope
of
alpha
2,
but
considering
like
matrix,
people,
expect
high
performance
and
having
these
logs
in
hot,
but
may
not
be
the
right
thing,
so
it
spent
some
time
to
see
if
we
can
get
rid
of
those
logs,
and
second
is.
This
is
something
which
allen
brought
up
when,
like
you,
did
the
espn
code
test.
So
to
the
best
of
my
knowledge,
I
had
to
validate
it.
B
So
if
there
are
no
fresh
update
to
a
metric
since
the
last
collect,
we
still
send
like
zeros.
So
it's
it's
probably
not.
B
The
right
thing
we
may
want
to
like
send
like
null
one
possible
option
to
indicate
that
there
is
no
update,
since
last,
like
null
would
be
an
indicator
or
we
need
to
like
figure
out
some
other
way
to
indicate
that
this
is
not
an
actual
metric
and
it's
up
to
the
exporter
to
decide
whether
it
wants
to
sell,
send
the
null
to
its
back-end,
because
some
some
back-ends
prefer
an
explicit
confirmation
that
this
metric,
like
I'm,
not
dead,
like
I'm,
still
sending
you
this.
B
But
this
knowledge
is
to
indicate
that
nothing
has
happened,
but
some
exporters
may
want
to
avoid
that
order.
It
simply
don't
send
at
all.
So
so
from
the
sdk
perspective,
we
shouldn't
make
that
decision.
We
should
just
do
let
the
exporter
make
that
decision,
but
currently
we
don't
have
a
way
for
the
exporter
to
distinguish
like
zeros
from
like
actual
zero
or
zero,
indicating
no
update
so
I'll.
Try
to
send
it
here,
which
can
like
introduce
a
nullable,
some
values
which
might
be
the
right
thing.
B
I
don't
know
I'll
just
send
a
pr
and
see
if
there
is
anything
any
other
issues
with
that
approach.
Otherwise,
we'll
do
that
because
this
seems
like
thing
what
we
do
currently
is
like
if
you
do
stop
sending
one
metric
after
sending
it
like
once
in
the
beginning
for
every
export
cycle,
we
will
be
still
sending
an
update
for
that
metric,
saying
zero,
so
it
may
or
may
not
be
efficient,
so
yeah,
I
think
yeah.
This
is
appear
and
see
if
it's
the
right
one.
Alan
sorry.
A
A
A
The
coming
week,
like
the
otp
exporter,
and
also
like
I
am
be
happy
to
contribute
tests
to
some
of
the
other
work
as
well.
How
should
we
best
track
conversations
like
this,
because
I
anticipate
other
little
kind
of
minutiae
will
come
up?
Should
we
open
up
an
issue?
I
think
it.
B
Would
be
best
if
you
open
issues
the
reason
why
we
did
not
open
issues
like
in
the
beginning,
it's
still
like
early
stages,
so
all
of
them
are
like
kind
of
known,
even
if
it's
not
explicitly
listed,
so
it
may
be
like
too
much
noise
to
have
issues.
B
So
that's
one
reason
why
I
did
not
like
prefer
to
like
have
one
issue
per
each
open
customer,
because
that
could
be
like
hundreds
of
issues
maybe
like
we
can
wait
for
at
least
one
or
two
more
of
the
releases
where
we
have
like
more
like
stable
things,
and
then
we
can
track
things
as
issues.
So
otherwise
I
mean,
if
you
start
opening
issues
right
now
I
mean.
B
Potentially,
we
can
open,
like
hundreds,
yeah,
each
and
every
open
question,
so
it
might
be
a
foreign
thing
to
wait
for
at
least
two
more
releases
before
we
start
opening
issues.
I
think.
C
That's
fair
yeah,
so
for
this
issue,
just
just
an
fyi,
the
issue
is
actually
related
to
there's
some
specs
out
there
that
talks
about
how
to
handle
essentially
stale
markers
and
so
forth.
So
there's
complication
in
it.
C
I
think
the
previous
metric
spec
had
something
that
said
that
you
know
aggregators,
you
know
have
a
time
to
live
and
you
need
to
clean
it
up,
but
the
current
spec
we
don't
even
deal
with
that
issue,
but
for
when
you
guys
are
investigating
or
looking
at
this
issue,
there's
some
concept
of
if
it's
cumulative
you're
always
going
to
have
to
send
the
last
value,
regardless
of
the
concept
of
you
know
not
being
refreshed
is
you
know,
needs
to
be.
You
know
it's
interesting,
then,
for
deltas.
C
That
brings
up
a
separate
issue
regarding,
if
there's
no
update,
when
do
we
not
send
it
versus
when
do
we
drop
it,
which
causes
a
reset
on
the
back
end?
So
there
it's
complicated
I'll,
just
say
that
there's
different
scenarios
to
deal
with
this
particular
issue
and
there's
also
a
separate
issue
about
how
to
clean
up
aggregators.
When
you
know
someone
stops
sending
metrics
all
together.
So
those
are
all
kind
of
related
and
unfortunately
none
of
the
spec
talks
about
it.
So
good
luck
with
that
allen
and
see
you
all
with
us.
B
So,
like
you
said
like
that,
the
version
of
the
sdk
we
had
two
years
back,
we
implemented
like
sort
of
a
gc
collector
within
the
aggregator,
so
we
mark
at
like
during
every
collect.
We
check
if
any
time
series
was
not
touched
at
all
in
that
cycle,
and
we
market
us
like
candidate
for
mobile
and
in
the
next
one.
If
you
still
see
new
update
we
removed.
If
we
get
an
update,
we
upgrade
it
to
the
like
active
one.
So
we
did
like
some
cleanups
like
that
in
the
previous
sdk.
B
I
think
the
spec
explicitly
asked
for
that,
but
right
you're
right,
like
I
don't.
C
Know
well,
the
previous
fact
did,
but
not
now,
not
not
currently
that
I
know
of
now,
there's
also
since
we're
on
this
topic,
there's
a
difference
between
cleaning
up
memory
and
aggregator
versus
sending
you
know
nothing
or
sending
a
marker
that
says
no
value
defined.
A
C
Have
some
marker
that
says
this
is
you
know
no
value
added,
but
I
don't
think
that's
been
merged
in
yet
either,
but
if
that
does
get
merged
in
then
for
some
of
the
otlp
protocol,
there
is
a
way
to
send
you
know
to
send
an
update
but
saying
there's
no
value
by
marking
that
flag.
That
says,
you
know
no,
no,
no
value
provided
and
so
forth.
So
but
that's
different.
That's
only
on
the
exporter
side
versus
what
we
do
for
memory
cleanup
and
stuff
in
the
aggregator,
so
that
again
more
complications,
so
yeah
fyi.
B
Yeah,
I
think
the
least
thing
we
should
know
is
like
we
should
have
the
export
like
when
the
exporter
receives
a
metric
item.
It
should
have
a
way
to
tell
whether
it
is
a
real
thing,
or
it's
just
telling
me
that
nothing
has
happened.
So
that's
the
very
least
thing
we
should
do
and
let
the
exporter
worry
about
whether
it
wants
to
accept
it
or
it
wants
to
send
it
or
drop
it.
B
The
cleanup
of
the
aggregators,
I
think,
we'll
come
back
when
the
spec
comes
about
come
like
comes
up
with
something
for
that.
For
now
we,
so
it's
basically
what
I'm
saying
is
if
you
created
some
metric
for
a
time
series
at
the
beginning-
and
you
don't
talk
about
it
for
like
next
one
hour,
we'd
still
be
sending
that
time
series
with
some
marker
saying
that
it's
not
been
updated
to
the
exporter
and
if
the
spec
allows
for
cleaning
it
up,
then
we'll
do
the
cleaning
app
so
as
of
today
and
for
the
next
release.
B
C
Yeah
so
given
where
the
spec
is
today,
I
think
we
just
wind
up
once
once
a
metric
has
ever
sent
anything
we're
just
going
to
wind
up
continuing
to
send
that
yeah.
So
it's
like
keeping
it
forever.
B
And
probably
that's
the
right
thing.
I
I
just
don't
know
like,
like
you
said
like:
if
you
try
to
clean
it
up
for
delta
and
then
we
see
it
again,
it
might
cause
the
reset
to
occur.
So
I
I
don't
know
whether
we
should
be
like
forgetting
it
ever
even
for
delta,
but,
like
I
said
I'll,
wait
for
the
specs
to
clarify.
C
B
All
right,
yeah,
so
yeah,
I
think
like
just
to
bring
back
the
like
thing,
which
I
wanted
to
discuss
for
alpha
2.
I
would
try
to
do
these
two,
if
at
all
possible,
first
before
adding
the
anything
else
like,
I
think
the
scope
was
to
include
the
at
least
a
mini
version
of
the
view
and
mini
version
of
not
beneficial
like
supporting
like
one
asynchronous
instrument,
so
most
likely,
we
should
be
able
to
do
that
as
well.
It's
just
that.
B
I
would
try
to
like
see
if
we
can
avoid
these
locks
in
the
hot
parts
and
deal
with
the
like
stale
marker
part
as
well,
and
we'll
come
back
to
the
alpha
three
or
whatever
is
next.
I
think
it
would
still
be
alpha
because
until
we
support
all
the
instruments
we
can
still
be
in
alpha
and
once
we
support
all
the
instruments,
we
can
call
it
like
beta,
okay,
yeah
victor,
like
you,
wanted
to
ask
some
questions,
or
were
you
just.
B
C
B
All
right
yeah,
I
I
will
like
try
to
get
to
it,
but
it's
very
unlikely
that
I
will
have
time
to
it,
because
I
want
to
like
see
if
we
can
solve
like
a
couple
of
fundamental
problems,
maybe
like.
If
we
are
all
happy
with
these
two,
we
can
do
a
alpha
two
like
much
earlier
than
plant
and
then
like
include
the
mini
view
and
a
single
instrument
on
alpha
three.
B
I
just
don't
know
like
how
much
time
it
will
take
to
like
see
if
we
can
like
modify
the
aggregate,
because
the
current
dictionary
like
since
it
can
be
like
modified
like
any
time
and
when
we're
trying
to
iterate
through
it
kind
of
like
throws
exception,
because
you
cannot,
I
trade
the
dictionary
which
is
parallelly
being
modified.
So
my
cheap
solution
was
just
like
wrap
everything
with
the
log.
So
I
want
to
see
if
I
can
get
rid
of
that
at
least
to
make
the
performance
more
reasonable.
C
Yeah,
I
mean
sure,
I'm
just
saying:
there's
a
bunch
of
pr's
out
there.
So
if
you
guys
have
time
and
opportunity
it'll
be
it'll,
be
wonderful!.
B
B
The
reason
is
like,
while
we
still
have
like
fairly
big
prs,
especially
the
views
and
like
when
we
have
like
more
aggregated
support,
we
expect
them
to
be
like
fairly
big,
so
we
want
to
be
like
minimally
destructive
when
we
are
working
on
like
close
to
the
release.
So
we
still
keep
the
matrix
branch
for
any
like
major
work
so
but
like
when
we're
about
to
release.
If
everyone
is
happy
with
the
like,
if
the
public
ap
is
like,
even
if
the
performance
is
like,
the
internals
are
like
later
changeable.
B
But
if
the
apis
are
like
reasonably
shaped,
we
can
move
it
to
the
main
branch
and
do
the
release
from
there.
So
as
of
today,
the
releases
are
only
happening
from
main
branch.
Matrix
branch
is
primarily
for
the
contributors
to
experiment
like
major
changes.
We
are
not
releasing
anything
from
the
matrix
prime,
so
it
will
be
mostly
for,
like.
C
B
Build
and
test,
okay
that
something
which
I
wanted
to
share
but
didn't
miss.
It
missed
it
in
the
beginning.
Okay,
any
other
things
to
be
discussed.
C
So
quick,
so
a
comment
for
I
think,
alan
probably
so,
and
for
you
probably
cjo,
is
that
the
the
the
concept
of
a
exporter
needing
to
tell
the
aggregators
or
whatever
whether
the
temporality
is
that
was
discussed
today
in
the
meeting.
So
I
don't
know.
A
C
Have
a
conclusion
on
that,
so
I
know
that
the
at
least
the
last
I
looked
at
the
metric
branch.
There
was
some
changes
made
to
collector
to
enforce,
or
you
know
a
collector
tells
or
collector
has
to
be
towed.
C
Well,
let
me
rephrase
that
a
collector
supports
either
cumulative
or
or
delta,
and
then
the
collective
forces
that
onto
the
aggregator,
so
that
concept
may
or
may
not
be
what
we
would
wind
up
doing,
because
it
sounds
like
there's
some
discussion
to
say
just
even
today
about
how
to
actually
specify
that-
and
I
think
you
know
riley
is
wanting
to
start
the
exporter
spec.
B
Yeah,
so
the
current
way
is
like
we
when
we
add
the
push
or
pull
metric
processor.
We
dis
define
like
whether
we
want
like
delta.
What
not.
So
it's
not
per
instrument,
it's
like
for
the
entire
instruments
and
there
is
no
ability
to
currently
over
predict
per
instrument.
B
C
B
So
we'll
wait
for
the
spec
to
come
out
and
clarify
that
before
changing
anything,
it's
quite
likely
that
we
will
need
to
support
per
instrument
control
primarily
through
views.
So
we
can
say
that
like
even
if,
like
you
have
100
instruments
but
for
this
particular
instrument
like
two
delta,
but
for
other
instrument
to
cumulative
the
current
state
is
like
it's
either
delta
for
all
with
all
the
metrics
from
this
pipeline
or
it's
cumulative
for
all.
So
I'm
pretty.
C
So
I
think
the
the
main
discussion
isn't
have
anything
to
do
with
that.
The
main
discussion
revolves
around.
We
know
that
we
need
to
do
some
conversion
between
delta
to
cumulative
or
cumulative
to
delta.
The
question
at
hand
is
who
should
be
doing
that
you
know.
Should
that
be
a
concept
of
the
exporter,
or
should
that
be
a
concept
of
the
quote
aggregator
and
I
think
that's
where
the
current
debate
is.
I.
B
See,
okay,
yeah,
that's
a
good
point
because
we
at
least
in
the
current
code.
We
don't
do
that
like
conversion,
so
it
it's
something
which
we
definitely
want
to
do.
But
I
just
don't
know
like
where
I
have
the
same
question:
whether
it
should
be
the
exporter's
responsibility,
whether
it
wants
to
convert
from
delta
to
humidity,
or
vice
versa,
or
like
the
sdk,
to
do
it
and
give
the
right
thing
to
the
exporter.
C
Yeah
so
in
the
list
I
have
a
pr
out
there
for
supporting
delta
cumulative
and
so
forth.
You
know
conversion
stuff,
and
I
did
that
in
the
aggregator.
So
if
you
guys
want
to
comment
or
or
you
know,
if
you
guys
want
to
comment
on
that
particular
viewpoint,
please
do
so
in
the
pr
I
post
it.
Okay.
B
Yeah,
I
think
your
approach
was
to
do
that
in
the
like
aggregator
itself,
and
the
exporter
has
no
knowledge
about
where
it's
happening.
It
always
gets
the
right
thing.
C
Yeah
comment
on
the
pr:
yes,
it's
I
think
a
bit
more
complicated
than
just
saying
that.
But
yes,
generally,
yes,
the
exporter,
tell
the
exporter,
has
a
choice
of
you
know
asking
for
delta
or
cumulative
and
depending
on
the
aggregator
they
may
or
may
not
support
it
with
potential
conversions,
okay,.
A
A
Question
I've
kind
of
had
as
far
as
just
logistics.
Since
I
know
that
there's
I
mean
I've
attended
some
of
the
sig
meetings,
so
I
know
that
there's
ongoing
conversations
about
about
things,
aggregation
temporality,
you
know
and
also
aggregation
type
and
where
that's
all
going
to
be
done,
but
logistics
wise
do
do
victor.
Do
you
want
to
ideally
land
your
prs.
C
So
I'll
give
you
my
viewpoint.
Is
that
and-
and
my
understanding
is
that,
if
you,
if
you
could,
if
you
attended
the
the
the
sigs,
the
call
out
is
for
pay
babies
basically
for
different
languages
to
do
prototypes
so
that
they
can
be
informed
to
then
discuss
spec
decisions
all
right,
so
so
that's
the
general
concept
is
that
yes,
we
we
are
my
my
intention
is
to
we
do
need
to
do
a
spec
or
sorry.
C
We
need
to
do
a
poc
just
so
that
we
know
how
to
have
a
conversation
with
the
spec,
and
it
is
likely
that
we
will
have
to
change
our
poc
accordingly.
Just
as
you
know,
the
c-sharp
folks
have
changed.
The
plc
joshua
on
the
java
is
changing
the
poc
as
well
as
josh
mcdonald
has
changing
the
gold
poc.
C
C
If
we
were
a
different
language
that
were
not,
you
know
designated
as
being
one
of
the
marquee,
then
we
could
just
wait
for
the
spec
to
be
done,
but
I
think
it
was
determined
some
time
ago
that
java
go
and
c-sharp
were
going
to
attempt
to
do
the
prototype
to
help
with
the
spec.
So
thus,
my
call
out
is
that,
yes,
I
do
believe
we
should
move
one
step
ahead
of
the
spec.
In
other
words,
we
should
try
and
review
and
understand
and
do
our
poc
for
that
purpose.
A
Definitely
appreciate
that
I
think
that's
a
that's
a
good
path.
How
does
that
align
with
you
see
joe?
As
far
as
what
you
envision
wanting
to
release
say
an
alpha
2
versus
you
know
the
next
alpha.
A
Would
you
be
okay
landing
some
of
these
consent,
like
just
proof
of
concepts
in
an
alpha,
knowing
that
they
might
dramatically
change?
I
mean.
B
It's
as
long
as
it
sounds
for
beta,
we
should
have
the
freedom
to
like
make
big
changes,
but
if
it's
like,
we
are
just
trying
to
do
like
some
pocs.
We
may
not
want
to
release
it.
If
it's
just
like
proof
of
concepts,
we
can
still
do
it
in
the
matrix
branch.
B
If
there
is
a
need,
we
can
I
mean
if
we
are
happy,
we
can
merge
it
and
release
it
from
the
main
branch.
Otherwise
they
can
remain
in
matrix
branch
as
a
poc,
and
then
we
can
indirectly
help
the
spec
with
our
pocs.
Okay.
That
makes
sense
yeah,
because
if
we
try
to
release
all
the
plc's,
then
it
will
be
like
big
turn
like
it
might
not
be
what
we
want
for
even
for
alpha
release.
A
Okay
yeah,
thank
you
for
that
clarification.
Actually,
I
just
realized
that
this
this
pr
that
you
have
up
now
is
still
against
the
metrics
branch,
so
that
makes
sense
to
me.
Okay,
yeah.
B
So
the
view
is
like:
what's
something
which
is
very
thing,
that's
fairly,
the
biggest
feature
like
feature
wise:
it
would
be
the
biggest
one
and
like
then
it
would
be
like
the
like.
Actual
exporter
spark
like
once
the
spec
comes
over
it,
so
those
would
be
like
very
fairly
disruptive.
So
if
you
try
to
do
that
in
the
main
branch
and
while
we
are
trying
to
do
like
alpha
one
alpha
to
release,
we
like
fairly
disruptive,
you
cannot
like
make
any
progress
because
you'll
be
like
constantly
like
making
changes.
B
So
we
don't
know
like
that,
what
point
we
should
stop
and
release.
So
that's
why
I
think
it
makes
sense
to
do
like
smaller
increments
and
release.
Maybe,
like
I'm,
okay,
to
release
like
every
week,
we
can
do
like
alphas
every
week
with
whatever
things
which
we
are
happy
from
the
main
branch
and
still
keep
like
the
major
big
improvements
in
the
matrix
branch.
So
we
are
not
really
disrupting
the
main
branch
and
we
can
revisit
this
approach,
maybe
like
week
to
week
on
a
weekly
basis
make
based
on
our
progress.
B
We
can
keep
it
in
the
metrics
branch
until
we
have
enough
time
to
like
walk
through
it
and
polish
it
and
then
get
it
to
main
point
and
like
my
personally,
I
was
thinking
that
we
should
like
try
to
do
like
some
basic
version
like,
even
if
we
don't
have
the
views
or
any
any
of
the
advanced
features.
It
should
just
work
like
end-to-end.
So
that's
why
I
was
insisting
we
should
release
something
rather
than
waiting
for
everything
to
be
coming
before
releasing
so
part
of
the
reason
is
like.
B
If
you
look
at
the
dogs,
I
want
it
to
be
like
very
straightforward
to
use.
It
should
be
like
less
time,
but
how
many
lengths
we
have
20
25
lines
yeah.
It
should
be
like
very
straightforward
to
use,
and
we
want
like
this
to
be
like
undisrupted.
So,
even
if
you
add
views
it's,
if
it's
like
completely
optional,
we
don't
need
to
do
change
anything
here.
B
So
because
yeah
I
mean,
I
think
I
left
that
comment
like
if
you
expect
the
inducer
to
pick
the
aggregator,
including
the
monotonous
monotronicity
and
the
temporality
it
all
of
a
sudden
feels
like
a
fairly
daunting
task,
because
they
spend
like
time
analyzing
the
spec
and
figuring
out
which
instrument
they
want
out
of
the
five
or
six,
and
then
they
again
spend
time
analyzing.
Okay.
How
do
I
map
that
into
a
view
and
which
aggregator
I
pick
so
those
feels
like
bit
complex
and
it
will
scare
away
most
folk.
So
just.
C
B
B
B
That's
why
I
said
it's
just
an
example:
it's
not
a
spec,
it
says
like
you,
may
allow
it
you
may
not
it's
that's
why
it
is
in
the
examples
and
not
in
the
thing
like
once
the
the
aggregator
spec
gets
more
progress.
I
think
this
is
quite
likely.
I
hoping
that
this
is
where
we
would
get
to
specify
that,
but
yeah
I'll
wait
for
it,
but
just
to
come
back
to
the
main
point
like
whether.
C
Yeah
so
at
that
point
see
joe,
maybe
you
want
to
also
add
your
comment
more
in
the
aggregators
back
in
case
people
missed
it
because
the
view
now
it's
already
merged,
so
people
won't
see
it.
So
maybe
you
should
just
additionally
add
that
comment
in
the
aggregate
specs,
so
people
will
be
top
of
mind
for
them.
B
Can
do
that
yeah
so,
just
to
like,
like
talk
about
at
least
the
like
any
major
disruptive
feature,
I
would
still
prefer
to
keep
it
at
least
for
now.
In
the
matrix
branch
like
once,
we
like
have
a
reasonable
agreement
that
this
is
what
we
want.
Then
we
can
move
to
the
main
branch
and
add
a
like
new
dock,
which
says
like
customizing,
sdk
and
add
all
the
advanced
features,
but
we
would
still
prefer
to
keep
like
the
getting
started.
Example
should
be
like
most
straightforward
least
number
of
lines
of
code.
B
The
user
has
to
write
so
at
least
like
this
will
not
scare
away
like
potential
users.
They
can
try
it
and
give
some
feedback,
but
if
you
make
it
like
really
complex,
we
like
scare
away
a
lot
of
potential
users.
So
that's
my
opinion
on
like
adding
any
major
features
without
confirmation
that
this
would
be
indeed
required
by
the
spec
or
we
are
going
to
do
it
and
blue
is
a
good
example
like.
I
know
that
we
need
definitely
need
views
because
I
still
want
to.
B
I
mean
the
only
question
which
I
have
as
an
open
thing
is
what
about
the
aggregator
configuration
within
the
view.
So
that's
part
of
the
reason
why
I
modified
our
milestones.
Last
week
we
decided
like
we
can
do
scale
down
view.
That
would
be
like
a
lot
easier
and
then
we
can
always
like
add
more
things
to
the
views
so
that
we
can
do
it
like
increment,
because
we
think,
like
I
still
think
we
have
like
more
fundamental
issues
to
be
solved
about
what
should
be.
B
B
I
think
those
are
like
more
fundamentals,
I'll
like
try
to
spend
some
time
there
and
try
to
over,
because
I
think
if
you
look
at
the
tracing
one,
we
spend
like
a
lot
of
time
trying
to
avoid
the
allocations,
even
in
the
non-hot
path
like
in
the
export.
Also,
we
spend
a
lot
of
time
like
trying
to
avoid
the
allocation
so,
but
for
matrix
we
having
focus
there.
We
are
mostly
trying
to
optimize
the
recording
path,
but
we
never
spend
any
time
doing
the
what
what
happens
on
the
collect.
B
So
I
want
to
like
spend
some
time
there,
because
that
would
directly
affect
the
exporter
api.
So
I
think,
like
those
are
like
more
fundamentals,
which
is
why
I
was
saying
like
I'll
try
to
spend
some
time
on
those
like
initially
and
then
do
reviews
or
advanced
aggregator
configuration
or
any
of
the
advanced
aggregation.
Algorithms,
like
I
say,
like
probably
something
which
we
can
tackle
once
the
basics
are
set.
B
C
Happy
days
so
so
I
don't
disagree
with
your
opinion
cjo
on
that.
I
just
wanted
to
say
that
from
terms
of
ordering
you
might
want
to
follow
the
order
in
which
the
sig,
you
know
is
doing
it.
So
they're
they're,
they're,
just
starting
the
exporter,
so
that's
really
early,
but
they
already
finished
the
view.
So
I
think
fundamentally,
we
probably
should
put
more
attention
on
the
view.
Given
that
the
view
spec
is
now
merged
into
main.
B
So
I,
when
I
said,
like
the
export
thing,
I
didn't
really
mean,
like
the
exact
signature.
What
I
really
meant
was,
if
you
look
at
the
tracing,
what
we
do
is
like.
We
use
a
like
right,
lock,
free
buffer,
to
keep
all
the
items.
We
create
a
batch
out
of
it
to
the
exporter
and
there
is
no
allocation
there,
because
the
batch
is
simply
pointing
to
the
same
buffer
and
it's
like
pre-allocated
at
the
beginning,.
C
B
Matrix,
it's
it's
just
a
data
structure.
We
call
it
batch.
It
can
mean
like
multiple
metrics
that
can
be
triggered
by
that
so
yeah.
C
B
Like
I
said,
it's
part
of
the
at
least
the
planet
faction
for
alpha
2
includes
views,
so
it's
not
being
ignored.
It's
there
like
having
changed
it.
It's
still
in
our
milestone
description.
Also
only
thing
I
mentioned
is
it
would
be
like
scoped
down
version
of
the
view
which
would
just
avoid
the
aggregator
part,
because
aggregator
is
still
like
a
bit
unclear.
How
would
we
tackle
that
so.
B
Following
that
yeah,
it
won't
be
like
in
a
week,
I'm
pretty
sure
it
would
be.
Our
plan
is
to
release
it
by
end
of
next
week,
so
we
may
not
have
the
aggregator
sold
by
the
spec
at
that
time,
so
it
would
be
like
wise
to
like
don't
touch
the
aggregator
part
in
the
next
alpha.
B
A
A
A
My
one
question
that
I
did
put
on
the
pr
at
this
point
in
time
actually
is
relates
to
this
conversation
about
scaling
it
down
because,
like
the
add
view,
function
right
now
takes
in
an
aggregator
type,
and
so,
as
far
as
I'm
concerned
just
kind
of
looking
over
this
pr.
I
think
that's
the
that.
That's
the
main
thing
that
jumps
out
at
me
as
what
scaling
to
what
scaling
down
means.
Is
that
specifically.
B
Referring
to
these
two,
but
I'm
going
to
straight,
because
all
these
things
are
called
out
explicit
explicitly
in
the
specs.
So
we
would
definitely
need
that
except
this
part
which
is
mentioned
in
the
examples,
but
not
in
the
spectrum.
Why?
Why?
Why
accept?
C
B
So
that's
the
part
which
I
said,
it's
still
unknown
for
me,
but
the
rest
are
following
the
spec
assets,
like
all
these
things
are
required
by
the
spec,
maybe
like
different
name,
but
at
least.
C
B
But
I
think
like
when
I
use
the
word
like
scale
down
view.
What
I
really
mean
is
like,
whatever
I
have
highlighted,
except
these
two
lines
which
says
like
how
do
we
customize
the
actual
aggregator?
That's
all
I
mean
by
the
scaled-down
version
of
the
view.
A
B
Yeah,
I
think
so
I
mean
I
haven't
looked
at
it
very
recently,
but
that
was
my
like
biggest
like
stand
out
thing
like
so.
C
B
C
So
so
yeah,
so
so
I
just
want
to
be
be
kind
of
clear.
I
don't
I'm
not
concerned
necessarily
at
this
point
about
the
what
we
expose
public
interface
I'll.
Let
siegel
decide
that
I'm
most
mostly
interested
in
the
internals
of
the
infrastructure
to
make
sure
we
have
a
way
to
support
the
view,
even
if
we
don't
publicly
expose
it.
So
I'm
I'm
fine
with
that.
That's
my
actual
ask
for
the
view
pr.
It's
really
all
that
just
that.
B
Yeah,
that's
fair
yeah
and
one
additional
thing:
it's
not
related.
We
don't
really
support
multiple
exporters,
saying
like
we
don't
have
a
way
to
like
define
multiple
pipelines
right
now
so
like
like
victor,
like
do
you
think,
that's
like
any
like.
C
Public
interface,
to
only
have
only
one
export,
I'm
fine
with
that
as
well.
The
internal
infrastructure-
I
don't
think
matters
whether
you
have
one
exporter,
multiple
exporter
and
I
suspect
that
it'll
likely
come
with
the
pipeline
one.
You
know
to
potentially
have
multiple
exporter,
but
who
knows
what
that
will
come
in
so
where
I'm
I'm
happy
to
you
know,
remove
you
know
from
the
public
interface
for
the
moment.
C
B
You
know
I
mean
I
I
was
just
about
to
say
that,
like
if
it's
not
exposed-
and
it's
mostly
fine-
I
just
want
to
see
like
like
in
the
pier
like
how
how
do
we
like
deal
with,
like
you,
probably
want
to
like
mark
this.
C
I
mean
I'm
happy
to
you,
know,
update
the
pr
to
not
expose
it.
That's
fine
did
you.
I
could
do
that.
B
Those
things
like,
then,
it
would
be
like
like
much
more
like
scaled
down.
We,
these
are
things
which
we
anyway
want.
C
To
solve
and
right,
but
to
be
clear,
we're
just
talking
about
the
public
interface
still
we're
still
only
talking
about
the
public
interface,
but
the
question
is
really
deeper.
Is
that
do
you
want
to
actually
not
have
code
that
supports
it,
or
do
you
want
to
just
limit
the
exposure
to
code
that
currently
supports
it?
So
that's
really
the
main
question
here.
B
So
the
best
way,
I
think
I
I
would
answer
is
this:
if
it's
going
to
like
affect
like
all
the
classes
in
metrics-
and
I
think
I
would
say,
don't
do
it
now,
because
we
still
have
to
solve
the
first
problem,
which
is
like
I
mentioned
in
the
beginning.
We
want
a
word
that
logs
in
the
hot
path.
B
So
if
you
have
like
10
additional
places
which
you
are
trying
to
touch
and
I'm
trying
to
modify
at
the
same
time,
we
will
just
be
like
conflicting
with
each
other
in
the
pr.
So
I
would
say
if
you
can
avoid
that,
that
would
be
my
suggestion
and
like
it
should
be
like
possible
to
add
it
back
anytime,
but
it
it's
a
lot
difficult
to
test
the
same
classes.
B
At
the
same
time,
we
will
be
just
having
like
much
conflict,
so
one
of
us
will
be
like
constantly
like
re-updating,
based
on
what
the
other
pr
progresses.
So,
if
you
can
avoid
like
like
touching
it
at
all,
that
would
be
great
like
if
you
are
just
dealing
with
a
single
pipeline
as
it
stands
today.
C
And
no
way
so
you
so
so
to
be
clear
to
clarify
you
you're
talking
about
the
your
example
and
the
public
interface
correct.
Oh.
B
No
they're
actually
limited
because
to
me
like,
if
this
has
let
me
just
open
it,
this
would
be
like
touching
almost
all
the
providers,
aggregated
stores,
including
pretty
much
all
the
aggregators
right.
So
if
I'm
also
making.
C
B
I
have
to
check
the
actual
pr
to
see
whether
that
is
correct
or
not,
because
I
think
I
think
I
removed
that
so.
C
C
So
the
general
I
saw,
I
think,
the
general
question,
if
I
got
this
right
in
the
summary,
is
that
first
you
prefer
that
the
public
interface
is
more
limited
and
then
secondarily,
if
possible,
or
if
convenient,
that
the
actual
implementation
strips
out
any
support
for
multiples,
because
you
think
that
it
will
potentially
conflict
in
the
future
yeah.
I
think
that's
the
goal,
one
and
goal
two,
yes,
and
so
let's
agree.
A
C
C
Why
not
because
we
could
debate
on
goal
two,
but
let's
agree
on
goal
one:
the
goal:
one
is:
basically
you
don't
wanna
have
additional
stuff
in
the
public
interface.
So
if
we
updated
the
public
interface
to
not
expose,
you
know
multiple
exporter
and
aggregator,
then
you're
fine.
A
C
B
Yeah
I
mean
that's
like
exactly
what
I
said
in
the
beginning,
like
I'm
happy
to
get
it
in
as
soon
as
we
remove
like
anything
which
we
are
not
convinced.
That
would
be
part
of
the
public
epa.
B
Okay,
I'll,
send
a
pr
later
today
for
that
mm-hmm
and
for
the
second
part
yeah.
I
think
I
need
to
look
at
the
actual
pr
and
see
like
whether
we
can
still
like
manage
that
internally
without
touching
the
public,
but
that's
something
which
I
cannot
like
give
a
straight
answer
right
now.
I
have
to
like
look
at
how
it
is
structured
right
now.
B
I
certainly
don't
want
to
have
the
situation
where,
like
all
of
us,
are
like
submitting
prs,
which
requires
like
one
of
them
or
multiple
of
them,
to
do
like
constant,
merge,
conflict
resolutions
based
on
the
actual
changes,
so
it
would
go
a
little
bit
slow
there,
but
again
it
really
depends
on
which
classes
are
being
modified.
B
Example
like
if
you're
adding
like
a
like,
I'm
just
giving
an
artificial
example
now
so
if
you
are
just
adding
a
a
new
aggregator
or
maybe
like
you're,
just
modifying
the
current
aggregator
for
histogram
to
be
an
actual
like
histogram
working
one,
it
wouldn't
conflict
with
any
of
the
other
classes
like.
If
someone
is
working
on
adding
views,
they
can
work
independently
without
like
clashing
with
each
other.
I
hope
so.
B
So
the
merge
would
be
like
a
little
bit
difficult
at
that
point
so
mostly
like,
since
it's
just
two
of
us
or
maybe
like
three,
it
should
be
like
possible
to
resolve
that
like
offline,
we
should
be
able
to
like
cue
it
one
by
one
and
then
get
it
out,
but
I
certainly
don't
want,
like
all
of
us
to
like
work
on
the
same
area
and
potentially
conflicting
yeah.
I
mean,
like
I
said
like
if
you
can
do
a
scaled-down
version.
That
would
be
like
really
you
can.
B
We
can
maybe
release
it
like
even
earlier
than
next
friday.
We
can
get
the
metrics
used
like
much
earlier
than
what
we
originally
planned.
C
B
Yeah,
I
think
for
me
like
what
allen
works
on
so
far
is
not
conflicting
with
any
of
he's,
mostly
working
on
instrumentation
and
otlp
exporter,
at
least
for
now,
and
those
are
very
unlikely
to
be
conflicting
here.
So
that
seems
like
a
very
nice
parallel
work
and
if
anyone
wants
to
add
more
instrumentation
like
feel
free
to
add
that,
because
it
should
not
conflict
with
any
of
these
things,
because
the
instrumentation
only
requires
one
api
from
this
repo,
which
is
the
meter
provider,
builder,
dot,
add
instrumentation.
B
Everything
else
is
coming
from
the
dot
net,
so
there
is
no
like
debate
or
anything
so
that
can
be
like
really
done
in
parallel
and
also
like.
If
anyone
wants
to
do
the
prometheus
part,
that
is
also
going
to
be
like
not
conflicting
with
any
of
these
things,
because
I
added
the
very
basic
thing.
But
if
anyone
wants
to
work
on
it,
that
would
also
be
like
not
conflicting
at
all,
but
they
are.
B
I
was
saying
that
the
reason
why
I
never
asked
anybody
these
are
like
not
the
top
priorities,
because
we
have
like
more
fundamental
problems
to
solve.
This
can
be
like
sold
anytime
in
the
future,
so
it
never
is
a
top
priority
right
now
for
me,
but
happy
to
accept
like
prc.
If
anyone
works
on
it.
C
There's
a
one
other,
there's
one
item
that
you
know
I
think
would
be
helpful
if
people
added
is
in
diagnostic
logging
in
metrics,
we
don't
currently
have
a
easy
means
to
quote
log
diagnostic
messages,
and
I
think
the
spec
called
out
several
places
where
we
need
to.
B
I
think
we
mark
like
to
do's,
but
yeah.
That's
right
thing.
We
have
to
do
that
login
here.
I
didn't
spend
like
too
much
time
like
looking
at
that.
I
think
it's
too
early
to
do
that
logan,
because
since
things
are
still
changing
actively
we'll
leave
without
logs
for
now-
and
we
can
add
it
to
anytime
later,
I
think
we
put
like
some
to-do's.
I
like
like
seen
some
to-do's
like
last
week,
but
yeah
okay,
yeah
victor,
like
you,
have
like
more
comments.
C
B
Okay,
yeah
so,
hopefully
we'll
try
to
get
the
escape
scaled
on
version
of
the
view
and
like
slightly
better
log,
free
or
like
less
look
version
of
the
sdk
and
deal
with
the
exporter
part
by
end
of
next
week
or
hopefully
much
earlier
than
that.
That's
the
main
goal
and
we'll
decide
on
the
scope
for
the
next
release
next
week
and
like
even
if
we
need
to
do
like
a
weekly
release.
As
soon
as
we
add
feature,
it's
totally
fine,
okay,
thank
you.
B
Everyone
like
also
like,
if
you
get
time
like,
please
look
at
open
issues.
There
are
like
issues
coming
and
we're
trying
to
address
them
as
whenever
we
get
free
time
but
like
if
you,
if
any
of
you
have
free
cycles
like
look
at
the
issues
and
if
you
can
respond,
then
and
close
it.
That
would
be
helpful.
B
Okay,
thank
you
see
you
all.
Next
week,
thanks
y'all
bye,
everyone
see
ya.