►
From YouTube: 2021-10-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).
B
B
B
From
at
last
did
nikita
and
mattias
have
you
met
james.
C
B
James
is
a
actual
user
from
atlassian.
A
B
Yes
and
also
another
representative
from
our
the
what
asia,
pacific
time,
australia
right
james,
no
there's
like
eight
time
zones
in
australia,
though
I
just
saw
for
some
reason.
My
son
was
just
asking
about
this
and
we
looked
it
up
and
it
was
very
confusing
to
me.
B
A
We
grew
in
multiple
assignments
that
we
have
in
some
tests,
so
we
we
have
to
use
2.1,
which
is
still
snapshot,
but
if
we
use
2.1
snapshot,
then
everything
almost
everything
works
out
of
the
box.
We
have
to
do
some
small
changes,
the
biggest
change
and
that
change
is
actually
common
both
for
java
part
for
converting
to
java,
I
think
and
converting
to
spock
2,
that
our
smoke
tests,
which
use
a
custom
sputnik
based
runner,
test,
runner
and
sputnik,
was
removed
from
spoke
too.
A
So
anyway,
wherever
we
we
convert
our
tests.
We
have
to
migrate
our
smoked
application
server
test
runner
that
we
have
to
do
anyway,
and
I
don't
object,
converting
our
smoke
tests
to
java
meaning
unit
5
and
then
finding
a
way
to
replace
our
custom
runner
because
well,
we
have
to
do
that
work
anyway,
but.
A
As
after
that
migrate
into
spock,
2
and
groovy
3
is
actually
easy.
B
A
B
Cool
sounds
good
this
one,
oh.
E
A
A
C
E
Yes,
so
it
yeah
librarian
users
to
have
some
config
mechanism
already.
That's
the
main
motivation
for
not
trying
to
use
our
own
because
it
wouldn't
integrate
with
that
anyways.
A
So
so
I
agree
that
probably
we
should
have
some
code
based
over
over
other
right
mechanism
speaking
about,
but
I
wouldn't
bring
spring
as
an
example
here,
because.
A
What
what
I
want
to
say
about
spring,
I
want
to
say
that
probably
we
shouldn't
do
that.
Much
work
regarding
spring
because
spring
spring
users
already
have
their
own
observability
built
in
especially
now
that
spring,
starting
that
spring
observability
pro
project,
which
is
still
in
alpha,
but
anyway,.
C
A
Yes,
okay,
but
but
even
if
you
have,
even
if,
given
library,
have
a
speci,
its
own
specific
configuration
module,
don't
you
agree
that,
for
example,
that
they
can
use.
A
Our
config
to
feed
the
configuration
mechanism
again
because
we
have
we,
we
provide
that
environment.
Variable
system
properties,
spec
even
started
to
think
about
a
configuration
file
that
will
be
also
embedded
into
our
in
our
config,
so
one
config
source
for
all
open,
telemetry
supported
configuration
sources
that
may
be
useful
for
library
instrumentations
as
well,
even
if
just
to
fit
library
specific
configuration
mechanism
from
the
single
source.
B
How
do
you
see
it
compared
to
like
the
auto
configure
module
in
the
sdk
like
I
was
for
a
library
instrumentation,
for
example,
like
the
the
auto
configure
is,
is
only
specked
out
configurations
right.
So
it's
a
more
limited
stable
set,
but
we
do
I
mean
we
do
take
that
in
and
we
do
configure
based
on
that.
B
E
Yeah,
that's
the
model
we
took
for
the
sdk
like
we
wanted
a
separate
configuration
and
programmatic
setup
so
that
we
could
imagine
that
for
ours
as
well,
it's
a
bit
annoying
that
every
library
would
probably
have.
I
can
type
an
auto
configure
or
something
like
that,
but
that
allows
the
auto
configuration
to
be
separate.
A
A
A
E
B
So
can
you
say
that
again,
so
the
tracing
builder
has
setters.
B
A
And
it's
so
if
we
are,
if
we
are
thinking
that
we
don't
want
developers
using
library
instrumentations,
we
don't
want
them
to
force
using
our
configuration.
C
C
E
A
E
B
C
Okay,
so
next
questions
should
we
move,
I
mean,
should
I
delete
my
pr
of
the
experimental
config
class,
I
was
planning
to
move
it
to
java
agent
instrumentation
api,
but
now
that
we've
decided
that
config
actually
should
be
placed
in
instrumentation.
E
C
That,
probably
the
experimental
graphic
class
should
also
be
there
since
it's
it's
supposed
to
be
used.
As
I
mean,
even
our
library
instrumentation
sometimes
have
those
set
experimental,
something
something
options,
so
it
should
be
used
as
the
default
source
of
values
for
those.
C
I
think
it
was
supposed
to
encapsulate
the
property
names
like
you,
you
don't
really
have
to
remember
the
whole
string.
You
just
ask
for.
I
don't
know.
B
C
A
A
I
I
I
even
not
sure
like
okay,
our
virtual
field,
they
work
only
in
java
agent,
or
can
they
work
without
javascript.
A
C
Yeah
I
mean
if,
if
we
move,
if
we
move
back
or
decide
to
remove
the
configure's
edges
from
there
and
if
we
get
rid
of
what
was
also
there,
oh
yeah,
the
pv
service
attribute
extractor.
Then
it's
just
a
couple
of
things
and
maybe
you
can
move
it
merge
it
with
the
instrumentation
api.
E
E
A
Wait,
what
does
it
mean?
They
certainly
forgive
challenge
like
class,
yes,
classes.
E
A
A
Yes,
that
that
makes
sense
only
in
in
instrumentation
java
agent,
okay
called
sdk.
E
A
A
B
A
A
A
B
E
We
have
sort
of
a
goal
to
keep.
I
guess
our
important
api
as
small
as
possible,
just
to
make
sure
it's
like.
If
a
library
author
is
writing
their
instrumentation,
we
don't
want
them
to
get
confused
by
this
call
depth.
Maybe
they'll
use
it
in
some
bad
way,
like
the
less
apis
that
are
the
easier
it
is
or
the
harder
it
is
to
have
mistakes
in
the
library
instrumentation.
A
A
B
How
about
I
would
propose
that
you
know
for
now
we
keep
the
split
and
keep
things
in
the
java
agent
api
where
we
can,
but
then,
let's
revisit
you
know
as
we
get
closer
if
more
things
end
up
bridging
over.
B
I
don't
know
what
what
are
you
trying
to
you're
just
trying
to
keep
the
number
of
modules
down.
A
A
So
that's
that
choice
in
some
cases
is
more
or
less
arbitrary.
At
least
that
seems
to
that
seems
to
me
right
now.
I
I
don't
quite
understand
where,
where
any
gear
and
class
should
go
like
that
three
class
that
we
have
in
java
agent
instrumentation
api,
why
is
that
in
java
agents
instrumentation
api,
not
in
the
instrumentation
api.
A
E
E
C
Was
used
in
one
of
the
classes
in
bootstrap
passover
yeah
the
instrument,
this
task
classes
that
one
so
yeah,
but
I
agree
that
we
probably
shouldn't
expose
it.
Yeah.
E
C
A
E
E
A
B
I
think
the
if
you're
looking
for
sort
of
a
rule
of
thumb
for
where
things
go,
the
at
least
the
rule
of
thumb
that
I
sort
of
think
of
is
just
that.
Instrumentation
api
is
going
to
be
the
most
important
public
api
that
this
repo
publishes,
so
things
should
only
go
in
there
if
really
necessary,
if,
like
that
should
be
so,
if
there's
other
options
and
possibly
the
java
agent
instrumentation
api.
B
A
B
Yeah,
let's
see
what
this
trims
down
to,
because
you
know,
maybe
if
we
put
some,
you
know,
look
through
it,
we
might
find
that
there
are
only
a
couple
that
you
know
like
this.
One
does
feel
to
me
like
a
java
agent
instrumentation
concern,
and
this
one
also
very
specifically,
because
of
instrumenting
java
7
code.
A
B
But
you're
right
nikita,
I
when
we
introduced
the
client
suppression,
I
deleted
a
bunch
of
the
call
depth
because
it
was
duplicative
with
the
client
suppression.
B
So
it's
a
that
we
have
a
few
weird
usages,
but
maybe,
if
they're
you
know,
another
option
is
if
it's
weird
enough,
like
one-off
stuff,
it's
not
worth
having
in
here
right.
We
can
now
that
we
have
that
ability
to
create
an
instrumentation,
specific,
bootstrap
module
or
just
inject
it.
We
could
just
copy
this
into
somewhere.
That
needs
it.
B
E
B
E
B
A
B
Yeah,
the
reason
was
was
more.
At
least
the
question
I
had
was:
what
what
advantage
do
we
get
from
user
perspective?.
A
We
do
have
users
who
want
to
use
extension
api
to
implement
their
own
propagators
or
samplers
for,
for
example,
and
for
them
instrument
instrumentation.
They
they
don't
care
about
that,
but
they
want
to
depend
on
something.
I
know
that
that's
stable,
so
for
them
the
declaring
of
extension,
extension,
api
and
extension
mechanism
in
general
is
stable.
You
now
can
rely
on
that.
That
may
be
important
got
it
so.
E
A
A
E
C
E
E
A
A
A
E
E
A
D
Yeah,
that's
an
interesting
question.
I
was
just
thinking
about
it.
I
mean
currently,
we
we
just
use,
we
just
configure
the
sdk
just
via
code
and
that
works
fine
for
us,
because
we
just
kind
of
configured
the
sdk
for
everyone
consuming
our
library.
But
you
know
a
yaml
file
is
always
nice.
I
like
yellow
files,
is
that
something
that
is
is
looking
to
be
done.
I
know,
there's
some
talk
in
the
spec
about
that
sort
of
thing.
E
So
do
you
have
any
sort
of
opinion
on
whether
you
would
desperately
want
the
hotel
stuff
to
also
be
in
that
same
conflict
mechanism
or
having
a
separate
one?
That's
not
tied
to,
for
example,
the
application
profile
like
there's
so
many
sprint
features
we
wouldn't
be
able
to
support
with
our
yaml
file.
So
I
wonder
how
much
value
it
actually
provides.
E
E
D
D
E
B
All
right,
I
added
this
just
you
know,
but
we
obviously
talked
plenty
about
this
and
then
it's
been
on
nikita's
mind,
but
I
think
it's
a
good,
recurring
topic
to
just
make
sure
we're
tracking,
I
don't
know,
did
you
think
of
anything
more
nikita
about
how
to
track
progress
towards
stability.
A
B
This,
oh
yeah,
any
thoughts
honorary.
Did
you
have
a
chance?
I
know
because
you
probably
have
the
most
experience
with
the
this
mechanism
from
the
sdk
repo
yeah.
E
B
A
E
A
Yeah
so,
but
I
I
actually
still
not
quite
sure
that
then
I
fully
understand
how
exactly
do
you
use
this
task
in
comparison
in
in
in
sdk,
I
mean.
A
A
B
And
does
it
fail
anything
if
you
break
an
api
or
that's
like
if
you
remove
something
it's
just
manual.
E
A
Actually,
not
for
all
that
we
want
to
declare
stable.
I
I
took
that
from
some
of
the
tasks
got
it.
I
see,
you
just
add
it
wherever
we
want
it.
A
B
A
A
E
E
B
B
Nikita
called
it
in
like
a
year
ago,
here,
the
so
the
the
we
just.
We
keep
drifting
back
to
this
format,
even
though
everybody
except
me
prefers
the
nullable
up
here,
and
I
I'm
okay
with
the
drift,
but
I
do
prefer
consistency
so,
but
this
is
why
it
keeps
drifting
because.
B
And
I
did.
I
was
wondering
why
the
sdk
repo
wasn't
having
this
problem
and
it's
because
in
the
sdk,
it's
using
the
not
using
the
checker
nullable
and
the
checker
nullable,
specifically
targets
type
use,
so
versa,
where
this,
of
course.
E
I
think
someone
I'd
say
the
primary
reason
I
wanted
like
sdk.
I
never
actually
got
around
to
switching,
but
I
was
sort
of
wanting
to
use
the
checker
framework
version
because
of
some
mess
in
jakarta,
like
there's
the
annotation
module
that
the
version
2x
or
something
moves.
The
package
like
there's
a
breaking
change
in
jakarta,
annotations.noble,
or
something
like
that.
So
I
think
javax
annotation
has
some
chance
of
dependency
conflicts
unless
we
do
it
carefully,
which
we
can
so,
but
I
just
didn't
want
to
deal
with
that,
but
we
can
deal
with
it.
E
So
that's
probably
the
main
motivation
of
not
using
javaxx
annotation
at
the
time
we
don't
get
any
special
note
miss
checking
because
we
don't
use
the
checker
framework
because
no
way,
no
way
it
doesn't
do
type
annotation
type
of
checks
check
for
framework.
Would
I
don't
think
we're
gonna
ever
use
the
checker
framework,
because
it's
a
bit
insane,
so
we
probably
don't
get
any
special
functionality
there.
E
E
E
Yeah,
I
think
we
can
probably
try
to
go
back
to
javafx
annotation
our
code
baseball,
so
that
seems
to
make
sense
what
happened
in
armory.
Is
they
defined
their
own
nullable?
That
extends
from
javax
annotation
like
apparently
that's
what
they
needed
for
maximum
cockpit
features,
and
I
found
that
to
just
be
making
the
problem
even
worse.
B
This,
oh
just
if
I
may
honor
I
I
did
not
understand.
B
E
B
E
B
E
B
Yeah
yeah,
let
me
give
that
another.
Try
net
attributes,
extractor
api
change,
there's
two
options
to
now.
Now,
since
that,
since
you
woke
up
mate,
I
sort
of
went
back
but
then
went
forward
so
anyway
have
a
have
a
look
and
we'll
get
this
is
this
is
probably
if
you
haven't
been
for
non-mateish
people.
B
E
E
E
B
Yeah,
well,
usually,
I
think
there
was
in
some
cases
but
you're
right
that
it
it
it
may
be
not
correct
and
that
it
may
be
based
on
the
url
and
not
based
on
the
actual
opened
connection.
Is
that
what
you're
getting
at.
E
E
E
B
As
the
http
host,
that's
a
good
question:
why,
like
I
mean
net
peer,
I
p.
I
definitely
get
right,
but
why
net
pure
name?
Could
you
are
you
thinking
that?
Because
it
could
resolve
to
something
different
or
just
that
it's
duplicative
then.
E
B
E
B
And
this
was
sort
of
what
we
kind
of
knew,
except
that
they
enhanced
this,
that
we
should
send
our
explanation
to
the
government's
committee.
I
don't
think
there
would
be.
E
B
Issue
with
this
given
the,
but
I
did
want
to
bring
up
the
the
option
of
doing
a
release,
branch
and
prs
against
the
release
branch.
I
I
kind
of
like
from
like
it's
a
little
weird
doing
a
patch
really
going
during
the
patch
release
process
with
that
doesn't
require
any
review.
E
E
A
A
A
B
A
A
E
E
E
A
E
B
E
A
E
B
E
A
E
A
B
B
In
the
I
couldn't
get
a
clean
anything
so,
but
I
was
kind
of
curious
if
I
had
terry
picked
some
files
yeah.
B
So,
let's
see
what,
if
anybody
has
more
thoughts
later,
we
don't
have
to
decide
now.
B
All
right,
that
was
a
lot
of
things,
anything.
B
C
I
have
beer
with
the
http
headers
extraction
open,
so
I
I
think
nikita
has
already
approved
it,
but
I
appreciate
it
yeah
with
somebody
else.
C
That's
what
I
fixed,
but
this
one
that
I
mean
we
don't
ever
expose
the
attribute
keys
in
any
public
apis.
So
I
thought
it
would
be
a
bit
better
to
hide
them
and
if
you
have
like
multiple
clients,
multiple
server
instrumentations
working
at
once,
then
with
the
cache,
you
can
be
sure
that
there's
exactly
one
instance
of
an
attribute
key
for
one
header.