►
From YouTube: 2021-05-20 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
B
C
E
I
got
I
got.
E
To
talk
about,
or
at
least
mention,
if
there's
nothing
else,
I
was
gonna
put
it
on
the
agenda.
But
one
of
the
engineers
I
was
hoping
was
going
to
join
up,
didn't
didn't
make
it
because
it's
kind
of
late
for
him,
but
we
are
working
on
a
logging
prototype
using
log
back
and
log
for
j
and
basically
creating
an
appender.
E
There's
an
issue
open
for
it.
I
believe,
but
we're
trying
to
build
sort
of
like
a
poc
using
the
hotel
logging
standards
so
to
speak.
E
In
java,
so
that
was
kind
of
where
we
started
and-
and
I
can
update
the
meeting
notes
with
with
the
issue-
that's
open.
E
So
so
I
was
just
joining
the
meeting
to
hopefully
with
one
of
them,
but
they're
not
able
to
make
it
so
just
kind
of
a
heads
up
and
meet
the
community,
and
such
I've
done
a
lot
of
work
personally
on
the
collector
side,
especially
on
tracing.
So
but
my
first
time
meeting
with
you
all
so
good
good
to
be
here.
F
It
would
be
super
cool
if
you
you
all
and
maybe
work
with
jason
plum
on
this,
because
he's
also
interested
could
write
in
an
otlp
logs
exporter
and
maybe
work
a
little
bit
on
the
log
model
inside
the
the
sdk.
F
There's
a
there's,
a
very
kind
of
rough
prototype
version
of
that
right
now,
but
it
doesn't
really
match
the
style
or
structure
of
the
tracing
and
metrics
object
model.
Okay,
that
would
be
super
helpful.
E
No,
that's
that's!
Basically
what
we're
building
I
was
just.
I
was
just
gonna
pull
up
the
issue,
but
yeah
the
idea
behind
it,
and
there
was.
There
was
kind
of
some
discussion
on
the
on
the
slack
channel
about
it,
but
we're
basically
going
to
create,
like
emitter,
an
emitter
and
a
sink
essentially
and
kind
of
like
create
the
different
components
that
we
would
use
for
this.
E
So
there
isn't
anything
currently
built,
but
we've
kind
of
mapped
out
the
tests
and
we're
starting
on
the
work,
so
cool
yeah
we're
definitely
interested.
So,
let's
yeah
looking
forward
to
seeing
some
of
that
yeah
for
sure
yeah.
You
should
see
some
stuff
soon
on
that
side
and
we've
been
building
off
of
the
kind
of
the
the
early
early
alpha
code.
That's
already
there
kind
of
that
someone
wrote.
We
talked
to
him
about
that
on
on
slack.
E
So
we
we
chatted
with
david,
I
guess,
did
the
initial
work,
and
so
we
chatted
with
him
to
kind
of
add
on
or
continue
where
he
left
off
and
he
had
a
couple
questions.
But
so
yeah.
F
I
think
the
thing
that
I
would
like
to
see
is
right
now
the
way
david
built
it.
He
didn't
use
any
of
the
existing
things
like
attributes
and
the
classes
that
we
already
have
built
for
tracing
and
metrics
and
it'd
be
really
great
to
use,
use
all
those
same
classes
that
we've
already
built
and
support,
rather
than
kind
of
reinventing
the
wheel
for
logging,
which
is
what
is
in
there
at
the
moment.
Yeah.
E
F
F
E
I'll
definitely
provide
that
guidance
to
the
the
team
here
on
that
street
awesome.
Does
anybody
who
might
have
peeked
in
on
other
sigs
have
a
sense
of
where
logs
stability
in
the
spec
is.
F
It
is
basically
it's
probably
close
to
complete,
but
it's
totally
on
hold
because
we
want
to
get
metrics
done
first.
I
think
that's
what
it
is.
It's
not
declared
stable,
but
it's
probably
pretty
close
to
actually
like
de
facto
stable.
Okay
just
nobody's
working
on
it,
because
we
want
to
get
metrics
done.
E
Yeah,
so
that's
why
we
kind
of
started
on
this,
because
I
felt
like
this
had
been
sitting
around
forever
and
no
one
was
doing
anything
and
then
it
was
kind
of
like
which
sdk
do
we
implement
the
poc
and-
and
we
were
just
more
comfortable
in
java,
so
we
decided-
and
there
was
obviously
a
little
bit
of
stuff
there,
so
it
was
kind
of
the
idea
was
implemented
there
actually
ohad
on
my
team
he's
on
the
call
he's
sort
of
silent-
it's
pretty
late
there
in
in
israel,
so
but
yeah
he's
he's
working
on
it.
E
A
Yeah,
it's
great
timing.
We've
been
getting
a
couple
questions
recently
from
users
about.
A
B
A
Your
work,
like
the
the
logging
sdk
and
the
logging
exporter
would
go
here
and
appenders
would
go
over
here.
A
B
A
E
F
It's
in
the
it's
just
in
the
java
in
in
the
regular,
open,
telemetry
java.
It's
one
of
the
api
classes.
Okay,
got
it:
okay,
cool.
E
E
E
Cool
I
mean
that
was
kind
of
it,
but
I'll
try
to
attend
when
I
can
just
to
kind
of
see
what's
going
on,
give
updates
and
and
that
we
didn't
open
an
issue
on
this.
I
don't
believe.
Do
you
want
us
to
do
that
or
open
a
proposal
like
we,
we
sort
of
had
to
navigate
around
a
little
bit
before
we,
you
know,
came
to
the
right
group
team
here
so.
F
E
F
E
Pretty
loosey-goosey,
okay
cool,
I
wasn't
sure
if
there
was
some
groups
want
a
certain
like
set
of
questions
answered
in
a
proposal
or
something
like
that,
but
okay,
yeah
we'll
do
that
for
sure
yeah.
We
leave
that
up
to
the
specs
in
which
repo
do
you
want
it
and
that's
the
other
tricky
question
I'm
assuming
in
the
in
the
instrumentation
repo.
Well,
I
would.
F
I
would
like
an
issue
just
in
the
open
source
java,
just
to
track
writing
and
creating
like
fleshing
out
the
log
model
and
the
exporter
and
an
otlp
exporter
for
logs.
F
E
F
I
mean
export
format
because
otlp
obvious
is
only
one
case,
but
you
might
want
to
append
to.
I
don't
know
something
else:
okay,
so
having
having
kind
of
that
independent,
like
I
guess
so.
What's
the
right
word,
a
log
object
model
which
it's
gonna
be
super
simple
right
logs
are
not
complicated.
They
don't
there's
not
a
lot
of
data
in
there.
Wow.
F
All
of
that
code
is
in
our
cement,
our
semcom
semantic
convention
module
and
that's
all
generated
from
the
spec.
So
that
is
the
that's
something
that
I
mean.
I
don't
know
if
we
have
logging
semantic
conventions
in
the
yaml
in
the
spec,
yet
I
don't
think
we
do
I'm
not
sure
but
yeah
the
semantic
conventions.
That's
one
thing,
but
then
there's
also
just
the
object.
The
java
objects
that
we
want
to
use
the
pojos.
F
We
want
to
use
for
kind
of
the
common
model
between
log
back
and
log
for
j
and
log,
for
whatever
the
new
logging
framework
somebody
invents
next
week,
because
they're
bored
and
it
needs
to
be,
I
mean
easily
bridgeable
over
to
otlp,
obviously,
because
we
want
that
to
be
super
efficient,
but
it
shouldn't
be
just
raw
protobufs,
because
protobufs
are
nasty.
A
F
E
A
All
right
we're
at
the
end
of
our
agenda,
who
wants
to
speak,
who
has
to
speak
up
anything.
B
Jonathan
hi,
do
you
do
you
happen
to
have
any
update
on
the
roadmap
of
the
instrumentation
going
to
stable.
A
There
has
been
progress,
three.
B
Instrumentation,
like
the
java
minus
instrument,
we
have
an
instrumentation
packaging,
maven
central,
the
instrumentation
api.
I
believe
that
is
considered
a
stable
should
went
out
with
the
tracing
api
right.
F
B
A
Updates
on
it
I
mean
there's
been
work
towards.
This
is
the
main
thing
that's
happening
and
there's
been.
You
know,
issues
targeting
this
pr
is
targeting
this,
but
if
you're
asking
for
a
date,
we
don't
have
a
date.
B
I
am
not
asking
for
like
a
specific
date,
but
any
any
plan
or
any
any
roadblocks.
A
The
plan
is,
oh
sure,
the
roadblock
is
on
this
issue
and
the
plan
is
to
update
all
of
the
instrumentation
to
the
new
instrument
or
api
before
we
declare
the
new
instrument
or
api
stable.
B
Okay,
cool
and
does
this
have
any
dependency
on
on
the
metrics
specification
or
implementation.
A
No
well
so
it
has
a.
It
does
have
a
dependency
on
metrics,
the
metrics
api,
but
it's
a
very
light.
There's
just
a
couple
of
methods
in
the
in
here
that
need
that
use
it
and
they
are
marked
those
methods
are
marked
with
the
unstable
annotation.
A
A
Yeah,
I
think
we
just
chatted
about
that
on
in
our
earlier
meeting
this
week.
Nikita,
I
think
nikita
brought
that
up.
A
C
A
All
right!
Well,
why
don't?
I
do
quickly
the
the
week
in
review,
so
we
can
look
at
prs.
Just
a
quick
look
at
pr's
merged
in
the
last
week.
Oh
only
36,
okay
falling.
A
What
was
our
oh,
no,
that's
right
on
our
average,
our
average,
because
I
looked
it
up
on
the
dev
stats.
Recently
it
was
about
five
pr's
a
day.
A
So
we've
been
having
a
lot
of
flaky
build
problems,
so
this
is
good
stuff.
I
think
we
still
have
a
ways
to
go
with
our.
I
don't
know
why
that
it
kind
of
fluctuates
in
flakiness.
It
felt
like
we
had
gotten
to
a
better
place,
and
then
it
went
sour.
A
A
bunch
of
cleanup
stuff:
this
was
a
memory
leak.
That
was
a
good
fix.
We
still
don't
check
like
we
removed
in
this
one
place
is
recording.
We
don't
check
that
at
some
point.
It
would
be
interesting
to
see
if
that's
something
we
want
to
apply
throughout
all
the
instrumentations
as
like
an
optimization
before
collecting
attributes.
A
Maybe
it
makes
sense.
I
wonder
materias
in
the
new
the
instrument.
B
A
A
bunch
of
muzzle
work
get
going
towards
being
able
to
break
out
the
muzzle
plug-in
as
a
standalone,
gradle
plugin,
which
will
be
really
great
for
people
building
their
own
java
agent
instrumentations.
To
be
able
to
use.
A
That
more
test
cleanup-
oh
here's
yeah.
So
this
is
us.
We're
gonna,
probably
see
a
lot
of
these
over
the
next
week,
updating
individual
instrumentations
to
the
new
instrument
or
api.
We
have
a
couple
open
in
flight
also
and
hopefully
that
will
we're
expecting
that
to
help
flush
out
any
kind
of
small
issues
in
the
instrument
or
api
there's.
A
couple
pr's
yesterday
also
flush
that
came
out
of
observations
of
while
updating
some
of
these
http
quiet
instrumentations
of
test
flakiness.
A
A
A
More,
this
is
really
great.
Our
servlet
advice,
of
course,
is
very
contorted
because
we
take
into
account
all
these
things
like
was
this
band
started
in
tomcat,
because
we
natively
instrument,
tomcat
or
undertow,
to
get
the
full
span,
the
full
request,
even
beyond
just
the
servlet
instrumentation
and
then
a
lot
of
other
things.
So
we've
been
making
some
good
progress
lately
on
simplifying
the
that
those
contortions-
and
this
nikita
talk
about
this.
C
Essentially,
the
first
pull
req
the
first
pull
request
into
allowing
much
simpler
extension
of
java
agent.
So
so
far,
if
somebody
wanted
to
add
their
own
sampler
or
exporter
or
instrumentation
or
iid
generator
they
have
to,
they
had
to
repackage
the
whole
challenge
and
strictly
follow
our
shading
rules
in
their
build
scripts
and
whatnot.
So
it
was
quite
complicated.
C
C
A
That's
it,
this
is
a
a
lot
of
people
want
to
add,
like
customize,
add
their
own
sampler,
add
their
spam
processors
to
the
java
agent,
and
that's
been
really
painful
up
to
this
point.
So
this
is
a
much
watched
feature.
C
Yep
next
step
is
doing
proper
example
with
more
proper
the
documentation,
and
maybe
if,
if
I
decide
this
is
needed
some
how
to
if
with
me,
is
not
enough,
then
I
will
start
pushing
that
to
our
clients
and,
let's
see
how
that
goes.
F
Yeah
having
some
documented
guidance
on
when
to
use
when,
when
to
use
the
extensions
versus
when
to
just
configure
versus
when
to
build
your
own
agent,
I
think
that
having
those
guidance
like
maybe
a
flowchart
or
something
like,
if
you
need
to
do
this,
this
is
the
easiest
way
to
do
it.
If
you
want
to
do
this,
this
is
the
easiest
way
to
do.
It
would
be
really
helpful.
I
think.
C
A
And
I
I
really
like
that,
the
extension
that
we
don't
really
have
to
add
new,
like
an
api
for
these
extensions,
that
it's
all
built
on
top
of
the
it's
just
using
the
sdk's
auto
configure
apis.
A
Yeah
I'll,
let
me
ask
onorag
about
that,
because
he
has
thought
he
was
debating
for
a
while,
whether
that
should
go
over
to
the
auto
configure
module.
A
True
for
building
for
building
java
agent,
yes
for
building
instrumentation,
yes
right,
that's
a
good
point
that
extensions
is
not
just.
I
forgot.
Extensions
are
not
just
about
extending
the
sdk,
the
underlying
sdk.
It's
also
now.
We're
kind
of
using
that
term
to
include
custom
include
instrumentations.
A
All
right,
I
think,
that's
it
any
last
any
last
topics.
Anybody
thought
of.
G
I
actually
thought
of
something
when
we
were
earlier
when
you
mentioned
the
separating
out
the
muzzle
plug-in.
So
I
looked
up
the
issue
and
saw
that
there's
kind
of
a
blocker
on
that
because
of
the
circular
dependency
between
the
build
plug-in
and
the
source
code.
G
And
here
let
me
just
paste
the
issue
that
I'm
looking
at
so
paul
suggested
a
proposal,
and
I
wanted
to
kind
of
maybe
take
that
one
step
further
and
say
that
what
if
the
plug-in
portion
that
got
published
was
a
little
bit
more
generic
and
said
just
for
any
arbitrary
maven
dependency
within
a
particular
range.
G
Do
a
specific
action
and
then
that
action
could
be
defined
in
the
gradle
task
and
that
could
potentially
make
it
so
that
you
know
a
portion
of
the
the
the
the
large
portion
of
the
plugin
could
be
published
externally
and
then
have
the
task
definition,
not
even
necessarily
in
the
the
build
source
folder.
C
G
That
yep
I
mean,
ultimately,
you
want
kind
of
a
a
more
generic
plug-in
that
says:
hey
for
a
particular
maven
range,
apply
a
specific
action
and
then
that
action
could
be
defined
at
the
task
level
right.
G
Well
so
this
could
potentially
be
done
with
somebody
that
wants
to
scan
maven
artifacts,
for
you
know,
security
vulnerabilities
or
scan
maven
artifacts,
for
you
know
particular
api
usage
or
or
like
I,
I
guess
what
I'm
trying
to
say
is
like
there's
other.
C
G
Yeah,
the
other
thing.
B
G
You
could
potentially
benefit
from
that
is
having
a
portion
of
that
of
the
plug-in.
That
doesn't,
for
example,
depend
on
you
know,
open
telemetry,
internals
or
the
instrumentation
api,
or
something
like
that,
because,
right
now,
it's
very
closely
correlated
between
you
know
the
build
plug-in
and
a
muzzle
and
the
rest
of
the
source
code.
C
G
D
By
the
way,
I
sort
of
broke
this
dependency
circle
for
the
muzzle,
compile
type
plugin,
because
we
have
several.
You
know
all
this
code
generation
classes
that
are
still
located
in
tooling,
but
all
they
depend
on
is
in
the
ex
java
agent
extension
api,
which
is
supposed
to
be
made
stable
in
in
the
future.
G
Right
so
there's
still
a
certain
amount
of
circular
dependency,
but
would
that
still
work
if
you're
trying
to
push
publish
it
as
like
an
external
plugin?
So
I.
D
Thought
that
we
could
make
the
javaigen
extension
api
module
stable
and
you
could
it
could
serve
as
a
spi
sorry
api
for
the
muzzle
compile-time
plug-in,
which
could
be
used
in
the
ins
in
generation
instrumentations,
which
themselves
would
also
depend
on
the
extension
api.
So
as
long
as
you
keep
the
version
of
the
extension
api
used
by
generation
instrumentation
and
the
muzzle
compiles
that
you
plug
in
the
same
or
consistent,
it
would.
G
G
Made
instrumentation
api
changes
for
some
some
reason.
You
wouldn't
necessarily
pick
that
up
within
the
build
project
until
it
got
published
and
then
the
build
started.
Failing.
A
A
So
if
we
wanted
to
make
changes
there,
they
would
be
sort
of
two-step,
like
we
could
make
a
change,
make
a
release
and
then
depend
on
that
yeah.
Exactly.
G
Another
another
potential
option
would
be
like
making
a
more
generic
api
for
a
muzzle
that
muzzle
owns
and
then
using
that
api
internally,
like,
for
example,
you
know,
instead
of
having
a
muzzle
call
a
specific
interface
within
our
implementation.
That's
on
the
agent
api.
We
could
make
that
interface
defined
in
muzzle
and
have
like
a
muzzle
a
muzzle
api,
for
example.
That
is
like
a
separate,
published
jar
that
are
that
we
use
as
a
compile
time
dependency.
G
That
would
be
internal
to
the
project.
G
So
the
plugin
would
say:
hey
it
could
potentially
use
like
a
service
loader
or
something
like
that.
Like
give
me
an
implementation
that
implements
this
interface,
I
I
I'm
still
fuzzy
on
the
details
of
that.
I'm
just
saying
that
that
strategy
could
potentially
work.
A
A
A
I
know
this
is
on
matias's
brain
lately
and
a
bunch
of
muzzle
clean
ups.
This
past
week
and
honorable
I
know
I
converted
the
whole
muscle
plug-in
from
groovy
to
java.
G
Oh,
the
muzzle
build
file,
the
build
source
folder
has
a
build
plug-in.
Sorry,
a
build.