►
From YouTube: 2021-09-21 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
C
Yeah
we're
getting
some
cool
evenings,
which
is
nice,
but
how
about
starting
to
think
about
turning
the
heater
on
at
some
point?
Not
yet.
B
B
C
Yeah,
I
do
the
I
I
do
you
say
31
and
I
say
times
I
do
the
times
two
plus
32.
B
C
C
I
gotta
normalize
to
yeah.
You
can.
C
So
what
do
we
have?
Yes,
we
have
nikita.
We
can
talk
about
things
again.
We
were
holding
some
very
important
topics
for
you.
Sorry,
no,
no,
no,
nothing!
Nothing!
Urgent!
Just
things
that
we
would
okay
composite,
build.
A
Okay,
almost
I
mean
I
mean
I
spent
last
couple
days
of
my
vacation,
trying
to
split
like
core
agent
from
instrumentations.
A
You
using
composite,
builds
in
the
same
repo
like
just
one
real
one
repo,
but
several
projects
which,
like
include
each
other,
and
that
was
a
sorry
and
I
think
we
will
have
exactly
almost
exactly
the
same
problem
if
we
just
try
to
split
core
and
instrumentation
and
like
in
two
separate
pro,
because
what
what
are
the
main
problems
that
I
have
encountered
are.
A
So
we
have
our
dependency
management
module.
If
you
want
to
reuse
that
in
separate
instrumentation
project,
we
have
to
publish
that
as
well.
Okay,
not
a
big
deal,
but
a
little
bit,
I'm
not
sure!
If
we
even
can
do
that,
how
you
can
publish
java
plus
okay,
you
can
publish
java
platform
build
okay,
that's
solvable.
A
Next
problem
was
that
we
actually
very
like
not
sloppy,
but
we
sometimes
reach
into
like
into
projects.
For
example,
our
tests
reach
into
project
testing
command
find
a
file
from
from
the
certificate
to
use
that
in
ssl
tests.
If
we
split
instrumentation
from
testing
commands
into
separate
projects,
we
can't
do
that
anymore.
A
A
A
We
have
to
have
two
gel
agent
modules,
essentially
one
just
for
core
and
another
which
aggregates
all
instrumentations.
A
D
A
That
that
may
create
problems
even
when
we
split
instrumentations
into
like
main
one
and
contributes
one,
then
it
will
it
will.
It
will
be
a
little
bit
more
complicated
to
include
that,
because
you
can
include
like
just
no
normal
maven
maven
dependencies
yeah.
Not
all
majority
major
coordinates.
Yes,
like
I
depend
on
io
telemetry,
blah
blah
blah.
A
A
When
I,
I
still
think
that
this
thought
framework
like
separating
core
from
instrumentations,
it's
a
correct
one
and
it
may
solve.
If
we
think
about
that
this
way
we
still
may
solve
that
problem
of
well.
We
now
want
to
include
gradle
plugins
in
our
build,
which
itself
uses
some
other
projects
in
our
build.
So
how
to
do
that.
B
Is
there
sort
of
a
concrete
win
you're
hoping
for
by
splitting
up
the
builds
into
separate
ones,
because
I
like,
if
we
want
to
version
them
separately
or
release
them
separately?
That's
also
still
possible
with
one
build
right.
So
I'm
wondering
if
there's
something
in
particular,
we
want
by
splitting
the
builds.
A
A
I
see
two
benefits.
One
is
exactly
that
it
may
help
with.
A
B
A
B
A
C
Nikita
can
you
rewind,
I
didn't
follow
the
what
you
were
saying
about
how
to
use
gradle
plugins
in
the
crc.
B
A
C
We're
talking
about
the
that
publishing
site.
A
A
So
build
crc
project
actually
can
be
replaced
if
you
just
rename
that
folder,
for
example,
to
conventions
for
example,
then
we
can
include
that
as
a
composite
built
into
our
main,
and
if
that
it
works
out
of
the
box,
so
you
just
replace
build
cersei
with
included,
build
and
that's
it.
B
A
Yes,
so
you
cannot
include
project
into
build
surfing,
but
you
can
include,
but
you,
if
you
re
like
rip,
if,
if
you
replace
build
crc
with
just
included
project
which
contains
all
conventions
plugins,
just
like
it
right
now,
then
you
can
include
into
there
another
project
and
then
you
substitute
dependency
like.
A
If
you
remember,
we
have
in
bill
gradle
file
for
builder
c,
that
gradle
jar
dependency
plugin
dependency
coordination,
so
they
can,
they
will
be
replaced
with
included
build
as
as
usual.
So
yes,
you
can.
Then
you
can
do
that.
You
cannot
do
that
into
build
30,
but
you
can,
if
you
can
include
that
into
conventionally.
B
A
A
C
Because,
at
least
when,
when
I
kind
of
went
through
those
updating
things-
and
it
wasn't
quite
the
same
but
yeah,
okay.
A
That
works,
if
you
actually
can
switch
classes,
then
all
these
discussion
is
not
a
present
matter,
but
so
like
exactly
exactly
the
same
way
or
the
same
reason.
Why?
If
you
remember
my
pull
request
from
some
time
ago
that
tasting
simplifying
tasting
agent,
that's
just
bare
bone
agent,
plus
one
extension
compared
to
previous
one.
A
Let's
combine,
let's
cook
something
like
a
la
carte,
so
I
still
think
this
is
like
good
framing.
I'm
not
sure
that
we
have
to
implement
that
framing
into
in
in
project
build
system,
because
it's
probably
built
a
big
change.
It's
probably
a
disruptive
change.
A
A
C
So
with
what
your
you're
we're
trying
locally
was
that
just
splitting
out
kind
of
the
minimal
for
the
to
try
to
get
the
gradle
plug-ins
pulled
in
and
to
be
able
to
cross
build
those,
or
were
you
trying
to
do
sort
of
this
bigger
split.
A
Yes,
we
have
to
do
big,
bigger
split,
because
if
we,
let
me
think.
A
C
A
And
yes,
and
if
you
want
to
remove
both
really
both
publishing
publishing
requirements,
then
we
have
may
make
that
big
split
and
we
have
to
split
the
instrumentation
from
core.
B
All
right
this
week,
I'll
finally
have
time
to
try
out
the
work
great.
I
approach
like.
I
think
it
is
probably
the
smallest
change
to
get
muzzle
included
without
having
to
use
the
published
artifact.
Of
course,
it
doesn't
move
us
in
a
direction
of
the
split,
but
it
can
solve
that
problem
and
probably
with
the
smaller
change
and
maybe.
B
Right
now,
yeah
like
I
can
probably
implement
that
this
week,
like
I
think,
either
way
like
the
work
great
sort
of
conventional
now
for
calling
java
codes,
even
if
we
didn't
end
up
with
that
as
a
long
term,
it's
still
good
to
be
using
the
work
api.
I
think
from
what
I
understand,
so
it's
probably
worth
just
trying
it
and
see
where
that
gets
us,
and
then
we
can
go
from
there.
A
B
A
B
B
Sort
of
my
idea
was
that
most
of
the
often
changing
things
like
muzzle
would
be
outside
the
gradle
plugins
and,
what's
in
gradle,
plugin
would
be
sort
of
just
a
small
wrapper
around
our
code
and
the
other
artifact.
So
even
if
that
always
has
to
be
published,
it's
not
as
painful
as
when
muzzle
is
included
inside
the
plug-in.
B
So
right
now
we
have
this
package
inside
the
gradle
plugins,
which
is
the
bytebody
plug-in
implementation,
and
that
depends
on
muzzle,
I
think,
yeah,
and
so
that
should
like
using
the
work
great.
We
should
be
able
to
move
that
outside
of
the
gradle
plugin,
so
that
those
classes
can
be
included
into
the
worker's
classpad
and
then
the
greater
plugin
isn't
different
than
muzzle
anymore.
B
A
B
Because
similar
to
how
we
have
that
muzzle
or
the
code
gen
configuration
where
we
collect
the
classes
to
be
used
when
matching,
we
can
also
set
up
the
class
path
for
the
work
rate
and
a
similar
mechanism.
We
have
a
configuration,
that's
the
bytebody
class
path
that
just
includes
the
bite,
buddy
plugin
and
its
dependencies.
A
B
B
B
A
A
A
C
And
it
is
a
good
point
about
the
contrib
split
out.
I
think
you
know
we'll
have
to
think
carefully
about
that.
You
know
what
also
what
are
the
pros
and
cons
I
mean
I
mean
I
think
we
know
the
pros
I
mean,
but
you
know
the
current
state
is
not
the
worst.
I
would
wouldn't
want
to
have
like
a
huge
disruption
and
make
the
tooling
you
know
harder
and
have
to
jump.
C
You
know
back
and
forth
between
the
repos,
although
I
do
think
once
things
are
stable,
you
know
at
whatever
point
that
is,
that
will
be
less
of
a
problem.
A
C
C
B
D
If
you
look
at
the
last
point
in
our
today's
agenda,
I'm
proposing
another
backwards,
incompatible,
breaking
change,
so
it's
still
a
bit
of
a
bit
in
the
future
before
we
can
extract
anything.
B
C
A
C
Okay,
all
right
this
one.
Yes,
so
the
question
about
what
the
default
java
agent
artifact
should
be.
We
have
java
agent
all
java
agent,
slim.
A
Right,
I
think
that
at
the
end,
the
long
term
goal,
at
least
in
my
in
my
opinion,
is
that
we
should
have
opened
elemental
java
agent,
dot
jar,
which
contains
everything
that
is
needed
for
out-of-box
experience
for
our
main
repo,
which
means
first-year
interpretations
and
exporters
at
least
or
utility.
I
don't
know
all
of
them
are
not,
and
then
all
jar
should
be
published
by
country
country.
People
could
publish
just
country
which
includes
all
instrumentations
that
we
have.
B
B
C
I
think
this
was
a
good.
The
question
that
I
think
onorak
brought
up
last
week
was
whether
the
you
know
the
instrumentation
doesn't
tend
to
be
very
big.
So
if
the
open
telemetry
java
agent
is
27
megs
and
the
open
telemetry
java
agent,
contrib
is
28
megs.
A
A
B
C
B
C
Which
is
reasonable,
I
mean
like
what
are
the
collector
how's,
the
collector
doing
it,
because
they
have
a
kind
of
a
similar
model,
and
I
got
the
impression
that
most
people
are
using
the
contrib.
C
A
B
Tend
to
be
smaller
use
cases,
I
think
the
resource
detection
processor
isn't
contributing
that's
the
most
important
one
there,
but
whether
that's
there
for
the
long
term
or
not-
I
don't
know,
but
for
now
you
would
use
the
contract.
Just
for
that.
I
guess,
but
I
expect
once
oklp
is
the
main
format
the
intent
is
for
the
core
to
be
what
people
use.
I
don't
know
if
that
is
the
same
statement
for
java
agent,
though,
because
there's
nothing
to
converge
on
it's
just
a
bunch
of
frameworks.
A
B
B
It's
not
so
it's
not
about
the
repo
split
it's
more
about.
Is
there
any
point
to
publish
two
jars
if
everyone's
just
gonna
use
the
contraptor
anyways
like?
Maybe
it's
just
causes
some
support
burden
because
first
we
have
to
ask
which
jar
are
using
anytime.
Someone
asks
a
question
and
then
go
from
there,
and
so,
if
all
three
of
us
destroys
are
going
to
use
the
contrib
jar
anyways,
I'm
seeing
a
big
trend.
This
quarter
to
not
have
any
point
in
existing.
A
I
I
I
may
agree
with
you
until
and
until
and
unless
we
still
implement
that
crazy
idea
about
start
open,
telemetry.
B
Yeah
so
I'd
say:
if
you're
the
long
term,
I
would
still
recommend
it
to
be
like,
even
if
instrumentation
split
out
into
country,
we
should
still
somehow
figure
out,
like
even
the
open
challenge
collector.
Now
it's
in
this
weird
state,
where
they
have
the
releases
repo
that
combines
the
core
and
the
contributors
into
one
artifact,
and
so
that's
what
they've
done.
We
can
do
something
along
the
similar
veins,
where
what
we
release
is
a
combination.
B
A
C
One,
I
think,
that's
what
we
had.
You
know
kind
of
previously
thought
yeah.
So
you
know
it
seemed
like
kind
of
the
default
approach,
but
you
know
I
think
these
are
good
reasons
to
challenge
that
default
approach.
A
But
don't
forget
that
or
if
I'm
not
mistaken,
all
the
majority
of
other
things
publish
their
framework
integrations
from
country
people.
C
C
And
in
in
that
vein,
I
mean,
if
other
does,
it
makes
sense
to
just
keep
all
instrumentations
in
one
repo
I
mean,
essentially,
if
that's
what
other.
A
A
C
Though,
like
we
could
take
like
justin,
you
know
make
him
a
approver
of
the
reactor
module.
B
To
provide
some
context,
the
collector
counter
people
and
I
think,
even
the
core
repo
nowadays
like
yeah
folders,
can
have
specific
approvers
and
then,
if
they
do
and
the
approver's
approved,
then
the
maintainer
just
rubbers
jumps
and
merges
it
in
so
that,
like
similar
to
how
we're
currently
rubber
stamping
anyways
for
instrumentation,
we
don't
understand.
A
B
A
D
A
Marriages,
no
no
so
country
prepo
was.
It
was
vetted
okay
to
grant
right
access
for
the
wider
community
exactly
because
that's
country
people,
and
so
we
have
that
author,
which
I
which
I
wrote
that
kinda
kind
of
resolved
that
it's
okay,
okay,.
A
A
And,
of
course,
don't
forget
that
another
reason
for
us,
at
least
for
me
to
want
wanting
split
our
instrumentations.
I
am
tired
of
our
huge
project,
so.
B
B
I
need
it
for
developing
internal
stuff.
Lately
I've
been
doing
some
stuff
on
the
internal
repo,
so
without
it
just
can't
do
it
with
it.
It
screws
up
my
other
open
source
stuff.
So
I
need
a
virtual
machine.
I
guess.
B
A
B
A
B
A
That
the,
but
actually
probably
what
I
want,
is
just
an
agent
with
our
agent
with
those
essential
instrumentations
like
the
class
loaders
and
executors,
so
that
light
and
slim
agent
and
everything.
So
I
want
this
two,
these
two
jobs
for
the
record:
okay,
but
okay,
so
you
want,
I
will
not
die
on
the
on
on
this
bridge.
A
D
C
Otlp
over
http
right
so
that
it
can
be
smaller.
I
don't
know,
I
actually
don't
know.
D
I
I
mean
I
also
kind
of
share
your
feeling,
because
it
it
makes
sense
with
our
plug-in
architecture
to
have
a
separate
car.
That's
like
complete,
separate
thing
that
you
can
use,
even
without
all
that
stuff
of
the
other
stuff,
and
just
you
know,
attach
all
the
plugins
you
want,
like
yeah
yeah
started
open
to
the
best
video.
A
A
C
Honorary
do
you
have
a
remember
how
big
that
is.
B
C
Because
yeah,
because
the
grpc,
what
are
the
sizes,
are
pretty.
C
B
I've
been
meaning
to
experiment
with
whether
using
the
http
exporter
causes
significantly
faster
startup
on
lambda
right
now,
our
land
delay
is
still
using
the
grpc
exporter.
It
takes
around
10
seconds
of
cold
start
time.
Probably
most
of
it
is
initializing
jrpgnet,
and
so
I'm
wondering
what
the
look
like
with
http
just
haven't
tried
it.
Yet.
C
Yeah
because
look
at
these
files
so
that
currently
a
java
agent
all
is
29.5,
megabytes
and
java
agent.
Let's
call
it
slim
is
7.5
megabytes.
So
that's
all!
That's!
That's
all
grpc
neti.
C
C
C
We
run
out
of
time
or
before
I
run
out
of
time,
also.
B
B
C
Can
I
say,
plus
plus
one
for
otlp
http
in
the
slim
I'll,
add
that
to
the
oh,
so
timing,
wise
then,
should
we
go
ahead
and.
C
Make
this
official,
because
it
sounds
like
that
the
question
was
if
it
was
going
to
change
when
we
break
out,
can
trip,
but
if
java
agent,
especially
if
java,
if
we're
thinking
java
agent,
would
remain
that
our
main
artifact
would
remain
the
one
that
has
the
kitchen
sink
in
it.
C
B
C
So
it
makes
sense
to
me,
but
let's,
let's,
let's
sleep
on
it
and
we'll
revisit
this
next
week,
we
won't.
I
won't
push
that
pr
further.
Let's
see
what
we
all
think
next
week,
sound
good
nikita.
D
Breaking
things
yeah,
so
the
last
point
is
mine,
and
I
looked
at
the
issue
that
I
think
you
created
to
ask
for
this,
benefiting
from
instrumentation
context
and
write
down
instrumentations
which,
as
far
as
I
remember
right
now,
the
jdbc
and
all
k,
http
library
instrumentations-
would
benefit
from
it.
But
I
suppose
that
it's
kind
of
useful
for
everything
in
the
future.
D
So
I
basically
thought
that
we
could
move
the
instrumentation
context
and
the
context
store
classes
to
instrumentation
api,
because
it
would
be
easier
to
just
have
like
one
entry
point
for
that
and
just
detect
the
instrumentation
context
calls
from
from
the
instrumentation
api
and
yeah.
If
we,
if
we
are
moving
it
and
changing
the
package
name,
should
we
rename
the
context.
C
C
D
C
B
A
B
C
B
B
D
A
C
C
C
C
Let's
see
anything
else,
let's
take
a
quick
look
at
pr's,
okay,
good
this
past.
So
I'm
going
to
merge
that
just
for
the
build,
I
think
there's
still
one
thing:
that's
failing!
C
Oh
not
this!
It
was
a.
C
C
So
if
somebody
has
a
chance
to
look
at
that,
you'll
see
it
because
ci
runs
test
latest
depths,
so
that'll
throw
that'll
keep
failing
still,
but
at
least
the
prs
should
should
be
green.
Now,.
D
Yeah,
there's
no
such
method:
the
kafka
server
broker
state.
It
looks
like
a
good
reason
for
moving
off
the.
C
Yes,
yes,
oh
speaking
of
the
kafka
stuff,
so
with
the
the
new
producer
receiver.
C
Yeah
receive
and
process
in
the
messaging
sig
last
week
somebody
brought
up
that
they
had
modeled
it
that
way
in
node
also,
and
they
were
getting
a
lot
of
users
telling
them
that
the
instrumentation
was
broken
because
it's
a
different
trace
from
producer
isn't
connected
to
process
anymore.
C
C
Because
I
was,
I
updated
our
distro
and
our
smoke,
the
kafka
smoke
tests
are
failing
because
it's
not
continuous
and
actually
our
back
end
and
that's
the
issue
is
that
a
lot
of
back
ends
don't
support
links
and
surprisingly,
our
back
end
actually
does
support
links.
So
the
the
picture
is
actually
correct
there.
D
B
D
And
yeah
you
by
instrumenting
in
that
way,
you
like
get
the
full
picture
of
the
receive
thing
and
how
much
time
actually
did
the
pawn
intake
and
if
there
are
multiple
messages
processed
on
after
one
receiver
used
to
have
them
leaked.
So
it
makes
sense
to
do
so.
But
if
we
provide
a
flag
to
just
skip
the
receive
span-
and
you
know
just
have
the
straight
parenthesis-
relationship
between
producer
and
process-
consumer-
that's
perfectly
fine!
D
Is
more,
I
know
it
is
easier
to
have
working
and
easier
to
understand.
C
Yeah,
especially
for
back-ends
that,
don't
like
say
a
jaeger
or
zipkin,
or
something
anything
that
doesn't
support
the.
C
Links,
but
also
what
do
you
think
like
so
this
is
the
picture.
Oh,
am
I
sharing
yeah.
B
C
End-To-End
transaction,
so
this
is
what
the
picture
looks
like
with
the
links.
So
this
is
linked
to
this
send,
but
this
receive
is
kind
of
off
by
itself,
like
I'm,
not
really
sure
visually.
What
that's
supposed
to
wear
where
that
fits
in
the
flow.
D
A
A
C
So
that
I
think
I
probably
will
that's
why
I
think,
for
this
release
at
least
I'll
probably
keep
introduce
that
flag
and
maintain
hours
the
same
way
it
used
to
be
until
I
have
time
to
really
vet
this
with
sort
of
our
back
end
and
product
folks.
C
We'll
talk
about
sun
misc,
unsafe
I'll,
try
to
look
again
at
this
before
thursday
or
or
just
merge
who's.
Oh
everybody's
approved
it
so
so
the
honorable
mattis
you're,
both
good
with
oh
yeah,
the
boot
class
loader,
the
mr.
I
think,
okay.
C
B
B
C
Yeah
I
was
going
to
ask
you
nikita
because
I
mean
it's
a
good
example
of
the
native
images,
but
I
do
think
it's
different
for,
like
char,
like
I
can't
think
of
any
jar
like
from
that
I've
downloaded
from
maven
central
that
looks
like
that.
Have
you
looked
into
them.
A
B
Being
said,
if
we're
going
to
give
the
bill
repeated
stability
argument,
we
should
first
confirm
that
our
build
is
actually
reproducible
outside
the
timestamps.
I
don't
know
if
you've
ever
checked,
but
I
don't
know
if
every
single
file
in
our
build
is
guaranteed
or
not
have
a
time
stamp
inside
it
like
some
manifest
files,
sometimes
have
it.
I
think
where
and
if
that's
not
true,
then
that
argument
goes
away.
C
Okay,
http
this
version
491
january
30th.
Was
that
the
same?
B
C
It's
also
fire.
It's
not
it's
totally,
not
a.