►
From YouTube: 2022-02-01 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
A
A
Good
good
yeah
so
help
wanted
I've
seen.
Sometimes
that
is
supposed
to
be
like
for
new,
like
good
first
issues,
but
I
guess.
B
B
A
C
A
A
Okay,
good,
so
we've
never
created
the
backlag
label.
So
yes,
I,
like
that
and
mateo's
just
been
doing
that
for
looks
like
half
a
year
already.
A
Nikita
anything
you
said
you
were
looking
at
the
meeting
notes
for
the
last
two
weeks.
Anything
else
you
wanna
no.
B
A
A
A
So
it
kind
of
from
josh
josh
was.
It
seemed
like
in
the
slack
josh
was
wanting
us
to
not
sort
of
my
reading
of
it
was
he
didn't
want
us
to
cave
in
the
sdk,
the
java,
sdk
and
kind
of
go
backwards.
A
So
I
think
honorable,
is
that
a
fair
to
say
you
and
jack
are
on
the
same
page
as
far
as
not
removing
the
I
forget.
No,
you
don't
have
mult
you,
you
just
don't
fail
on
mo
today.
What's
the
behavior
today.
C
A
C
C
Good
and
I've
been
bringing
up
the
async
instrument
registry
hack
that
I
wrote
multiple
times,
because
I
think
it
illustrates
pretty
well
why
we
should
have
multiple
callbacks
support
so
that
classes
like
that
do
not
exist.
And
instrumentation
authors
and
matrix
api
users
are
not
required
to
use
like
layer
over
api.
A
Yeah,
I
think
the
problem
with
that
micrometer
example
is
that
it's
it's
not
a
like
a
end
user,
like
it's
a
bridge
and
so
yeah.
You
know
bogdan
or
other
people
can
argue
that,
oh
you
should
go
about
it,
a
completely
different
way
versus
like
the
connection
pool
example,
where
it's
just
this
real
concrete.
Well,
let's
see,
how
are
you
supposed
to
implement
that.
C
I'm
planning
to
but
well
I
very
rarely
appear
there,
so
I'm
not
even
sure
how
the
conversation
will
look
like,
but
I'll
just
try
to
chip
in
with
it,
but
yeah
anyway.
It.
It
is
my
opinion
that
releasing
this
stable,
sdk
spec
without
multiple
vehicle
and
possibly
removing
instruments,
is
just
it's
not
a
good
idea,
because
we
won't
be
able
to
write
at
least
like
several
instrumentations.
C
We
probably
will
shouldn't
write
them
because
of,
for
example,
the
or
the
memory
leaks
or
research
leaks
issues
that
are
brought
up
in
one
of
these
issues
that
are
just
impossible
to
handle
without
being
able
to
their
registered
callbacks.
So.
A
A
A
And
I
saw
there
was
a
spec
issue,
respect
pr
to
mark
most
of
the
metrics
sdk
as
frozen.
A
C
A
Honorary
have
you
has?
Is
there
any
discussion
among
the
sdk
maintainers
on.
A
For
the
releasing
a
stable
sdk
without
you
know,
without
if
there's
no
multiple,
callbacks
or
unregistering
instruments.
A
E
E
A
E
C
C
E
Like
the
attributes
would
be
different
is
sort
of
one
assumption,
though
so
and
that's
like
so
I
guess
micrometer
uses
name
and
tags
for
identity,
which
this
makes
sense
to
me
and
the
hotel
also
used
attributes,
but
because
hotel
can't
register
attributes
for
instruments,
then
it's
a
bit
different
model,
but
like
a
queue
that
is
named,
something
like
it
in
a
different
queue.
That's
totally
different.
E
E
A
Okay,
well,
let
us
know
how
it
goes
at
the
spec
meeting.
A
C
A
All
right
internal
javadoc
annotation
nikita
you're
asking
for
annotation
instead
of
javadoc
yeah.
C
B
And-
and
the
answer
on
that
issue
was
that
on
unstable
api
is
meant
for
the
public
api,
which
is
yet
unstable,
but
this
use
case
is
this:
is
internal
api
and
will
be
internal
forever?
Don't
use
it.
So
that's
a
little
bit
did
different
semantics
and
I
think
that
annotation
is
better
than
just
javadoc,
because
annotation
can
be,
at
least
in
theory
verified
by
some
tooling.
B
E
Because
we
already
have
the
internal
package,
so
javadoc
is
just
clarifying
that,
but
I
think
having
both
the
internal
package
and
an
annotation
as
well
is
just
going
too
far
but
and
good
job
photo.
I
mean
john
is
much
more
in
favor
of
the
javadoc
than
me.
I
don't
care
that
much.
He
likes
that
double
check
there
as
well,
which
I'm
okay
with,
and
so
I
would
still
like.
A
And
that
that's
why
I
wrote
this
was
playing
with
the
error
prone,
because,
if
we're
going
to,
if
we're
going
to
adopt
that
convention
in
the
instrumentation
repo,
I
think
it's
a
very
annoying
convention,
not
that
it's
useless.
I
think
it
yeah.
E
A
I
couldn't
bring
it
up
on
thursday
with
john
see
what
his
it'll
be
good
to
hear
his
motivation
for
it
being
javadoc.
A
Okay,
are
you
good
with
going
forward
with
that
pr
yeah,
yeah?
Okay,
oh
honor,
I
I
couldn't
get
the
convention
thing
working
the
problem
I
had
so,
if
you
put
it
in
the
java
file
and
build
source
in
the
conventions,
it's
available
on
the
compile
class
path
right
so
but
the
problem
was,
I
didn't
know
how
to
make
it
an
annotation
processor
on
the.
E
A
E
B
C
A
Check
because
this
is
another
one
of
these
like
instrumentations
producing
logs,
so
it's
using
the
sdk
directly.
E
A
E
E
E
A
B
A
Oh
yeah,
the
running
instrumentation
test
against
the
full
java
agent
did
you
nikita?
Did
you
have
thoughts
on
how
so
currently
would
have
all
of
like
the
internal
instrumentations
and
things
that
we
run
all
the
tests
against
in
that
like
base
java
agent.
B
We
have
base
agent
and
model
specific
extensions.
We
can
create
the
full
full
agent
and
use
that
intel's,
but
anorak
was
against
that
like
some
time
ago,
because
creating
a
full
agent
takes
more
time.
If
you
just
want
to
take
several
modules,
it
will
be
slower.
I
argue
that
if
you
want
to
test
everything,
it
will
be
still
faster
because
you
create
full
full
agent
only
once.
E
B
A
I
think
what
andrag
and
I
were
imagining
is
in
you're
working
in
instrumentation
a
and
that
one
is
you
would.
The
extension
would
have
all
the
other
instrumentations
except
that
and
then
instrumentation
a
would
still
come
from
yet
another
extension.
A
B
A
Yeah
yeah,
I
I
like
the
I
mean
I
like
the
idea
just
the
same
concern
of
the
performance,
but
it
may,
but
it
may
not
be
a
issue.
A
A
So
we
could
do
something
like
in
the
build
sort
of
like
the
api
diffs,
where
we
could
run
that
and
if
there's
any
difference
fail.
The
build.
A
E
E
Why
why
not
like
the
version
number
is
also
in
there
like,
if
you
happen
to
update
twice
it's
sort
of
annoying
to
update
the
licenses
multiple
times,
not
a
big
deal,
though.
E
E
A
All
right
that
was
my
any
and
what
was
on
my
mind
anything
james.
Anything
on
your
mind.
D
Nothing
too
much.
I
haven't
really
just
getting
back
into
the
hotel
space
after
the
new
year
at
the
moment.
So
not
really
I'm
just
kind
of
here
to
see.
What's
going
on
yeah
I
like
them,
the
micrometer
stuff
is
really
interesting,
though
that's
just
like
we
use
micrometer
all
around
atlassian.
D
It's
like
the
kind
of
standard
thing,
so
that
would
be
really
interesting
for
us
once
it's.
I
don't
know
what
what
kind
of
state
is
it
at
the
moment.
D
D
Yeah:
okay,
now
that
sounds
sounds
good.
Yeah
that'll
be
that'll,
be
awesome
for
us.
I've
also
been
looking
at
the
agent
as
well
trying.
D
Still
still
figuring
things
out,
but
yeah,
that's
cool,
good
stuff.
D
A
Yeah
we
would
love
feedback
on
the
micrometer
stuff.
We've
been
chatting
and
the
micrometer
folks
have
been.
We've
had
a
lot
of
collaboration
with
them
in
the
the
last
month
or
so.
A
D
A
We're
not
sure
what
to
do
yet
on
the
micrometer
tracing
side.
The
micrometer
metric
side
is
super
clear,
because
it's
just
I
mean
such
a
de
facto
standard
in
the
java
space
that
it
just
makes
a
ton
of
sense
to
bridge
it,
and
we
can
bridge
it
efficiently
and
we
can
bridge
it
into
the
sdk.
So
it
feels
like
a
pretty
nice
solution.
A
And
there's
a
little
bit
of
mismatch
on
some
of
the
context,
propagation
stuff.
That
probably
just
needs
a
lot
more
usage
of
that.
If
you've
seen
there's
the
hotel,
sleuth
bridge.
D
D
C
Is
migrated
to
micro
yeah
and
there
should
be
a
like
later
trace.
Yeah
there
is
my
community
tracing
bridge
hotel
artifact
over
there
in
the
microwave
tracing
repo.
D
Yeah
cool
I
have
to
have
a
play
around
with
the
micrometer
stuff,
whether
that's
in
the
agent
or
just
as
library
instrumentation
will
be
remains
to
be
seen-
probably
library,
instrumentation
but
yeah
I'll.
Let
you
know
if
I
happen
to
keep
it.
D
A
Cool
nikita
you're
dealing
with
post
post
vacation-
I
don't
know
depression
syndrome.