►
From YouTube: 2022-05-11 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
A
C
C
B
You
want
to
drive
it
today,
robert
yeah,
I
can
drive
I'm
just
giving
a
few
moments
and
listing
the
names.
I
don't
know
if
zac
is
joining
or
I
never.
B
B
B
So
here's
one
from
rasmus-
I
don't
know
if
anyone
got
a
chance
to
take
a
look.
But
basically
I
think
the
idea
was
to
load
the
to
use
a
different
load
context
for
loading,
the
basically
the
trace
provider,
to
have
a
different
load
context
for
sdk,
where
the
trace
provider
is
bootstrapped
and
the
other
one
for
the
application,
and
only
having
some
kind
of
regional
integration
for
the
libraries
which
are
sure
we've
used
uses
the
shared
state
which
are
system
diagnostic
source
and
the
login
abstractions.
As
far
as
I
understand.
E
Yes,
so
this
is
similar
to
one
of
the
proposals
that
that
was
previously
thrown
out,
where
we
have
to
have
a
proxy
to
to
basically
bridge
those
two
contacts
to
be
able
to
communicate
back
and
forth.
C
G
We
don't
need
to
do
different
load
context
right.
The
same
load
context
will
help
us
as
we
have
a
build
time
dependencies.
Don't
even
need
to
think
about
that.
B
Raj,
should
we
should
dress,
was
alright,
try
to
elaborate
or
and
or
is
it
clear
or
not,
feel
free
to.
G
Ask
or
if
I
need
to
understand
correctly,
that
we
are
going
to
have
a
new
get
package
built
from
an
auto
instrumentation
and
we
are
asking
customers
to
take
a
real-time
dependency
on
that
you
get
package
and
what's
my
understanding
it,
we
will
have
that,
but
I'm
what
I'm
not
getting
is
and
like.
On
top
of
it,
we
are
saying
with
that
nuget
we
will
load
the
open,
telemetry
libraries
in
a
different
load
context,
not
in
the
context
of
the
application.
G
The
moment
we
do
that
we
are
having
a
proposal
saying
that
diagnostic
source
will
be
in
the
comment
box
like
in
the
app
context
on
only
open
telemetry
will
be
in
the
different
context.
G
G
For
example,
the
open
telemetry,
which
is
with
the
customer,
might
have
a
different
diagnostic
source
version
and
the
one
we
bring
might
have
a
system.diagnostic
version,
not
only
that,
as
you
called
out
memory
or
system
dot
buffer,
all
of
them
could
be
different,
so
we
cannot
use
a
common
place
common
diagnostic
source
for
that,
so
it's
going
to
create
an
issue.
C
D
But
we
don't
need
for
the
application
principle.
We
don't
need
to
ship
those
be
because
we
just
need
to
be
sure
that
there
is
a
reference
in
the
application.
You
know
and
the
you
you
build
the
nougat
package
without
building
the
dlls.
If
I'm
not
mistaken,
this
is
kind
of
the
thing
that
is
already
in
place,
for
I
think
runtime
storage.
D
C
D
We
know
that
that
is
not
a
zero
impact
solution.
You
know,
we
know
that
there
is
impact
on
that,
but
I
think
for
the
time
being,
we
should
focus
on
that
path
with
the
nougat
package,
then
later
after
we
have
that
scenario
kind
of
working,
then
we
move
to
kind
of
these
more
advanced
scenarios.
You
know.
C
D
G
There
are
two
different
issues
we
need
to
address.
This
is
something
different
from
what
is
my
proposal.
My
proposal
is
going
to
address
the
assembly
load
issues
at
the
run
time,
and
what
you
are
trying
to
propose
is
something
at
the
build
type.
If
we
need
to
do
a
zero
touch,
that's
when
the
approach
I
proposed
will
come
into
picture.
If
customer
has
a
control,
if
he
can
change
it
yeah.
G
Definitely
we
need
to
take
this,
but
the
only
thing
that
we
need
to
just
do
our
two
different
streams
and
we
can
even
drive
in
parallel.
The
only
thing
question
I
have
in
this
approach
is:
should
we
load
in
a
different
contest
that
that's
my
only
worry?
Actually
the
moment
you
load
in
different
contests,
I
don't
know
whether
open
telemetry
can
listen
to
a
diagnostic
source
which
is
in
the
other
place
and
provide
the
activity
to
the
context.
G
I
tried
something
similar
to
this.
It
did
not
work
in
the
past
for
me.
Maybe
we
need
to
do
that.
Research,
if
we
are
thinking
about
a
different
context
without
a
different
context,
if
we
are
planning
to
build
a
new
gate
to
solve
all
the
dependency
solution
issues.
That
is
good.
If,
on
top
of
that,
we
are
trying
something.
I
think
we
should
have
a
valid
like
a
proof
of
concept
written
even
before
trying
that
out.
C
G
B
G
Yeah,
I
just
did
not
do
it
for
review,
probably
whatever
the
prs
that
I'm
creating
now
for
the
metric
prep
and
everything
is
based
on
this
one.
It
is
a
complete
working
solution.
Whatever
I
have
a
proof
of
concept
and
I
used
that
there
is
a
package
also,
I
updated
if
you
take
a
look
into
that.
It
is
like
that
latest
runtime
package,
which
is
being
like
released
from
the
open,
telemetry
contrib
repo
on
matrix.
G
I've
included
that
and
if
you
look
at
the
console,
it's
all
the
metrics
from
that
it's
emitting
all
the
dotnet
based
metrics
on
its
wall.
So
it's
based
on
that.
I'm
I'm
sure,
like
I'm,
going
to
continuously
create
prs
and
take
all
the
things
from
here
and
put
it
in
our
repo.
In
two
weeks
we
should
have
a
working
solution
with
without
test
without
integration,
test
or
a
test.
We
will
have
something
with
a
demo
app
and
we
will
start
working
on
the
tests.
G
H
B
B
B
Yes,
I
think
that
probably
we
want
to
use
the
ot
meter
metrics
exporter
by
default,
with
the
http
protocol
default
protocol
to
use
the
same
as
for
I
think
that
we
can
already
implement
those
two
and
vars
or
you
want
it.
A
separate
issue
correct
and
I
thought
that
maybe
sort
of
integration
test
here,
but
I
can
also
extract
it
to
other
issues.
You
prefer.
G
I
I
would
say
whatever
the
follow
has
got
a
good
approach
for
us.
He
updated.
He
has
everything
in
as
a
part
of
the
one
launch
settings.json.
G
D
I
B
G
I'm
also
in
parallel
checking
how
we
can
bring
logging
looks
like
there
is
minimal
effort
needed
in
that
space.
Also,
if
I
say
logging,
I
am
just
saying
only
the
dot
net.
I
logger
it
logs,
whatever
the
opentelemetry.net
supports
at
this
point,
looks
like
it's
more
simpler
than
getting
the
meter
provider
itself.
So
let
me
explore
if
that
comes,
I'm
going
to
create
something
there
as
a
proof
of
concept
for
everyone.
E
D
D
We
just
because
just
mentioned
it's
kind
of
obvious,
but
because
we
haven't
been
doing
all
the
instrumentations
regarding
monkey
patching
we
do
for
tracing,
but
if
there
is
any
kind
of
method
that
depends
on
initialization
of
something
to
be
able
to
generate
the
methods,
then
we
can
start
also
doing
monkeys
for
that
kind
of
stuff.
You
know
I
I
I
don't
think
I
hope
that
is
not
actually,
but
if
he
needs
we
can
do
it.
B
Exactly
and
hello-
and
this
is
the
last
one-
just
adding
dotnet
runtime
matrix
instrumentation,
which
is
already
your
poc.
By
the
way,
I
think.
E
Yeah,
so
one
thing
I
I
haven't
looked
at
regarding
the
the
runtime
metrics:
do
we
know
if
anybody
working
on
that
has
been
trying
to
define
the
semantic
conventions
for
the
net
runtime
metrics.
G
So
I
know
of
sean
is
an
engineer
who
is
working.
He
he's
also
from
my
team
so
he's
closely
working
with
the
dotnet
team
itself
to
find
those
areas
and
bring
clarity,
and
whatever
we
are
saying
like
aligning
it
with.
The
like
semantic
convention
is
something
that
he
is
exploring,
but
I
don't
have
a
like
more
update
on
that
part.
E
E
G
E
B
G
I
will
try
and
get
an
answer
by
next
week.
If
not,
I
I
think
it's
better
to
have
nowhere
joining
us
to
provide
the
writers.
E
E
Yeah,
similarly
from
what
I
remember
with
prometheus,
prometheus
metrics
use
a
different
naming
convention
than
open
telemetry
and
so
there's
a
translation
layer
for
both
the
receiver
and
the
exporters.
When
dealing
with
prometheus.
E
I
that's
what
I
remember.
I
remember
finding
code
specifically
in
exporters
and
receivers
for
it
so
converting
from
snake
case
to
dot
case
and
similarly.
B
Okay,
next
one
I
just
created
like
a
clone
for
for
creating
a
documentation
how
to
instrument
the
windows
service,
because
you
already
have
an
issue
to
document
how
to
instrument
an
is
an
ias
service.
B
Okay,
this
one
is
a
discussion,
but
we
haven't
got
all
the
answers
yet
so
also
someone
tried
to
use
so
basically,
it's
an
issue
created
by
a
user,
so
yeah.
E
I've
got
a
few
things
just
to
say
about
this
one.
If
you
don't
mind,
robert
go
roll
and
go
yeah,
so
just
just
to
catch
everybody
up.
This
issue
started
out
with
them
using
an
older
version
of.net,
which
used
an
older
version
of
diagnostic
source,
and
so
they
needed
to
do
a
few
things.
E
In
order
to
get
things
to
load
successfully,
then
it
came
down
to
them
not
seeing
all
of
the
instrumentation
that
they
had
hoped
for,
and
so
there's
a
couple
things
going
on
here:
one
they're
using
net
five
and
two
they're
using
postgres,
the
postgas
rest
driver
itself.
So
the
existing
sql
instrumentation
library,
that
we're
loading
doesn't
support,
postgres
and
so
turns
out
that
postgres
offers
another
instrumentation
library
in
its
repository
to
be
able
to
do
source
based
instrumentation.
E
And
so
that's
that's
something
that
we
should
consider.
E
D
I
I
would
say
that
we
have
other
stuff
to
do
that's
more
generic,
but
because
it's
gonna
help
with
adoption.
I
think
we
should
open
the
ticket
and
kind
of
see
the
cost.
If
it's
something
that
we
can
do
relatively
at
lower
cost,
then
one
of
us
should
pick
up
just
to
get
keep
going
the
feedback
with
the
user.
You
know.
A
D
B
E
B
E
Know
I
I
just
assumed
something
like
redis
would
be
more
popular.
B
E
I
don't
think
we
want
it
in
this
next
beta
if
we're
releasing
one
per,
but
probably
the
the
follow-on
after.
That
is
my
guess,
because
we're
releasing
support
with
this
next
beta.
Do
we
want
to
include
postgres
in
that
beta
as
well.
A
E
E
So
I
don't
know
if
they're
running
into
a
problem
specifically
with
net
five,
it's
unclear
but
they're,
definitely
not
getting
what
they
want
from
postgres,
and
so
I
I
don't
know
if
dot
net
five
is
also
a
source
of
the
problem,
but
anyways
your
recommendation
to
try
net
six
makes
sense,
okay
and
then
we'll
see
how
they
respond.
B
So
this
is
this
diagonal,
this
assembly
resolution
design,
which
you
were
like
describing,
and
there
was
already
some
feedback
from
chris
and
paulo-
that
they
like
proposal
number
one,
and
my
first
question
is:
do
you
have
raj
any
questions
so
far?
Do
you
want
to
are
you
working
activity
or
need
any
comments
from
your
site?.
G
As
as
I
called
out
right,
currently,
we
are
not
having
the
scorpius4.6
and
dotnet
seven
like.
Currently,
we
don't
have
an
issue.
Because.Net
6
and
open
telemetry
uses
the
diagnostic
source
6.0,
and
I
was
thinking
about
a
resolution.
We
have
a
very
simple
resolution.
Also
with
this
I
was
thinking
we
need
to
implement
something
custom,
but
we
may
not
need
to
like.
We
could
use
an
additional
depth
and
runtime
store
to
bring
the
latest
version
of
the
sdks
and
use
our
instrumentation
normal
library,
which
will
have
a
little
lower
version.
G
So
I'm
also
working
internally
with
the
dotnet
team
to
un
like
check
with
them.
There
are
additional
the
runtime
stores
we
create
for
each.net
version
and
each
runtime
architecture,
so
I'm
checking
with
them
if
we
can
reduce
the
size
of
it.
So
in
parallel,
I
need
to
engage
it
like
noah's.
Helping
me
engage
with
the
developer,
who
is
working
on
the
runtime
store
part,
so
let
me
work
with
them
and
see
if
we
can
reduce
the
size
of
the
package
there.
So.
B
C
C
B
E
Yeah,
so
to
summarize,
your
proposal
involved:
okay,
let's
let's
simplify
the
scope
of
this
project
and
be
able
to
support
somebody
who's
using
the
sdk
in
their
code
to
also
enable
bytecode-based
instrumentation,
and
so
this
is
removing
the
devops
scenario
and
the
auto
bootstrapping
concepts
from
from
this
project
and
just
trying
to
simplify
things.
And
so
my
my
line
of
thinking.
E
There
is
yeah
that
so
there
there
are
two
separate
problems
here
that
can
be
addressed
independently,
but
I
think
the
by
code,
instrumentation
aspect
of
things
is
a
bit
more
straightforward.
E
We,
I
think
we
have
good
ideas
on
how
to
do
that.
We
could
have
a
nuget
package
that
could
be
used
in
addition
to
the
open,
telemetry
sdks
new
get
packages,
and
then
they
would
also
potentially
have
to
set
up
some
environment
variables
to
get
that
working
unless
we
figure
out
how
to
use
that
one
api
to
see
if
it
works
to
trigger
the
bootstrapping
via
or
at
least
a
profiler
bootstrapping
via
code.
E
But
I
I
had
a
conversation
with
raj
and
I
think
this
devops
scenario
is
gonna,
be
really
important
and
there's
already
use
cases
being
planned
for
where
we
really
need
the
ability
to
install
our
project.
In
let's
say,
a
docker
container
template.
E
So
that
people
who
are
sending
their
running
their
applications
in
the
cloud
they
can
use
that
cloud
providers
templates
and
it
may
already
contain
our
open
telemetry
project
and
the
idea
is
to
just
have
things
working
out
of
the
box,
and
I,
I
think
that's
a
bigger
use
case,
and-
and
we
should
strive
to
support
that
with
that
being
said.
E
If
we
see
some
people
really
wanting
to
have
the
the
nuget
package
to
be
able
to
just
add
bytecode
instrumentation,
while
programmatically
using
the
sdk,
I
think
we
could
easily
add
support
for
that.
D
Yeah,
I
I-
and
I
I
add
to
that-
that
there
is
the
devops
solution,
but
really
really
people
a
lot
of
devs
and
companies
take
very
different.
When
you
say
hey,
add
this
dependence
versus
add
this
dependence.
Add
this
snippet
of
code
could
be
small,
could
be
simple,
but
they
take
very
different.
You
know,
if
you
need
to
touch
code,
they
take
very
different
than
hey.
D
Add
this
package,
you
know
and
build
the
other
thing
that
cross
my
mind
in
this
regard
is
kind
of
we
already
have
a
path
to
allow
them
to
load
their
sdk
by
their
themselves
if
they
prefer,
for
some
reason
and
in
terms
of
organization
kind
of
makes
sense,
perhaps
to
have
the
part
of
loading
the
sdk
completely
separate,
but
I
think
in
terms
of
because
we
are
trying
to
cover
the
scenario
that
we
inject
the
sdk
anyway.
D
The
benefits
of
splitting
that,
for
us
at
this
moment,
are
not
that
big.
You
know
I
I
can
see
that
makes
sense,
but
I
from
just
a
kind
of
separation
of
concerns,
but
on
the
other
hand,
I
think
it
is
gonna
be
another
thing
for
us
to
to
to
manage
and
another
separation
that
at
this
stage
I
don't
think
it's
bringing
value
to
us.
B
So
I
just
want
to
sum
up
that
after
you
know
this,
I
have
read
after
I
thought
it's
the
second
time
I
even
was
thinking
to
close
it
immediately,
but
I
just
wanted
to
have
this
conversation
because
kind
of
I
agree
that
probably
it
could
be
used,
as
you
said,
paulo
as
a
next
step,
maybe
to
reorganize
even
internally
our
repository,
our
structure,
but
probably
to
better
to
do
it
in
the
baby
steps
and
if
there's
really
an
issue
and
then
ask
right
now
it's
more
important
to
address
the
things
that
are
coming
up
and
not
something
that
I
artificially
thought
up
like.
B
I
Yeah,
I
was
gonna,
say
yeah.
We
can
just
kind
of
pursue
each
of
those
independently.
If
we
decide
like
we
want
to
actually
want
to
separate
them
out
right
now.
We
have
both
and
maybe
both
projects-
encodes
us-
you
know
inside
here,
and
so
we
don't
have
to
like
change
much
right
now,
but
this
can
just
be
like
a
guiding.
B
B
B
B
A
Yeah,
let's
see
it's
not.
E
Just
opinion
yeah,
I
it
is
an
opinion
it's
valid,
and
so
this
was
something
that
I
was
torn
on
myself,
which
is
why
I'm
I'm
bringing
it
up
and
so,
like.
I
said,
I've
gotten
feedback
from
from
a
couple
of
you
and
I
I
don't
know
if
the
others
have
had
a
chance
to
review
it
if
they
think
it
looks
good.
E
I
E
A
look,
and
if
things
look
good,
I
can
feel
free
to
open
a
pr.
I'm
gonna
be
taking
a
vacation
next
week,
but
I'll
be
back
the
the
following
week.
So
just
depending
on
the
timing
of
things,
if
things
look
good
and
it's
not
submitted
before
I
return,
I
can
go
and
open
it.
When
I'm
back.
D
Do
you
think
if
we
have
feedback
for
you
later
today
already
perhaps
we
can
get
this
done
before
your
vacation.
D
Cool,
so
I
I
will
take
a
look
right
after
the
meeting
added
any
feedback
that
I
have,
so
we
can
try
to
push
this.
E
Yeah,
and
just
depending
on
the
timing
of
things
once
I've
got
that
pr
open
I'll
I'll
send
a
link
out
to
it.
I
just
won't
be
responsive
to
that
pr
for
a
week.
B
Okay,
raj
russia
watch
raj,
the
ticket
was
already
discussed
and
basically
david
just
started
working
on
implementing
the
last
missing
test,
which
is
for
sql
client
instrumentation,
just
a
smoke
test
that,
basically,
it
emits
any
any
spawn
from
there.
So
we
just
put
it
in
progress.
C
Test,
if
anybody
noticed,
if
the
mongodb
or
graph
here
failed
again.
B
I
think
they
were
failing.
I
even
I
think
I
even
yeah.
I
think
I
was
even
here
yesterday,
re-running
on
before
merging
crashes.
Vr.
B
B
B
E
Yeah
speaking
of
flakiness,
I've
seen
this
across
multiple
repos,
but
sometimes
when
you're
running
a
net
build,
it
dies
on
some
sort
of
ms
build
parsing
and
I
have
no
idea.
What's
going
on.
E
B
B
B
Raj,
so
I
just
I
will
try
to
I
assigned
to
you
and
made
it
in
progress.
Bootstrap
now
bootstrapping
the
metric
provider,
because
I
believe
this
is
what
you're
working
on.
Is
it
correct.
D
G
E
B
We
had
an
issue
regarding
enabling
all
source
instrumentations
by
default
and
basically
chris,
I
think
chris
and
rasmus
during
the
last
six
meeting-
or
I
don't
remember
when
no
there
was
discussion
that
there
was
an
idea
that
when
we
detected
that
an
assembly
is
loaded,
that
we
can
source
instrument
and
then
we
could
try
to
add
the
source
instrumentation,
but
right
now
the
trace
provider
is
immutable
and
it's
not
possible
to
add
additional
source
instrumentation
after
the
trace
provider
is
created.
So
basically
erasmus
created
pr
to
add
such
functionality.
B
B
Okay,
anything
work
here
that
anyone
wants
to
describe
ask
or
is
it.
G
G
So
whatever
the
approach
we
are
going
to
take
on
the
long
run,
this
is
going
to
cause
us
an
issue,
so
we
might
need
to
engage
the
open,
telemetry
sdk
and
ask
for
an
option
either
to
disable.
I
like
provide
a
disable
option.
I
chris
also
called
out
in
my
one
of
my
issues,
but
we
should
really
have
an
option
and
we
can
provide
an
option
to
the
customer
whether
he
need
to
override
the
sdk
or
leave
it
as
it
is.
G
G
G
E
Yeah,
so
I
mean
my
only
question:
there
is
what
what
behavior
is
someone
expecting
in
that
scenario?
E
Are
they
really
expecting
their
sdk
usage
to
be
the
one
that
takes
effect,
or
are
they
expecting
this
project's
configuration
to
be
the
one
that
that
takes
effect.
G
For
example,
the
user
has
a
open,
telemetry
sdk,
which
sends
the
like
data
to
zip
key.
G
Now
he
decides
that,
like
auto
instrumentation
provides
me
an
option
to
send
it
to
a
tnp
without
changing
any
of
my
code,
so
I
will
just
take
the
auto
instrumentation
enable
it.
I
want
my
sdk
things
to
turn
off.
Devops
will
feel
it
that
way,
so
we
we
should
all
have
an
option
to
do
that.
Currently
we
don't
have
that
part
in
us,
I'm
just
giving
an
exporter
as
a
simple
example.
It
can
be
done.
E
For
any
take
yeah,
so
I
think
that
the
thing
that
stands
out
the
most
in
my
mind
there
is
in
that
scenario
there
is
a
conscious
choice
being
made
where
they
actually
want
their
sdk,
that's
in
code
to
be
disabled
and
so
the
so
having
that
that
switch
to
to
make
that
possible,
I
think,
makes
sense
in
the
case.
E
One
of
the
cases
that
that
I
was
imagining
is,
let's
say:
they've
got
their
application
and
let's
say
they
were
running
it
on-prem
and
they
were
using
the
open,
telemetry
sdk
to
manage
that,
but
now
they're
migrating
to
the
cloud
and
so
they're,
switching
to
a
cloud-based
template
which
is
using
our
project,
and
so
in
that
case
my
guts
tell
me
they
want
their
s.
Their
manual
sdk
usage
to
take
precedence
over.
G
I
agree
chris
with
you
like
the
thing
is
that,
like
we
should
have
an
option
at
this
point,
getting
the
option
earlier
from
the
sdk
is
a
lot
better
for
us,
because
we
have
another
approach
where
we
plan,
we
are
going
to
have
a
least
possible
sdk
version
with
us,
so
having
that
feature
enable
that
is
going
to
help
a
lot
in
that
way,.
E
G
So
I
have
seen
a
common
issues
within
our
telemetry
sdk.
What
they
will
do
is
people
they
just
add
a
telemetry
sdk
package
reference
in
their
cs
approach,
but
they
don't
do
the
like
tracer
those
kind
of
configuration
in
their
code
and
they
don't
even
realize
such
thing
is
happening
and
they
just
feel
that
telemetry
is
not
flowing.
D
D
Yeah
that
that
of
the
trouble
shooting,
I
find
very
interesting.
You
know
because
people
struggle
especially
right
now
that
the
sdk
just
have
event
source.
They
don't
log,
try
larger,
so
people
sometimes
struggle
with
that.
D
B
I
just
want
to
go
back
a
little
step
back
to
the
topic.
Personally,
I
don't
know
if
this
transition
or
to
the
outer
instrumentation
or
to
the
coded
manually
coded
sdk,
is
so
important.
Personally,
if
I'll
be
a
developer,
I
would
even
not
search
for
such
functionality.
I
would
just
wrap
all
the
code
in
an
if
statement
and
control
it
using
environment
available,
for
example,
or
some
configuration
I
would
not
even
bother
searching
if
there
is
such
out
of
the
box
functionality.
B
B
D
Yeah,
I
I'm
I'm
thinking
also
about
the
the
side
effects,
because
a
natural
way
to
do
that
will
be
kind
of
hey.
I
wanna
just
label,
you
are
gonna,
create
a
know
what
sdk
right
and
then
you're
gonna
call
a
bunch
of
things,
but
then
I
still
have
all
the
side
effects
of
any
parameters.
Anything
that
you
build
in
your
lab
does
or
something
that
you're
doing
the
setup
exactly.
D
Gone
all
right,
I
think
it's
time
to
invite
raj
to
be
one
of
the
maintainers.
He
had
been
working
on
some
key
problems
that
we
have
regarding
version
regarding
metrics,
a
bunch
of
stuff,
so
I
think
it's
time
to
make
official
and
make
raj
one
of
the
maintainers.
D
All
right
later
today,
I
will
create
the
pr
and
update
the
membership
and
raj
welcome.
You
are
one
of
the
maintainers
now.