►
From YouTube: 2022-04-05 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
What's
that
weld?
First,
no,
I'm
just
windy!
Today,
I
guess
we
looked.
There
were
several
around
portland,
but
like
trees,
there's
a
lot
of
trees.
Here
they
fall
on
power
lines
and
we
lose
power.
B
A
B
B
B
A
We're
out
like
we're
low
priority
like
if
there's
like
a
big
ice
storm
or
something
there's,
not
high
density.
So
and
without
heat
I
mean
we've,
we've
got
a
wood
stove
and
a
fireplace,
but
still
heat
is.
A
Materials,
thank
you
for
chipping
away
at
api
stability.
D
Yep
you're
welcome.
I
don't
have
like
a
well-formed
topic
but
that,
let's
say
general
discussion
about
instrumentation,
api
and
stability,
so
I
think
there's
probably
very
little
work
left
to
be
done
there
and
I
suppose
there
is
a
chance
that
the
next
release
could
be
sort
of
an
rc
release.
D
I
still
have
like
a
few
pr's.
I
don't
need
two
three
of
them
that
I
know
that
I
want
to
do.
But
besides
that
we
could
probably
start.
You
know
looking
at
the
whole
library
and
try
to
figure
out
if
there's
anything
else
that
needs
to
be
changed
or
removed
before
we
sort
of
market
the
rc
or
whether
it's
in
a
good
enough
shape.
A
Cool,
so
do
we.
A
D
I
don't
think
that
they're
exposing
anything
actually
that
slew
for
micrometer
tracing
or
whatever
it's
called
nowadays,
it's
it,
it
all
hides.
The
all
the
open
symmetry
stuff
is
best
implementation,
detail.
D
A
Yeah,
maybe
we
could,
because
it
would
be
really
nice
to
get
like
somebody
who
really
wants
to
use
it
in.
C
A
B
B
D
D
B
B
C
B
D
A
D
Yeah,
so
that's
it
for
instrumentation
api.
I
also
took
a
look
at
the
java
agent
instrumentation
api
and
at
the
extension
api
java
agent
instrumentation
api
is
it's
a
kind
of
a
weird
thing.
D
Let
me
just
take
a
look
at
it
because
it
contains
like
three
classes
and
there's
the
rest
of
it.
Oh
there's
a
concurrent
instrumentation
helper
classes,
there's
three
of
them,
and
I
I'm
not
sure
that
this
is
something
that
we
would
like
to
expose
in
an
api
and
the
rest
is
just
like
easily
internal.
D
B
D
It
and
java
8
reach.
D
But
extension
api
depends
on
the
current
this
javascript
instrumentation
api,
because
there
are
some
of
the
internal
classes
over
there
hold
stayed
like
the
during
the
cluster,
all
the
transformation
there's
a
boolean
effect
that
we
set
that's
used
by
instrumentations
or
stuff
like
that,
and
I'm
not
sure
if
we
could
release
extension
api
or
as
stable
with
it
being
dependent
on
unstable
direction.
Good
stuff,
unstable
internal.
The
agent
would
stop.
B
C
D
That's
the
worst
part:
it's
not
the
instrumentation.
Api
isn't
good
stuff
and
accession
is
an
agent.
D
I
mean
it.
It
would
make
sense
to
just
move
these
free
classes
over
to
the
extension
api,
but
they're
in
different
there.
So.
B
Because
it's
so
common
and
it's
our
main
use
case
versus
java
agent
extensions
and
the
end
users
also
get
different
instrumentation
versus
java
agent
end
users.
I
guess
this
is
the
main
user
of
other
extensions.
So,
of
course
combining
all
those
into
one
instrumentation
api
would
make
the
most
sense,
but
then
we'd
have
the
problem
where
part
of
it
is
in
the
bootstrap
and
whatever
is
on
the
bootstrap,
but
does
it
matter?
B
C
D
I
think
that
we
would
probably
have
to
document
that
very
well
that
actually
this
one
jar,
even
though
it
seems
like
you
know
one
thing:
it's
actually
split
into
two
parts
and
then
they,
those
parts,
aren't
loaded
by
different
class
numbers.
B
We
should
document
it,
but
and
then,
if
even
that
like,
if
it
doesn't
really
matter,
then
that's
sort
of
fine,
I
guess
yeah,
because
then
we
can
move
this
instrumentation
matcher
to
javascript
and
instrumentation,
and
we
really
have
that
one
artifact
that
anyone.
That's
writing
java
agent,
instrumental
just
depends
on
that
and
get
what
they
need
without
all
this
weird
other
extension
stuff.
A
A
D
D
A
So,
like
a
bootstrap
package.
A
A
And
then
the
internal
stuff
here
versus
because
we
have
the
java
agent
bootstrap.
A
A
D
I
think
the
first
two
are
reused
by
the
matchers
in
the
next
station
api
and
the
third
one
is
only
used
by
the
executor
instrumentation
details
in
this
package.
So
if
we
move
to
the
executor.
A
Yeah,
do
we
use
these
across
multiple
instrumentations.
A
So
we
can't,
because
we
have
the
ability
to
have
like
an
executor's,
bootstrap
artifact
now,
which
we
didn't
have
at
one
point.
D
And
there's
only
appender
left,
which
well
does
it
also
deserve
its
own
bootstrap
module,
or
should
we
move
it,
how
many
classes
are
there
is
one
just
like.
A
What
is
this?
Oh.
A
A
just
a
global
bootstrap
holder,
yeah
one
of
those,
so
actually
it
should
probably
be
in
the
java
agent
bootstrap.
Maybe.
D
I
think
it
if
it's
supposed
to
be
like
the
core
instrumentation
like
the
one
that
will
at
the
end,
stay
in
the
instrumentation
repo
and
not
be
moved
into
contract
and
it's
probably
okay
to
use
them.
But
if
it's
something
like
you
know,
rocket,
mq
or
some
weird
library,
that's
that
nobody
of
us
here
understands
and
will
probably
be
at
some
point,
move
to
the
contrary.
Proposal
than
only
instrumentation
api.
A
D
A
B
D
I
suppose
it's
true
there's
already
a
lot
emitter
provider
holder
class
in
the
vendor
api
and
it
looks
really
similar
to
the
agent
one.
A
Okay,
yeah
like
but
yeah
like
under
egg,
said
it's.
It
could
easily
live
under
extension,
api
bootstrap.
D
Yeah
I
mean
we
probably
still
have
a
bit
of
time
to
think
about
it.
It
will
take
a
few
days
to
implement
all
all
these
changes
anyway.
So.
A
D
D
A
Yeah,
I'm
pretty
happy
with
how
things
turned
out
all
that
that
that
work
you
did
around
the
the
pacinian.
I
like
that
pattern.
I
forgot
where
but
yeah
passing
the
builders
in.
A
D
B
A
Yeah,
it
was
so
clearly
called
down
back,
so
I
might
file
an
issue,
but
that's
the
kind
of
thing
that
will
not.
A
A
B
A
So
what
jessica,
so
we,
our
instrumentation,
the
goal
with
the
instrumenter,
is:
if
somebody
wants
to
do
extra
extraction,
do
we
have
hooks
to
add
their
own
attribute,
extractors.
B
B
A
Yeah,
definitely
let
me
know
when
you're
gonna,
like
run
in
the
java
repo,
when
you're
gonna
run,
that
prepare
to
prepare
the
release
branch,
because
I
I'm
like
pretty
important.
That
is
not
all
gonna
go
smoothly.
D
A
Yeah,
if
you
wanted
like
right
after
our
or
around
our
thursday
friday
morning,
meeting
yeah
cool
yeah,
I
will
plan
on
it
yeah.
I
hope
that
that
repo
is
the
first
to
go
through
a
release
with
all
the
latest
changes
yeah.
So
sorry
about
that.
Otherwise,.