►
From YouTube: 2021-04-29 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
A
A
Oh
yes,
an
important
decision
we
made
in
wednesday's
meeting
is
that
we
are
going
okay,
so
this
is
we're
going
to
label
our.
This
is
very
important
decision.
We're
going
to
call
our
sig
days
of
the
week
by
utc
time
so
that
we
have
wednesday
meeting
thursday
meeting
and
friday
meeting
so
the
so
there
won't
be
there'll,
be
maybe
less
maybe
more
confusing.
B
B
B
F
Yep,
so
is
this
going
to
change
for
everyone,
or
just
yourself.
A
Yeah
I
have
rights
to
update
this
okay.
I
think
it
will
take
effect
for
everybody
cool.
You
have
the
power
yeah.
A
Let's
try
this
all
this
and
following
events,
should
I
send
don't
send
don't
say
I
don't
care
yeah.
A
A
A
B
C
B
G
No
sorry,
it
was
just
like
my
my
zoom
needs
a
lot
of
time.
When
I
want
to
turn
on
video,
I
have
no
idea
why
but
hi
I
am
jonathan
and
I
work
in
the
spring
team
and
also
I
am
like
one
of
the
maintainers
pretty
new
one
for
spring
cloud
suit
and
micrometer
as
well.
A
B
A
We
have
a
lot
of
portland
folks
here
myself,
john
jason,
the
other
jason
jason
yeah.
G
I
am
one
of
the
leaders
of
the
like
seattle,
java
user
group,
so
please
feel
free
to
reach
out
to
me.
If
you
want
to
give
a
talk
on
cjag.
E
B
Yeah,
so
the
first
one
I
put
in
so
that
we've
had
a
kind
of
a
long-standing
issue
in
the
java
repo
to
detect
public
api
changes,
specifically
really
breaking
changes
to
make
sure
that
they
don't
creep
in
this
ends
up
being
a
little
non,
pretty
non-trivial.
But
what
I
have
put
together
in
this
pr
is
something
that
will
actually
report
all
of
the
public
api
changes
for
every
published
module
and
you
can
actually
specify
which
versions
like
if
you
want
to
generate
a
report
for
specific
versions
that
are
out
there
published
versions.
B
You
can
do
that
as
well
and
what
it
does
right
now.
Is
it
it
actually,
when
you
run
the
gradle
task,
which
is
currently
in
this
pr
hooked
up
as
a
dependency
of
the
build
task,
it
will
generate
for
every
public
published
jar
module
that
is
stable,
it
will
generate
a
little
file
inside
the
docs
directory
for
that
module
that
describes
the
any
api
changes
versus
the
latest
release.
B
So,
for
example,
you
can
see
that
one
there
for
the
api,
not
that
one,
but
that
one
doesn't
have
anything
in
it
at
this
moment,
because
there
have
been
no
changes
but
scroll,
you
missed
it.
You
skipped
there
that
one.
B
Yes,
so
this
is
the
current
version
of
the
jar
versus
the
latest
release
and
you
can
see
it
has
a
description
of
everything.
That's
changed
in
the
public
api
for
the
api
module
in
particular,
so
you
can
see
there's
an
interface
modification,
we've
added
a
method
to
this,
to
the
span
interface
and
to
the
span
builder
interface.
B
So
it's
a
little.
The
the
format
is
kind
of
looks
like
a
diff
sort
of
a
diffish
format.
This
is
what
the
plugin
that
I'm
using
the
gradle
plugin
that
I'm
using
outputs
by
default,
I'm
working
on
maybe
a
more
human,
readable
diff.
But
basically
the
idea
is
that
anyone
who
puts
in
a
pr
and
they've
run
the
build
locally.
It
will
generate
these
files
and
if
there's
any
changes,
they'll
show
up
in
the
pr.
B
Unfortunately,
if
you
look
at
the
text
files,
I
made
a
comment
on
it
in
here
somewhere
this
one
right
here
so
accidentally,
the
zipkins
fan
exporter
now
has
a
public
logger
which
it
did
not
have
before,
and
that
is
now
a
part
of
our
public
api.
This
was
not
on
purpose
and
it
wasn't
caught
in
code
review.
B
B
A
So
the
is
the
idea
with
the
files
checked
in
is
that
you
always
have
the
current
versus
latest
and
then,
as
part
of
the
release
process.
You
would
bump
this.
You
would
rerun
that
or
something
it.
B
A
And
people
would
have
when
they
run
it,
they
would
have
to
oh
well
they'll
already
you'll
have
this
in
under
source
control
already,
so
they
would
just
be
modifying
that,
so
they
wouldn't
forget
to
add
it
right.
So
it
would
show
up
as
a
part
of
the
pr
exactly.
B
Visible
anyway,
thoughts
and
critiques-
and
I
consider
this
kind
of
just
like
the
very
first
cut
at
this-
and
that
obviously
we
would
need
to
we-
could
improve
it
and
change
the
formatting,
make
it
more.
Human
readable,
like
I
said,
all
those
things
as
we
go,
but
getting
something
like
this
in
place
feels
like
it'll,
be
a
valuable
resource
not
only
for
us
as
maintainers,
but
for
the
community
to
see
exactly
what
apis
have
changed.
A
B
Anyway,
feedback
strongly
desired.
A
Nikita,
do
you
want
to
drive?
Do
you
want
to
share
or
to
talk
about
this.
D
D
D
Like
extension,
exporter
configuration
sdk,
auto
configuration
and
additional
instrumentation
modules
via
one
single
like
give
me
a
jar
file,
and
I
will
load
everything
that
it
contains,
or
several
jar
files
or
directory.
So
how
I
try.
I
tried
to
implement
that
so
I
I
took
our
exporter
class
loader
as
a
basis
and
created
extension
class
load.
What
extension
class
loader
does
is
essentially
it's
the
usual
class
loader,
which
overlap,
overloads,
find
class
method
and
whenever
he,
whenever
it
three
it's
a
class.
It
performs
online
runtime
remapping
what
our!
D
So,
and-
and
so
this
allows
essentially
that
you
have
an
external
jar
built
against
usual
open,
telemetry,
java,
api
or
sdk
without
any
shadowing
without
any
relocation,
and
when
you
load
that
jar
through
this
plus
loader,
then
all
that
relocation
happens
during
runtime
and
now
how
this
class
load
is
used
is
in
our
agent
initializer.
D
We
before
that
we
created
an
agent
class
load
and
used
that
class
loader
to
load
everything
from
the
agent,
well,
almost
everything
all
agent,
specific
instrumentations,
all
agent,
specific
sdk
extension,
etc.
What
we
now
do,
one
more
extension
class
load
which
has
agent
class
loader
as
a
parent
and
use
extension
class
loader
to
load
everything.
D
D
So
apparently
there
are
two
two
different
pull
requests
done,
one
which
uses
this
fine
class
overload
and
get
resource
upstream
overload
to
remap
everything.
Another
pull
request
uses
a
similar
mechanism
to
what
we
use
in
agent
class
loader,
which
is
using
a
separate
url
handler
to
perform
all
remappings.
D
D
What?
If
we
just
create
a
new
class
file
transformer
which
detects
classes
and
resources
loaded
by
prestige,
class
loader
and
do
remapping
over
there?
It
may
work
for
classes.
The
problem
is
that
now
I'm
thinking
about
that
by
by
the
laws
advices
not
as
classes,
but
just
as
resources,
input
streams,
it
doesn't
define
clock,
clock
cluster
so
that
that
class
file
and
transformer
probably
will
not
work
but
anyway.
D
I'm
look
I'm
looking
for
feedback,
yes,
one
of
which
one
of
two
approaches
is
better
and
did
I
miss
something
like
fundamental
one
of
these,
of
those
pull
requests
now
contains
example
as
well.
So
we
have
this,
for
example,
for
repackaging.
Now
there
is
extension
example
as
well,
which
shows
how
to
do
extension,
and
that
is
certainly
much
simpler
from
the
build
perspective,
no
shadow
plot
plug-in
at
all
no
relocating
nothing.
You
just
well
provide
whatever
you
want
and
that's
it
usual
jar
file.
D
So
that's
much
simpler
and
I
am
looking
for.
D
If
you
all
customization,
I
haven't
thought
long
about
that,
but
I
will
about
how
custom
vendor
distribution,
maybe
even
can
use
this
extension
loading
to
simplify
its
repackaging.
So
maybe
we
can
reuse.
It
somehow
still
provide
one
jar
for
vendor
distribution,
but
vendor
distribution
shouldn't
actually
repackage
and
relocate
everything.
D
But
just
like
do
something
else
like
if
you,
if
you
combine
our
agent
class
loader
and
having
like
internal
jar
inside
like
inst
folder
inside
the
jar
file.
So
maybe
we
can
have
extension
jar
inside
agent
jar,
as
I
like
in
extension,
folder
inside
that
may
make
things
for
vendors
a
little
bit
easier
as
well.
A
I
probably
wouldn't
use
that
in
in
this
in
our
distro,
just
because
of
the
overhead
preferred
not
to
deal
with
the
overhead
of
runtime
shading,
I
mean
it
shouldn't
be
extreme,
but
since
startup
performance
is
a
kind
of
a
sore
point
in
general
for
the
java
agent
already
anything
yeah.
D
D
D
A
Which
pr
has
the
the
example
extension
in
it.
A
And
does
that
run
all
the
tests
that
the
the
same
tests
that
the.
D
A
A
Yeah,
that's
gonna,
be
so
much
simpler.
I
think
for
users
who
just
want
to
throw
in
like
a
custom
sampler
than
the
previous.
A
Oh
well
before
I
share:
why
don't
we
just
pass
on
sharing
to
materish.
E
Yeah,
I
have
a
topic.
That's
somewhat
connected
to
what
nikita
presented
and
over
the
last
few
days,
I
tried
to
extract
everything:
that's
not
internal
to
java
agent,
that's
supposed
to
be
used
by
dividend,
instrumentation,
authors
into
a
separate
module.
So
this
is
what
I
this
is
what
I
got
and
I
just
show
you
the
few
important
classes
that
got
introduced.
E
E
One
thing
extends
or
implements
this
extension
is
an
instrumentation
module,
so
all
instrumentations
are
by
nature
extensions,
and
this
instrumentation
model
hasn't
changed
much
and
everything
that
was
some
in
some
kind
of
internal
to
the
agent
and
contained
some
crazy
things
like
bytecode
transformations,
I've
hidden
behind
this
agent
extension,
tooling
interface,
so
things
like
instrumentation
contacts
or
how
to
injection
injector
or
even
class
loaders
that
are
actually
exposed
by
the
java
agent
are
now
hidden
behind
this
interface.
E
So
extension
authors
do
not
have
to
reach
into
our
utils
class
or
do
not
have
to
care
how
hamburger
injector
works,
and
then
you
can
just
create
it
using
this
and
yeah.
As
a
nice
thing,
I
think
I
managed
to
replace
all
java
agent
tuning
usages
in
overall
instant,
almost
or
our
dividend
instrumentation
modules,
so
they
only
depend
on
this
extension.
Api
and
tests
still
work.
Everything
still
runs.
E
One
major
problem
that
I
probably
might
have
introduced
with
this
is
a
re
really
a
lot
of
backwards
and
compatible
changes,
because
I
I
moved
classes
around
to
different
packages.
I
changed
some
method
names
and
so
on.
E
A
A
Yeah,
I
do
think
that
this
one
is
only
this
stuff
is
mostly
used
by
vendors.
At
this
point,
so
I
wouldn't
spend
a
lot
of.
I
would
just
go
forwards.
A
The
sooner
we
can
get
these
changes
and
nikita's
changes
in
the
sooner
we
will
have
like
a
more
stable
something
that
we
can
offer
to
people
to
build
on
yeah.
That
was
exactly
the
point.
C
Would
we
anticipate
this
new
api?
This
is
for
I
guess,
nikita
or
mateos.
Do
we
anticipate
the
new
api
that
extension
api
kind
of
replacing
something
like
the
component
installer
or
do
we
think
the
component
installer
has
a
different
scope.
E
E
Install
it,
but
some
kind
of
component
and
stutter
like
interface,
will
definitely
be
a
part
of
it.
E
D
C
And
do
you
anticipate,
or
do
you
think
about
this,
leading
to
a
potentially
more
modularized
agent
in
the
long
term
like
I
know
that
java
agents
like
dash
dash
java
agent
java
agents
are
hard
to
modularize,
but
if
there's
like
this
file
system
convention
that
could
lead
to
it,
I'm
just
thinking
about
use
cases
where,
like
there
are
contemporary
users
that
are
like.
Why
am
I
being
encumbered
by
all
of
this
like
weblogic
instrumentation?
I
don't
even
want
that
right,
like
let
that
be
fringy
for
people
that
are
still
running
sorry
go
ahead.
F
D
D
I
see
I
still
think
that's.
That's
connects
to
my
second
favorite
topic,
as
of
now
is
a
a
agent
instrumentation
so
answering
to
your
question.
Yes,
that's
one
of
the
way
how
you
how
we
can
make
our
java
agent
more
modularized,
how
we
trade
off
that
with
ease
of
use
and
out
of
the
box
experience.
That's
open
question.
C
C
A
E
I
haven't
yet
I
kind
of
dropped
it,
because
all
the
things
that
I've
implemented
worked
partly
there
were
some
few
missing
a
few
missing
things
on
our
side,
so
I
kind
of
waited
and
then
oh
yeah
they're
still
in
the
review.
So
I'm
still
waiting
for
them
to
get
matched.
A
E
Yeah
sure
just
give
me
a
minute
I'll,
open
intellij
with
that.
B
B
We
think
they're
kind
of
poorly
put
together
so
mateosh,
and
somebody
else
I
don't
know
who
else
have
been
probably
honorable
have
been
working
on
a
new
instrumentation
api
that
will
encompass
not
only
tracing
and
spans,
but
metrics,
eventually
and
probably
logs
as
well,
and
so
that
that's
what
is
here
is
mateosh
has
been
experimenting
with
trying
to
see
this
new
experimental
instrumentation
api,
how
it
would
work
for
the
sleuth
use.
G
Case
does:
does
this
mean
that
the
java
instrumentation
project
will
depend
on
metrics
and
logging
of
open
telemetry
like
the
the
specs
as
well,
and
also
the
implementation
part
as
well?
I
I
am
asking
from
the
roadmap
perspective.
Basically.
G
Oh
okay,
let
me
ask
another
question,
then
so
does
the
one
point
zeros
like
they
disable
the
stable
release
of
the
joint
instrumentation
depend
on
these
or
not.
G
So
the
question
is:
does
like
matrix
and
and
logging
being
in
alpha
blocks,
java,
instrumentation
being
stable.
A
Yeah,
that's
an
excellent
question:
we've
that
we've
been
batting
back
and
forth
for
a
couple
of
weeks
trying
to
decide
how
to
not
have
it
block
us
being
stable
and
we
had
a
good
discussion
last
week
with
honorable
did
I
not
wow.
I
had
two
terrible
notes
in
that
meeting.
A
Okay,
we
won't
go
there,
we'll
just
go
to
so
onorak
put
in
a
a
pr
just
recently
to
so
in
this
new
instrument
or
api,
adding
metrics
to
it,
and
so
this
is
sort
of
where
you
know
we're
really
going
to
have
to
decide
that,
and
so
what
we
discussed
last
week
or
no,
it
was
just
was
it
tuesday
slash
wednesday
was
probably.
A
No,
that
there's
we
do
plan
to
release
instrumentation
we're
not
going
to
let
that
hold
back
instrumentation
the
new
instrument
or
api
from
going
stable
and
what
we're
going
to
do
is
we
are
going
to
have
a
dependency
on
the
alpha
metrics
and
there
is
one
there
is
one
surface
area
that
is
exposed
of
of
that
al
and
we're
going
to
mark
that,
as
with
the
like
an
unstable
annotation
to
basically
kind
of
get
around
december
for
allowing
us
to
have
a
have
expose
that
piece.
A
Does
that
help
answer?
Yes?
Yes,
thank
you,
yeah
yeah!
It's
definitely
on
our
mind
and
that's
what's
driving
a
lot
of
the
instrumenter
api
work
right
now
is
yeah
and
why
we
had
been
so
hesitant
to
to
move
forward
on
the
the
making
it
state
the
instrumentation
api
stable,
because
nobody
really
was
in
love
with
that
api.
A
We
knew
that
we
wanted
to
make
some
significant
changes
hand
over
sharing.
Do
you
do
matage,
yep
cool.
E
E
Window
well,
so
they
previously
were
extending
the
http
server,
tracer
or
http
client
tracer,
and
there
was
a
lot
of
various
hacks
to
make
it
work
together
with
the
spring
sleuth
api
and
what
I
did.
I
I
tried
to
completely
remove
any
usage
of
our
trace
api
and
replace
it
with
a
new
instrumenter,
and
it's
got
a
bit
simpler,
so
the
instrument
are
now
the
usage
of.
E
It
is
extremely
simple
in
a
way
that
you
can
just
call
start
and-
and
that's
all
and
all
all
complexity
lies
with
its
configuration
and
where
was
it
configured
it
wasn't.
Maybe
I
can
find
where
it's
created.
E
That's
that's,
not
a
which
configuration
sounds
good,
okay,
so
those
instruments
separate
one
for
a
client
and
separate
one
for
server
stuff
that
are
sort
of
like
composed
of
several
building
blocks.
So
there
is
an
extractor
of
http
attributes
that
just
tries
to
get
various
things
from
the
request
or
response
like
hd
method,
url
or
root
or
headers.
E
Oh,
I
probably
forgot
to
add
it,
but
yeah
status
codes
and
they
there's
it
was
you
previously,
but
of
course
there
are
getters
and
setters
for
propagation,
and
so
what
the
the
previous
tracer
api
you
rely
heavily
on
extending
an
inheritance
and
extending
methods
and
trying
to
make
this
work
so
and
the
new
instrumentary
api
instead
realizing
composition.
So
you
have
several
different
attributes:
extractors
that
can
extract
various
things.
E
For
example,
there's
a
separate
one
that
extracts
the
http
path
attribute
that
was
previously
just
coded
somewhere
in
the
onstart
or
on
request
method
in
the
server
handler
so
yeah
anyway.
The
main
aim
of
my
proof
of
concept
was
just
to
see
if
the
instrumental
api
is
missing,
something
it
was
there's.
E
There
was
a
significant
problem
with
trying
to
get
the
network
attributes
which
we
assumed
would
be
easily
resurrectable
at
the
end
of
processing,
and
it
turned
out
that
spring
sleuth
does
a
bit
of
magic
with
wrapping
the
request
and
stuff,
and
it's
actually
preferable
to
get
those
things
as
early
as
possible.
E
But
this
is
already
addressed
in
another
pr
in
our
instrumentation
api.
So
once
it's
done,
I
think
that
all
tests
would
boost
this
ripple
will
pass
and
we
could
possibly
get
rid
of
the
single
tracer
api
usage
and
yeah.
So
that's
pretty
much.
Oh
there's
one
more
thing
that
that
I've
noticed
and
I
couldn't
really
fix
it
myself
easily.
E
G
If,
if
you
have
like
any
idea
to
like
or
or
otto
has
like
a
standard
way
of
for
context
propagation,
just
just
let
us
know,
I'm
not
very
familiar
of
this
piece
of
code
in
in
suit
hotel.
But
we
can
always
talk
to
marching
and
I
can
take
advantage.
E
Okay,
so
while
I
have
some
kind
of
idea
how
it
should
look
for
spence
and
how
to
fix
that,
I
was
just
completely
lost
how,
when
I
got
to
the
baggage
and
how
how
baggage
works
since
in
springsloof
and
yeah.
This
is
this
was
the
part
that
defeated
me
in
my
last
attempt
to
understand
it.
So
we'd
probably
have
to,
I
don't
know,
combine
our
own
knowledge
with
of
sleuth
and
autumn
together
to
kind
of
fix
it.
A
For
the
context,
propagation
honorag
has
done
some
nice
context,
bridging,
for
example,
with
grpc
context,
propagation
and
hotel
context
propagation,
where
they
to
make
those
interop
seamlessly,
where
we
store
the
hotel
context
in
the
grpc
context,
and
we
store
the
grpc
context
in
the
hotel
context
so
that
basically,
whichever
one
gets
propagated,
the
other
one,
then
we
propagate
along
with
it.
So
there's
there's
some
good
prior
art
there
that
we
can.
We
can
leverage-
and
I
think,
that's
the
general.
That
seems
to
be
the
best
approach
for
interoperating
with
contexts.
A
G
A
Instrumentation,
we
don't
have,
I
don't
think
we
have
anything
published
there.
A
I
think
the
big
one
is
this:
this
instrumenter
api
and
then
you
know
letting
that
bake
a
little
bit.
A
We
were
thinking
on
so
there's
some
library
instrumentations.
So
are
you
familiar
with
sort
of
the
terminology
that
we
use
say
for
grpc?
We
have
both
java
agent
instrumentation
and,
like
we
call
library,
instrumentation
and
so
library
instrumentation
can
be
used
without
the
java
agent.
It's
a
just
a
maven
dependency.
A
Yeah
yeah,
so
this
would
be
more
the
traditional
like
like
or
not
traditional,
but
the
brave
approach
where
some
helpers
to
instrument,
and
so
the
library
instrumentation
depends
on
the
instrumentation
api.
A
A
It's
just
like
this
class
that
says
here
pass
me
a
open,
telemetry
object
and
I
get
a
then
give
me
a
new
client
interceptor
that
I
can
register
with
grpc,
and
so
we
would
have
a
implementation
dependency
on
an
alpha
version,
but
that's
something
that
we've
decided
across
both
the
sdk
and
the
instrumentation
repo.
A
That
is
acceptable
because
users,
if
they
wanted
to
depend
on
that
alpha
version,
they
would
have
to
pull
that
in
explicitly
into
their
project,
and
we
have
a
bomb
to
sort
of
control
that
so
we
may
be
able
to
release
some
of
the
library
instrumentations
sooner.
A
The
new
instrument
or
api
is
a
it's
a
lot
of
work.
We
have
a
lot
of
instrumentations
to
migrate
and
I
think
we
would
ideally
want
to
migrate
them
all
before
declaring
that
stable
to
make
sure
that
it,
you
know,
covers
all
of
these
kind
of
weird
corner
cases
that
we
have
and
all
these
weird
instrumentations.
A
G
Is
this
just
for
your
interest?
So
I
believe
that
at
this
point
I'm
I'm
totally
fine
like
just
hearing
this,
but
I
believe
not
not
for
just
me,
but
for
the
I
believe
the
four
community
it
would
be.
It
would
be
beneficial
to
having
something
like
it
doesn't
necessarily
need
to
be
a
document.
G
It
can
be
like
just
a
like
a
guitar
project
where
you
can
put
all
of
those
issues
that
you
want
to
resolve
before
you
want
to
go
to
stable
so
that
it
is,
it
is
trackable
or
google
docsis
is,
is
also
fine
too.
As
far
as
I
know
like
the
the
the
api,
the
dd
specs,
they
they
prefer.
Google
docs
mostly.
A
And
is
this
because
we
haven't
had
any
one
else
besides,
I
don't
think
we've
had
anyone
any
other
users
besides
the
spring
cloud
sleuth
that
have
been
sort
of
pressing
for
this
to
be
stable,.
A
Is
it
yeah
I
mean,
is
it
primarily
so
that
you
can
try
to
put
dates
or
expectations
to
your
users?
Are
you
getting
sort
of
pressure
from
your
users
on
releasing
something
stable
there.
G
G
G
A
And
which,
which
instrumentation
like
like
with
that?
Would
it
be
an
option
for
you
kind
of
what
we're
trying
to
do?
What
we're
thinking,
potentially
with
releasing
grpc
instrumentation
as
stable,
without
the
instrumentation
api
being
stable.
A
Would
are
you
able
to
hide
the
open,
telemetry
instrumentation
api
surface
area
from
your
users,
so
that
you
could
depend
on
that,
but
not
expose
that.
H
You
mean
by
like
shadowing
it
or.
A
A
Even
though
it's
alpha,
because
we
control
the
whole
bomb
and
so
and
we're
not
exposing
any
public
api
surface
through
the
grpc
instrumentation
from
the
instrumentation
api,
so
end
users
can
use
the
stable
grpc
instrumentation
and
benefit
from
that
without
us.
Committing
to
the
instrumentation
api
being
stable.
G
A
very
good
question
because
I
believe
like
a
right
now
and
it
it
doesn't
use
it
so
it
is
not
really
affected,
but
since
it
will
be
in
the
jar
the
users
can
so
I
believe
maybe
the
question
is
that
is
there
any
way
that
we
can?
Basically
let
the
users
know
that.
G
However,
this
is
a
stable
jar,
but
you
are
using
a
unstable
class
and
I
don't
know
like
you
can
mark
it
like
with
incubator
or
unstable
or
whatever
annotation
may
be
deprecated
as
well,
maybe
a
fair
game
or
like
force
them
to.
I
don't
know
to
provide
a
flag
like
minus
the
preview
equals
true,
and
otherwise
these
classes
will
not
work.
I
I
don't
know
from
from
saud
perspective.
G
G
It's
a
little.
Yes,
it's
a
little
bit
weird,
but
if,
if
I
believe
there
are
other
libraries
which
are
doing
this,
that
hey
this
class
is
is
incubator
like
it
can
change,
we
just
introduced
it,
we
are
receiving
feedback
and
we
might
change
it
if
you
are
using
it.
You
need
to
accept
that
fact.
G
Okay,
so
this
is
basically
like
a
different
different
char.
It
is
not,
it
is
not
just
like.
It
is
not
part
of
the
of
teacher
instrumentation,
major
okay,.
A
So
there's
the
in
here
there's
the
instrumentation
api.
A
This
is
the
one
that
you
depend
on,
and
this
is
the
one
that's
alpha
and
it
doesn't
contain
like
the
grpc
is
a
different
jar
different
okay,
so
users
could
pull
in
so
this
one
could
be
stable.
Users
can
pull
in
this
and
use
this.
This
would
have
a
run
time
dependency
on
the
alpha
jar
so
that
when
they
build
their
app,
it
gets
pulled
into
their
runtime
class
path,
but
they
can't
actually
use
the
alpha
classes
directly
without
explicitly
opting
in
by
adding
it
the
alpha
jar
to
their.
A
H
G
Okay,
I
I
thought
the
other
way
so
that
the
api
would
be
stable
and
the
api
would
depend
on
something
which
is
also
but
not
used.
G
Okay,
so
to
from
through
perspective,
the
the
important
thing
would
be
like
the
instrumentation
api
being
being
stable.
A
But
could
you
do
the
same
thing
that
we're
doing
with
grpc
and
if
your
users
don't
need
to
use
this
directly,
you
could
have
a
runtime
dependency
on
this
module.
The
the.
G
Is
that
that
sleuth
will
use
that
right,
like
this
jar,
and
if,
if
this,
if
the
instrumentation
api
will
change
and
did
there
will
be
a
breaking
change
that
would
affect
us
like.
G
And
and
also
maybe,
we
need
to
change
the
the
api
of
a
stable
like
project
that
is
depending
on
something
which
is
unstable
and
that
that
thing
can
like
freely
change
and
introduce
breaking
changes,
and
if
sleeve
goes
stable,
then
we
will
not
have
that
freedom
anymore.
So
I
believe
I
I
would.
I
would
bind
like
a
sleuth
auto
being
stable
to
the
instrumentation
api
being
stable.
G
A
A
Future
weeks
and
thank
you.