►
From YouTube: 2021-08-12 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).
C
A
C
Adding
there
was
there's
good
stuff
going
in
the
sdk
repo
all
the
time
also.
C
Okay
cool:
well,
let's
get
going
honorary
added
this
here.
I
don't
know
if
he
wanted
us
to
discuss.
B
I
think
at
least
we
need
to
make
sure
that
we
publish
what
the
release
cadence
is
expected
to
be
like.
I
don't
think
we
have
like
you
know,
at
least
in
instrumentation,
in
the
core
java
repo.
We
have
documented
our
attempted
release
things.
I
don't
know.
If
that
isn't
contributing
also
do
we
even
know
how
to
release
can.
C
B
C
B
C
B
It
sounds
like
honorary
should
do
it,
especially
since
it
sounds
like
he
probably
is
the
one
who
cares
the
most
about
the
things
being
released?
B
C
A
C
A
A
B
C
Once
we
start
moving
instrumentations
over
to
contrib,
I
was
as
guest
thinking
that
we
would
do
something
like
the
collector
does.
Where
there's
the
base
collector
that
doesn't
have
all
the
contrib
stuff.
C
A
They
should
they
must
be
aware
that
there
is
one
more
country
and
that
country
is
still
like
open
telemetry
like
sanctioned
or
like
it's
still
of
the
same
quality
as
the
main
reaper.
C
E
In
my
experience
on
other
projects,
what
happens
is
that
the
contribs
tend
to
spread
out
over
a
lot
of
different
areas
and
a
lot
of
different
libraries,
and
that
can
make
it
difficult
for
the
core
contributors
to
actually
really
feel
that
they
understand
the
contributions
well
enough,
and
so
that
means
that
prs
tend
to
get
through
with,
with
with
the
person,
accepting
the
pr,
not
necessarily
always
having
the
highest
confidence
that
it's
actually
correct,
so
putting
it
into
a
contra
repo,
with
an
expectation
that
it's
it's
reviewed
specifically
by
the
people
who
are
are
experts
in
that
area
makes
that
a
bit
clearer.
E
A
So
you
trust
you
you're
thinking
that
we
will
have
our
current
java
agent,
so
our
current
instrumentation
repo
we
with
only
tier
one
instrumentation,
then
we
will
have
the
separate
java
agent
contribute
like
instrumentation
country,
which
will
have
all
other
instrumentations
and
we
will
release
bigger
java
agent
from
that
combining
with
smaller
challenge
and
current
java
country
is
still
like.
Only
for
I
don't
know,
api
sdk
based
contributions,
not
instrumentations
ones,.
C
That's
a
good
question.
I
I
was
kind
of
assuming
just
everything
in
this
one,
but
we
could
certainly.
A
Because
people
generation
can
trip
you
that
wasn't
the
name
of
the
repo
that
was
the
name
of
the
jar
all
right.
Yes,.
A
C
I
can't
tell
you
how
nice
it
is
to
take
notes,
and
it
not
be
so
laggy.
I
I
copy
a
archived
I
took
like.
D
D
A
Well,
one
that's
a
good
point
and
maybe
then
we
should
stop
doing
all
currently
all
means
like
agent
plus
all
exporters,
and
we
don't
have
any
exporter
in
like
in
the
corridor.
A
Maybe
we
should
just
the
core
jar
should
include
only
otlp
exporter
and
all
other
exporters
by
by
default
in
country.
A
A
The
use
case
was
that
you
can
grab
that
you
can
grab.
You
can
use
hotel
exporter
jar
to
provide
just
the
exporter
that
you
want
to
keep
the
jar
size
smaller.
A
Well,
once
we
declare
extension
stable
in
one
two:
five
yeah
yeah,
but
anyway
that's
yeah.
That's
the
same
use
case
that
you
don't
get
all
exporter
that
you
don't
actually
want,
but
by
the
same
logic
they
already
get
like
hundreds
instrumentations
that
they
don't
want.
So
why
why
exporter
makes
any
difference
yeah,
it
definitely
has
been
a
source
of.
B
A
I
I
said
for
a
long
time
that
we
need
start.opentelemetry.io.
B
B
B
A
B
No,
I
think
it's
a
fantastic
idea.
In
fact,
it's
something
that
I've
been.
I
mean
I've
been
thinking
about
it
for
at
least
a
year
over
a
year,
so
you
know
what
what
do
you
think
about
actually
putting
putting
an
issue
into
the
community
repo,
because
I
think
this
could
be
super
useful
and
something
that
would
be
incredibly
valuable
for
the
community.
B
B
D
Yeah
and
like
people
are
going
to
want
to
they're
going
to
want
apis,
so
they
can
automate,
deploys
with
it
and
and
and
and
like
yeah.
D
A
A
C
What
do
you
think
of
swapping
for
now
swapping
the
meaning
of
having
the
default
one
be
the
one
that
has
all
the
exporters
and
publishing
one?
That's
like
dash.
No
exporters.
B
B
So
it
might
be
might
be
better.
It
might
be
good
to
publish
both
the
dash
all
and
the
regular
one
for
at
least
a
little
while,
and
maybe
the
dash
all
has
some
plugin
that
will
log
very
loudly
that
this
is
deprecated.
Don't
use
this
jar
anymore
when
you
plug
it
into
java.
I
don't
just
think
out
loud.
C
This
is,
as
this
seems
like
a
nice
idea.
I
was
just
trying
to
think,
though,
like
how
common
the
jaeger
zipkin.
C
That's
a
good
point:
they
are
mandated
by
the
spec
at
least
to
be
available
for
in
the
sdk
repos.
So
it's.
C
And
that's
probably
I
mean
that
that's
being
more
friendly
to
these
ecosystems
also,
and
once
we
have
the
otlp
exporter
in
there,
then
we
have
that's
the
big
the
jar
file
size,
wise.
That
is
already
the
grpc
neti.
C
Cool
release
week.
B
Yep
so
1.5.0,
I
think,
hopefully
we'll
unless
there's
something
urgent
that
needs
to
go
in
I'll,
probably
release
it
tonight
or
tomorrow,
after
touching
baseball
on
rod
in
the
afternoon
today-
and
it
be
you
know,
big
heads
up-
this
does
have
a
massive
metrics
api
change
to
match
the
new
instrument
names
and
simplify.
It
streamline
the
api,
a
little
bit
still
not
stable,
but
it
definitely
will
break
everything.
That's
out
there.
B
C
Yeah-
and
I
I
I'm
I'm
excited
for
this
because
I
feel
like
it
will
be-
it's
finally
like
at
close
to
the
end
stage
like
we
can
now,
I
feel
like
we
can
now
start
investing
in
metrics
api
work
and
not
have
it
be
thrown
away.
A
A
B
E
This
yeah,
this
is
really
just
a
an
informational
announcement.
I
don't
know
if
people
follow
the
quarkus
development
track,
particularly
closely,
but
some
some
movement
towards
being
able
to
support
java
agents
by
doing
build
time.
Instrumentation
has
been
underway
and
we're
about
ready
to
try
it
out
with
some
real
agents.
So
one
of
the
ones
that
we
want
to
do
obviously
is
the
the
open
country
one.
So
this
is
really
just
a
kind
of
a
watch
to
space
notification.
E
I've
got
some
engineering
time
with
a
colleague
next
week,
we're
going
to
try
it
out
we'll
let
you
know
how
it
goes.
C
Cool
yeah
I've
been
getting
that
question
a
few
times
of.
How
will
we
support
grahl?
I
assume
this
is
compil
using
grawl
or
I
don't
really
understand
the
space
that
well.
E
Okay,
so
basically
the
the
point
is
is
that
nobody
really
knows
what
statically
compiled
java
is
because
java
is
so
amazingly
dynamic
in
so
many
ways
that
there
is
not
a
commonly
accepted
definition
of
what
it
what
it
actually
means.
So
at
the
moment,
the
only
real
run
time
that
exists
for
statically
compiled
java.
E
Well,
I
shouldn't
say:
runtime
platform,
which
is
a
specifically
compiled
java,
is
growl,
so
the
the
definition
of
what
statically
compiled
java
is
is
whatever
the
hell.
Well,
vm
does
so
that's
that's.
E
What
qualcus
does
it
leverages
scroll
vm
to
produce
an
aot
compiled
binary
and
that's
what
what
we're
trying
to
do
with
the
with
the
java
agent
piece
is
to
actually
see
if
we
can
get
all
of
the
information
that's
needed
to
do
a
pre-main
out
of
the
out
of
the
the
the
compilation,
the
build
phase,
because
effectively
what
this
means
is
that,
rather
than
running
pre-main
before
main
you're,
actually
running
it
when
you
build
so
your
definition
of
where
you
stop
and
freeze
the
binary
is
no
longer
purely
build
time.
E
Not
really,
I
mean
it's,
it's
mostly
just
some
exploratory
hacking
to
start
with.
There
may
be
a
branch
in
in
the
quarkus
repos
that
we'll
I
can
share.
Issues
may
also
appear
in
the
github
for
for
the
for
the
ato
java
instrumentation,
depending
on
what
works
and
what
doesn't.
But
I
guess
we'll
find
out.
C
I
see
so
does
the
when
you,
when
growl
runs,
is
it
still
going
to
call
when
it
loads
a
class?
Is
it
still
going
to
call
transform
on
that
class
and
just
the
things
that
we've
registered
in
the
instrumentation.
E
F
Just
like
transform
all
the
classes
during
build
time.
E
You
can
I
I
sort
of
feel
in
my
bones
that
that
may
be
maybe
overkill.
You
may
end
up
with
too
much
instrumentation,
but
answering
that
question
about.
Can
you
just
do
everything
and
just
blat?
It
all
is
one
of
the
things
I
want
to
figure
out.
I
was
more.
F
F
Like
basically,
if
you
have
you're
doing
like
static
compilation,
you
you
already
know,
like
all
the
classes
beforehand,
and
you
could
just
like
process
all
of
them
with
our
instrumentation.
E
Yeah,
that's
the
basis
of
how
we're
going
to
approach
it.
I
mean
there
are
obvious
corner
cases
to
do
with
reflection
and
method
handles
that
you
have
to
worry
about,
but
but
broadly
yeah
provide
providing,
there's,
nothing
reflective.
That
happens.
That's
that's
the
general
approach.
That's
that's
the
core
of
how
well
does
it.
B
C
C
And
at
run,
if
there
is
dynamic
stuff
at
run
time
like
proxy
proxies
or
something
will
graw
fall
back
to
normal
java
class
loading
and
class
file,
transforming.
E
B
E
So
you
you
have
to
you,
have
to
provide
a
an
exhaustive
list
of
everything
which
will
be
loaded,
reflectively
or
via
a
method
handle,
and
if
that
list
is
incorrect
and
you
try
to
load
something
which
which
there
is
a
compiled
code
for
you,
die.
E
E
Agent
splits
out
like
a
list
of
everything
which
which
came
in
via
reflection,
and
then
you
take
that
and
feed
it
back
into
the
build
process.
But
of
course,
if
it
so
happens
that
your
test
data
didn't
exercise,
parts
and
didn't
wasn't,
wasn't
a
complete
set
of
everything
which
needed
to
be
loaded
reflectively.
You
are
still
vulnerable
to
that,
but
hopefully
that
that
doesn't
happen.
Too
often,
it
seems
like
you.
E
Yeah,
that's
a
great
plan
that
that
might
actually
be
one
of
the
things
that
I
could
start
with
is
to
actually
just
run
the
test
case
with
the
test
cases
with
the
the
agent
which
spits
out
a
list
of
everything
which
loads
reflectively.
E
That's
not
a
bad
starting
point
at
all,
and
and
then,
as
you
say,
if
it
later
does
prove
to
crash,
you
know
you.
You
know
that
the
test
coverage
is
not
as
complete
as
it
should
be.
D
Of
tests,
so
I'm
working
I'm
working
on
a
change
that
will
allow
us
to
aggregate
these
overhead
test
results
over
time,
similar
to
the
way
iguanodon
did
it.
But
I
need
to
I
need
to
check
them
into
a
branch
somewhere
and
I
think
maine
might
be
a
bad
idea,
because
it
triggers
a
build
right.
D
If
it's
a
pen,
so
if
you
just
picture
like
a
csv
file
growing
over
time,
how
do
I
append
if
they
don't
if
those
files
don't
exist
in
main
or
if
they're
not
kept
up
to
date,
so
in
iguanodon?
I
just
used
main
because
I
didn't
care,
but
I
don't
want
to
trigger
a
build
every
night
just
because
the
tests
ran
right.
So
I
don't
want
to
commit
stuff
back
to
master
and
trigger
a
build.
So.
D
C
C
D
Look
at
that
next
and
then,
when.
C
That
the
other
thing
I
was
going
to
mention
is
that,
even
if
it
did
trigger
a
build,
it
should
be
really
fast
because
it
should
come
from.
You
know
all
the
gradle
cache
stuff
should
get
hit
since
you're,
not
actually
updating
anything
yeah.
That's
true.
D
Be
the
worst
if
that,
okay-
and
this
is
for
nikita
and
trask,
did
you
want
me
to
use
liberica?
I
I
wasn't.
D
C
D
C
Cool
well,
most
of
you
follow
the
repo
very
closely
and
know
all
of
the
great
things
that
went
in
last
week.
I
do
want
to
call
out
the
we
made
some
good
progress
on
converting
to
the
instrumentation
api,
we're
now
at
almost
a
third,
almost
a
third
of
the
way
there,
maybe
picking
up,
speed,
we've.
C
Find
this
discussion
really
interesting.
I
was
very
surprised
to
learn
this
and,
but
more
importantly,
the
bite
buddy,
not
caching,
the
method
instance.
C
C
C
C
F
C
F
C
Yeah
yeah,
it
was
really
I
was.
I
was
baffled
by
that
and
it's
surprising
to
me
for
such
a
for
us
for
something
to
change
like
that
in
you
know,
basically,
I
assume
nine
is
sort
of
end
of
life.
I
don't
know,
maybe
not,
because
ten
is
servlet.
Five
right.
C
Cool,
well,
I
don't
have
anything
else.
Any
last
thoughts,
discussion
items.