►
From YouTube: 2022-01-24 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).
B
B
Nikita's
utc
plus
two,
I
think
I'm
utc,
plus
one
that's
one:
okay
and
I'm
honestly
not
sure
what
oh.
What's
the
name
of
the
time
zone,
it's,
whether
it's
eastern,
european
or
central
european,
no
idea,
but
it's
yeah,
utc
that
one.
C
C
Cool-
I
I
just
put
this
the
spec
pr
from
jack
to
look
over
and
try
to
get
some
reviews
approvals
see
if
we
want
to
go
ahead
and
merge
that
and
move
on
to
some
another
one
anything
that
ben
anything
you
wanted
to
particularly
review
today.
D
I
mean
there's,
I've
got
a
pr,
that's
outstanding
for
the
contrib,
but
I
think
it's
been
approved
by
several
people.
It
probably
just
can
be
merged.
C
C
It
looks
like
this
one
got
hidden,
I
don't
know
if
you
caught
that,
then.
D
C
I
patented
think
it
does
pub
unused
public
because
it,
I
think
it
scopes
to
the
file.
C
C
Am
I
not
getting
the
pretty
diff,
let's
try
there,
we
go.
E
Sure
so
so,
there's
four
different
metrics
that
I
propose
for
to
represent
memory.
There's
usage
init
committed
in
max,
and
I
don't
have
a
strong
preference
of
whether
we
need
all
of
those
or
just
like
a
subset
of
those
definitely
usage,
and
you
know
committed
and
in
max
are
good.
E
Init
is
probably
useful
to
some
people,
but
I
included
that
mostly
because
that
information
is
available
from
jmx,
not
necessarily
because
I
have
a
strong
belief
that
it's
necessary
or
use
case
for
it,
and
so
the
reason
I
broke
these
out
into
separate
metrics
instead
of
having
init
committed
max
and
usage
as
attributes
on
a
single
message.
E
A
single
metric
is
because
the
asynchronous
up
down
counters
are
the
are
supposed
to
be
aggregable
across
spatial
dimensions,
and
so
what
that
means
is
that,
like,
if
you
were
to
take
out
any
attributes
like
filter
out
any
attributes,
the
values
should
still
be
semantically
meaningful.
E
And
so,
if
you
were
to
combine
init
committed
in
max,
for
example,
and
you
were
to
filter
out
the
attribute
that
indicated
whether
this
particular
stream
was
init
committed
or
max,
then
you'd
get
all
of
a
sudden.
Like
the
sum
of
them
to
the
sum
of
init
committed
in
max
and
that
wouldn't
make
any
sense
and
so
yeah
that's
why
you
separate
those
out
as
different
metrics
as
opposed
to
having
those
be
an
attribute
and
then
the
other
things
that
are
interesting
to
talk
about,
I
suppose,
are
the
the
dimensions
that
I
included.
E
So
there's
a
type
and
a
pool
type
is
just
a
categorization
of
heap
or
non-heap.
That's
an
attribute.
That's
availa!
That's
a
there's,
a
method
on
the
the
memory
pool
beam
that
you
get
from
jmx.
That
indicates
whether
the
pool
is
a
part
of
heap
or
not
heap,
and
then
the
pool
name
itself
is
another
field.
A
E
F
Some
other,
like
less
common
values
like
the
compressed
class
space
and
code
cache
and
so
on,
but
I
don't
really
remember
any
any
value
here
for
any
jvm.
I
checked
that
would
be
like
very,
very
wide
so
that
we
need
to
normalize.
I
believe
like
keeping
them
as
is,
is
a
good
like
first
first
approach.
D
D
E
So,
unless
we
explicitly
configure
like
a
new,
an
enumeration
of
possible
values
for
pool
names,
then
back
ends
will
have
to
be
able
to
accommodate,
like
a
variety
of
values
in
there.
They
basically
they'll,
be
they'll,
have
to
design
around
the
fact
that
the
the
list
is
unknown
to
some
extent
and
have
behavior.
That
reflects
that.
E
So,
like
one
thing
that
you
could
do,
is
you
could,
for
example,
a
back
end?
Could
fetch
all
the
different
pool
names
that
were
present
down
the
data
and
display
a
panel
for
each
and
you
know,
take
the
name
of
each
pool
and
use
that
as
the
name
of
each
panel.
So
you
could
say
like
like
g1
old
gen
as
a
function
of
time
and
so
on
and
so
forth,
and
you
might
be
able
to
display
the
you
know
on
one
single
panel
for
g1
old
gen,
for
example,
you
could
display.
E
You
know
the
init,
the
use
the
committed
and
the
max
on
one
panel.
D
I
mean
do
we
want
to
do
that
or
do
we
want
to
actually
do
something
where
okay,
we
have
a
general
very
specific
tag,
name
like
g1,
even
for
example,
but
then
we
also
do
have
an
enumerated
list
of
of
pools
that
we
try
to
map
to
so
just
something
like
youngjan
or
eden,
and
that
the
the
implementation
figures
out,
which
pool
to
map
into
the
into
the
the
canonical
list
of
enumerated
full
types,
because
then
that
way,
the
back
ends
don't
have
to
do
anything
special.
D
D
That's
that's
asking
you
know
users
to
to
to
bring
quite
a
bit
of
java
knowledge
to
the
table
in
order
to
make
sense
of
it,
and
if,
if
there
is
a
way
I
I
would
like
us
to
be
able
to
to
just
have
it
plug
in
and
work
get
some
data
which
actually
is
meaningful.
I.
E
I
don't
mind
the
mapping
idea,
but
you
know
for
someone
who
doesn't
know
a
lot
about
java.
You
can
still
say
what
is
the
total
heap
usage?
What
is
the
total
non-heap
usage
and
that's
like
kind
of
a
higher
order
view
or
like
you
know,
because
these
are
aggregateable
across
the
dimensions.
You
could
say
you
know.
What's
the
overall
memory
usage
of
heap
and
non-heap
by
just
like
you
know,
summing
up
all
of
the
all
of
the
dimensions
and.
F
F
So
basically,
they
have
just
like
on
the
ui
like
two
dashboards,
one
for
heap,
one
for
non-heap
and
showing
the
initial
committed
min
max,
and
basically
that's
all
if
you
need
to
take
dig
down
and-
and
you
will
need
like
to
look
into
the
the
the
other
areas
like
I
don't
know
like
eden
or
the
survivor
space
or
or
or
whatever
you
will
need
the
java
knowledge
in
order
to,
in
order
to
be
able
to
read
that
that
dashboard,
and
also,
if
you
want
to
like,
provide
some
functionality
for,
like
I
don't
know
like
yangchen
and
origen.
F
I
believe
that
will
be
pretty
hard
because,
like
there
are
like
you,
you
need
to
take
consideration
into
like
a
lot
of
jvm
implementations,
what
they
are
doing
and
a
lot
of
like
jc's
and
how
they
like
organize
the
the
memory
and
also
there
are
implementations
which
are
like
non-generational
like
there
is
no
old
channel,
and
there
is
no
young
gen.
There
is
simply
not
not
an
existing
thing
and
also
there
are
jvms,
which
are
like
only
commercially
available
like
do.
You
want
to
support
that.
D
As
well,
I
I
don't
see
how
we
can
realistically
support
proprietary
jvms,
I
mean
the
the
main
one
here
would
be
azul
zing
if
they
wanna,
if
they
wanna
supply
an
implementation
and
and
and
tell
us
how
to
hook
it
up.
I'm
sure
the
result
can
can
write
a
bit
of
code
to
do
that,
but
that
that
also
you
know
it
raises
another
point
which
is:
should
we
be
specifying
exactly
what
we
support?
D
D
We
support
java
8
on
hotspot
on
j9,
you
know
and
we
here's
the
list
of
collectors
we
support
and
in
that,
in
that
case,
okay,
it's
more
complicated
and
we're
doing
more
work
down
in
the
individual
handlers
and
the
individual
in
the
code
to
produce
that
mapping
table,
but
you
know
is
that
is
that
worth
it
for
the
simplicity
of
user
experience
that
we
can
we
can
provide?
E
So
what
would
the
common
combinations
of
things
that
we
would
have
to
support
then
be
the
set
of
jvms
that
we
want
to
support
and
as
one
dimension
and
then
also
the
different
types
of
gcs,
that
we
want
to
support
as
the
as
an
as
the
other
dimension?
And
so
like?
Let's
say
we
want
to
support
five
different,
jvms
and
and
and
three
different
jc
gcs
is
15
combinations
that
we
have
to
be
aware
of.
D
Well,
bear
in
mind,
of
course,
the
the
gc
algorithms
are
not
generally
portable
across
across
jvm
implementations
right,
so
there's,
no
there's
no
equivalent
of
g1
or
parallel
for
for
j9
j9
has
its
own
set
of
vm
of
gcl.
Available
unit
has
balanced
and
whatever
the
other
one's
called.
So
what
we
actually
need
to
support.
So
in
the
hotspot
space
we
would
support
parallel.
D
Serial
serial
is
important
because
that's
what
you
get
by
default
in
a
single
core
container,
zgc
and
shenandoah
g1
parallel
cereal
surgery
shenandoah.
So
there
are
five
collectors
from
hotspot
that
we
need
to
support.
Cereal
has
got
basically
no
information
in
it,
so
which
is
actually
a
problem.
This
is
something
I've
discussed
internally
at
red
hat.
This
is
whether
we
actually
want
to
to
try
to
get
some
additional
event
types
in
for
cereal,
because
it's
actually
still
surprisingly
widely
used
and
then
for
j9.
D
Yes,
good
point:
cms's
is
gone
for
17,
so
we
wouldn't
support
that
from
the
jfr
implementation,
but
would
need
to
be
supported
on
the
jmx.
The
jmx
based
implementation
also.
F
Just
like
enough
fi
like
some
like,
as
far
as
I
know,
like
coretto,
which
is
like
a
open
gdk.
Essentially
they
are
working
on
a
generation
of
shenandoah,
so
this
might
be
like
more
than
that.
Eventually,
I.
D
Mean
generational,
shenandoah
is
definitely
a
thing,
that's
being
done.
There
are
folks
at
red
hat
working
on
it.
I
know
there
are
folks
amazon
interested
in
it,
but
it's
all
being
done
in
the
context
of
open
jdk.
So
it
won't
be
like
a
correct
or
everything
it
will
it
will.
It
will
all
go
into
upstream
cool.
C
So,
ben,
what
would
that
look
like?
I
just
wanted
to
capture
that
if
we
did
break
out
an
attribute
like
a
pool
type
that
would
be
young
or
old,
eden
or
old.
C
E
I
mean
you
could
do
it
a
couple
of
different
ways.
You
could
use
these
types
of
dimensions
that
you're,
proposing,
trask
or
or
you
could
just
have
like
a
set
of
pool
names
that
are
kind
of
normalized
that
we
we
map
the
jmx
pool
names
too.
So,
like
an
enumeration
of
I
don't
know,
however
many
values
we
need.
D
I
was
thinking
that
we
would
normalize
some
jack
so
basically
that
we
would
have
a
an
eden
or
a
young
gen
pool
type,
and
that
would
g1
even
would
map
to
that
par.
New
eden
would
map
to
that
in
the
case
of
where
you're
running,
cms
and
so
on
and
so
forth.
So
so
the
the
the
the
normalized
full
name
is
always
there,
but
where
it
sources
its
data
from
varies
from
the
different
collectors.
D
We
have
a
the
the
actual
real
name
of
the
pool
is
always
included
as
well,
okay,
but
we,
we
include
the
pool
type
to
show
how
we've
done
the
translation.
D
E
D
Yes,
but
what
it
means
is
that
that
neither
back
ends
nor
dashboards
have
to
be
aware
of
all
of
the
different
possibilities
for
football
types
so
because
they
can
just
grab
the
pool
type.
E
F
And
I
believe
that
that
would
that
would
be
needed,
like
anyways,
for
example,
if
you
have
like
a
gc
which
is
like
non-generational,
and
you
cannot
really
like
have
like
a
young
and
an
origin
there.
But
you
need
to
provide
the
value
because
there
are
back
ends
which
doesn't
like
if,
if
the,
if
the
time
series
like
have
the
same
name,
but
the
list
of
tags
are
different,.
E
C
So
did
I
get
it
right,
the
it's.
The
proposal
is
just
to
add
a
third
attribute
here,
pool
type
that
is
either
young,
old
or
unknown.
E
I
think,
yes,
I
think
the
name
of
the
attribute
and
the
the
the
values
are
up
for
debate
and
discussion,
but
like
yeah,
directionally,
correct.
B
F
E
C
C
I'd
say
it's
a
mixed
bag
in
the
spec
repo,
but
certainly
that
the
java
ins,
the
java
repos
instrumentation
and
contrib
repos
especially
tend
to
take
the
more
iterative
approach.
Sometimes
the
spec
is
a
little
less
iterative
because
they
want
to
get
more
clarity
on
the
whole
picture
first,
but
I
think
we
have
flexibility
to
do
what,
whichever
we
would
like
in
this
case.
E
I
suppose
one
thing
that's
lacking
in
this
description
and
the
existing
pr
is
whether
the
dimensions
are
optional
or
required.
F
One
more
quick
thing
we
might
need
to
include
for
the
for
the
list
of
cheeses,
substrate
vm.
F
It
has
like
a
different
cheese.
It
is,
it
is
serial,
but
I
have
no
idea
if
it,
its
gc
has
a
a
real
name
and
also
they
have
like
a
g1
implementation,
which
is
only
available
in
the
in
the
enterprise
graph
vm
edition.
D
My
understanding
is
is
that
this,
this
area
is
potentially
under
review
at
the
moment
with
substrate
and
there
may
be
some
changes
coming,
which
I
don't
think
are
fully
decided
upon
and
probably
not
public,
yet
so
good
catch.
Let's
keep
an
eye
on
it.
C
Cool,
so
I
think
I
will
ping
try
to
get.
We
still
need
official
spec
approvers
to
weigh
in
so
I
will
ping
some
folks
and
try
to
get
that
officially
approved.
E
I
know
I
know
that,
for
other
semantic
invention,
like
instrumentation
working
groups,
they've
tried
to
get
approval
rights
given
to
that's
the
specific
area
that
a
sig
is
working
on.
For
example,
like
the
messaging
sig
is
working
on
the
semantic
inventions
for
messaging
systems,
and
I
believe
those
folks
have
been
given
approval
rights
to
that
specific
section
of
the
semantic
inventions.
C
On
this
file,
yeah,
that's
a
great
idea
and
volunteers
ben
is
the
unofficial
official
leader.
Can
I
put
you
down,
try
to
get.
C
E
E
Out
some
sort
of
mechanism
to
assign
specific
groups,
you
know
ownership
over
specific
files
and
directories.
C
C
Okay,
cool
next
steps.
I
know
we
had
started
talking
about
the
cpu
as
metric
as
potential
next
step.
D
D
Which,
basically,
was
was
just
talking
about
wanting
to
use
counters
rather
than
histograms,
so
I
think
that
just
basically
reflects
what
what
jack
was
talking
about.
F
I
I
will
take
a
look
at
it
in
the
next
couple
of
days.
Last
week
I
kind
of
like
lived
in
a
cave
the
whole
week.
I
was
like
very
very
like
distracted
and
focusing
another
thing,
but
this
week
I
should
be
able
to
take
it.
Take
a
look
at
it.
F
Yes,
there
the
reason,
because
the
cpu
metrics
basically
consist
of
two
things:
one
is
the
cp
usage
of
the
jvm
kind
of
like
the
process
and
the
other
one
is
the
system
and,
as
far
as
I
know,
there
is
like
a
a
different
like
file
and
workgroup
for
the
system
level.
Metrics,
so
should
we
should
we
talk
to
them
and
like
decide?
Where
do
we
want
to
put
the
system
level
information
about
the
cpu
usage.
C
E
What's
what's
like
the
the
meaning
of
that
anyways?
Would
that
just
be
the
total
system
cpu
time
across
all
processes
on
the
machine.
D
C
D
E
And
I
guess
the
question
that's
in
my
head
is
like
you
know,
is
that
within
the
the
set
of
responsibilities,
for
you
know
the
jvf,
the
java
instrumentation
to
collect
you
know,
even
if
we
could,
should
we
collect
it
or
should
we?
You
know
if
there's
another
component
in
the
open,
telemetry
ecosystem
collecting
that
same
data
should
we
omit
it.
D
E
C
A
So
just
go
ahead,
nothing.
I
was
just
thinking
now
that
jack
brought
up
the
resource
thing.
I
was
just
thinking
well,
one
resource
should
be
this
service.
It's
like
the
instance
of
the
application
that
you're
monitoring
and,
if
you're,
including
some
host
metrics
like
system
metrics,
wouldn't
that
be
a
different
resource.
Actually,
wouldn't
it
be
correct
to
say
hey.
This
is
this
resource
for
the
app,
and
this
is
the
resource
for
the
system
where
that
app
is
running.
F
So
that
that's
the
that's
the
two
like
topics
we
are
talking
about
cpu,
so
one
is
the
process
metrics,
basically
like
how
many
or
how
much
cpu
the
jvm
is
using
and
the
other
one
is
like
how
much
cpu
or
whole
system
is
using,
and
we
are
basically
like
debating
about
the
this.
F
This,
the
second
one,
the
system
usage,
the
the
jvm
is,
I
believe,
that's
quite
like
straightforward
because,
like
there
is
no
existing
specification
for
that,
and
it
that's
up
upon
us
how
to
how
to
define
it
or
what
do
we
want
to
show,
but
for
the
system.
We
have
this,
this
other
existing
metrics
specification
that
we
can
conflict
with.
If
we
define
something.
F
Also,
maybe
that's
why
I
would
do
you
happen
to
know
like
who
who
owns
that
the
system
metrics,
because
we
might
we
can.
We
can
ask
them
that?
What
is
what
is
their
derivation
for
this?
Where
should
this
be
implemented?
Should
the
the
sdk
or
the
or
the
instrumentation
for
every
language
implement
this,
or
should
this
be
in
like
another
component,
like
a
machine
agent.
C
And
just
to
add
more
complexity,
there
is
a
pr
that
should.
A
C
E
F
So,
based
on
the
feedback
that
we
can
get
back
from
these
process,
metrics
in
the
system,
metrics
group-
maybe
we
are
done
with
this
or
maybe
we
need
to
define
all
of
them
again.
C
So
jack
the
way
I
think
about
this,
I'm
of
the
opinion
that
we
should
keep
our
stuff
within
the
jvm
namespace.
C
It
does,
of
course,
get
fuzzy
when
you
talk
about
stuff
like
process,
cpu,
usage
utilization,
but
the
reason
I
think
that
is
because
we're
kind
of
viewing
it
from
within
right.
We
are
jvm
code
running
in
the
jvm,
we're
gathering
these
things
from
the
vm
itself,
whereas
these
higher
levels,
I
see
those
could
be
observed
by
a
separate
process
or
a
collector
right.
So
that's
like
viewed
from
outside,
I
think
our
stuff
viewed
or
measured
from
within
the
jvm.
We
could.
C
C
What
about
like
take
process,
memory,
usage,
for
example-
I
mean
we
if
we
have
if
we
could
capture
this,
for
example,
in
the
jvm,
but
then
you
know
we
have
this,
but
then
we
also
have
more
details
under
the
jvm
namespace.
E
Yeah,
I
mean
that's,
certainly
certainly
true
for
memory.
We
have
details
that
they're
not
trying
to
capture.
G
Right
I
mean
I
get
what
you're
saying
about
what
we're
observing
from
the
inside
versus
what
generic
or
arbitrary
tools
or
whatever
would
be
looking
at
from
the
outside,
but
I
think
things
in
the
jvm
namespace
should
be
focused
on.
G
E
So
let
me
ask
you
a
question
then.
So,
if,
if
we
were
to
take
that
stance,
does
that
mean
that
even
if
we
have
the
ability
to
collect
information
on
cpu
time
and
cpu
utilization
that
we
don't
because
an
external
process
might
be
collecting
that
already
with
more
detail.
G
E
G
I'm
just
like
I'm
just
saying,
like
that's
the
nuance
right,
if
we're
saying
well,
if,
if
they
are
not
going
to
have
anything
else
turned
on
and
we
can,
we
can
collect
it,
then
yeah
we
should.
Does
that
mean
we
should
use
a
totally
duplicated
namespace.
I
don't
think
so
like
do.
We
need
the
same
metrics
replicated
inside
that
that
doesn't
make
any
sense.
It
doesn't
provide
any
value,
it's
redundant
information.
Why
are
we
doing
that.
F
Also,
this
is
this
is
about
the
like
most
about
this
specification
right
like
where
should
these
like
definitions
live,
it
doesn't
like,
doesn't
tell
you
anything
where
should
this
be
implemented,
if
it
is
like
inside
of
the
jvm
or
like
an
external
process
or
or
whatever?
I
believe
that
will
be
like
case
by
case
on
the
on
the
platform
situation.
F
And
also,
I
believe
this.
This
doesn't
mean
that
we
cannot
like
provide
data
like
outside
of
it.
We
can.
We
can
still
like
define
cpu
related
things
that
that
are,
for
example,
like
jvm
specific,
for
example,
the
what
is
the
name
of
it,
the
available
processor
count.
F
That
is
a
very
interesting
thing,
because
maybe
you
have
like
10
cpus,
but
if
you
are
running
in
a
container,
maybe
you
don't
have
that
many
or
maybe
you
are
using
an
overjvm
which
will
basically
ignore
the
the
docker
settings
and
it
will
use
the
the
host's
like
processor
account,
which
can
be
like
an
interesting
metric
to
check
if
you
are
running
in
containers,
because
the
jv
and
we
resize
a
bunch
of
things
based
on
these,
for
example,
the
cheat
threads,
the
gc
threads
and
also
the
the
common
thread
which
is
used
by
the
fork
showing
pool
and
so
on.
F
E
Do
you
know
who
they
are?
No,
I
can
use
my
sleuthing
skills
to
go
find
out,
though
yeah.
C
Yeah
I
was
wondering
if
they've
chatted,
if
this
has
been
a
topic,
I'm
not
aware
of
any
group-
that's
kind
of
tackled
this
I
know
there's
you
know
some
individuals,
who've
posted
prs
in
the
spec.
C
But
yeah
chuck
and
I
can
try
to
track
that
down.
I
my
my
guess
is
that
we
would
get
pushback
if
we
try
to
have
duplicate.
If
we
don't
try
to
share
the
common
like
process
metrics,
where
possible.
C
F
Have
so
how
about
so?
If,
if
I
like,
review,
what
is
in
there
right
now
and
like
cross
check
it
with
what
we
do
have
like
on
the
jvm
side,
indeed
in
the
spreadsheet,
and
and
reveal
those
things
that
are
conflicting
and
that
we
can
add,
like
only
from
the
jvm
perspective,
I
will
just
collect
them.
It's
not
necessary.
F
I
can
actually
still
file
a
pure
request,
because
I
believe
the
additional
things
they
can
go
into
a
pr
which,
like
are
clearly
not
conflicting,
for
example,
the
available
processor
count.
I
can
still
see
that
that
can
go
there
and
we
can
continue
the
discussion
with
the
with
the
other
groups
about
the
process
system.
Cpu
usage.
E
Yeah,
I
was
going
to
suggest
that
an
additional
pr
might
be
useful
too.
If
for
no
other
reason
than
to
illustrate
the
the
overlaps
and
between
general
versus
jbm
specific.
E
C
C
What
what
do
you
think?
What
do
people
think
the
next
thing,
after
memory
and
cpu,
that
we
should
focus
on
gc.
D
Definitely
you
see,
I,
I
do
have
some
code
that
I've
started
writing
for
this,
but
I
actually
wanted
to
get
some
feedback
on
on
the
branch
first.
D
So
probably,
what
I
might
do
is
put
up
a
draft
pr
which
I'm
not
intending
to
merge
in
its
current
state,
but
just
to
get
some
comments
and
feedback
on
it.
If
people
have
got
some
time
to
take
a
look
at
it,.
C
I
might
have
one,
I
don't
know
how
interesting
it
is
to
the
group
at
large,
but
something
that
we
have
been
kicking
around
a
little
bit
is
where
there
might
be
differences
between
measurements
obtained
from
jfr
and
measurements
obtained
from
jmx.
G
One,
the
other
one
trask
is
I'm
just
gonna
call
you
trash
because
that's
shortest
everybody,
so
joanie-
and
I
were
talking
about
that
issue
that
went
through
with
the
the
micrometer
implementation
down
in
the
instrumentation,
the
job
instrumentation
project
component
repo
right
now
working
because
I
I'd
like
to
make
sure
this
is
the
thing
we're
seeing
in
a
couple
different
places
where
you
have
a
group
of
people
who
are
in
maintainer
mode
at
different
levels
of
maintenance,
so
like
joni's,
looking
at
where
micrometer
is
and
what
the
long-term
supported
versions
are
and
how
that's
supposed
to
work.
G
And
then
at
the
java,
instrumentation
project
level.
People
who
write
instrumentation
agents
are
at
a
fundamentally
different
level
of
what
has
to
be
supported
and
how
it
has
to
work.
But
we're
like
all
in
the
same
working
group.
Am
I
making
sense,
I'm
looking
for
confirmation
of
nodding
from
someone.
So
I
it
it's
like
the
the.
G
I
would
just
like
to
make
sure
that,
as
we're
trying
to
resolve
all
these
concerns,
we
start
to
get
some
kind
of
a
clear
articulation
of
what
is
expected
to
be
supported
and
maintained
for
what
purposes
and
at
what
levels
right.
So
it's
like.
If
I
talk
to
john
watson
and
we
talk
about
instrumentation,
he
talks
about
instrumentation,
almost
filling
the
role
of
here's.
What
you
want
to
do
when
you
don't
have
access
to
the
source
code
or
for
for
various
reasons.
G
G
G
G
Here's
where
we
think
instrumentation
should
happen
and
here's
the
different
layers
we
feel
people
are
operating
at
and
which
apis
are
available
and
what
we
recommend
and
if
there's
nuance
great,
let's
try
to
point
out
where
those
nuances
are.
If
that
makes
sense,
oh
good
you're
nodding
all
right,
because
I
was
like.
C
Yeah,
I
would
love
to
chat
about
this.
I
could
chat
for
a
couple
minutes
to
give
kind
of,
but
it
might
be
better
to
spin
this
to
happen.
G
G
A
G
C
Cool,
I
will
cue
that
up
on
the
the
first
on
the
agenda
and
that
way,
we'll
have
john
who's
there
for
the
just
the
first
half
hour
of
those
meetings
also.
G
C
Absolutely
I
can
give
you
just
one
link
for
just
a
little
bit
of
reading
before
it
doesn't
really
answer
the
question
you're
asking,
but
I
think
we
should
answer
that
question
more
explicitly.
G
G
G
C
It'll
be
awesome
if
somebody's
able
to
like
run
some
experiments
and
show
some
data
on
what
these
differences
are.
That
would
probably.
C
Cool
then
we're
two
minutes
over
great
to
see
everybody.