►
From YouTube: 2022-01-19 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
C
B
Yes,
that's
true:
it's
a
good
idea
to
ping
morgan.
E
B
Oh,
my
goodness,
you
guys
are
hearing
me
because
my
my
window
is
frozen.
B
C
Yeah,
I'm
feeling
so
much
better.
Oh
my
gosh,
I
slept
for
a
few
days
and
I
I
want
to
say
sunday.
I
started
to
to
see
a
big
difference
where
I
was
feeling
better
so
yeah
yeah
much.
B
C
Yes,
yes,
yes,
so
my
whole
household
is
vaccinated
and
even
have
the
the
boosters
that
are
allowed
here,
but
yeah
broke
through
for
me,
yeah.
B
All
right,
so,
let's
give
that
one
more
minute.
I
might
I
don't
know
why
my
my
chrome
here
from
time
to
time
now
it's
working
but
from
time
to
time
it
takes
a
big
nap.
B
So
I
I
ask
for
you
guys
to
share
this
stuff,
because
I'm
afraid
that
in
the
middle
of
the
thing
the
thing
is
gonna
decide
to
take
a
nap.
B
B
Wow,
okay,
so
yeah,
I
I
I
asked
one
of
you
guys
to
to
share
the
screen.
D
D
D
So
what
is
new,
based
on
some
conversations
I
have
created,
and
I
think
it
was
also
based
on
some
comment.
There
was
a
proposal
to
build
this
look
at
packages
of
oral
dependencies
of
one
of
our
workarounds,
and
basically
I
just
created
an
issue
to
capture
that
to
not
forget
about
this
idea.
B
B
But
while
that
new
get
package
could
be
useful
on
that,
I
I
kind
of
tend
to
think
that
we
can
do
this
after
beta
I'd
like
to
hear
what
people
think.
D
Next,
one
is
remove
unnecessary
environmental
availables,
so
I
just
spotted
when,
when
developing
making
some
changes
that
they
are,
they
are.
These
things
are
simply
unused
as
far
as
remember,
I'm
not
sure
if
this
one,
but
for
sure
this
analytics
enabled
this
one
probably
is
working.
I
think
it
was
a
bug.
I
will
make
a
question
mark
here
to
double
check
this.
B
Yeah,
no,
and
and
and
this
is
good
to
to
remove
this
kind
of
stuff,
if
we
are
not
gonna,
have
down
the
line
or
anything
related.
It's
good
to
remove.
D
No,
it's
all.
No!
It's
not
here.
Telemetry
lost
section
to
the
troubleshooting
docks,
so
this
one
I
noticed
when
I
was
trying
the
sample
app,
which
was
throwing
an
exception
at
me
that
when
some,
when
the
application
is
gracefully
shut
down,
we
have
the
spans
thanks
to
the
up
domain
abdomen
events
which
were
there.
I
think
it
was.
I
don't
remember
exactly
the
event,
but
when
there's
an
exception,
nothing
happens.
D
So
these
are
the.
These
are
like
two
scenarios
where
we
can
lose
spans
right
now.
One
is
one
nx
and
had
exception
happens,
and,
secondly,
someone
just
kills
the
process
in
process
explorer,
for
example,
and
I
asked
if
we
could
for
first
document
this
behavior,
that
this
is
when
we
can
lose
the
data,
because
I
think
it
can
be
quite
frequently
troubleshooting
and
maybe
handling
100
exception
will
solve
at
least
this
issue.
D
Maybe
even
both
I
don't
know
how
how
dotnet
is
handling
kill
signal
if
it's
also
receiving
exception
or
not.
D
D
C
What
do
you
think
chris
yeah,
I
think,
it'll
be
a
quick
test.
I
just
noticed
that
I
left,
I
have
an
important
typo
in
my
response.
I
I
meant
to
say
new
relic
is
not
capturing
that
event.
A
A
B
C
Changes
everything,
and
so
I
I
took
a
quick
read
through
that
event,
and
it
looks
like
there's
a
lot
of
gotchas
for
the
original
versions
of
net
so.net
framework,
one
and
one
1.1,
but
it
seems
like
there
probably
aren't
a
lot
of
gotchas
for
the
versions
of
net
in
in
use
today,
so
it
may
work,
it
may
not
work.
C
Some
of
the
things
that
are
interesting
is
that,
depending
on
which
app
domain
you
subscribe
to
that
event
on
will
affect
the
behavior
of
how
those
events
are
processed
in
general,
and
so
as
long
as
we
can
somehow
subscribe
to
that
event
on
the
default
app
domain,
I
think,
will
be
okay
and
won't
cause
any
change
in
behavior
for
customer
applications
that
that's
my
guess
but
we'll
see,
because
I
I
don't
know
if
subscribing
to
that
event
can
prevent
the
application
from
shutting
down.
C
F
C
Was
at
towards
the
very
bottom-
and
it
was
talking
about
different
versions
of
visual
studio.
C
A
saturn,
okay,
yeah,
there's
a
couple
of
events
that
you
could
subscribe
to
that
can
prevent
the
termination,
but
we
don't
want
to
cause
a
change
in
behavior
yep.
It's
the
key.
We.
B
Basically,
just
want
to
attempt
to
flush
exactly
just
just
to
be
sure,
because
there
is
kind
of
the
unhandled
exception
and
also
you
you
talk
about
termination
of
the
process,
so
a
signal
should
terminate
the
process.
In
that
case,
we
we
should
also
be
trying
to
flush.
I
just
want
to
be
sure
that
we
cover
both.
You
know,
especially
the
interrupt.
H
B
Yes,
but-
and
I
think
the
the
thing
that
we
have
to
be
careful
here
is
the
following
from
upstream:
they
are
doing
that
for
sure,
but
here
we
are
using
the
sdk.
B
So
the
main
question
for
us
here
is
kind
of
from
the
hooks
that
we
create
and
everything
do
we
need
to
do
something
in
relation
to
the
sdk,
because
the
sdk
also
has
a
temperature
flush.
I
think,
if
I
recall
correctly
so
the
the
main
thing
is
kind
of
in
us
building
from
ops,
three
main
news,
the
sdk.
Are
you
still
doing
the
right
thing.
H
E
No,
I
think
I
think,
that's
good
so
when
we
are
going
to
implement
this,
and
probably
you
need
to
add
tests
as
well
to
make
sure
that
customer
application
life
cycle
is
not
changed.
F
B
Yes,
we
can
decide
to
not
do
some
stuff,
but
at
least
we
need
to
understand
where
we
are
right
now.
D
Point
zero,
so
major
version
number
two
data
dock
made
significant
changes,
especially
in
the
native
layer,
so
they
got
rid
of
the
integration
json
they're
using
this
generated
instrumentation
definitions,
they
also
improved,
I
think
the
dark
typing,
etc,
etc,
and
I
think
it
will
be
good
to
make
an
upstream
pool
for
for
this
code,
especially
that
personally,
I
think
it
will
be
easier
to
make
a
hook
for
future
for
vendor-specific,
instrumentations
or
functionalities,
using
adding
some
hook
in
the
instrumentation
definitions
that
you
can
add
more
simply,.
B
Yeah,
so
I
was
I
was
gonna
ask
today.
Zach
is
not
here.
D
A
J
B
I
think
I
think
we
be
more
productive
and
have
this
conversation.
If,
if
zack
is
present,
you
know.
D
Personally
speaking,
I
think
that
it
is
not
a
must-have
for
the
better
release,
but
I
think
it's
a
very
nice
to
have
yes.
D
B
Exactly
my
thought-
and
I
was
just
thinking
kind
of
kind
of
want
to
to
because,
besides
bugs
in
principle,
we
can't
wait,
you
know,
but
I
I
would
like
kind
of
to
perhaps
get
a
feeling
from
zach
about
the
cost
of
doing
that.
So
we
can
kind
of
decide
if,
if
we're
gonna
try
to
tackle
or
not
that.
D
Okay,
so
I
will
keep
it
keeping
it
here
regarding
stuff
in
progress,
so
raj
is
not
here,
but
I
think
I
think
that
he
was
telling
somewhere
that
not
here.
So
we
will
have
no
no
update
from
raj
here
in
this
issue,
chris
unable
to
auto
instrument
us
network
three
point
one.
Apparently
I
don't
have
any
updates.
I.
D
Yeah
here
we
have
also
no
update
from
from
from
here
regarding
this
one.
I
just
created
a
pr
today,
so
I
make
a
click
quick,
just
teaser
later
same
here,
chris
right,
no
update,
correct
document,
additional
tips
and
runtime
package
store.
D
There
was
for
sure,
okay,
so
here
also
ratchet
old,
because
I
remember
that
paulo
you
said
that
you
can
document
together
with
other
stuff.
You
you
said
that
you
will
try
to
document
it
any
progress
here.
B
B
He
worked
it
yeah.
No.
Oh
raj
said
that
when
two
days
ago,
okay-
yeah-
I
I
kind
of
did
some
recap
last
week,
but
very
little.
I
I
put
very
little
down
on
the
page
you
know
kind
of.
I
was
basically
recapping
this
stuff
and
I
I
still
haven't
really
to
get
started
on
that.
One.
E
B
E
Not
much
just
about
the
idea
to
we
should
really
open
in
asia
and
the
dot
net
runtime
github
so
because
they
are
still,
I
hope,
they're
still
designing.
2.7,
then,
if
you're
on
time,
there
might
be
a
feature
for
us.
E
So
yeah
the
plan
is
to
move
the
communications
to
public
instead
of
having
internal
communications
in
microsoft,.
D
D
Okay,
that's
all
for
the
board,
not
much,
not
a
lot
of
pull
requests,
so
it
will
be
very
quick.
D
There
are
two
work
in
progress,
one
is
from
chris
and
it
was
discussed
last
week
and
no
update
right
and
the
other
one
very
small
is
for
me
so
basically
based
on
the
other
issue
to
use
the
otlp
exporter
by
default.
I
tried
it,
but
I
tried
it
very
quickly
for
some
reason,
I
on
dotnet.net.net
core
not.net
framework,
I
saw
the
spans
in
the
console
exporter,
but
they
did
do
not
get
to
the
collector.
D
The
more
interesting
thing
is
that
on
the
dotnet
framework-
as
I
think
chris
and
also
erasmus
some
time
ago,
we're
discussing
there's
these
problems
with
the
native
native
dependencies,
and
I
just
noted
it
down
and
so
far
the
comments
from
rasmus
is
just
to
focus
on
on
the
dot
on
the
dot
net
core
scenario
and
postpone
the
problems
for
for
dotnet
framework,
which
personally,
I
think
is
a
good
idea
to
focus.
D
On.Net
and
dotnet
core
for
the
beta
and
also
chris,
had
a
good
idea
that
if
there
will
be
some
problems,
we
can
use
the
http
protocol
instead
of
the
grpc.
I
think
that
one
of
the
benefits
is
also
that
it's
also
that
these
are
less
dependencies,
but
still
we
we
are
taking
these
dependencies
of
grpc
anyway.
So
I
will
just
try
whatever
gets
me
to
do
working
scenario.
B
B
No,
I
was
gonna
say
that
I
like
this
proposal
of
going
over
http
instead
of
jrpc,
because
even
if
the
library
under
has
the
dependency
in
theory,
you
are
not
going
to
bring
up
this
problem
and
I
think
kind
of
http
actually
should
work
for
most
of
the
case.
I
I
kind
of
tend
to
think:
let's
do
the
suite,
but
let's
do
the
suite
using
the
switch
using
http
instead
of
grpc.
C
F
B
B
So
robert
test,
the
the
otop
using
http,
if
that
works,
let's
go
with
that
instead
and
what's
about
the.
A
C
C
Grpc
library,
which
is
100,
managed
code,
and
so
there's
no
native
dependencies,
and
so
that's
likely
easier
to
work
around
all
of
the
dependency
issues
than
with
the
the
library
that's
required
for
older
frameworks,
which
has
a
managed
component,
because
the
grpc
library
is
basically
a
managed
wrapper
around
the
c
plus
plus
grpc
implementation.
You.
C
And
by
the
way
that
that
other
grpc
library,
it
calls
out
that
it
is
deprecated.
B
So
so,
in
a
sense
to
use
that
we,
you
have
to
have
that
deprecated
dependence
to
should
the
chain
yeah
yeah.
I
I
really
feel
like
your
suggestion
about
going.
Http
is
the
way
to
go.
C
And
for
what
it's
worth,
I
believe
java
has
switched
to
basically
using
their
own
http
implementation
for
for
grpc,
as
opposed
to
just
using
the
grpc
library
directly.
D
There's
only
one
reason
why
I
still
like
feel
that
maybe
we
should
consider
defaulting
to
grpc
the
one
is
that
maybe
we
still
want
to
support
grpc.
If
you
know
the
user
wants
to
enable
it
using
the
environmental
variables
yeah
and
basically
that's
the
default
that
the
sdk
uses.
So
for
sake
of
consistency,
but
I
think
it's
just
a
matter
of
taste
and
at
this
point
of
our
development,
whatever
we
work
will
be
better.
C
Because
we
got
to
solve
the
same
dependency
loading
problems
there,
it's
just
a
question
of
whether
or
not
we
want
to
do
something
different
for
newer.net
applications
and
older
dot-net
framework
applications.
C
So
it
may
be
the
case
that
we
decide
for
net
framework.
We
only
support
protobuf
over
http,
but
for
newer.net
apps.
Perhaps
we
support
both.
D
D
B
I
think
we
we
have
on
the
community,
so
I
I
expect
that
morgan
update
there
too.
If
he
did
the
update.
L
J
B
B
C
Okay,
so
zach's
here
now,
if
we
wanted
to
go
back
to
the
one
upstream
sync
issue,.
D
You
miss,
you
missed
all
the
good
job
you
have
done
in
data,
though
so
version
2
and
all
the
native
codes
that
you
have
done
there
and
not
only
yes.
So
basically
I
try
to
keep
it
short.
You
know
what
you
have
done.
We
think
it
will
be
extremely
beneficial
if
we
can
pull
it
to
pull
it
here.
What
do
you
think.
I
Yeah,
I
think
that
it
makes
it
a
lot
better
to
work
with
there's
some
more
there's
some
caveats
regarding.
I
don't
know
if
you
have
already
learned,
but
everything
basically
works
on
p
invokes
so,
instead
of
using
like
integrations.json,
we
send
the
like
the
methods
like
the
summit,
name,
methods,
types
and
all
that
via
p
invokes
and
so
any
sort
of
improvements
or
changes
to
say
like
structures,
it's
brittle,
so
they
have
to
be
kind
of.
D
I
have
a
question:
do
you
see
any
problems
that
it
would
be
that
we
could
add
some
extensibility
point
there?
So
if
we
have
a
distribution
that
I
don't
know,
some
reflection
could
be
used
or
whatever
to
add
additional.
I
don't
know
you
know
or
some
partial
classes
or
things
like
that.
Do
you
think
it.
I
Would
be
doable
yeah,
so
the
nice
thing
is-
and
maybe
maybe
I
can
provide
you
a
link,
but
since
it
is
done
via
code,
if
we,
if
we
have
say
yeah
a
provider,
wants
to
add
their
own
integrations,
you
would
just
have
to
basically
provide
the
same
information
and
you
can
call
the
p
invoke
method
multiple
times.
So
you
recall
it
from
our
base.
I
Hotel
distribution
and
then
like
another
distribution,
would
have
their
own
list
of
integrations
and
they
would
just
call
that
you
would
just
change
like
an
id
just
like
a
good
so
that
they're
unique.
But
you
would
just
pass
your
own
list,
and
so
you
can
even
do
stuff
dynamically
as
well,
so
very
sensible
cool.
B
No,
it
seems
pretty
good
to
add,
as
we
a
per
description
of
zach,
so
I'm
just
kind
of
I'm
really
tempted
to
put
in
the
bar
for
beta.
You
know.
D
I
B
D
D
Now
we
are
going
to
the
auto
beta
release
plan
proposal,
so
this
is
one
for
that
I
have
created.
I
just
want
to
go
through
quickly,
go
for
the
vision
and
ideas
and
to
make
sure
what
we
that
we
are
in
line,
what
we
can
consider
as
a
better
better
release.
The
thing
is
that
I
see
that
we
have
a
lot
of
issues,
but
probably
it
will
be
very
good
to
have
any
release
that
will
like
usable
release
that
will
get
us
some
valuable
feedback.
D
We
saw
already
some
issues
that
someone
wants
to
test
it.
They
were
asking
how
to
build.
Where
are
the
artifacts,
etc,
and
basically,
because
of
it,
I
just
created
this
plan
and
yeah.
I,
the
hyperlink
to
this
one,
is
in
the
in
the
notes,
so
you
can
always
take
a
look
later
and
comment
it
today,
later
or
tomorrow
or
whatever,
but
basically
he
was
what
I
propose
basically
so
focus
on
supporting.net
core
three
plus
one.
D
We
can,
because
this
is
what
we
have
for
in
the
ci
pipeline
right
now.
We
can
also
at
mac
os,
because
we
had
this
as
well,
but
also
with
an
asterisk,
that
it's
nice
to
have.
B
In
that
same
line,
we
are
fine
for
us
to
have
http
as
default.
You
know
for.
A
D
The
thing
that
probably
needs
the
most
the
most
attention
is
user
documentation,
so
instructions
how
to
install
common
troubleshooting,
especially
regarding
com
problems,
that
we
see
right
now
how
to
what
to
do
with
the
exceptions
that
there's
some
some
assembly
is
missing
or
there's
a
conf
or
we
do
not
see
the
spans
that
possibly
the
diagnostic
sources
in
different
version.
D
So
I
think
we
need
to
make
sure
that
this
is
clearly
and
very
well
documented,
documented
in
one
place,
because
right
now,
I
think
it's
it's
not
very
clear,
as
we
saw
already
by
the
issues
that
were
created,
I
think
we
need
at
least
one
really
simple
good
working
sample
application.
D
The
console
application,
which
is
right
now,
is
not
really
working,
yeah,
basically
most
important
issues.
Software
workers
documented.
This
is
just
like
a
buffer
that
we
already
know
that.
Probably
there
will
be
things
coming
up
popping
up
as
we.
J
B
One
thing
related
to
that,
I
think,
is
the
the
thing
that
we
also
briefly
mentioned
today,
but
we
should
target
the
build
scenario.
You
know
I
think
raj
had
this
stuff
for
the
let's
say
devops
scenario,
but
I
I
think
realistically
for
beta.
We
have
to
think
about
one
of
scenario.
Only
you
know.
D
D
D
B
Yeah-
and
I
think,
looks
good,
I
think
in
agreement
with
what
we've
been
talking
the
last
few
weeks
and
also
as
every
plan
is
evergreen.
So
if
we
need
we
also
come
back,
but
we
are
trying
to
commit
to
kind
of
this
for
the
beta.
D
I
thought
about
creating
issues
for
more
of
them,
but
I
decided
first
to
just
talk
about
it
and
if
no
one
would
disagree,
then
I
will
create
issues
just
to
make
sure
that
I
do
not
mess
up
or
you
know,
on
github
issues.
So
basically,
here
the
stories
like
use
otlp
by
default,
remove
this
unnecessary
environmental
rules,
support.net
6
and
a
lot
of
stuff,
which
is
already
in
above
plan
for
beta.
D
I
don't
know
if
you
noticed
we,
we
have
a
lot
of
noisy
stuff
like
console,
write
lines
that
if
you
have
the
instrumentation
working
there's
some
some
some
strange
characters
that
instrumentation
has
loaded
blah
blah
blah,
so
I
think
it
should
be
removed
if
we
want
to
really
ask
users
to
to
remove
it
and
yeah
and
and
then
focus
on
user
documentation,
documentation,
remember
about
bumping
hotel,
sdk
document
how
we
want
to
release,
because
someone
will
need
to
do
it.
I
have
no,
and
even
in
order
to
discuss
it,
how
will
release
it?
C
Yeah-
and
I
don't
even
know
if
we've
talked
through
how
we
want
to
package
things
as
far
as
a
release
goes
like.
Are
we
just
going
to
provide
a
zip
file,
tar
ball
so
on.
B
Yeah
and
just
it's
already
there,
but
just
I
think
that
especially
being
a
beta,
the
path
that
most
people
will
try
is
kind
of
create
a
quick,
asp.net
core
app
and
try
the
things
so
having
support
for
six,
it's
kind
of
essential,
you
know:
nobody's
gonna,
try
this
with
their
already
existing
application,
and
people
are
gonna,
just
do
dot
net
new
and
by
default,
that
is
dot
net
six
nowadays.
So.
D
There's
a
few
things
that
are
currently
print
to
beta,
which
I
propose
postpone
one-
is
to
switch
to
otlp
export
integration
tests.
I
think
that,
for
sake
of
quicker
release,
we
can
still
keep
this
environmental
environmental
environment
variable
to
select
the
exporter
and
use
this
zipkin
zipkin
mock
receiver
to
use
an
integration
test.
D
I
don't
think
it's
a
blocker
for
us,
especially
that
we
do
not
plan
to
add
any
new
integrations,
so
we
will
not
like
if,
because,
if
we
plan
to
add
new
integra
new
in
auto
instrumentations,
I
would
rather
first
update
the
current
existing
tests
to
not
increase
future
future
reward.
But
right
now
I
think
it
can
be
postponed.
D
D
To
have
as
this
one
a
very
good
improvement,
but
it's
not
a
must-have
extension
point
for
custom
weight
of
instrumentation.
So
this
is
what
zach
told
that
it's
possible
so
also
nice
to
have,
but
definitely
not
a
must-have,
something
that
we
can
work
on
post
beta,
maybe
even
post
post
rc
improve
yeah
and
the
one
thing
is
about
this
additional
dependencies,
because
we
already
see
that
we
have
still
some
problems.
D
We
see
some
things
going
on
the
dotnet
runtime
in
dotnet
7
version
that
might
possibly
break
stuff.
I
just
want
to
make
sure
that
using
it's
nice
to
have,
but
I
don't
think
it's
a
must-have
scenario
to
use
this
additional
dependencies.
I
still
think
that
good
enough
is
to
use
this
build
this
scenario
for
that
someone
has
access
to
the
build
pipeline.
D
E
C
E
I
don't
see
it
currently
in
this
list,
but
so
if
we
finalize
the
startup,
then
the
additional
depth
comes
anyway
with
a
startup
implementation.
E
C
The
the
one
gotcha
there
is
that
bumps
it
to
be
more
than
just
a
nice
to
have
is,
as
part
of
that
we're
disabling
the
bootstrapping
in
the
profiler,
which
can
break
different
applications.
I
see.
C
So
chris,
what's
your
proposal
to
postpone
it,
or
so
I
think
it's
a
it's
a
requirement
for
the
beta.
D
B
Yeah,
so
just
of
course
we
can
change,
but
in
principle
we
are
saying
that
set
up
for
the
the
thing
goes
to
that
path.
You
know
so
basically
is
a
single
path
for,
for
the
setup.
D
D
D
D
C
No-
and
I
think
this
captures
everything
that's
in
flight
and
things
that
we
already
have
above
the
the
beta
bar,
so
okay.
B
C
L
B
Which
reminds
me
that,
but
this
down
the
line,
I
think
because
we
wanted
to
have
somebody
from
the
sdk
also
involved.
So
we
have
cjo
is
still
here,
but
I
think
from
microsoft.
Raj
has
been
doing
the
work,
but
I
think
it's
a
a
longer
path
and
she
will
say
that
we,
you
want
to
bring
him
as
a
maintainer,
but
it's
something
that
we
also
should
keep
in
mind
for
the
future.
But
the
moments
right
now,
thanks
robert
great
to
work
with
how
long
this
month
that
you've
been
doing
here.
B
Yeah
all
right,
I
think
it
was
a
very
good
one.
Okay,
does
anyone
have
anything
else
for
the
day
today,.
B
All
right,
we
I
I
think
we
have
the
path
for
the
beta.
We
perhaps
start
in
doing
some
work.
We're
gonna
get
perhaps
trying
to
have
a
feeling
for
a
date
which
will
be
challenging,
but
I
think
we
should
perhaps
next
week
try
to
have
some
milestones,
so
we
can
track
some
progress
and
be
sure
that
we're
moving
forward.