►
From YouTube: 2021-08-18 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
B
C
So
a
few
holidays
that
the
company
gave
I
I
took,
but
I
didn't
take
any
vacations
this
year.
My
my
house
is
in
construction,
I
mean
outside
the
household,
I
don't
know
I
I
I
think
I
will
have
a
lot
of
vacations
starting
september.
B
Yeah
with
all
of
the
smoke
in
the
area
now
the
camping
will
probably
start
slowing
down
yeah.
C
Yeah
yeah,
we
we
had
a
relief
yesterday
here
in
the
area
it
cooled
down.
There
was
a
cleaning,
but
I
think
the
last
10
days
is
kind
of
hazy
all
the
time.
C
C
C
All
right,
so,
let's
get
started
one
thing
that
came
to
to
rasmus
and-
and
I
were
talking
about
when
he
had
some
long
path-
errors
during
the
builds
during
doing
to
some
changes,
and
this
was
actually
something
that
I
noticed
before
and
kind
of
forgot.
C
But
our
names
right
now
are
kind
of
really
big
for
the
dlls
and
stuff,
and
it's
open
open,
telemetry,
auto
instrumentation,
then
chilean
clr
profiler.manager,
for
instance,
and
the
auto
instrumentation
bit
was
added
kind
of
to
differentiate
from
open,
telemetry
instrumentation
that
we
have
coming
from
the
sdk
side.
But
I
think
the
clr
profiler
is
already
pretty
good
enough
to
indicate
that
this
is
related
to
code
injection
and
jit
chains.
C
You
know
so
although
people
say
that
naming
computer
sciences
the
hardest
problem,
I
think
I
I
suspect
that
we
will
have
agreement
about
removing
the
auto
instrumentation
part.
C
C
Okay,
so
I'm
assuming
that
everyone
is
okay
with
that.
If
not
let
us
know,
then
robert
robert
is
on
vacation
now,
but
he
he
mentioned
something
that
we
eventually
have
to
do
is
kind
of.
We
are
doing
this
work
on
the
plc.
C
And
also
we
have
to
eventually
switch
that
to
be
the
main
branch,
so
we
probably
want
to
kind
of
do
some
have
a
point
to
our
data
milestone
to
do
that
and
see
if
we
need
to
do
something
before
I
do
have
concerns
about.
We,
the
upstream
pools
what
we
are
gonna
doing,
how
we
are
gonna
handle
that
I
think
my
main
concerns
is
the
native
part,
because
there
is
where
we
can
have
bug
fixes
that
we
really
need
to
pick
it
up.
You
know.
C
So
if
we
do
this
change
to
the
poc,
we
don't
have,
for
instance,
the
tracer,
but
we
still
want
to
get
the
changes
for,
let's
say
duck
typing
the
nature
changes
especially
bug
fixes.
C
I
didn't
put
much
thought
about
that,
but
I
think
looking
at
the
organization
of
the
code,
I
suspect
that
we
could
perhaps
have
some
area
some
folders,
that
we
do
this
pool
from
time
to
time,
especially
as
I
said,
for
bug
fixes
and
this
kind
of
thing.
But
then
there
will
be
a
lot
of
things
that
we
are
not
going
to
be
following
kind
of
part
of
the
tracer
and
the
other
chains.
C
I
I
don't
expect
us
to
come
with
a
plan
right
now,
but
just
something
to
bring
it
up
to
people
to
keep
in
mind.
You
know,
and
as
I
said,
I
I
think
the
main
interest
is
kind
of
native
change
fixes
there
instrumentation
support
duct,
typing
and
changes
in
instrumentation
code
like
if
there
is
a
bug
or
something
that's
fixed.
C
We
want
to
be
sure
that
we
don't
miss
that,
perhaps
not
for
next
week
next
week,
I'm
planning
to
kind
of
document
everything
that
we
did
on
the
plc
and
how
everything
would
work.
Basically
that
that
short,
let's
say
summary
that
I
gave
last
meeting
kind
of
put,
that
in
a
dock,
and
so
people
coming
later
to
the
repo
can
understand
easily
how
this
stuff
is
working
and
how
we
are
dealing
with
the
the
issues
about
version.
C
But
after
that,
I
think
we
should
really
think
about
this
and
do
the
switch
eventually
to
the
poc
branch
they
use
in.
The
sdk
becomes
the
main
branch
that
we
start
to
work.
C
Yes,
yes,
I
agree
with
you
that
that's
the
I
I
think
the
tenders
over
time
that
will
be
will
be
the
case.
One
thing
that
this
is
a
side,
but
one
thing
that
I
was
thinking-
and
this
is
we
we
should
take
down
the
road
not
now,
but
we
know
that
for
writing.
These
instrumentations4.net
is
much
harder
than
compared
to
something
like
java
and
I
think
right
now,
the
entry
barrier
for
somebody
to
write
a
a
bytecode
instrumentation
is
pretty
high.
C
You
know,
ideally
in
the
future,
we
should
kind
of
visit
that
and
then
I
think
it
will
be
a
collaboration
with
upstream
you
know
kind
of,
because
if
we
do
something
that
is
good
on
this
area,
I
think
there
will
be
interest.
But
I,
realistically
speaking,
we
have
much
more
basic
steps
to
do
before
that,
but
is
an
area
that
perhaps
kind
of
in
the
same
way
that
that
typing
made
the
life
much
easier
compared
to
what
was
before.
C
We
should
have
kind
of
ways
to
to
make
the
the
instrumentation
much
easier.
If
you
look
at
java
instrumentation
right
now,
I
think
a
a
good
java
developer
can
just
sit
and
write
instrumentation.
You
know
it's,
it's
perhaps
harder
to
test.
It's
the
same
challenge
that
we
have
on
the
test
inside.
You
need
to
start
dockers,
and
this
kind
of
thing,
but
at
least
the
code
is
something
that
a
dev
can
switch
and
do
it.
I
don't
think
right
now
we
are
in
this
place.
C
C
I
did
some
stuff
on
the
the
branch
that
we
have
on
the
fork
that
we
have
and
then
you
have
to
open
the
windowpg
or
native
debugger
and
look
at
the
il
and
do
that
kind
of
stuff.
I
don't
think
most
developers
in
dotnet
are
ready
to
do
that.
You
know
it's
a
specialized
knowledge.
You
know
it's
not
kind
of
the
thing
that
you'll
find
in
everyday
developers.
Sorry,
I
took
a
a
bigger
side
on
that.
That's
not
something
that
we
should
be
doing
soon.
B
At
the
same
time,
I
I
see
dot
net
specifically
being
a
case
where
library
authors
are
more
likely
to
use
open
telemetry
because
of
the
the
way
microsoft
is
approaching,
the
open,
telemetry
apis
and
how
it's
just
part
of
the
language
more
or
less.
C
Yeah,
I
I
I
have
high
hopes
for
that.
That's
true.
I
have
high
hopes
that
I
don't
know
in
four
or
five
years
these
you
come
straight
from
the
libraries.
You
know,
people
use
activity
sorts
and
these
things,
but
we
don't
know
so
that's
another
reason
for
we
evaluate
that
idea
in
the
future.
When
we
actually
have
our
release,
you
know
so
yeah,
but
but
that's
a
very
good
point.
I
also
have
hopes
on
that.
But
let's
see.
C
Okay,
there
was
a
a
kind
of
I'm
jumping
through
the
part
of
the
pr's,
and
actually
the
first
thing
was
not
about
the
prs
themselves,
but
we
had
the
otop,
and
these
had
a
bug.
I
think
on
the
sdk
side
had
a
bug
on
the
collector
and
the
thing
is
actually
for
net
core
3.1.
C
There
is
a
configuration
flag
that
you
need
to
set
to
be
able
to
get
the
otop
exported
working
robert
figured
out
that
he
found
the
right
documentation
and
added
to
the
code
on
the
repo.
So
on
our
ripple,
we
should
be
able
to
export
straight
to
otlp
with
net
core
3.1.
The
the
instrumentation
automatically
adds
that
so,
which
is
good,
but
this
was
rolling
for
some
time
in
a
bunch
of
reports
from
open
telemetry,
and
now
it's
figure
out.
That's
why
I
I
bring
up
and
animation
right
now.
B
Yeah,
so
I
added
a
comment
to
that
as
something
to
watch
out
for
when
the
proof
of
concept
branch
becomes
the
main
branch,
because
I'm
not
sure
that
that's
something
that
we
want
to
enable
by
default.
B
Of
this,
so
so
we
may
need
to
protect
that
that
flag,
a
bit
more
or
at
least
give
them
more
control
over
it.
B
B
And
the
reason
is
because
there's
there's
probably
additional
risk
when
you
enable
non-ssl
connections
with.
D
B
2-
and
so
I
don't
know
if
there's
different
exploits
that
could
be
enabled
by
setting
that,
if
they're
not
expecting
it.
C
Okay,
yeah,
that's
a
good
point.
That's
a
good
point.
I
actually
don't
know
the
the
grpc
by
default.
Now
it's
secure
right.
I
think
it
was
a
few
years
ago
that
they,
the
default,
was
without
the
ssl.
I
think
nowadays
the
default
is.
B
C
Yeah
no,
but
I
think
I
think
you
are
right.
I
think
we
should
create
a
pr
to
have
a
config
around
that
you
know.
C
The
question
will
be:
if
we
go
with
the
secure
by
default,
then
it
will
be
disabled
by
default
and
if
people
need
they
enable.
So
I
think
we
should
add
and
disable
by
default,
that
in
that
case,
so
we
follow
the
the
kind
of
morning's
creation
policy.
C
This
basically,
at
least
in
in
my
mind,
completes
kind
of
the
instrumentations
that
we
want
to
add
to
have
kind
of
awful
release.
C
We
still
have
work
to
do
in
other
areas
and
you'll
be
kind
of
just
two
bytecode
instrumentations
for
this
kind
of
alpha
release,
but
it's
just
kind
of
more
to
be
sure
that
we
cover
all
the
topics
and
then
we
after
we
have
this
offer
released.
Then
we
start
to
add
the
instrumentation
you
know,
but
that
should
be
the
last
one
that
we
do
for
kind
of
trying
to
shoot
to
have
a
release.
I
in
my
mind
I
would
love
to
have
a
release
by
the
end
of
the
day.
C
You
know,
but
we
should
put
some
plans
a
little
bit
forward,
but
I
think
if
we
could
release
anything,
together.net
6
will
be
pretty
good.
C
Okay,
sorry,
the
noise
here
I
don't
know
if
it's
getting
here,
but
I
don't
know,
there's
people
blowing
leaves
here,
but
it's
still
summer,
but
that's
not
the
problem.
C
Okay,
these
were
the
topics
that
I
I
had
in
mind
to
bring
it
up.
Do
you
guys
want
to
bring
it
up
something
else.
B
Yeah,
I'm
glad
that
you
all
figured
out
the
otlp
issue,
yeah
that
that's
kind
of
a
sneaky
one,
since
the
profiler
starts
up
before
the
app
code
even
runs.
C
One
all
right,
if
you
folks,
have
any
other
questions
that
perhaps
we
didn't
get
into
the
meeting
just
let's
use
this
like
and
keep
in
touch
all
right.
If
no
other
comments,
then
let's
save
a
few
minutes
for
us
and
keep
the
meeting
short
all
right
nice
to
see.
Everyone
have
a
great
one.