►
From YouTube: 2022-05-04 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
C
E
Hey
hi
jay
hi,
everyone.
D
D
Just
quick
question:
are
you
still
in
india
I
missed
connecting
with
you
yeah,
no
idea,
I'm
back.
I
came
back
this
week
weekend.
Sorry,
I
could
not
connect,
but
I
will
find
a
u.s
time
zone
time
to
connect
with
you
for
sure
in
next
one.
No,
no
problems.
E
E
D
D
C
D
Yeah
now
there
is
no
noise
is
coming,
so
that's
perfectly
fine.
So
what
we
will
do?
We
have
a
quick,
two
or
three
slide
to
discuss
and
after
that,
based
on
the
feedback
from
all
of
you,
we
will
take
it
forward.
So
that
is
something
so
do
you
want
me
to
start
with
that?
Really.
B
E
F
B
Let
me
let
me
try
that
I
think
I
should
be
able
to.
D
B
B
So
this
nginx
module
on
the
the
architecture
of
this
model
is
pretty
much
same
as
what
we
have
done
for
the
apache
module,
which
is
already
there
in
the
open
source
so
and
and
and
it
this
nginx
module,
also
does
module-wise
monitoring
like
it
it
it
monitors
every
module
that
goes
through
that
http
request,
and
this
is
similar
to
what
we
have
done
for
apache.
B
So
the
kind
the
way
it
is
done
is
through
monkey
patching,
so
the
nginx
module
it
intercepts
the
nginx
hooks
and
tries
to
call
the
specific
modules
as
a
part
of
that
and
calculate
the
spans
for
each
of
these
modules.
So
the
architecture
is
also
similar
to
what
we
have
done
for
apache.
B
So
the
the
main
proposal
is
almost
similar
to
what
we
have
done
for
apache
here.
So
it's
again
the
same
thing
I
think,
and
it
also
talks.
We
are
talking
about
the
module,
wise
monitoring
here
so
as
as
we
had
discussed
earlier,
that
the
root
cause
of
any
any
particular
modules,
the
root
cause
of
an
http
request,
any
delay
in
the
http
request
can
be
looked
at
it
at
the
individual
models
which
got
involved
in
that
request.
B
Processing
phase,
so
this
model
was
monitoring,
would
anyway
definitely
be
helpful,
and
we
have
this
comparison
again
here
on
this,
with
the
existing
hotel
engine
x,
module
and
the
app
dynamics
engine
x
model.
So
as
of
now
the
app
dynamics
engine
x
module
has
this
capability
of
monitoring
through
the
individual
models
through
multiple
modules,
which
is
kind
of
missing
in
the
open
source,
nginx
module.
As
of
now
and
and
and
and
the
way
we
have
designed
this,
our
web
server
agent
is
like
it
uses.
B
The
wrapper
which
you
have
already
donated
now
and
just
the
nginx
nginx
directory,
will
go
and
sit
in
the
same
hotel
web
server
module
and
that's
how
it
is
different
from
the
existing
one
and
all
the
other
features,
whichever
was
is,
is
being
added
in
the
nginx,
can
also
be
easily
added
in
the
app
dynamics,
nginx
module.
B
So
I
have
a
so
the
reasoning
and
logic.
Everything
is
same
similar
to
what
we
have
done
for
apache,
and
I
would
like
to
share
you
a
demo
of
this
in
the
zipkin,
so
so
this
is
a
sample
request
that
we
have
share.
We
have
created
here
on
on
slash
endpoint,
and
these
are
the
individual
modules
which
got
involved
as
a
part
of
this
request,
and
there
are
multiple
phases
and
in
each
of
these
phases
some
modules
got
involved.
B
So
you
can
see
here,
http
rewrite
module
is
being
monitored
twice
here.
That's
because
these
two
are
from
two
different
phases.
So
so
that's
how
we
we
show
all
the
modules
which
are
part
of
this
request.
B
So
yeah,
so
that's
pretty
much
from
this
nginx
model
contribution
so.
G
B
G
A
single
file
as
well
like
an
so
that
is
a
normal
nginx
extension,
or
is
it
something
different
sorry
come
again?
Is
it
like
a
shared
library
as
well
the
things
that.
B
Loads,
okay,
yes,
yes,
it's
a
shared
library
and
this
module
is
is
actually.
This
agent
is
specifically
a
module
in
the
engineering,
and
one
key
difference
we
have
is
the
shared
library
that
would
which
we
so
we
have
divided
our
library
into
two
individual
libraries.
B
So
that's
how
the
apache
is
also
being
developed,
so
so
only
difference
which
will
go
as
a
part
of
this
module
is
the
hooking
logic
which
will
go
into
our
repository
and
whereas
the
existing
wrapper
over
c
plus
sdk
remains
same.
So
there
won't
be
any
change
on
that.
So
that's
how
so
so
it's
it's
kind
of
in
terms
of
maintainability.
B
D
So
so
value
proposition
perspective
again,
it's
the
same
thing,
what
we
discussed
for
the
apache
so
from
the
architecture,
the
feature
set
which
we
talked
about
apart,
you
think
same
thing
is
applicable
here
on
the
engine
x
also
and
then
from
the
maintenance
perspective
x.
Devotees
is
saying:
future
extension
is
much
easier.
Whatever
we
want
to
enhance
for
the
apache
module,
it
will
be
very
easy
to
do
the
same
thing
for
the
indian
excitement.
D
We
do
understand
right
now.
This
portal
engine
x
module,
which
is
available.
We
have
gone
through
the
details.
There
are
few
features
which
available,
but
those
can
easily
be
extended
in
this
nginx
module
from
our
side
and
we
will
make
sure.
Basically,
there
is
no
functionality
is
missing
out,
but
mainly
lalit,
and
all
we
wanted
to
understand
from
your
side.
What
is
the
current
state
of
this
x?
Module
which
exists
and
what
are
the
future
plan?
Are
we
having
the
active
enhancement
and
the
contributor
on
this
particular
module.
G
Yes,
when
I
was
maintaining
it,
I
was
not
actively
developing
it
correctly.
I
was
just
merging
some
of
the
pull
requests
and,
as
of
a
few
days
ago,
we
received
another
maintainer
who
has
been
active
on
the
project,
but
otherwise
for
the
plans.
I
think
the
largest
plan
there
was
to
support
openresty
and
the
lua
blocks
as
well.
D
Yes,
so
that's
good,
so,
as
I
said,
definitely
our
plan
was
to
stabilize
the
apache
module
first
and
make
sure
some
of
the
additional
functionality
like
the
cento
x
7.x
support
the
ubuntu
support.
Those
are
the
thing
which
we
were
focusing
on
and
now
we
wanted
to
discuss
with
you
guys
when
I
saw
the
message.
Definitely
there
is
some
discussion
and
then
involvement
is
happening
on
this
engine
x
module.
So
what's
your
proposal
or
suggestion
same
on
this
proposal?
D
G
Yeah,
I
really
like
that.
It's
tracing
through
all
of
the
modules
that
I
think
is
that's
really
useful.
G
D
Is
definitely
one
of
the
value
proposition
which
we
want
to
call
out
and
again.
This
is
definitely
initially
we
developed
for
the
fd,
cisco
customer,
but
we
realized
this
is
for
the
bigger
community
and
rest
of
the
people
would
also
be
beneficial.
That's
where
we
really
would
like
to
contribute
so
that
other
people
can
benefit
and
then,
at
the
same
time,
people
like,
I
think,
a
person
by
name,
tobias
and
then
sim.
You
are
working
on
the
nginx
module
right.
D
So
if
we
get
the
opportunity
to
replace
this
nginx
module
and
then
we
can
collaborate
so
that
we
can
add
further
features
on
both
apache
and
also
on
the
nginx
module.
So
that
way
it
will
be
the
same
architecture.
The
extensibility
would
be
much
easier
and
with
one
single
repository
we
would
be
able
to
take
things
forward
for
the
future
plan.
A
D
Yeah,
so
absolutely
we
don't
want
to
miss
out
any
feature
which
currently
exists
and
devajit
and
produce
has
looked
into
the
code
and
the
feature.
Those
looks
like
a
minor
extension
which
we
have
to
do
on
this
engine
x,
so
that
we
will
be
able
to
do
it
in
that
way,
we
will
make
sure
from
the
parity
wise.
There
is
no
difference
in
both
the
module
and
there
will
be
the
additional
feature
which
currently
this
engine
x
and
replacement
is
not
possible.
We
will
not
be
able
to
add
this
fd.
D
G
G
D
Yeah,
so
I
like
the
approach
last
time,
lalith
also
suggested,
probably
for
some
time
we
can
continue
having
both
the
repository
exist,
but
at
the
same
time
we
can
announce
some
kind
of
are
saying
we
will
be
replacing
it,
and
people
can
start
utilizing
this
new
module,
which
is
more
reachable
feature
rich
and
other
way.
So
we
will
not
be
kind
of
completely
deactivating.
D
The
existing
module
both
can
co-exist
and
then
let
most
of
the
new
users
start
using
the
new
module
and
the
existing
one
can
plan
to
migrate,
and
once
we
have
that
satisfactory
answer,
saying
there
is
nobody
who
is
kind
of
using
it.
That's
where
we
can
decide
to
deactivate
that's
what
we
thought
would
be
the
best
proposal.
E
I'm
just
just
to
add,
I
think
at
one
time,
probably
once
we
start
once
we
have
a
feature
parity
and
we
plan
to
deprecate
or
make
it
make
the
existing
nginx
module
obsolete.
Probably
we
should
have
and
have
a
thorough
migration
document
which
will
help
the
existing
customers
to
migrate
from
the
existing
to
the
new
one.
I
think
probably
that
would
be
important
to
have
and
that
will
help
the
existing
customers
to
migrate.
D
I
absolutely
agree
yeah.
Definitely
the
document
which
we
will
be
having
for
the
new
module
like
how
people
can
use
it,
but
at
the
same
time
we
can
also
add
some
additional
section
how
people
can
migrate
from
the
existing
one
to
the
new
module.
D
D
B
Yeah
so
with
with,
with
with
the
kind
of
internal
testing
we
have
done,
we
have
not
found
anything
as
such,
which
which
raises
a
concern,
but
yeah
we
might
have
to
do
a
wider
range
of
performance
testing,
considering
various
kinds
of
use,
cases
that
is
still
pending,
maybe
once
we
stabilize,
we
can
start
doing
that
and
and
and
if,
if
situation
arises
like.
B
G
G
B
Yes,
we
we,
we
do
support
some
of
the
directives
and
that
is
similar
to
what
we
have
done
for
apache
in
the
repo
and
and
if
you,
if
you
see
the
directives
and
compare
with
the
existing
nginx
module,
the
engineering
hotel
module,
provides
lots
of
directives,
configurable
parameters
for
the
user.
G
Okay
yeah,
so
if
we
were
to
get
to
feature,
but
it,
I
think,
I'm
not
sure
if
we
want
the
directors
with
the
same
name,
but
perhaps
for
if
you
want
to
deprecate
the
old
engine
x
agent,
we
should
at
least
support
some
of
the
directives
right.
B
So
once
once
we
say
that
the
old,
the
new
one
is
more
matured
enough.
We
can.
That
will
be
the
point
when
we
have
all
the
directives
which
were
supported
in
the
existing
engine
x
has
been
also
been
supported
in
this
in
this
offering
in
in
the
one
that
we
are
suggesting,
and
then
only
we
can
say
that
this
has
been
mature
to
the
level
which
the
current
one
has
been
there
like
in
terms
of
directives
or
configuration
directives
being
provided.
D
And
internally
also,
we
we
are
trying
to
have
the
complete,
the
recreation,
environment
and
other
thing,
and
even
I'm
involving
some
of
the
qe
member
also
from
my
team,
so
that
whatever
we
develop
whatever
we
contribute
to
the
community,
those
are
properly
tested
thoroughly,
both
from
the
performance
perspective,
the
quality
perspective,
because
we
don't
want
any
of
the
who
are
using
this
community,
offering
they
suffer
any
kind
of
performance
or
any
security
related
issue.
So
this
is
kind
of
commitment
we
are
having
from
cisco
decide
so
people
whatever
we
will
be
delivering
it.
D
B
Yeah
we'll
be
raising
a
pull
request
for
this
in
the
hotel
web
server.
Module
repository
right
under
instrumentation
we'll
be
raising
a
pull
request
under
a
separate
branch
so
that,
once
the
nginx
part
is
being
tested
and
and
properly
approved
by
our
kiwi
team,
we'll
be
then
merging
that
changes
to
the
main
branch.
That's
how
we
are
planning,
so
we
have
not
raised
yet
we'll
be
raging
in
couple
of
days.
B
B
We
have
similar
dependencies
for
nginx
as
well,
so
boost
is
anywhere
there
yeah.
But
if.
D
Yeah,
so
there
is
no
additional
thing
lalit,
so
basically,
whatever
we
discuss
from
the
apache
perspective,
because
it's
the
same
architecture
same
code
base,
it's
the
only
the
additional
folder
and
we
have
followed
the
modular
approach.
Basically,
the
sdk
or
the
core
module,
which
is
basically
both
are
kind
of
shared
by
apache
and
the
engine
x.
From
that
repository
perspective,
also
it's
a
kind
of
very
organized
core,
but
yeah.
But
apart
from
the
boost,
there
is
no
other
major
dependency,
I
would
say
and
boost
also
as
we
discussed.
D
B
Yeah,
so
to
be
clear,
I'm
sharing
my
screen.
So
this
is
the
hotel
web
server
module.
So
when,
when
the
once,
we
once
in
this
source
directory,
we
can
see
there
is
a
directory
called
apache
and
we
have
core
and
util,
which
is
purely
the
modular
one,
which
ajay
was
talking.
B
It's
it's
kind
of
a
wrapper
of
a
cpp
sdk.
Similarly,
when
we
push
for
nginx
we'll
be
having
a
directory
called
nginx
here
and
that
will
have
all
the
engine
x,
hooks
related
code
base,
yeah.
G
B
Yeah
and
and
in
terms
of
library-
maybe
we
might
have
to-
and
these
are
the
dependencies
which
we
are
current-
these
are
the
dependencies
for
apache
for
nginx.
Some
of
the
dependencies
might
not
be
there.
Maybe
apr
and
api
util
might
not
be
there.
I
might
have
to
re-look
it
into
this.
I'm
not
very
clear
at
this
moment,
but
yeah
boost
open,
telemetry,
cpp
sdk
will
anyway
be
there
boost,
is
on
and
and
again
on
boost.
We
are
only
dependent
on
the
file
system
and
system.
B
Yes,
yeah
and
coming
to
sims
question
about
the
configuration
direct
directives,
so
these
are
the
directives
which
are
provided
for
apache
and
similar
directives
are,
can
also
be
provided
for
nginx
with
with
with
instead
of
apache
module,
we
can
have
we'll
be
having
something
engine
x,
module
and
the.
B
Sampling
we
had
because
open
telemetry
sdk
provides
the
options
we
just
kept
it
as
with
this
optional
parameters,
but
I
think
these
are
of
no
value.
As
of
now
always
on
is
always.
Is
there
always
off,
doesn't
make
any
sense.
E
B
Yes,
so
we
we
have
to
do
some
extra
kind
of
work
to
support
all
of
this.
I
I
have
I've
seen
these
directives,
so
these
are
some
good
amount
of
directives
which
are
being
supported
in
the
current
engine
x,
and
these
are
also
different,
http
attributes
that
are
being
supported.
B
D
We
definitely
have
a
plan
to
support
these
missing
thing
in
our
module.
D
D
So
we
will
definitely
have
the
active
support
from
our
side
and
but
other
maintainer
and
the
contributor
definitely
could
be
most
welcome
and
that
will
help
us
to
leverage
the
community
members
bandwidth
also,
but
from
our
commitment
perspective,
definitely
we
will
be
making
sure
we
are
supporting.
We
are
enhancing
and
maintaining
it.
D
So
it's
the
same
commitment
what
we
have
given
for
the
apache.
It
could
remain
the
same
for
the
engine
x,
also
because
sometime
I
have
seen
we
contribute,
but
when
it
comes
to
the
future
enhancement,
some
kind
of
bandwidth
is
required
and
if
we
lose
track
of
those
kind
of
enhancement
or
we
are
not
able
to
actively
maintain
it,
sometimes
these
components
start
losing
its
values
so
yeah.
Definitely
we
will
be
maintaining
it,
but
it
will
be
again
just
like
the
rest
of
the
component
which
exists
in
the
community.
C
D
You
mean
the
integration
test
which
internally
we
have
developed.
That's
what
you
are
asking
yourself.
C
Or
something
that
I
mean
for
future
development
so
like
that
everybody
has
to
pass
those
tests,
not
exactly
what
you
are
testing,
but.
B
B
Be
there
because
I
I
really
feel
that
currently
we
don't
have
so
if
any
functionality
changes
we
make,
we
have
to
be
very
much
sure
that
the
existing
functionality
doesn't
break,
and
that's
if
you
don't
have
that,
that
will
be
a
great
challenge
for
us.
Yeah.
D
D
So
we
are
planning
to
automate
that
ci
thing
which
is
talking
about
so
that
future
testing,
the
qualification
other
thing
becomes
very,
very
automated
and
it
requires
some
of
those
ci
pipeline
can
be
utilized
for
the
rest
of
the
c
plus
plus
repository.
If
there
are
any
other
component
and
those
kind
of
pipeline
applicable
for
there
as
well.
I
think
people
can
definitely
leverage
it,
but
for
the
apache
and
the
engine
export
the
thing
we
are
planning
to
develop
very
automated
continuous
development
and
the
integration
mechanism.
G
B
G
D
So
sim
definitely,
I
have
not
interacted
with
the
existing
owner
of
this
nginx
module.
Tobias,
do
you
have
any
connect
with
him
and
do
you
want?
I
should
be
interacting
with
them
or
it
is
okay.
We
can
go
ahead
and
start
putting
down
the
request
and
in
case
obvious,
is
available.
He
can
also
review
some
of
our
requests.
G
So
I
wrote
the
ingenix
agent
initially,
but
oh,
it
hasn't
received
the
bunch
of
updates
as
of
late,
it's
like
in
a
maintenance
mode,
but
we
received
a
new
maintainer.
So
perhaps
he
wants
to
help
with
a
new
one
as
well.
D
So
if
you
have
wrote
initially,
I
think
your
review
and
the
comment
would
be
most
welcome
and
those
would
be
valuable.
So
if
we
all
agree,
definitely
can
start
putting
down
some
of
the
next
step
like
raising
the
pull
request
and
other
thing,
and
we
will
be
making
sure
all
we
follow
the
all
the
process
and
in
the
next
meeting
we
can
provide
all
the
updates
like
what
are
the
next
step
we
have
done
so
far
and
what
would
be
the
future
thing?
D
So
there
was
it
do
you
know
how
much
work
would
be
required
for
us
to
really
put
down
this
nginx
module
in
a
quality
manner
after
testing
rough
idea.
B
Yes,
we
might
have
to
do
some
kind
of
internal
like
code
refactoring,
not
code
refracting,
some
naming
conventions
that
we
have
to
follow.
B
Those
kind
of
changes
are
required
and
some
qe
testing,
and
once
that
is
done,
we
can
we'll
be
anyway
raising
appear
and
in
a
separate
branch,
it's
just
that
kiwi
will
test
it
parallely,
and
then
we
can
say
that
this
is.
D
Done:
okay,
that's
good,
so
we
can
start
doing
those
activity
and
probably
after
two
weeks
when
we
meet
again
in
this
meeting,
definitely
you
will
have
more
update
to
say
right,
right,
right.
B
E
D
E
Okay,
matrix
implementation,
causing
something
which
is
has
been
on
priority
for
some
time,
and
I
have
split
created
two
different
milestones
as
of
now
for
this.
E
So
I
think,
for
the
alpha
release,
we
look
good.
Probably
I
think
this
is
also
done.
We
just
need
to
look.
Go
go
go
to
the
mat
current
matrix
for
the
specs,
the
compliance
matrix
to
see
where
all
where
are
we
in
the
current
implementation,
and
probably
we
can
based
on
that,
we
can
decide
whether
we
should
have
a
alpha
release
or
not
for
beta
release.
E
E
I
know
there
are
issues
there
would
be
some
performance
things
which
we
need
to
take
care
of,
that
there
are,
there
are
issues
and
how
we
handling
the
aggregation,
temporaries
and
multiple
instrumentations
for
the
asynchronous
aggregations,
which
we
don't
support.
I
don't
know
so
multiple
using
callbacks,
so
there
will
be
some
more
items
which
we
will
get
added
here,
but
I
think,
looks
to
be
in
good
shape
as
of
now
and
probably
probably,
I
think
at
least
we
can
target
for
the
alpha
release
to
start
with
and.
E
That
next
be
part
of
beta,
I'm
going
to
add
that
as
a
new
new
item
here
on
your
site,
we
need
to
support
at
least
few
beer
minimum
exporters
like
premier,
ts
and
otlp.
Actually,
these
shows
should
be
there
primitius
already
assign
has
implemented
it.
We
already
have
that.
I
think
otlp
is
something
which
is
missing
for
now.
We
need
to
support
it.
B
Yeah,
because
we
have
some
dependency.
D
G
So
to
get
it
right
that
currently
the
promatus
exporter
is
available,
but
no
other
exporters.
C
E
H
E
Yeah,
it
was,
I
think,
ease
of
integration.
That
was
the
only
reason
I
could
find
out
going
through
the
history
of
all
the
discussions.
I
think
I
shared
one
of
the
discussions
in
the
channel
and
that
points
out
that
that
was
the
only
reason,
the
ease
of
integration.
You
don't
need
to
have
any
build
systems
if
you
just
want
to
use
the
instrumentation.
I.
H
See,
okay,
should
we
keep
that
or
we
can
maybe
or
we
can?
We
should
maintain
that
for
future
releases,
we're
wondering.
E
H
I
only
received
a
few
ask
on
only
so.
I
think
it
is
not
considered
as
important,
but
if
we
have
like
have
work
around
to
suggest
like
maybe
the
only
disadvantage
of
linking
a
static
library
to
each
of
the
customers
component,
maybe
only
a
few,
a
few
megabytes
like
so
or
less
than
that
memory
and
others
are
same
like
context
propagation.
E
H
H
H
And
yeah.
E
H
E
Oh
yeah,
I
mean
I
totally
get
this
use
case
that
that's
a
very,
very
valid
use
case.
I
mean
how
many
customers
are
really
asking,
probably
because
I
mean
I'm
just
thinking
if,
like
the
example
of
ptw
exporter,
which
is
header
only
and
we
are
kind
of
marketing
it
as
a
header
only
just
because
we
get
the
episode
only
so
there
are
some
of
the
things
which
are
going
to
break,
which
we
may
not
be
able
to
support,
as
we
have
been
doing
as
of
now.
E
H
I
think
them
like
memory.
Extra
cost
is
just
a
mean
within
enemies,
not
that
important,
but
I
think
it's
a
cross-component
in
propagation,
where
we
will
be
become
more
important
as
people
it's
more
component
enabled
up
in
telemetry.
Then
they
found
that
if
we
can
correlate
with
other
like
outer
process,
we
can
do
that
right
whenever
the
context
fabrication
by
the
in
process,
then
they
can't
propagate
that
across
modules.
That
will
be,
I
think,
one
more
cause
confused.
E
E
E
E
E
Let's
continue
exploring.
The
good
point
is
that
we
already
have
that
implementation.
I
know
one
of
the
developers
has
already
implemented
that
in
his
own
private
branch.
So
whenever
we
plan
to
support
it,
we
can
look
into
we
can
we
can
discuss
with
him.
You
know,
I
think,
he's
hugely
good
he's
eagerly
waiting
to
contribute
his
changes
in
our,
but
it's
a
big
decision.
I
think
probably
it's
a
breaking
change
for.
H
Well,
we
can
provide
like
a
setup
here
which
just
links
to
the
or
the
static
into
our
static
library,
and
then
user
can
go
into
the
according
to
the
star.
Let's
start
the
url,
but
anyway
this
requires
some
some
extra
wrapper
around
above
us
exactly.
H
Okay,
thanks
and
yeah:
let's
keep
discussing
always.
E
Data
model
is
stable,
we
don't
have
a
bandwidth
as
of
now.
H
Question
on
the
proto
update
for
the
the
current
product
file
we
are
using
for
metrics.
Is
that
stable
or
there
are
some
some
updates
which
file
the
current.
E
I
haven't
seen
that
it
may
not
be.
We
may
not
have
so.
I
think
that
that
should
have
got
upgraded
as
part
of
our
upgrade
to
the
protocol
right,
because
so
the
proto
will
bring.
I
mean
if
we
upgrade
our
total
sub
module,
it
will
bring
all
matrix
traces
and
logs,
so
it
should
have
got
upgraded
with
that.
Whenever
we
have
would
have
done
the
upgrade.
H
E
Think
this
is
kind
of
I
mean,
as
so
tom.
I
think
you're
saying
this
would
be
a
blocker
for
us,
because
we
won't
be
able
to
upgrade
our
pro
to
proto
files.
H
E
E
E
H
H
E
We
start
implementing
it
that
time
we
will
have
a
problem
with
yeah.
That's.
H
E
Yeah,
but
we
need
to
yeah.
Definitely
we
need
at
least
a
bare
manual
work
on
this
to
make
it
compliant
with
the
existing
lock
data
model.
So
even
the
log
sdk
is
not
just
the
model
I
think
logs
is
sdk
is
also
stable.
Now.
E
D
We
would
like
to
contribute
as
much
as
possible,
but
current.
Our
commitment
is
for
some
of
the
modules
which
we
are
planning
to
do
lalith
and
also
some
other
project
in
future.
Definitely
bandwidth.
But
after
we
are
done
with
engine
x,
module
part
right,
probably
we
will
be
able
to
pick
up
some
of
the
activity.
E
Yeah
thanks,
I
think,
totally
understandable,
nothing,
yeah,
okay,
let's
discuss
it
next
week,
tom,
I
think,
probably
where
we
are
on
this-
whether
we
really
need
to
do
changes
on
this.
If,
yes,
then,
probably
I
think
I'll
take
it
over
or
maybe
me
or
you
can.
Somebody
can
take
it
over
on
this.
If
really,
we
have
to
implement
this.
E
Yeah
we
do
have
concurrent
http
exporter,
I'm
not
over
time
and
devashi
has
done
lots
of
work
on
this.
There
is
nothing,
probably
I'm
sorry
about
this.
I
haven't
been
tracking
it
for
some
time,
but
do
you
have
any
update?
I
mean
I'll
be
good
enough
to
at
least
merge
some
of
the
changes
in
the
feature
branch.
B
E
B
I
have
gone
through
it,
but
I
would
also
ask
all
of
you
guys
to
also
review
it.
Yeah.
E
Can
you
can
you
just
approve
it
once
you
feel
you're,
it's
okay!
I
think
probably
I'll
also
go
through
this,
but
I
mean,
if
you
feel
it
so
good
to
good
enough.
I
think
just
approve
it
so
that
you
think
sure.
C
I
just
had
one
question:
has
anybody
tried
gcc
11.
E
This
is,
this,
is
compiler
is
coming
with
any
distribution
or
it's
you
just
try
to
upgrade
yeah.
We
want
to
relate
this,
which
one
sorry.