►
From YouTube: 2022-01-13 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
D
E
D
F
F
All
right,
robert
or
piata,
can
you
share
the
the
board?
So
then
I
I
can
try
to
take
notes.
At
the
same
time,
I
think
we
have
quorum
and
we
usually
give
more
minutes,
but
I
think,
let's
see
most
oh
raj
also
said
that
he
is
on
india
time
zone.
So
he's
not
gonna
be
attend
the
meeting.
It
was
not
clear
to
me
if
it's,
if
he's
gonna
be
doing
some
stuff
or
not,
but
at
least
the
meeting
he's
not
gonna
be
able
to
attend.
F
All
right,
we
had
some
good
progress
on
the
stuff
that
was
done.
Zach
did
two
pr's.
F
So
I
started
kind
of
doing
the
the
thing
for
the
dark,
but
it
went
a
little
bit
slower
and
I
actually
thinking
that
perhaps
some
stuff,
that
chris
is
doing
kind
of
changes
a
little
bit
of
that
so
kind
of
not
that
one
needs
to
wait
the
water
for
that,
but
I
think
it's
kind
of
after
that
is
done.
We
probably
will
be
updating
the
dogs
again
anyway.
You
know
on
that
regard.
F
Something
that
I
want
to
kind
of
bring
you
to
discussion
is
one
idea
that
I
I
briefly
mentioned
to
to
chris
about
perhaps
using
for.net
core
using
the
startup
hook
to
actually
load
the
profile.
So,
let's
say
for
net
core
in
a
sense,
we
could
get
rid
of
the
profiler
configuration.
F
F
Okay,
do
we
have
any
new
lighting
on
the
project
board.
F
Yeah,
so
if
you
scroll
down
on
the
backlog,
there
is
nothing
you
wanted
to
buy
right.
F
F
Yeah,
I
I
I
think
perhaps.
F
B
F
And
just
so
folks
are
aware:
it's
because
the
the
sdk,
the
the
fallback
name
for
the
service
is
the
current
process
process
name.
But
if
you
launch
something
like
dotnet
your
dll,
then
the
name
of
the
process
in
that
case
becomes.net,
so
I'm
suggesting
like
we
had
in
the
coming
from
upstream.
We
had
attempt
first
the
enter
assembly.
F
E
F
I
think
we
are
good
here
on
the
on
the
board.
Does
anybody
want
to
discuss
something?
That's
on
the
board
that
they
they
want
to
chat
about
or
something
they
have.
F
F
So
this
is
is
the
issue,
if
the
version
being
I
I'm
not
following
exactly
if
they
are
going
ahead
or
behind.
F
That's
that's
the
the
thing
I
didn't
understand
when
you
described
it,
you
mean
which
part
so
the
issue
is
is
having
trouble
with
the
dependence.
If
the
application
is
ahead
of
the
framework,
the
framework
I
mean
the
runtime
card
that
you
are
using,
that's
the
issue
currently
bot.
H
F
Sorry,
I
am
I
I
I'm
not
clear
kind
of,
because
okay,
the
application
is
using
four.
H
So,
basically,
if
user
is
referencing
a
different
version,
so
it's
generating
the
backer
package
reference
in
the
cs
project,
then.
H
D
F
H
H
F
Okay,
so
this
is
the
case
that
raj
was
trying
to
address
with
the
kind
of
rapper
right,
yeah,
probably.
F
Yeah,
the
idea
should
have
one
type
that
is
kind
of
neither,
but
that
type
can
refer
via
reflection
to
any
version.
The
part
that
is
not
clear
to
me
is
the
following:
then,
how
you
use
the
sdk?
F
F
What
I
think
it
should
be
possible,
but
it's
not
going
to
be
possible
in
our
cases,
is
to
update
the
the
json
files
that
have
the
dependence
to
kind
of
flow,
the
version
that
we
need,
but
I
would
say
that
it's
not
supported
to
simply
go
and
update
that
json.
You
know.
So
this
is
what
is
crossing
my
mind.
Please
guys,
if
you
guys
have
other
ideas.
Come
to
my
mind,
because
what
I
have
concerned
about
the
the
wrapper,
I
already
said
is
the
compatibility
of
the
sdk.
F
The
alternative
that
I
see
is
that
okay,
the
applications
are
red,
butte
has
the
depth.json,
so
we
could
update
that
to
reference
the
stuff
that
we
need,
so
the
idea
would
be
basically
kind
of
we
wanted
that
json
to
look
like
as
if
we
had
built
the
application
with
the
reference
that
we
need.
F
You
know,
but
that
said
I
I
don't
think
there
is
any
kind
of
let's
say,
api,
to
kind
of
update
that
json
on
that
way,
and
actually
I'm
not
a
hundred
percent
sure
that
works
or
all
the
cases
because
of
versions
that
the
runtime
itself
uses,
but
that
it's
it's
a
kind
of
side
question.
But
the
path
that
I
see
right
now
is
updating
the
depth.json.
H
F
Do
you
have
the
wrapper
steps
on
the
issue.
F
Yeah,
no
because
I
I'm
thinking
some
stuff
should
try,
but
I
think
I
would
like
to
see
the
exact
steps
that
you
are
using.
It's
just
running
the
tempo
application,
or
there
is
some
other
step
yeah,
I'm
just
trying
to.
F
Yeah
that
that
could
be
because
it's
part
of
the
runtime,
so
there
is
some
special
treatment
there,
but
I'm
I'm
not
100
sure.
F
I'm
gonna
try
to
gather
a
few.
We
we
try
offline
to
kind
of
I'm
gonna,
try
to
first
repro
as
after
I
get
the
rapper
I'll
try
to
understand
exactly
the
issue
with
you.
I
work
with
you
on
that,
but
the
first
thing
that
came
to
my
mind
was
that
that's
j
zone,
if
that's
not
a
workaround,
if
the
only
way
is
the
way
that
raj
had
proposed
that
similar,
also
what
greg
had
talked
about
long
time
ago.
E
Yeah,
so
my
understanding
there
is
that
the
sdk
would
actually
be
loaded
into
a
separate
context
so
that
its
own
set
of
dependencies
can
be
loaded.
E
F
I
I
I
I
I
have
the
impression
that
this
is
something
that's
going
to
take
a
quite
a
bit
of
time
to
be
complete
and
really
working
to
satisfaction.
Let's
say.
H
F
I
I
think
that
can
be
optimized
in
the
end
and
using
the
the
expressions,
but
the
thing
that
we
have
to
prox
everything
back
and
forth.
I
I
think
kind
of
and
you
need
to
have
handling
for
all
the
important
versions
right,
like
version
x,
had
a
field
and
then
version
y.
That
was
all
that
doesn't
have
a
field
that
we
can
leverage
for
a
feature.
F
F
I
think
this
is
the
stuff
that
raj
had
been
kind
of
talking
about,
so.
H
E
Push
it
ahead,
yeah,
I
think,
there's
a
few
things
that
raj
is
trying
to
push
with
net
seven,
and
one
of
those
is
the
ability
to
force
an
update
of
dependencies
that
ship
with
the
framework
or
the
run
time
I
should
say
so,
especially
system.diagnostic
source,
because,
like
paulo
said,
that's
probably
the
reason
that
updating
the
depths.json
didn't
work
is
because
of
the
security
rules
in
the
runtime.
H
That's
why
the
upgrade
is
working,
oh
really
yeah,
but
they
already
made
an
issue
to
fix
it,
so
the
devastation
would
be
the
lowest
priority,
because
when
it
was
in
the
middle
it
also
was
able
to
downgrade
dependencies,
which
is
very
bad.
I
F
Okay,
the
the
question
that
I
have
in
my
mind
is
like
right
now.
I
think
we
should
kind
of
pursue
these
as
we
we
we
are
kind
of
doing
before
in
a
separate
track.
For
now,
let's
keep
pursuing
the
path
of
people
that
can
build
time
and
in
parallel
we
pursue
this
track.
That
is,
for
a
red
built
applications.
F
You
know
the
devops
scenario,
I
think
all
of
us
are
having
a
lot
of
questions.
I
think
we
should
revisit
this
and
try
kind
of
to
kind
of.
I
think
I
already
forgot
some
stuff
that
we
discussed
about
this
last
year,
so,
at
least
for
me,
I
think
I
need
to
really
refresh
this.
I
remember
that
there
was
somewhere
a
list
of
expected
cases
that
we
are
to
reach
this
issue,
and
I
don't
think
it
was
just
one,
but
it
was
all
in
the
devops
scenario,
so.
F
F
So
I'm
I'm
gonna,
do
some
work
on
that
with
erasmus,
but
but
just
to
kind
of
buy
water.
Talking,
don't
expect
that
we
have
any
solution,
but
at
least
we
kind
of
have
a
better
understanding
of
the
exact
limitation
issue
and
kind
of
know
the
case
that
we
expected
to
not
work.
You
know.
F
Okay,
does
anyone
want
to
add
anything
to
this
topic
before
you
move
ahead.
H
F
F
F
Okay,
anything
else
on
the
board,
guys.
I
So
I
just
added
a
new
issue.
I
don't
usually
have
a
lot
of
time
to
work
on
stuff,
but
with
the
call
site,
and
then
this
one
as
well.
I'm
thinking
I'm
just
coming
up
with
ideas
to
try
and
clean
up
the
code
and
remove
things
that
are
unnecessary.
So
I
just
added
one
to
use
the
duct
typing
to
replace
the
clr
profiler
emit
namespace
stuff.
I
So
that's
you
know
just
sort
of
a
nice
to
have,
but
I
threw
that
on
the
board
just
to
track
it
and
make
sure
you
guys
were
okay
with
that
idea.
Yeah.
F
No,
I
think,
that's
a
good
idea.
I
think
the
this
kind
of
issue,
then
the
the
only
question
is
then
that
it
always
comes,
is
kind
of
where
we
wanna
put
in
the
bar
right.
I
think
it's
an
excellent
idea
and
please
keep
those
coming.
F
I
I
would
say
from
my
take,
is
kind
of
we
don't
need
this
for
a
better
release.
I
think
we
have
more
pressing
kind
of
problems
like
we
are
discussing,
but
we
do
want
to
do
that
kind
of
stuff
right.
F
And
but
but
then
also
it's
it's
like
any
open
source
project.
We
are
trying
to
prioritize
our
stuff
that
we
think
for
the
release,
but
if
this
is
something
that
you
want
to
do-
and
you
have
the
time
please
do
it,
you
know
kind
of.
We
are
not
kind
of
gonna,
say
hey.
This
was
not
scheduled
for
the
beta.
You
know
it
doesn't
make
sense
for
open
source
project,
but
I
I
my
my
take
is
that
it
should
be
kind
of
after
the
beta.
Then
we
prioritize.
D
I
And
if
I
come
up
with
more
I'll,
let
you
know
essentially
just
because
I
we've
done
some.
You
know
various
code
cleanups
and
upstream
so,
as
I
think,
as
I
run
across
them
I'll
make
sure
to
try
to
incorporate
them
here
very
good.
F
Okay,
then,
I
think
the
only
pr
open
right
now,
I'm
switching
to
the
pr's,
is
the
work
in
progress
from
chris.
I
invite
people
to
look
because
I
think
it's
kind
of
important
and
it's
related
to
the
thing
also
that
I
want
to
talk
about.
This
was
kind
of
an
idea
that
came
when
I
was
kind
of
taking
a
overview
to
update
the
docs
and
and
and
that
stuff
came
to
to
my
mind.
F
So
the
change
that
kris
is
doing
is
is
simple,
but
it's
basically
based
on
the
startup
hook,
and
the
thing
that
I'm
seeing
is
that
I
think
I
mentioned.
I
don't
know
if
I
mentioned
this
just
to
crease,
but
the
dotnet
diagnostics,
they
use
a
managed
api
to
attach
the
profiler,
so
the
clr
had
for
many
years.
F
F
And
what
crossed
my
mind
was
the
possibility
of
for
net
core
just
to
have
a
kind
of
consistent
approach,
it's
possible
to
just
have
the
startup
hook,
because
then
we
can
call
the
startup
hook
and
download
the
profile
directly
from
manage
code.
You
know
we
have
to
test
and
validate
that
work,
but
in
a
sense
I
find
kind
of
we
still
gonna
need
the
profiler
for
bytecode,
instrumentation
and
dotnet
framework,
but
at
least
there
is
no
question
kind
of
should
I
use
the
profiler
or
they
start
up
hook.
F
You
know
it's
just
always
they
startup
hookford.net
core.
So
this
was
something
that
I
think
not
for
beta,
but
it's
something
that
perhaps
we
should
experiment.
So
we
can
make
a
informed
call
on
that
regard.
So
I
want
to
bring
that
up
to
see
if
some
someone
has
some
concern
about
that
in
the
sense
kind
of
perhaps
already
anticipate
some
problem
that
I'm
not
seeing
the
main
risk
that
I've
seen
so
far
is
that
I
didn't
look
at
what
dependencies
that
managed
api
has.
F
So
I'm
not
sure
if
it
brings
a
gas
zillion
things
you
know,
but
other
than
that
it
seems
reasonable
to
me,
because
then,
as
the
framework
gets
kind
of
it's
going
to
take
time,
but
it
gets
less
and
less
important
with
people
moving
really
to
core
with
net
6
and
after
that,
then,
is
a
single
story
about
how
you
get
your
application.
F
Instrumented.
It's
always
they
start
uphook.
You
know
it
works
in
the
cases
that
and
we
can
do
fancy
stuff
like.
Oh
there's,
no
bytecode
implementation
download
the
profiler.
You
know
why
pay
the
price
of
attaching
the
profiler
if
you
are
not
doing
anything
with
the
profiler,
so
I
think
it's
a
avenue
that
we
should
explore.
F
So
my
idea
of
mentioning
this
and
bringing
up,
as
I
said,
is
kind
of
to
see
if
you
guys
perhaps
have
some
concern
that
I'm
not
thinking
right
now
and
should
be
something
that
we
should
pay
attention
when
we
experiment
with
this
down
the
line
after
beta.
E
Yeah
so
I
mean
one
of
my
thoughts.
There
is
a
timing
question,
so
I
know
that
many
of
these
profiler
implementations
assume
that
it's
starting
up
at
the
beginning
of
the
process,
and
so
the
initialization
happens
early
on.
So
I
don't
know
if
there's
any
assumptions
that
are
going
to
break
if
we
attach,
after
a
few
things,
have
already
happened.
E
So
I
mean
the
startup
hook
runs
fairly
early
on,
but
that
also
means
that
there's
going
to
be
modules
loading
earlier
in
the
process
that
the
profiler
won't
be
able
to
see.
F
Yeah,
my
my
question
in
this
case
is
kind
of
what
we
can.
What
I
I
I
thought
about
that
was
kind
of
can
rigid
helps
in
this
case.
You
know,
because
we
can
ask
to
see
stuff
and
do
the
via
widget,
but
yes,
I
I
think
this
is
a
a
very
good
point
that
we
should
be
paying
attention,
especially
if
the
profiler
has
any
dependence
on
stuff
from
initialization.
E
And
zach,
maybe
you
know
the
the
answer
to
this,
but
can
the
inch
the
set
of
instrumented
libraries
change
at
run
time
with
the
current
region
support.
E
So
I
know
with
new
relic
we
have
the
ability
to
change
what's
instrumented
at
at
any
point
in
the
process's
lifetime,
and
so
it
just
relies
on
the
region
apis
for
that.
But
I
don't
know
if
you've
all
implemented
anything
like
that.
Yet.
I
No,
we
don't
have
any
mechanisms
to
currently
to
initialize
new
regents.
We
only
initiate
a
region
calls
on
module
load,
so
we'd
have
there'd,
have
to
be
new
mechanisms
added
here
to
dynamically
change.
It
to
you
know,
go
back
to
the
original,
il
or
or
use
this
instrumentation.
F
And
just
for
me
to
be
sure
chris,
what
you
are
saying
is
also
that
you
also
use
rigid
in
the
sense
kind
of
I
added
the
instrumentation
here.
But
some
criteria
triggers
that
kind
of
hey,
I'm
done
with
the
instrumentation
I'll.
Remove
the
instrumentation.
E
Yeah,
so
so
the
way
I
like
to
think
about
it
is
so
you
got
some
customer
and
they
want
to
debug
some
some
issue
in
their
system,
but
there
isn't
enough
visibility
right
now.
So
then
they
go
to
to
some
online
system
and
they
say:
okay,
I
want
to
add
instrumentation
to
this
method
and
instead
of
having
to
build
and
redeploy
their
application
to
just
use,
the
apm
vendor
system
send
that
information
down.
It
makes
its
way
down
to
the
profiler.
The
profiler
sees
okay
yeah.
F
I
don't
know
but
but
the
thing
that's
crossing
my
mind
is.
F
So
because
there
is
the
info
api,
there
is
the
event
that
is
to
notify,
but
you
also
can
query
some
of
that
information,
not
all
of
them.
I
don't
remember
from
the
top
of
my
mind:
can
you
create
query
modules?
For
instance,
you
know,
and
then
from
the
modules
query
this
stuff,
that's
there
from
each
module.
G
Good
questions
yeah,
I
don't
have
the
answer.
Yeah.
F
No
no,
but
I
I
I
will
try
to
to
it's
the
the
core
profiler
and
the
core
profiler
info
apis,
the
relation
between
the
two.
So
we
can
kind
of
see
if
all
that's
all
that
stuff,
some
of
that
stuff,
at
least
one
can
work
around.
Even
if
you
load
later,
that's
why
I
want
to
bring
up
the
the
the
this
idea,
because
I
knew
that
you
guys
are
going
to
bring
some
good
points
about
this
stuff.
You
know.
E
F
Yeah
yeah
and
once
more
my
my
my
my
ideas
just
because
I
think
then
we
have
a
consistent
way
of
kind
of
saying
how
you
instrument
I
kind
of
not
liking
this
thing
about
having
the
profiler
and
they
start
up
hook.
You
know,
because
people
are
going
to
be
asking
all
the
time
which
one
should
I
use.
You
know,
and
I
rather
have
just
one
way
and
kind
of
also
makes
our
life
easier
in
the
sense
that
it's
just
one
scenario,
so
debugging
testing
becomes
kind
of
just
that
single
scenario.
F
Does
anyone
want
to
add
anything
here?
I
I
took
some
notes
here
for
the
future,
but
I
I'm
gonna
try
to
at
least
when
I
update
the
docs.
I'm
gonna
try
to
take
a
little
bit
of
time
to
perhaps
find
some
answers
to
those
in
the
box.
F
All
right
does
anyone
have
another
topic
that
they
wanted
to
talk
about.
F
Okay,
then
see
you
guys
next
week
hope
that
chris
is
better
by
then
actually
much
earlier
than
that.
I
hope
that
you
are
better
by
the
weekend,
especially
friday
evening.
You
are
completely
recovered.
Chris.
E
F
Yeah,
I
hope
that
this
is
just
going
to
be
kind
of
a
cold
and
soon
you
are
fully
back
there
here.