►
From YouTube: 2020-11-11 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
So
I
don't
think
you're
getting
any
negative
feedback
on
that
pr
for
the
configuring
aggregations.
B
True,
I'm
getting
very
little
feedback
period.
I,
but
I
need
to
okay
to
me,
yeah.
I
think
today,
I'm
gonna
write
unit
tests
for
it,
so
we
can
get
it
merged
cool.
I
mean
I
think,
bullet
point
two
in
the
agenda
is
not
unrelated
to
that,
but
I'd
rather
get
something
that
is
functional.
Now,
while
we
decide
what
we're
gonna
do
for
the
long
term,.
A
B
A
B
B
Well,
multi,
multi
exporter,
metrics
right
now
doesn't
really
work
at
all.
So
I'm
less
concerned
about
the
fact
that
that
that
we
don't
have
a
way
for
conflicting
views.
I
mean,
I
think
this
is
one
of
the
things
that,
as
the
actual
sdk
spec
evolves.
It
needs
to
support
that
mode,
and
I
would
you
know
for
from
bullet
point
two.
B
The
spec
it's
back
so
initially
I
didn't,
because
I
didn't
understand
it
and
I
well.
I
guess
we're
I
guess,
there's
enough
people,
the
three
of
us
can
talk
so
as
a
way
to
address
the
you
know
that
issue
that
I
think
we
need
to
redo
a
rewrite.
B
I
started
actually
doing
a
clean
room
implementation
based
on
the
spec,
and
it's
when
I,
when
I
put
aside
what
I
know
about
our
current
implementation
and
just
work
from
the
spec,
it's
much
easier
to
understand
and
the
spec
makes
a
lot
of
sense
and
I'm
also
getting
to
vet
the
spec
and
find
all
the
holes
in
it.
Because
I'm
like
oh
I'm,
trying
to
implement
this.
It
doesn't
tell
me
what
I'm
supposed
to
do
here
and
it
doesn't
make
any
sense
yeah.
B
B
B
Well,
they
show
up
sporadically,
I
mean,
I
think,
the
reason
why
we
moved
the
meeting
to
9
30
was
there
was
a
technical
committee
meeting
that
collided.
B
So
I
don't
know
yeah,
I
don't
know
well,
I
guess,
since
it's
maybe
just
the
three
of
us
today
and
nikita
didn't
even
put
his
name
in
so
it
looks
like
just
two
of
us:
yeah
ga
burn
down.
We've
got
nine
p1p2
issues
left,
which
is
down
from
three
last
week.
There
are
seven
in
progress,
though,
which
is
up
a
few
from
last
week,
but
that's
good
means.
People
are
working
on
stuff
and
five
more
have
been
completed,
so
that's
definitely
heading
in
the
right
direction.
B
Yeah
then
I
wanted
to
talk
about
the
metrics
stay.
The
metrics
sdk
I
was
hoping
carlos
and
or
bogdan
would
be
here
to
have
that
discussion.
B
I
know
that
carlos
has
started
looking
at
metrics
from
the
lightstep
perspective,
so
having
his
thoughts
on
that
would
be
super
valuable
yeah.
I
mean,
I
think
this.
This
question
here
is
the
big
one
right.
Would
we
want
to
go
ga
with
something
that
doesn't
look
like
the
current
sdk
spec,
and
I
think
that
if
we
tried
to,
there
would
be
a
lot
of
pushback
from
other
languages
and
other
like
in
the
specs
and
hopefully
from
the
tc.
B
So
my
gut,
but
I
would
like
tc
members
like,
for
example,
carlos
and
bogdan,
to
weigh
in
especially
since
bogdan
essentially
wrote
the
initial
implementation.
Hey,
there's
carlos,
showing
up.
B
B
I
think
the
spec
is
easier
to
understand
than
our
current
and
the
design
is
easier
to
understand
than
the
current
implementation,
and
I
think
the
big
question
is:
would
we
want
to
go
ga
with
something
that
doesn't
look
like
the
current
spec?
That
essentially,
is
a
completely
different
sdk
implementation
than
what
is
specified.
C
So
I'm
fine
with
the
way
it
works.
Now,
probably
we
should
try
to
rename
some
things
that
make
things
look
a
little
bit
similar
to
what
josh
wrote
but
yeah.
I
would
be
fine
with
keeping
things
the
way
they
are
now.
B
C
If
I
understood
correctly
it
and
and
correct
me,
if
I'm
wrong,
the
idea
is
to
add
stuff
like
views
and
more
exporters,
and
you
know
all
of
these
kind
of
features
this
is
coming
after
ga,
and
that
was
my
understanding.
No,
I
don't
think
so
not
from
what.
B
Josh
said
metric
sig
interesting
this
this
last
week
he
was
pretty
emphatic
that
we
would
need
to
have
at
least
support
both
push
and
pull
export
in
the
same
sdk
for
ga
there
was
an
issue
logged
in
the
specs.
I
think
about
that.
Within
the
past
few
days,.
D
A
big
potential
user,
I
think
it's
like-
would
be
good
to
try
and
match
things
up,
because
it'd
be
hard-pressed
to
sort
of
try
and
test
things
out
and
implement
something,
and
then
knowing
that
it
might
change
drastically
and
it
would
basically
be
sort
of
if
you're
changing
it
drastically.
It
would
be
sort
of
releasing
a
2.0
version.
I
guess
as
well
right.
D
B
B
So
please,
if
you
have
opinions,
weigh
in
on
the
the
issue
that
I
submitted
about
this.
B
Yeah,
but
I
mean
this
is
this,
I
think,
is
why
I'd
like
really
like
the
tc
to
weigh
in
I
mean
my
opinion
is
I
I
mean
my
personally.
I
have
a
really
hard
time
understanding
how
to
map
our
current
sdk
to
what's
specified
and
figure
out,
whether
we're
in
compliance
or
not,
because
just
things
don't
look
the
same
so
have
a
maintainer
have
a
really
hard
time,
knowing
whether
we're
ready
to
ga
or
not.
B
C
Totally
I
had
the
same.
I
was
trying
to
find
a
box
trying
to
find
a
box
that
was
hard
to
find
because
I
read
the
specification
and
the
java
code
was
different.
Yeah
it's
like,
but
do
you
think
that
there
will
be
like
a
side
effect
of
these
like
like
metrics
metrics?
Ga
would
have
to
to
happen
later
or
what's
you
is
there
any
specific
fear?
You
have
john
when
it
comes
to
rewriting
ourselves,
but
it's
gonna
take
time
for
sure
right.
B
I
think
the
I
mean,
so
my
opinion
is
that
I
don't
still
don't
know
what
a
timeline
is
for
metrics
ga
nobody
has
done
any
work
specification
work
on
views,
yet
no
one
has
done
any
specification
work
on
multi-export,
yet
josh
is
not
even
done.
Writing
the
sdk
spec,
like
there's
large,
there's
large
chunks
of
it
that
have
yet
to
be
written.
B
So
I
don't
know
what
the
timeline
is
and,
honestly,
if
we
implement
as
josh,
fills
in
the
spec,
I
think
timeline
wise
it's
much
easier
to
work
from
the
spec
than
it
is
to
kind
of
invent
it
from
the
beginning.
Yes,
yeah
and
there's
a
whole
bunch
of
stuff
that
can
be
reused
from
the
current
sdk
implementation
like
it's
not
complete,
throwaway,
but
structurally
it's
a
complete.
B
I
mean
you
have
to
tear
everything
apart
and
put
it
back
together
again,
and
I
think
we
could
definitely
do
things
like
preserving
the
current
exporter
interface
that
would
need
to
change.
Metric
data
could
stay
exactly
the
same.
Like
there's
a
whole
ton
of
stuff
that
wouldn't
have
to
change.
It
would
just
be
those
kind
of
that
internal
processing
pipeline.
B
Well,
I
don't
so,
I'm
not
even
sure
how
we
would
update
the
code
to
match
the
specification,
it's
just
structurally,
so
different
that
I
mean,
I
think
it
needs
a
ground-up
rewrite
pulling
in
pieces
as
we
go
and
there's
no
reason
like.
So
what
I'm
doing,
what
I
have,
the
pr
that
I've
been
working
on
or
the
branch
I've
been
working
on
is.
I
have
a
just
added
a
new
module
that
is
re-implementing
the
sdk
keeping
the
old
one
in
place,
fully
functional
and
working
as
I
go.
C
B
Yeah
yeah
continue,
please
I'll
just
say,
and
the
fallback
would
be
if
we
can't
get
it
done
and
we
need
to
release
something
we
have
something
that
works
so
yeah.
I
like
that
plan
yeah
anyway,
so
I've
I
mean
I've
basically
worked
on
it
for
two
days
and
I've
got
something
that
works
end
to
end
for
a
single
metric
single
instrument,
type
everything
else
coded.
C
Yeah,
okay,
great
okay,
good
good,
good,
good
thing
that
you're
telling
me
this.
I
will
talk
to
josh
and
let
you
see
see
what
are
the
ramifications
of
this
yeah
yeah
that'd
be
great
yeah,
yeah,
okay,
yeah,
perfect!
That's
task
with
me!
Please.
B
Excellent,
all
right,
yeah
and
if
people
have
opinions,
please
comment
on
the
issue
that
I
logged
about
this
all
right.
Next
agenda
item
from
me:
yeah,
so
we're
going
to
two
week
releases,
which
means
we
have
a
release
next
week,
which
is
good,
but
I
also
since
we're
trying
to
get
to
a
much
a
stabler
api.
I
think
everyone
wants
a
stable
api.
B
I
was
wondering
if
we
could
consider
actually
starting
to
deprecate
methods
before
removing
them.
So
essentially
we
could
like
deprecate
method
if
we
need
to
do
breaking
changes,
deprecate
the
methods
in
one
release
and
then
remove
him
in
the
next.
B
So
for
as
an
example
last
night
on
the
late
night
call,
we
were
talking
about
potentially
getting
rid
of
the
get
the
get
global
methods
and
we
could
consider
deprecating
them,
keeping
them
there
for
a
release
or
two
providing
the
the
new
methods
and
then
deleting
them
after
a
release
or
two
as
a
more
friendly
like
a
more
end
user
friendly
experience,
rather
than
just
everything
being
broken.
E
C
B
B
All
right,
well,
I
put
in
up
here
I
just
put
in
a
pr
to
do
some
cleanup
that
involved
one
breaking
change
in
the
sdk
and
I'd
use
this
strategy.
So
it's
a
good
chance
to
try
it
out.
B
It
was
just
a
a
leftover
method,
name
that
hadn't
gotten
cleaned
up
from
some
spec
changes
a
month
ago,
so
cool.
Well,
let's
try
it
out
and
see
what
happens,
and
I
will
let
honorard
know
tomorrow
afternoon
when
we
meet
that
this
is
the
plan
we're
going
to
go
with,
or
maybe
I'll
just
put
in
a
maybe
I'll
put
in.
B
Cool
and
then
my
last
agenda
item
is
just
a
general
reminder
for
people
who
are
on
the
approver
list.
Please
watch
the
repository
and
provide
some
reviews.
There's.
Definitely
some
there's
there's
some
stale
pr's
that
could
use
some
additional
eye.
Eyeballs,
so
it'll
be
great.
B
Cool
there's
not
I
mean
there's
just
I
think,
there's
some
things
that
are
just
languishing
a
little
bit,
so
nothing,
that's
nothing,
that's
terrible,
but
like
to
get.
We
have
a
lot
of
open
pr's
right
now.
I
think
we
have
like
23
open
pr's,
so
it'd
be
good
to
get
some
of
that
stuff
finalized.
B
D
D
But
I
ran
into
an
issue
and
had
it
been
five
years
ago,
I
probably
started
investigating
why
it
happens,
but
the
jvm
basically
crashes,
and
if
I
take
my
code
and
lift
it
outside,
and
I
run
it
in
a
separate
gradle
project.
I
can
build
it
fine
and
I
can
run
the
test,
but
when
I
run
a
test
within
sort
of
the
open
telemetry
project,
sometimes
the
test
fails.
D
Sometimes
the
jvm
sort
of
completely
crashes,
and
I
wonder
if
it's
sort
of
we
might
do
some
sort
of
bytecode
manipulation
and
since
we're
compiling
with
11
and
run
like
we're
using
11
but
we're
compiling
to
eight
and
I'm
writing
the
code
for
eleven.
So
I
should
do
some
change
there,
so
it
feels
like
there's
some
combination
of
stuff.
That
is
happening.
I
don't
know
if
anyone
has
hit
some
similar
issues
with
compiling
stuff,
and
is
this
using
the
agent.
D
It's
the
sort
of
the
pr
I
did
for
the
j4
stuff
in
so
it's
purely
instead
of
building
the
whole
sdk
or
this
is
like
even
just
building
my
part
of
the
sdk.
It
starts
crashing
running
the
tests.
I
was
trying
to
figure
out
sort
of
what,
because
there
were
so
many
changes,
and
I
never.
I
haven't,
used
this
sort
of
this-
the
tool
chain
stuff
for
the
jdk
before,
but
then
there's
we
have
the.
D
I
guess,
you're
running
error
prone
and
a
bunch
of
other
things
for
tests
that
are
doing
bytecode
manipulation
and
it
seems
like
some
of
those
things
together
with
j4-
is
sort
of
colliding
a
little
bit.
So
it
seems
to
be
happening
is
they
might
be
doing
bytecode
manipulation
on
the
jfr
class,
which
in
turn
causes
sort
of
the
jvm
to
fail
to
load
himself?
We
might
just
hit
the
jvm
bike
basically,
and,
as
I
had
been
10
years
ago,
I
would
like,
when
I
was
working
on
the
jvm.
D
B
We
you
know,
we
have
seen
some
we
have
seen
I'd,
say
a
fairly
significant
number
of
seg
faults
in
our
build
in
our
ci
builds
completely
independent.
Nothing
to
do
with
your
pr,
just
in
regular,
like
builds
on
them
on
the
main
branch
we
haven't,
I
haven't
had
a
chance
to
investigate,
what's
causing
them
or
what's
going
on,
so
I
I
guess
it's
possible.
That's
related.
D
Yeah,
it
might
be
sort
of
just
same
issue,
different
code
path,
just
hitting
it
basically.
B
It's
certainly
not
consistent
exactly
like,
maybe
one
build
and
I've
never
seen
it
locally.
It's
only
failing
on
ubuntu,
which
is
also
interesting.
I
haven't
seen
any
failures,
like
any
seg
faults
on
mac
os
yeah.
D
B
B
Yeah
and
that
jfr
stuff
is
really
interesting.
Stefan,
I
actually
would
really
like
the.
I
would
love
it
if
there
was
was
a
standard
bridge
from
jfr
to
open
telemetry,
so
a
little
bit
the
opposite
of
what
I
think,
you're
building
right.
B
A
way
to
expose
jfr,
metrics
and
events
as
open,
telemetry,
api
events
or
things.
D
Yeah,
no
it's
one
of
those
tricky
parts
like
yes,
you
have
the
api,
so
in
theory
you
can
just
do
it
in
the
agent
and
sort
of
start
listening
to
things
and
extract
data
from
it.
But
the
overhead
of
that
like
unless
yours
are
very
strictly
filtering
and
sort
of
making
sure
you're
only
looking
at
exactly
what
you
need
and,
depending
on
what
the
j4
like
what
is
running
in
gfrsd
over
it's
going
to
be
pretty,
can
be
pretty
massive.
A
D
A
B
D
And
I
think
some
of
those
are
fairly
okay,
the
biggest
cost,
I
think
will
come
when
you
start
sort
of
okay.
I
want
to
stack
trace
for
this,
or
I
want
to
do
the
profiling,
because
those
are
very
compressed.
The
the
way
it's
done
on
the
back
end
is
basically
okay,
here
the
by
or
here's
the
memory
addresses
of
from
the
stack
trace,
let's
shove,
those
in
into
the
jfr
stuff
and
then
the
way
it
works.
D
So
if
you
were
to
build
a
stack
trace
out
in
java,
you
were
actually
sort
of
build
all
the
strings
and
all
the
names
and
whatnot,
because
you
can't
really
use
you
could
rely
on
memory
addresses
and
that
that
will
explode
things,
but
but
some
other
things,
which
is,
of
course,
how
many
exceptions
do
I
throw
have
I
thrown
so
far,
and
we
have
a
counter
for
that.
That
should
be
sort
of
fairly
straightforward
to.
D
One
of
my
favorite
events
allocation
events
where,
where
did
it
come
from
and
what
not
there
might
be
tricks
we
could
figure
out.
I
don't
know
where
the
reconstitution
of
the
the
stack
trace
is.
If
you
could
sort
of
you
do
it
once
and
then
you
ask
give
me
a
hash
for
it,
and
then
you
sort
of
keep
things
in
memory
a
little
bit
and
try
to
avoid
to
recreate
it
and
in
certain
cases
or
you
ignore
the
stack
phrase
and
just
focus
on
like
here's.
B
B
I
would
love
that
that
would
be
amazing,
make
it
make
it
so.
B
D
Exactly
nobody,
but
it
might
even
be
sort
of
instead
of
doing
it,
sort
of
listening
in
java
and
extracting
that
they
have
an
open
source
telemetry
built
into
the
jvm.
They
can
say:
okay,
here's
sort
of
the
so
the
way,
the
way
that
the
events
are
sort
of
captured
is
also
each
thread
has
its
local
buffer.
Basically,
where
all
the
event
goes
in
once
that
buffer
fills
up,
you
send
it
into
more
of
a
global
management
stuff
where
it
goes
into
the
global
buffer.
D
So
you
could
have
a
thread
handling
that
do
open
to
telemetry
events
in
the
jvm
itself,
basically
and
sort
of
tie
it
in
that
way,
rather
than
sort
of
patching
it
on
on
the
outside,
for
example,
and
then
that
could
yeah
and
provided
how
we
sort
of
push
information.
D
Well,
maybe
we'll
have
a
protobuf
for
a
stack,
trace
and
and
figure
out
how
those
can
be
cached,
and
you
send
stack
traces
once
in
a
while,
and
then
you
send
sort
of
just
a
binary
pointer
to
that
stack,
trace
that
that
sort
of
the
update
was
yeah.
D
Yeah
interesting,
the
cool
part
with
just
having
the
spans
you
we
will
be
getting
with
this
plugin
is
what
mission
control
can
do
is
what
you
do
is
you
can
so
say.
Okay,
here
are
the
events
that
I'm
interested
in
for
spans.
I'm
like
filter
out
the
one
with
this
trace
id,
and
then
you
can
mark
sort
of
select
all
of
those
and
then
you
can
basically
say
get
me
all
the
events
that
happens
at
the
same
time
in
the
same
threads.
D
So
we
can
work
that
way.
Sort
of
we'll
have
to
figure
out
to
improve
the
ui
a
little
bit,
but
you
can
work
that
way
to
see
if
so,
okay,
these
cell
vacation
events
happen
during
the
spans
because
they
happen
in
the
threads,
where
the
context
was
active,
basically
and
stuff
like
that.
So
some
of
these
things
can
be
reconstituted
after
the
fact,
and
you
can
sort
of
rely
on
like
potentially
rely
on
okay,
when
we
have
an
alert
happening,
get
the
sort
of
the
current
running
jfr,
for
example,
and
and.
D
B
D
Yeah
the
benefit
you
have
is
there.
There
is
a
parser
in
the
jdk
itself
for
the
jfr
files,
but
you
have
a
faster
one
in
in
mission
control
itself.
I
actually
played
around.
I
don't
know
if
I
have
a
source
code
for
it,
I
played
around
a
little
bit
and
then
wrote
the
basic
parser
in
javascript
and
could
parse
it
sort
of
tried
parsing
them
in
the
browser
a
little
bit
to
see
it
works
and
it
works.
Okay
until
you
try
to
open
a
very
large
file
and
your
browser
starts
starts
melting
yeah.
C
Carlos
yeah,
I
don't
have
a
last
item
kind
of
boring
stuff,
but
you
know
trying
to
make
the
life
of
our
users
easier.
So
I
realized
that
people
like
marching
and
probably
other
users
are
they
are
trying
to
keep
up
to
date
with
us.
So
that's
why
they're
using
the
snapshots.
C
So
that
means
that
whenever
they
know
we
are
going
to
do
a
release,
they
are
you
know,
trying
to
make
it
as
fast
as
possible
as
well
right
so
probably
to
try
to
make
their
life
easier.
We
could
try.
I
don't
know
what
you
guys
think
to
try
to
avoid
any
breaking
changes
as
kind
of
policy
like
two
or
three
days,
three,
two
or
three
days
before
the
actual
release.
I
don't
know
if
that
sounds
or
like
overthinking
or
what,
but
I
would
like
to
get
your
opinions
on
that.
B
Yeah
this
is
this
is
the
other
alternative
to
my
proposal.
I
think
for
like
introducing
deprecation,
because
that
if
we
introduced
applications,
then
they
literally
have
at
least
two
weeks
to
see
that
things
are
gonna
break.
C
B
J
yeah-
I'm
not-
I
am
not
opposed
to
this-
seems
fine
to
me
I'm
and
I'm
really
hoping
that
the
number
of
breaking
changes
in
the
especially
in
the
api
is
going
to
be
radically
smaller.
In
the
you
know,
0.10
was
a
gigantic
upgrade
to
java
8
api
friendly
java
8
api's
friendly
java
8
friendly
apis.
That's
what
I'm
trying.
E
B
Okay,
it's
just
the
hope,
but
I
am
I'm
on.
I
I'm
fine
with
that.
C
Okay,
so
let
me
have,
I
have
a
pr
to
cook
against
not
related
to
not
merging
prs
with
weekends
like
breaking
changes,
stuff
or
things
that
are
not
simple,
and
I
will
have
this
pr.
Also
to
add
a
note
there
like,
please
consider
releasing
like
make
sure
that
there
were
no
breaking
changes
for
the
last
two
or
three
days
prior
to
releasing
something
like
like
small
note,
and
then
we
will
see
how
it
goes.
B
Yeah
so
yeah
putting
that
in
the
releasing
document
would
be
excellent
and
maybe
putting
it
in
the
we
have
the
is
it
like
the
contributing
doc,
where
we
have
kind
of
our
guiding
principles
that
might
be.
I
was
thinking
about
putting
in
this
deprecation
stuff
as
well.
B
Cool
all
right,
yeah
I've
been
favorite
yeah.
I
put
in
that
pr
I'll.
Take
a
look
perfect
thanks
so
much.
I
will
cook
the
pr
later
today
excellent
and
I
will
make
sure
honor
or
tag
on
our
god
also
also,
so
we
can
provide
his
opinions
cool
anything
else.
Anyone
wants
to
talk
about
nikita.
Do
you
have
any
burning
items.
B
B
All
right
well
excellent,
tell
my
boss.
I
will
who's
that
still
steve.
Yes,
absolutely
cool
all
right!
Well,
if
nobody
has
any
other
agenda
items
or
anything
to
talk
about
give
yourselves
a
few
minutes
of
your
lives
back
yeah
back
to
work.
I
have
a
lot
of
stuff
to
catch
up
on,
so
I
have
a
lot
of
metrics
code
to
keep
writing
so
I
mean
I
may
just
put
in
that
pr
just
to
show
the
state
of
things
I
like
that
yeah
or,
if
you're
interested
in
carlos.