►
From YouTube: 2021-08-03 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
B
C
C
B
B
B
A
Well,
I've
been
following
it:
I've
not
been
working
closely
on
it,
so
I'm
not
sure
if
there
is
anything
blocking
there.
As
far
as
I
understand
there
is
a
bunch
of
different
implementation
questions,
because
what
I
presented
a
few
weeks
back
was
basically
how
to
map
this
stuff,
but
there
is,
there
were
still
a
few
questions
about
how
to
like
store
the
data
in
the
in
the
protobuf
and
how
to
serialize
it
and
stuff
like
that.
But
I
have
to
admit
that
I
haven't
been
following
that
that
closely.
A
B
B
No
worries
how
I'll
follow
up
with
the
offline
and
to
my
understanding,
we
need
at
least
three
do
the
prototype,
and
once
the
prototype
was
proven
to
be
working,
we
should
be
good
to
go
right.
A
Yeah,
I
think
so
too,
so
I
think
there
is
like
work
going
on
by
uk
who
is
doing
stuff
in
java.
If
I'm
not
mistaken,
but
again
I
don't.
I
don't
really
know
the
exact
status
of
what
it.
What
that
looks
like
right
now
so.
A
Okay,
but
I
guess
it
probably
would
be
good
to
have
have
it
in
in
like
at
least
two
or
three
different
languages
right
to
compare,
how
how
it
works
and
how
I
guess,
production
ready.
That
stuff
is
so
we'll
probably
have
to
push
a
few
push
push
around
there
a
bit
and
make
sure
that
we
have
prototype
implementations.
A
I'm
sure
I
can
contribute
something
there,
but
yeah
we'll
probably
have
to
like
split
that
up,
so
maybe
follow
up
with
jmxd
and
see
how
we,
how
we
drive
this.
B
Okay,
thank
you
I'll,
follow
up
with
him
and
report
back
on
thursday.
Thank
you.
The
the
second
thing
I
want
to
talk
about,
so
we
discussed
last
time
that
we
want
to
remove
some
of
the
processors.
I
think
we
agreed
on
that
we're
going
to
remove
the
metric
processor
because,
like
that
part,
we
need
to
rework.
B
Another
thing
I
think
we
haven't
concluded
is
better.
We
keep
the
measurement
processor
and
from
the
common
it
seems
joshua
one
has
to
remove
the
measurement
processor
as
well.
I
put
a
link
here,
it's
related
to
another
issue
that
was
found
a
long
time
ago,
and
I
I
see
similar
ask
several
times
that
people
want
the
ability
to
at
least
consume
or
capture
the
raw
data
without
aggregation
with
the
measurement
process
we
have
today.
We
at
least
we
give
that
flexibility.
B
So
I
replied.
I
replied
back
saying
that
we
allow
the
processors
to
access
the
raw
data,
so
I
believe
this
problem
can
be
solved
in
the
ick
and
I
remove
the
sdk
tag.
If
we're
thinking
about
removing
the
measurement
process
as
well,
then
I
need
to
come
back
and
tag
this
issue
as
an
secret
issue
as
well.
So
I
want
to
get
some
like
initial
thoughts
from
folks.
Do
you
think
the
environment
processor
is
a
must-have
that
we
need
to
address
now,
or
we
can
put
that
later.
B
I
hope
we
can
give
that
in
the
first
release,
but
if
either
folks
that
believe
that
we're
we're
trying
to
get
the
minimum
scope,
let's
remove
that
for
now.
I'm
happy
to
do
that.
Just
want
to
get
some
thinking
from
folks
like
like.
Are
you
going
to
consume
the
wrong
metrics
at
all,
or
it's
not
a
problem
at
all.
D
I
guess
I'm
curious
about
I'm
somewhat
new
to
the
like
the
the
brain
space.
That's
been
going
on
on
this
particular
matter,
but
my
understanding
that
was
that
measurement
processors
were
going
to
be
a
way
that
things
like
baggage
context,
could
be
added
to
metrics,
and
I'm
just
curious
if
there
are
other
alternatives
that
have
been
discussed.
B
Oh
yeah,
so
the
other
alternative
could
be
instead
of
giving
that
logic
for
people
to
implement
whatever
they
want
like
grabbing
something
from
the
contacts
like
dimension
or
grab
something
from
the
instrumentation
library
and
add
that
as
an
attribute
to
the
raw
data,
another
way
is
only
exposing
some
declarative
thing
similar
like
view
you
can
declare
hey.
This
is
my
callback
function
or
you
can
even
invent
some
static
rules
saying
I
want
if
the
like
something
in
the
baggage
called
like
a
dot
b,
then
take
it
and
do
something
else.
B
I
personally
think
the
processor
model,
at
least
the
measurement
processing
model,
is
well
aligned
with
the
spam
processor
model
in
tracing.
So
without
that,
I
I
think
we're
creating
some
artificial
gap
between
tracing
and
matrix.
This
brings
additional
learning
problem
and
I
also
have
a
gut
feeling
that,
no
matter
what
we
do
now,
eventually,
we
won't
need
to
like
expose
this.
D
No,
that
was
that
was
super
helpful.
I
I
definitely
see
how
this
could
be
handled
by
views,
but
I
definitely
appreciate
the
api
ergonomics
argument
for
something
like
a
measurement
processor,
since
we
already
have
the
precedent.
B
Yeah,
this
is
why,
in
in
my
pr
currently
I
I
only
try
to
remove
the
metric
processor
for
now,
and
I
I
try
to
keep
measurement
processor.
If,
if,
whatever
decision
we
have
I'm
not
going
to
change
this
pr
to
move
two,
I
just
want
to
make
a
like
this
pr
specific
to
matrix
processor
and
we
decided
to
remove,
remove
measurement
process
anyways.
I
will
send
the
separate
pr,
but
so
far
it
doesn't
seem.
B
B
E
I've
been
on
vacation
for
a
week,
so
I
have
very
few
opinions
aside
from
processing
through
my
very
large
backlog
of
work,.
F
I
I
have
no
concern
with
that,
but
yet
again
I
I
have
been
mostly
an
external
observer,
but
it
does
sound
right.
B
Because
here
I
I
pinned
back
from
a
comment.
This
is
where
folks
are
asking
that
they
want
to
be
able
to
access
the
raw
data,
and
there
are
a
lot
of
thumb,
ups
and
a
lot
of
discussions.
I
got
a
guide
feeling
that
we
need
to
solve
this
in
isdk.
This
is
why,
when
I
added
the
skeleton
pr
of
the
matrix
sdk,
I
put
the
measurement
processor
and
folks
agreed
it
got
merged.
So
I
reported
back
and
saying
this
is
already
covered.
B
And
now,
if
we're
going
to
remove
that,
I
have
to
come
back
to
this
issue
and
add
the
ick
tag
back
again,
and
so
so
couple
things
number
one
is
in
this
pr:
I'm
going
to
focus
on
removing
matrix
processor,
not
the
measurement
processor,
because
this
is
what
we
all
agreed
on.
The
measurement
processor
is
not
something
we
agreed
on
at
least
from
what
I
could
remember
and
also
I
see
a
need.
B
So
I
I
would
prefer
to
keep
that
and
by
asking
around
here
in
this
meeting
it
feels
I
don't
see
some
need
and
other
folks
don't
have
strong
opinion,
but
the
kind
of
thing
I
think
this
kind
of
makes
sense.
So
I'll
get
back
to
josh
and
see
what's
the
motivation
or
reason
that
he
would
want
the
measurement
processor
to
be
removed,
but
by
default
number
one.
I
I
wouldn't
try
to
extend
this
pr.
B
B
C
Clear
do
you
yep,
so
only
comment
which
I
wanted
to
make
was,
I
think,
like
there
is
a
there,
was
a
separate
discussion
about
whether
we
want
to
expose
aggregator
as
a
thing.
So
if
we
are
not
doing
that
which
means-
and
if
you
are
not
doing
metric
processor
and
if
you
are
not
doing
measurement
processor,
then
there
is
like
very
limited
extensibility.
C
So
measurement
processor
seems
like
the
like
a
balance
like
it
gives
access
to
raw
measurements.
So,
even
if
you
are
not
happy
with
the
built-in
aggregators,
they
can
still
access
the
raw
measurements
and
do
whatever
they
want.
So
it
seems
to
me
like,
like
I
would
say,
measurement
processor
is
important,
so
I
would
say
plus
one
two
keeping.
E
Otherwise,
there's
going
to
be,
I
think
I
actually
share
this
opinion.
Otherwise
I
think
it
might
take
us
a
really
really
long
time
to
get
us
to
a
1.0
and
we
can
always
add
this
in
1.1
or
whatever
numbers
we're
using.
I
don't
know
you
can
always
add
these
things
right.
We
can
always
add
new
things.
We
can
never
remove
them.
So
let's
start
super
simple
and
get
something
that
works
and
is
reliable
and
then
add,
extensibility
and
make
sure
we
design
for
extensibility.
B
B
So
my
ask
is:
please
review
that
and
and
put
comment
and
given
victor
is
not
here.
If,
if
I
can
see
some
progress
here
and
there's
a
consensus,
I
I
already
asked
the
victor
to
give
me
permission
to
his
own
fork.
I
can
make
an
update,
so
if
we
can
accelerate
that
time,
I'm
happy
to
do
some
work
here.
B
B
B
Okay,
that's
all
from
my
side.
I
want
to
see
if
other
folks
have
any
questions
and
and
by
the
way,
john
before
before
you
took
vacation.
I
I
think
you
left
some
comments
on
the
view.
Pr,
I
believe
we
tried
to
address
all
of
them
and
in
the
end
I
think
we
addressed
90
of
them,
but
still
there's
one
comment
we
left
as
open
and-
and
I
want
you
to
see
if
you
still
have
concern-
and
I
want
to
like
resolve
that
as
well.
E
Yeah
I
was
looking
at
looking
at
that
very
quickly
this
morning,
the
merged
pr,
and
I
think
there
was
one
open
question
that
I
had,
which
was
about.
We
have
in
the
specification
written
that
there
is
a
way
to
get
data
out
of
the
context,
slash
baggage
as
a
part
of
and
add
attributes
from
that,
but
I
am
very
nervous
about
that,
because
it's
actually
fair,
very
non-trivial
to
define
how
that
would
work
like
how
you,
if
you
you
say,
I
want
something
out
of
the
baggage.
E
E
How
do
we
specify,
in
a
view,
definition,
I
don't?
Even
I
literally
have
no
idea
how
one
would
do
this
unless
you're
providing
the
user
of
like
a
functional
callback
that
they
can
use
to
extract
data
out,
and
I
think
we,
I
think
if
we
don't
know
how
that's
going
to
work,
we
should
not
put
it
into
the
specification.
B
E
B
B
Yeah,
so
I
understand
that
part,
so
it
seems
like
different
languages
might
have
different
challenges
here,
and
I
I
understand
the
what
you're
thinking
about
in
jail,
quick
question
coming
back
to
the
measurement
processor,
if
you
think
we
we
give
something
like
measurement
processor,
we
let
people
write
code,
do
whatever
they
want.
B
E
I
don't
think
it's
necessarily
too
hard
to
implement
I'm
just
I
I
just
would
prefer
an
incremental
approach
to
building
this
building.
What
we're
building
because,
like
I
said,
if
we
try
to
boil
the
ocean,
we're
we're
going
to
have
you
know,
17
features
per
sdk
that
all
have
to
be
aligned
perfectly
right
out
of
the
gate.
Yeah,
it's
going
to
take
us
a
lot
longer
than
if
we
have
like
three
features
that
every
language
needs
to
have
implemented,
and
then
we
very
gradually
incrementally
add
new
things
to
it.
E
So
it's
not
necessarily
difficult
of
implementing
any
individual
piece.
It's
more
just,
let's
start
really
simple
and
make
sure
that
we
all
agree
on
something
really
simple
and
we
can
all
get
it
implemented
and
released
as
like
a
actual
release
and
then
start
adding
features
to
it.
Rather
than
trying
to
continually
add
more
and
more
things,
yeah,
it's
why
it's
why
I
was
hoping
initially
we
weren't
even
going
to
do
views
like.
E
E
I
guess
I
don't
it
so
I'm
I'm
wearing
my
open
telemetry
hat
here,
not
my
splunk
cat,
and
that
is,
I
want
to
get
something
released,
even
if
no
customer
can
use
it
exactly.
I
want
a
minimum
viable
product.
I
want
an
mvp
for
metrics
that
we
can
build
on
and
then
make
sure
that
we
get
the
feedback
from
real
users
like.
Oh,
I
can't
use
this.
Unless
I
have
this.
Oh,
I
can't
because
right
now
we
have
you
know
like
20.
E
D
E
B
E
Yeah
I
mean
it
might
be
really
good
to
just
kind
of
like
have
just
a
you
know,
step
back
and
I
don't
know
maybe
put
it
on
the
agenda
for
the
meeting
we
have
a
meeting
on
thursday.
I
don't
even
know
when
the
meetings
are
anymore
like
just
have
like
a
little
like,
let's,
let's
actually
specify
exactly
the
minimal
scope
that
we
think
we
need
to
have
for
the
first
release
and
get
everyone
to
agree
to
that,
because
I
feel
like
I
feel
like
we
don't
have
agreement
on
that
right
now,
like.
B
E
Obviously,
josh
certh
is
not
in
agreement
with
that.
If
he
wants
to
remove
the
measurement
processor
right,
so
I
don't,
I
don't
think
we
if
it
may
be
in
the
otep,
but
it
doesn't
feel
like
the
current
people
working
on
the
project
necessarily
all
agree
with
what
our
minimal
the
actual
minimal
scope
for
the
first
release
is
going
to.
B
Be
we
we
do
have
the
debate
here
is
better
whether
we
should
do
that
in
the
measurement
processor,
or
we
should
do
that
in
the
static
declarative
way
in
the
view,
or
we
allow
the
view
to
take
some
callback,
then
people
can
put
whatever
code,
but
the
scope,
at
least
from
my
understanding.
I
I
think
at
that
time,
like
the
two
dodgers
and
many
other
folks.
They
spent
time
on
the
on
the
old
tab.
So
I
can
see
a
good
alignment
there.
Nobody
questions.
Should
we
just
remove
one
scenario.
E
B
E
I
I
maybe
there's
broader
agreement
than
I
think,
but
it
feels
like
a
lot
of
these
things
like
everyone
is
trying
to
get
their
favorite
feature
into
the
spec,
to
make
sure
it's
in
there,
rather
than
everyone
agreeing
that
these
are
the
and
features
that
we're
we
have
to
release
before.
We
can
call
1.0.
E
B
E
So
hey
rather
one
one!
Second
before
you
leave,
I
just
have
one
more
one
more
comment.
I
think
you,
you
asked
a
question.
My
brain
didn't
have
time
to
process
it.
I
would
prefer
for
all
of
these
things
to
not
build
declarative.
If
we
can
build
programmatic
implementations
of
things
and
then
we
can
build
the
declarative
things
on
top
of
that
afterward.
E
So
if
we
keep
the
expensive
extensibility
purely
programmatic,
like
you
have
to
write
a
measurement
processor,
you
have
to
write
a
some
sort
of
something
you
have
to
write
some
code
to
do
it
rather
than
having
some
sort
of
expression
language
that
we
build.
I
would
prefer
to
do
that
first
and
then
build
the
declarative
part
on
top
of
it
later.
That
would
be
my
general.
I
think.
B
I
see
so
I
have
different
opinion.
What
I'm
I'm
thinking
is
from
the
implementation
detail
part.
I
think
that
should
be
the
design
like
anything.
B
A
configurable
static
should
be
actually
backed
by
a
complete
logic,
but
from
the
design
perspective
I
I
guess
we
probably
want
to
first
expose
some
limited
functionality
like
you
can
only
do
this
and
that
by
a
static
rule-
and
this
also
makes
the
consumption
easier,
because
people
can
use
something
like
environment
variable
or
configuration
file
and
later,
if
we
see
more
need,
we
can.
We
can,
because
at
that
time
you
already
have
some
internal
implementation
which
allow
which
allows
the
callback.
Then
it's
just
a
decision,
whether
you
want
to
open
the
floodgate
or
not.
E
Yeah,
I
think
my
I
think
my
concern
is
that
if
you
specify
things
in
some
sort
of
text
string,
stringly
format
that
can
go
in
a
config
file
or
environment
variable,
you
are
you're
gonna,
you're
gonna
end
up
we're
gonna
end
up
in
the
same
situation.
We
are
right
now
with
tracing
with
like
17
17
or
18
different
environment
variables,
rather
than
a
consistent
structure.
E
This
is
why
I
like
a
year
and
a
half
ago,
I
put
in
a
pr
to
the
specification
that
requires
everything
being
programmatically
accessible
and
having
environment-based
stuff,
be
a
secondary,
a
secondary
concern,
but
that
there
is
a
requirement
in
this
fact
that
everything
must
be
configurable
via
code
yeah,
and
then
additional
things
can
be
built
on
that.
So
this
is
where
this
is.