►
From YouTube: 2021-12-07 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
Hey
that
was
great
news
about
koopa
watch.
B
C
I'm
really
glad
that
I
won't
have
to
do
this.
B
Thank
you
for
yeah
me
too.
Thank
you
for
pulling
this
splunk
strings
or
whatever
that
took.
B
All
right,
so,
let's
talk,
wrap
pack,
http,
client,
instrumentation.
B
D
B
Is
true
I
mean
we've
even
asked
people
who've
contributed
java
agent
instrumentation
to
make
their
life
more
complicated
by
asking
them
to
write
library
instrumentation
also.
E
B
Yeah,
but
that
doesn't
mean
that
we
can't
make.
I
would
I
do
I
mean
I
do
feel
for
people
who
come
to
write.
B
B
And
then
there's
also
that
issue
in
here
of
the
legacy
of
the
old
versions
like
how
and
yeah
I
mean
it
yeah,
it
would
be
nice.
I
mean
we
have
some
exam
that
I
think
users,
some
users
care
about
old
versions.
I
know
we
had
like
that.
Jetty,
http,
client,
java
agent,
instrumentation
contributed
and
that
user
specifically
wanted
an
older
version,
but
I
do
think
that
most
people
who
come
most
java
agent
contributors,
external
java
agent
contributors
are
going
to
care
about
more
modern
versions.
D
B
But
one
thought
I
had
that
wanted
to
see
if
it
made.
So
if
contrib
had
all
the
library
instrumentation
and
we
renamed.
A
A
Well,
if
we,
if
we
have
to
support
all
java
agent
instrumentations
ourselves
forever,
then
we
then
we
have
faith,
I
mean:
that's,
that's
not
sustainable
anyway.
We
we
have
to.
We
have
to
make
java
instrumentations,
like
approachable
by
external
contributors.
Anyway.
Yes,
it's
my
it's,
maybe
a
steep
learning
curve,
but
anyway,
so
I
don't.
D
B
So
yes,
java
agents
are
hard,
but
one
of
the
things
I
think
that
is
really
promising
about
this
project
is
the
the
care
that
we've
put
into
like
the
apis
and
the
structures
and
the
documentation
for
how
to
write
java
agent
instrumentation.
B
So
I
do
think
it
makes
it
much
more
like
how
we
can
improve
that,
but
it's
it's
obviously
never
going
to
be
as
simple
as
writing.
Library,
instrumentation
against
the
latest
version
of
a
library
even.
B
A
B
Well,
let's
take
the
specific
example
here
of
rat
pack,
so
the
user
wants
to
contribute
rat
pack,
http
client
library
instrumentation.
So
I
think
they
got
you
know
that
requires
bumping.
A
This
user
well
in
the
in
this
specific
case,
in
my
opinion,
it's
for
them,
it's
quite
easy:
they
they
want
to
contribute
back
client
instrumentation,
which
we
didn't
have
before.
Then
let
them
do
it.
However,
they
like
they
want
to
support
that,
starting
from
the
version
x,
okay,
they
create
a
new
instrumentation,
a
new
integration
for
that
back
her
client
starting
starting
version
x.
That's
it
that
is,
in
my
opinion,
there
is
no
need
to
change
anything
in
existing
server.
A
B
A
D
D
D
B
To
copy,
because
from
what
I'm
just
standing
from
rat
pack
on
rag,
you're
saying
that
there's!
Oh
it's
not.
B
E
A
I
mean
if
our
goal
is
to
make
external
contributions
as
easy
as
possible,
then
it
should
be
okay
for
them
to
copy
paste
if
they
want
to
support
like
similar
but
different,
like
in
this
case,
http,
client
and
later
version,
it's
okay
for
them
to
to
copy
paste,
and
then
we
can,
if
we
want
to
later
clean
that
up,
including
maybe
making
a
decision.
Okay,
we
bump
our
current.
A
C
Just
read
like
quickly
read
through
the
red
pack
instrumentation
code,
both
agent
and
library
and
the
agent
totally
doesn't
use
library.
So
they
are
essentially
two
completely
separate
modules,
and
could
we
perhaps
just
yeah
it
doesn't
java
agent
basically
implement
instruments
a
couple
of
minor
things
like
action
or
block
and
all
it
does
is
context,
propagation
or
house.
All
it
does
is
context
propagation.
C
A
I
think
for
me,
that's
like,
in
both
case
it's
breaking
change,
instrumentation,
which
worked
be
before,
doesn't
work
anymore,
why
it
doesn't
work
anymore,
you're,
just
adding
a
new
thing
to
an
already
existing
library.
Oh.
A
But
you
suggested
to
bump
minimal,
supported
version.
C
C
Yeah
rat
pack
1.4
still
exists,
but
we're
just
starting
start
to
publish
a
new
rat
pack
dash.
C
D
Like
I
wouldn't
want
to
have
to
like
the
idea
of
having
that
separate
for
atp
client,
I
don't
like
that
just
the
user
experience
also,
because
if
they
have
to
have
two
entry
points,
that
would
be
pretty
weird,
that's
good.
If
you
can
avoid
it.
This
time,
still
wondering
in
a
general
sense
like
there
will
be
cases
like
if
we
fork
library
instrumentation
into,
for
example,
two
entry
points
that'll
often
provide
a
pretty
bad
experience
for
library,
instrumentation
users.
I
think
so.
D
B
Yeah,
I
think
in
that
case
we
could
just
sort
of
consume
the
library
that
older
library,
instrumentation
version
inside
of
the
java
agent
instrumentation
from
even
central.
No
just
I
mean
structurally
right.
We
don't
we
like
you're,
saying,
say
the
in
the
rat
pack,
the
java
agent,
the
one
for
library
instrumentation.
B
E
D
D
B
D
B
Then
I
agree
like
that,
would
restrict
our
ability
to
drop
older
versions,
which
I
don't
think
is
a
good
thing
because
part
of
the
library-
and
maybe
we
can
jump
over
and
just
get
to
this.
D
B
D
Also,
but
would
so
the
point
isn't
about
vendor,
I
guess,
but
like
the
reason
these
exist
is,
I
think
our
needs
like
no
one
is
going
to
help
us
with
these
and
we'll
just
dump
it
to
contrib,
like
I'm
wondering
who's
supposed
to
be
contributing
to
these
libraries,
which,
like
the
reason
they're
there
is,
I
think,
maybe
not
vendor,
but
then
as
maintainers.
I
guess
like.
D
B
You
know
I
I'm
I
mean
we
could
say
that
we
are
more
picky
about
you,
know,
versions
and
tell
people
that
they
need
to
if
they
want
an
older
version
of
something
they
need
to.
You
know,
pull
it
in
from
contrib
specifically,
but
to
your
point
about
you
know:
if
vendors,
if
vendors
want
those
old
versions,
they
have
to
maintain
them.
Otherwise
we
delete
them.
C
So
there's
another
question:
whether
should
whether
we
should
move
the
old
versions
of
let's
say
important,
instrumentations
to
contribute
at
all,
because
I
can
definitely
agree
that
we
should
move
something
like
rocket
and
queue
to
country,
because
no
one
here
knows
how
it
works
really,
but
like
servlet,
2
or
93.
C
These
are
like
still
pretty
essential
and
I
think
that
we
should
probably
keep
like
if
we
support.
If
we
treat
neti
or
servlets
than
p1
or
important
javascript
component,
we
should
probably
keep
all
versions
in.
A
A
A
Okay,
okay,
then,
probably
my
point
is
more
like
we
should.
We
should
give
a
community
or
vendors
a
chance
to
take
over
the
the
support
of
some
of
some
versions,
so
will
that
option
include
some
not
incubating,
but
by
other
opposite
opposite
to
incubating
in
in
country
be
before
we
delete
it
completely
like
here
are
all
the
instrumentations
that
that
that
requires
additional
maintainers.
Otherwise
they
we
will
be
deleted
in
like
five
versions
or
five
months
or
six
months.
D
A
B
A
Idea,
yeah,
so
I
think
that's
that's
that's
sensible,
like
we
give
the
community
an
opportunity
to
like
to
think
a
little
bit
and
then
to
take
ownership.
Not
just
if
you
don't
take
it
in
a
week.
We
will
delete
it
so
and
how
exactly
that
process
looked
like
and
does
it
include
like
some
time
in
country,
but
not
that
separate
question.
D
A
E
B
Since
you
have
to
go
honorary,
can
you
take
a
look
at
this
today,
this
vr,
because
I
would
like
all
the
maintainers
either
approval
or
comments
on
it?
If
there's
anything
that
we
want
to
change.
D
B
Oh
yeah,
I
was
going
to
just
I
think,
just
paul
and
tyler,
probably
yeah.
D
B
So
they
have
not
given
up
on
hotel.
I
just
think
they
don't
find
it
a
priority
to
sync
to
try
to
use
the
upstream
or
try
to
merge
java
agents-
or
I
don't
know,
yeah.
D
B
Nice
yeah
ben
said
he's
starting
to
think
about
profiling.
He
wants
to
try
to
potentially
standardize
on
pea,
prof
and.
A
B
Yeah
but
you're
you're
you're,
just
sending
jfr
straight
jfr
to
your
backend
from.
C
Not
straight
jfr,
we
first
parse
it
a
bit
and
basically
trace
our
contextual
information.
To
that.
B
So,
do
you
have,
is
it
the
same
wire
format
for
different
languages
for
profile,
wi-fi.
A
C
B
E
D
E
A
B
Anyways,
oh
honorary
one
last
thing
for
you:
if
you
want
to
review
this,
I'm
gonna
probably
merge
it
tomorrow.
It
would
be.
It
would
be
nice
to
get
your
thoughts
just
because
it's
kind
of
a
slightly
new
bridging.
D
E
D
But
then
like
at
first,
I
thought
it
was
a
fluke
and
then
I
made
that
change
to
set
the
jvm
target
for
kotlin
compilation,
but
then
re-running
did
not
make
the
test
pass
until
I
turned
off
build
cache,
so
there's
obviously
something
wrong
with
kotlin
and
vote
cash
in
interoperability
in
general.
I
think
it's
only
in
the
incremental
case,
though,
some
will
think
that
disabling
this
will
reduce.
B
Those
I'm
fine.
I
have
no
objection
to
this,
but
would
like
nikita's
blessing
as
somebody
who
actually
knows.
D
Yeah
nice
should
have
peopled
a
bit
more.
I
I
was
able
to
debug
that
no
build
cache
fixed
it
and
without
it
it
failed.
So
at
least
there's
something
but
like
like
I
linked
to
the
jet
brains
issue
like
I
think
it's
a
known
issue
that
just
hasn't
been
fixed
yet
so
I
linked
in
slack
sorry,
I
can
edit
this
issue
also.
It.
D
Yeah,
like
gradle
close
their
bug,
saying
it's
a
bug.
Cotton
and
I
don't
know
if
caught
wind
compiler
people
will
care
that
much
about.