►
From YouTube: 2021-03-10 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
A
A
E
B
E
Yes,
yes,
I
felt,
I
feel
bad,
but
we
we
we
kind
of
never
didn't
got
anywhere
with
that.
Yeah.
D
A
E
E
Sorry,
the
wi-fi
has
really
been
weird,
the
last
two
nights,
so
I
switched
over
to
hot
spot
on
my
phone.
So
hopefully
that's
better.
E
So
sorry,
I
missed
what
you
were
saying
honorable,
I
mean
nikita
about.
G
What
happened,
did
you
release
the
instrumentals
part
or
not?
Yet,
as
we
do.
G
Yeah,
okay,
so
anton,
do
you
need
help
with
this
or
you
can
drive
the
discussion.
B
Sure
I
mean
I
can
just
like
my
intention
here
guys.
You
know
hey
on
iraq
whenever
I
met
I'm
anson
from
atlassian,
so
I
I
worked
at
aws
prior
to
atlassian,
so
alma
mater
yeah.
So
I
guess
the
the
subject
for
the
discussion
which
I'm
interested
in
a
big
and
something
which
added
to
bogdan-
and
some
of
you
guys
before
was
this
introduction
of
the
instrumentor's
support
in
the
instrumentation
package.
B
Basically,
so
currently
like
just
to
give
you
some
context
here,
so
we
have
the
tracer
concept,
which
is
doing
all
the
heavy
lifting
quiz
regards
to
recording
traces,
but
at
some
stage
and
we
at
atlassian
are
really
interested
in
that
stage.
We
want
to
go
beyond
that
and
we
want
to
support
for
metrics.
So
hence
there
was
an
idea
to
introduce
like
a
more
overarching
concept.
B
Call
it
instrumentor
or
you
know,
if
you
have
a
better
suggestion,
call
it
a
better
suggestion
but
basically
have
like
a
an
entry
point
for
recording
metrics
and
traces
and
yeah
start
thinking
like
a
little
broader
here.
B
So
there
was
a
little
bit
of
back
and
forth
on
the
pr
and
we
and
we
a
little
bit
collided
with
trusk
doing
the
same
thing
in
the
same
package
ended
up
with
a
huge
pass
but
anyway,
so
the
idea
was
that
I
basically
went
ahead
and
just
took
a
tracer
as
a
as
a
base
and
then
basically
just
refactor
it
to
rename
it
to
instrumentos,
and
my
initial
thought
was
okay,
so
tracer
is
already
doing
a
lot
of
orchestration
and
a
lot
of
preparation
work.
B
You
know
extracting
things
from
requests
and
you
know
massaging
that,
so
I
would
start
there
and
then
at
some
stage
I
would
add
the
metrics
and
and
the
other
stuff
there.
So
I'll
pause
here.
Just
to
give
you
some,
you
know
space
to
ask
questions
or
say
something.
C
I
believe
we
talked
about
those
instrumental
before
we,
we
thought
about
1.0
release
and
how
and
what
api
should
we
stabilize
and
whatnot,
and
at
that
time
my
opinion
was-
and
it
still
is
that
as
meta
api
metrics
api
is
not
absolutely
ready.
Yet
we
don't
know
what
metric
api
in
opengl
meter
will
look
like.
C
C
Then,
when
metric
api
is,
is
more
or
less
well
visible,
we
can
start
creating
similar
to
tracers,
like
meters
or
what
not,
and
then
we
can
create,
maybe
a
higher
level
api
on
top
of
those
two,
because
I
don't
feel
confident
that
we
can
now
create
the
higher
level
abstractions
on
top
of
tracers
and
metrics.
When
we
don't
have
any
single
meters
yet
and
we
don't,
we
didn't
use
any
any
meters
yet.
So
how
can
we
create
abstraction
or
something
that
that
doesn't
exist
and
wasn't
battled
they
tasted.
B
All
right
before
bogdan
jumps
in
I
just
want
to
say
I
mean
I
genuinely
see
your
point
nikita,
so
I
just
want
to
add
like
one
more
thing
in
a
favor
of
creating
the
abstraction.
So
even
if
we
don't
start
recording,
metrics
right
now,
there's
still
interest,
at
least
for
for
us
atlassian
and
I
believe,
a
community
maybe
as
well
to
kind
of
do
some
groundwork
and
preparation.
B
So,
for
example
like
currently
we
extract
things
from
requests
and
what
not
like
all
this
metadata
and
information
in
a
very
like
precise
and
prescriptive
and
opinionated
way
right.
So
we
like
look
for
certain
things
called
attack
certain
way.
I
believe
we
could
benefit
from
making
it
a
little
more
flexible
and
you
know
creating,
maybe
a
set
of
listeners
or
like
exit
points
for
the
user
code.
B
Where
I
can
do
my
stuff-
and
you
know
if
I
know
how
to
call
this
stock,
which
I
could
provide
like
the
implementation,
where
you
guys
can
you
know,
use
it,
it
would
be
useful
even
for
tracers,
even
if
it
just
abstract
away
from
metrics
completely,
even
for
tracers.
That
will
already,
in
my
opinion,
boost
the
the
usefulness
of
this
package.
That's
the
second
point
I
was
looking
for,
so
I
was
thinking
like
okay,
so
we
can
work
on.
B
You
know,
cleaning
up
the
the
hierarchy
and
introducing
these
exit
points
for
the
custom
code,
if
needed
and
where
needed,
and
then
at
some
stage
we
can
start
edit
metrics.
But
I
will
let
bogdan
comment
on
the
state
of
the
api
as
I'm
not
that
close
to
that.
G
G
C
G
Okay,
so
so
in
in
general,
when
it
comes
to
metrics,
let's
don't
forget
about
api
in
general,
okay,
just
when
it
comes
to
metric,
you
need
to
have
dimensions,
a
key
labels
or
whatever
you
call
them,
which
most
likely
the
same
ones.
You
want
to
have
them
on
traces
or
a
lot
of
them.
You
want
to
have
them
on
traces
on
spans
as
well
as
on
on
these,
and
you
may
want
to
consider
maybe
using
packages
for
this.
We
can
that's
what
we
are
doing,
yeah
yeah.
G
Let
me
let
me
see
so
so
so
there
is
these
attributes,
let's
call
them
attributes,
because
even
metrics
sooner
or
later
will
unify
an
attribute.
Maybe
so
there
are
some
canonical
or
semantic
attributes
that
we
you
need
to
extract
from
from
from
requests
a
response
or
or
from
frameworks,
and
this
with
these
attributes,
operations
that
I'm
seeing
so
far
that
are
possible
to
do
are
add
them
as
baggages,
maybe
record
them
as
spam
attributes
or
use
them
as
metrics
labels
make
sense.
G
Okay,
that's
that's
one
thing
that
we,
I
think
we
should
start
thinking
in
a
way
where,
where
our
instrumenter
will
be
able
to
reuse
that
logic
and
this,
this
api
should
be
able
to
not
duplicate
that
agreed.
G
So
so,
let's
start
from
there.
Okay,
then
then
we
can
take
on
as
an
example
the
the
the
baggage
and
the
the
spent
even
forget
about
metrics,
but
packaging
spans
are
stable
apis
and
we
need
to
give
users
the
capability
for
for
extracting
from
from
or
or
having
the
capability
of,
adding
things
into
the
baggages.
G
C
I
totally
agree
on
the
need
for
extension
points
yes
for
user,
provided
extension
points
to
current
tracer
that
I
totally
agree
upon.
Yes,.
G
But
but
let's
okay
for
for
good
or
for
bad,
let's
not
call
them
tracers
because,
as
I
said,
it's
a
very
big
confusion
with
tracing
we,
we
can
call
them
instrumenter
or
whatever
you
want
to
call
them,
but
it's
very
big
confusion
that
this
is
only
for
tracing,
but
actually
it's
not
only
for
tracing.
We,
for
example.
I
was
just
giving
you
an
example
that
I
want
to
to
manipulate
baggages.
C
G
Okay,
so
so
so
there
is
the
logic
of
extracting
these
attributes.
There
is
this
capability
of
adding
baggages,
which
already
know
we
need.
There
is
a
another
thing
is
when
it
comes
to
metrics.
I
think
the
only
specific
thing
is
that
we
want
to
do
something
at
the
beginning,
most
likely
record
the
plus
one
on
a
metric,
but
let's,
let's
not
do
that,
but
I'm
describing
kind
of
conceptually
what
we
would
like
to
do
like
most
most
likely.
G
We
probably
want
to
have
a
tracking
active
request
metric,
which
will
do
a
plus
one
whenever,
whenever
this
instrumental
starts
in
operation
or
whatever
you
call
it,
and
on
the
end
of
the
operation,
we
will
most
likely
in
certain
scenarios
based
on
user
config
to
probably
record
the
latency
of
this
operation
as
a
metric
and
probably
couple
of
things
from
the
request
response
like
bytes
in
bytes
out
or
things
like
that.
But
let's
not
get
into
details
whatever
metrics.
We
want
to
record.
G
Let's
stay
with
these
things,
so
for
metrics
to
be
able
to
to
to
extend
this
framework
to
support
metrics,
I
think
most
likely.
What
we
need
is
we
need
to
to
have
capability
of
recording
something
when
the
operation
or
whatever
it
is
called,
begins
and
whenever
operation
ends,
and
these
informations
are
also
part
of
the
same
framework
request
framework
response
objects.
G
That's
why
I
don't
think
it's
good
to
rewrite
the
entire
world
and
handle
the
case
of
knowing
how
to
extract
attributes
from
spring
requests
or
from
neti
requests
or
from
okay,
http
request
or
whatever
frameworks
you
are
doing
and
stuff
does
it
make
sense
so
far,
where
I'm
heading
I'm
not
again
right
now
suggesting
you
to
do
that,
but
I
want
to.
I
want
things
to
to
be
thought
this
way.
So,
whenever
metrics
is
ready,
we
have
only
a
very
minimal
work
to
do.
B
A
B
Thought
we
all
agreed
on
the
extension
point
just
to
add
a
small
thing
to
that.
Sometimes
it's
the
only
way
to
know
and
extract
the
things
from
user
request
is
basically
ask
the
user
code
to
do
that,
because
you
guys
simply
don't
know
where
to
look.
I
mean
you
can
know
like
in
some
very
generic
case,
but
in
the
most
useful
scenarios,
it's
only
the
application
logic
which
can
help
you
extracting
these
things.
Yeah.
C
C
C
G
So
so
I
think
I
think
I
think
we
need
to
also
think
about
users
that
are
not
using
the
java
agent,
but
are
consuming
your
instrumentations
yeah,
so
so
so
these
are
the
users
that
that
will
be
able
to
put
some
custom
code
or
custom
hooks
when
they
are
using
your
your
instrumentation,
so
think
about
think
about.
Let's,
let's
get
up
as
an
example:
http
instrumentation
that
you
have
okay,
if
the
http
instrumentation
accepts
open,
telemetry
object,
plus
a
hook
to
do
something.
G
G
H
H
H
H
They
start
and
stop
the
spin
and
define
the
attributes
and
inject
and
extract
and
like
do
everything
instead
of
splitting
those
parts
out,
and
so
I
was
just
trying
to
figure
out
how
to
sort
of
split
things
into
independent
life
cycles.
So
the
instrument
right
this
defined
here,
that's
what
fast
rodents
got
and
I
think
it's
about.
B
B
H
And
then,
in
addition
to
instrument,
try
also
defined
extractor,
because
I
really
want
these
two
things
to
be
separate.
I
wasn't
thinking
about
baggage,
but
basically
the
goal
of
instrumentation
is
figuring
out
what
attributes
are
available?
Let's
start
fill
them
into
this
band
builder
and
then
ones
that
aren't
available.
G
One
thing
one
thing:
I'm
not
sure
if
the
instrumental
will
always
have
request
response
or
you
need
to
to
have
a
multiple
version.
This
is
an
rpc
instrumental
which
has
request
response.
There
may
be,
there
may
be
other
instrumenters
that
don't
have
request
response
pattern.
I'm
not
I'm!
I'm
just
yeah,
I'm
not
saying
that.
That's
that
I
think
maybe
maybe
maybe
an
instrumental
base
and
then
you
may
have
rpc
or
http
or
whatever
you
call
them.
That
has
this
pattern
of
request
response,
but
there
may
be
others
with
only
one
argument:
yeah
yeah.
E
Has
changed
since
your
initial
pr
is
now
we
do
pass
already
all
that
work
is
done
to
return
context
everywhere.
So
it
is
the
context
passing
back
and
forth.
H
A
H
H
C
C
Okay,
so
if,
if
I
as
an
application
developer
using,
I
am
using
I'm
introducing
I'm
installing
some
library
instrumentation
like
these
are
mere
tracing.
Okay,
I
can
provide
some
interfaces
to
to
it
and
they
will
be
wired
up.
Okay.
C
G
By
which
library,
by
by
embedded
into
grpc,
for
example,
if
grpc
pages
the
way
everywhere,
where
we
ask
them
to
put
to
accept
open
telemetry,
we
may
ask
them
to
accept
these
these
extra
arguments.
G
So
so,
if
we
create
an
object,
called
instrumental
settings
that
has
the
the
open
telemetry
has
these
hooks,
it
may
have
some
extra
properties.
We
ask
people
that
writes
an
instrumentation.
You
should
have
as
an
entry
point,
not
only
open
telemetry
but
open
telemetry
settings
or
whatever
we
call
them
doesn't
matter.
What
I'm
trying
to
say
is.
We
should
ex
the
way
how
we
will.
They
should
accept
that
in
if
they
don't
accept
it
sure
we
cannot
do
anything.
E
G
Yeah
yeah:
this
is
kind
of
the
main
api
and
maybe
maybe
we
can
make
a
call
and
put
them
into
an
extension
on
our
ap
movie
to
core.
If
you
want
we
can
discuss,
but
let's
let's
we
can
keep
it
even
here.
If
you
make
it
stable
and
as
a
small
package
that
people
can
depend
on
and
not
have
the
entire
the
entire
world
coming.
C
G
Some
standard
extensions
like,
for
example,
extracting
headers
to
baggage,
and
you
you
ask
users,
give
me
end
var
or
properties
with
the
names
of
of
headers,
that
you
want
me
and
I
will
put
them
into
baggage.
I
we
can
provide
a
bunch
of
set
of
canonical
things,
canonical
extensions
that
we
support
and
and
allow
people
to
configure
that
without
instrumentation.
G
There
may
be
other
things
with
some
spi
or
stuff
that
we
can
do
maybe.
But
I
was
thinking
just
to
minimum
some
standard
things
we
can
give
to
the
user.
B
C
G
Nikita
nikita,
I
think,
that's
a
separate
problem
and
I
think
I
think
we
can
discuss
later
how
java
agent
can
can
use
these.
But.
E
Then
we
did
just
discuss.
Last
week
we
changed
our
decision
on
the
library
instrumentation
will
override.
If
the
java
agent
is
present
and
we
see
that
they
have
grpc
library
instrumentation.
We
will
back
off
of
the
auto
instrumentation
things
like
that.
Yeah.
G
C
I
think
so
because
this
is
part
of
the
instrumentation
api,
correct
yeah.
But
my
my
argument
when
I,
when
I
objected
to
that
idea
last
week,
was
that
we
can
have
our
current
current
racers
good
and
stable
and
release
them
as
stable,
and
then
we
can
add
the
higher
level
api
which
covers
both
tracer
tracing
and
metrics.
But
it
seems
that
you
want
to
just
well,
let's
have
one
and
then
release
table.
G
I
would
go
with
just
one
it's
up
to
you
guys
I
mean
I
I
mean
I'm
just
saying
that
I
think
one
is
better
in
this
scenario,
because
it's
easier
to
extend
in
my
opinion
than
than
adding
a
new
so
think
about.
If
you
add
a
baggager
or
whatever
for
baggage
support,
then
then
people
will
have
to
deal
with
two
three
four
five
objects,
but
the
whole
idea
with
the
instrumentation
was
that
you
have
just
open
telemetry
instrumentation.
C
B
Favor
of
this,
in
my
at
least
experiments,
I
was
figuring
out
that
if
we
introduce
instrumentor
and
then
kind
of
majority
of
complexity
goes
into
the
instrumenter
and
then
tracer
becomes
a
really
thin
object.
So
you
don't
really
need
to
almost
like
you
almost
don't
need
to
have
any
hierarchy
for
tracers.
Then.
H
C
B
All
the
leg
work
this
common
code,
which
bogdan
was
explaining,
which
is
exactly
your
hierarchy
of
base
tracer.
So
all
your
base,
tracer,
is
doing
the
this
leg.
Work
just
needs
to
sit
in
a
different
place
and
be
shared
between
metrics
and
tracers,
and
then
tracer
just
becomes
tracer,
which
I
think
is
the
same,
which
you
see
in
the
androx
pr
modulus.
You
just
pass
tracer
as
an
open,
telemetry,
tracer.
C
A
H
As
one
example
that
I
don't
know
if
it'll
come
across
the
speaking
in
the
vc
but
like
if
we
wanted
to
add
a
metric
for
active
requests,
it's
very
easy
like
we
would
have
a
meter
here.
Active
requests
here,
you
just
increment
and
then
here
you
decrement
no
work
in
any
other
instrumentation.
It's
just
here.
That's
the
whole
point.
G
C
G
B
G
We
can
do
that
so
so
you
have
these,
which
returns
a
list
of
attributes
which
we
may
put
as
baggages
or
whatever
we
want
to
do.
But
I
don't
know
if
onstart
should
directly
mess
with
the
with
the
with
the
tracing
or
or
metrics
or
anything
they
should.
It
should
just
know
how
to
extract
things
for
the
instructors
yeah.
H
C
B
H
G
G
The
other
thing
is
to
remember:
the
extractor
will
be
always
have
a
start
and
end
doesn't
matter
how
you
deal
with
the
life
cycle,
but
it
will
always
happen
that
you
have
a
start
moment
and
an
end
moment,
maybe
not
be
easily
to
follow
or
easily
to
do,
but
from
extracting
perspective
it
will
always
be
like
this.
Maybe.
H
B
H
C
Okay,
sorry
for
playing
they
will
advocate,
but
I
want
to
flash
out
all
the
problems.
E
E
H
This
pr
is
almost
okay
to
merge
in
some
like
as
a
prototype.
The
problem
I
ran
into
is
because
we're
populating
more
attributes,
our
generic,
like
http
server,
test
it's
hard
to
make
that
pass
for
new
and
old
patterns.
I
think
I
haven't
thought
about
it
at
all,
but
that's
the
one
problem
I
ran
into
like
many
more
attributes
so.
H
E
Of
the
h
of
the
base,
the
base
classes
and
then
kept
around
the
two
copies
and
then
eventually
got
rid
of
so.
C
H
D
G
I
would
suggest
that
you
pick
two
or
three
classic
one
or
two
classic
instrumentation
and
one
or
two
exceptions
and
give
it
a
try
to
this
api
before
before
moving
forward
with
full
speed.
I
think
it's
still
important
to
prove
the
api
before
we.
We
because
I
know
you
have
tens
of
instrumentation,
so
it
will
be
good
if
you
start
defining
the
api
as
a
standalone,
new
api
thing
and
then
and
then
start
moving
one
or
two,
and
then
you
can
do
a
big
thing,
maybe
to
move
all
of
them.
H
H
Like
we'd
have
the
like
the
order
I
was
going
to
go
in
for
this
was
maybe
like
arm
area
just
because
I'm
pleased
with
the
next
servlet,
because
that's
very
common
and
very
old
and
then
like
just
go
old
old
old
and
try
to
handle
as
many
cases
and
the
api
will
change
a
bit
as
we
handle
these
cases.
I'm
sure.
C
Can
we
can
we
start
with
like
with
something
similar
to
documentation?
I
mean
we
at
the
end.
We
will
need
to
write
some
some
text
explaining
end
users
how
they
can
use
it.
Can
we
maybe
even
start
with
that,
because,
like
press
release,
driven
development,
pure
faq,.
C
G
Where
you
want
to
see
the
goals
that
you
tried
so
very
clearly
stated
the
goals
that
we
just
discussed.
We
we
had
a
long
discussion
at
the
beginning
for
20
minutes
or
whatever,
where
we
discuss
pros
and
cons
and
why
we
believe
this
is
better
now.
I
think
this
can
be
put
it
in
text.
Sure.
Are
these
gonna
be
used
for
documentation,
probably
people
interested
into
understanding?
How
did
we
come?
How
did
we
get
here?
We'll
we'll
read
this
so
yeah?
G
I
would
say
why
not
have
some
at
least
iterating
the
the
goals
and
non-goals
of
these
and
then
make
sure
that
the
api
achieves
the
goals
and
the
known
goals.
G
Makes
sense
on
rock
anton
yeah.
B
A
B
G
Okay
thanks,
so
I
think
we
we
make
good
progress,
at
least
in
brainstorming
these.
I
don't
know
how
you
feel
trust
nikita
anarag.
H
To
get
rid
of
the
tracers
are,
am
I
the
only
one
that
doesn't
like
me?
I
thought
they're,
obviously
pretty
horrible,
but
maybe
not.
H
E
Yeah
and
all
the
work
that
matteos
has
been
doing,
at
least
it's
been
like
normalizing
everything
there
so
that
I
think
we
have
a
decent
chance
of
massaging
it
into
something
better
across.
You
know:
100
different.
G
Modules,
I
would
be
very
interested
to
to
look
at
this
if
you
ping
me
on
slack
when
you
have
this
ready
on
the
instrumentation.
G
I
I'm
not
following
the
instrumentation
repo,
because
I'm
getting
thousands
of
emails,
no
matter
what's
from
open
telemetry,
but
if
you
can
ping
me
whenever,
whenever
you
have
this
ready,
I
would
like
to
learn
about
this,
because
I
think
it's
as
as
us
producing
these
libraries,
we
have
to
understand
better
how
users
will
consume
and
give
them
more
user-friendly
things.
So
it
would
be
good
for
me
to
learn
about.
G
H
Muscle
so
I
ran
into
again
muzzle
just
being
a
pain
in
the
aws
instrumentation,
because
that
thing
has
plug-ins
and
I,
like
again,
our
instrumentation
doesn't
apply
because
we
ended
up
using
a
class
normal
plug-in
that
isn't
necessarily
on
the
class
path.
So
this
is
seemed
to
be
a
recurring
problem.
Now
I
just
found
the
issue
a
couple
hours
ago:
it's
on
the
aws
spk
v2,
where,
if
you
only
have
s3
on
your
class
path,
you
don't
have
the
json
serializer
on
your
class
path,
which
we
thought
we
were
going
to
use.
B
H
E
Not
all
of
the
yeah
are
you
able
to
split,
I
mean
I
think
we
talked
about
this
last
week
of
splitting
it
out
into
multiple
mod
instrumentation
modules.
Since
muzzle
is
I
don't
know
how
to
do
that.
H
H
So
this
I
mean,
I
don't
think,
there's
many
libraries
like
this.
It's
going
to
be
the
cloud
sdks,
I'm
sure
azure
sdk
must
have
something
along
these
lines,
also
g
cloud
or
whatever
grpc,
it's
just
a
framework.
So
it's
not
gonna
have
this
sort
of
problem,
but
these
plug-in
type
of
things
that
we
instrument.
E
H
E
A
common
piece
that
they
depend
on,
but
there's
it's
not
presented
to
users
as
like:
a
unified,
a
single
artifact.
H
Have
you
instrumented
yeah,
you
do
it
right
in
your
region.
H
E
E
A
H
E
Might
in
the
yeah
in
the
azure
sdk
case
they
set
all
the
attributes.
The
tracing
abstraction
presents
like
attributes
so
that
the
sdks
themselves
decide
what
attributes
to
attach.
H
E
H
E
Well,
it
seems
like
it's
doing
the
at
least
what
I
would
expect
in
the
in
the
aws
sdk
case,
where
it
is
backing
off
the
whole
instrumentation,
because
it
knows
that
in
the
instrument.
H
E
H
H
E
E
Yeah,
because
if
you
needed
extra
things
on
to
make
the
muzzle
task
pass,
you
should
have
to
add
the
extra
dependencies
flag
yeah,
but
without
that
yeah
I
would
have
you're
right.
I
I
it
should
it
should
fail,
because
then
then
it
would
be
explicit.
You
would
have
seen.
Oh,
I
need
to
add
the
json
here
or.
H
H
B
H
E
Yeah
yeah
yeah.
Definitely
I
mean
open
issues
for
both
of
those,
and
you
know
we
can
kind
of
collaborate
on
on
requirements
and
you
know
have
a
feeling
that
matthias
will
eventually
pick
it
up
be
interested
by
it.
If
we
can,
you
know
map
out
something
that
looks
interesting
and
useful.
H
H
H
E
I
see
you've,
I
thought
I
fell
behind
on
reviews
yesterday
or
today
or
today.
I
guess
god,
each
every
each
day
is
like.
Yes,
it's
only
been
a
day
since
I
fell
behind,
but.
H
E
It's
all
good
yeah,
but
I
saw
you
you're
continuing
on
the
the
library
breakout.
E
H
Mind-Boggling
yeah,
by
the
way
I
could
share
this
random.
Like
I
tried
to
upgrade
our
lettuce
to
lettuce
6.0,
you
know
I
found
lettuce
6.0
to
be
sort
of
broken
like
it.
There's
no
way
to
get
the
remote
address
is
just
a
bug
and
they
don't
have
any
unit
desperate.
So
I
sent
a
pr
to
let
us
decide
if
it's
that
that's
the
state
of
meta
6.0,
I
guess
it
sort
of
works,
but
it's
missing.
H
E
H
H
E
Yeah,
I
noticed
that
you've
also
been
doing
a
bunch
of
library
community
outreach.
H
E
Are
you
getting
requests
from
from
aws
customers,
yeah.
H
H
H
E
H
E
Oh
for
the
the
is
that
the
couch
face:
vlogs
yeah,
yeah,
yeah,
where's
john
john's
missing
tonight.
E
H
E
H
E
That
that
osgi
was
a
was
one
of
our
customers
found
ran
into
that
was
fun.
H
H
H
H
C
E
C
H
Like
I
even
suggest
this
to
the
vertex
guy
who's
at
the
pr's,
like
it
doesn't
have
the
initial
pr
annoying
but
like
we'll,
probably
want
a
context
bridge
from
hotel
into
the
vertex
context.
Theoretically,
that's
supposed
to
solve
all
problems
if
the
async
framework
handles
the
context
propagation.
So
that's
what
I'm
optimistic
about
at
least
for
vertex
for-
and
I
don't
know
if
it
applies
to
previous
versions,
but
you
can
see.