►
From YouTube: Real-Time Working Group 2020-05-06
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
I'm
not
sure,
like
I,
think
I
can
get
this
into
review
today,
hopefully,
or
at
least
market
for
review
I,
don't
see
anything
else,
I
think
it's
a
good
first
pass.
There
are
a
few
things
that
I
think
we
should
probably
follow
up
with.
One
of
them
is
the
customizability
over
like
currently,
we've
set
some
settings
so,
for
example,
the
number
of
threads
used
by
action-
cable,
it's
just
set
before
I-
think
that
should
probably
be
customizable
but
I.
Think
it's
fine
for
a
first
iteration.
A
You
can
test
it
by
checking
at
the
branch
and
running
docker
compose
up
once
you've
installed
darker
and
darker
compose
that
should
be
enough
and
I'd
also
encourage
you
to
run
to
prin
docker
images
every
once
in
a
while
or
our
IP,
your
hard
drive,
which
is
exactly
what
happened
to
mine,
so
cool.
So
hopefully
that
goes
through
review
and
yeah.
Anyone
can
run
it
and
that
basically
unblocks
us
to
hopefully
help
with
the
kubernetes
work
in
some
way
as
well
and
I.
B
Mean
I
think
I
mentioned
this
already
once,
but
it's
also
very
easy
to
use
this
branch
with
the
helm
charts,
but
you
don't
need
this
to
be
merged
to
like
work
on
the
helm.
Charts
here
that
you
can
just
cause
like
the
pipeline
actually
builds
these
images,
so
you
can
just
fetch
those
when
you're
working
on
the.
How
much
and
I'll
just
find
the
docks,
then
what.
B
A
So
do
you
know
about
the
the
nightly
builds
then,
because
of
the
minute
I'm,
not
sure
it's
a
bit
of
a
chicken-egg
problem.
We
have
a
new
container
called
the
action
cable
which
needs
to
be
built
locally
to
start
with.
I'm
soda
can
be
used
by
docker
compose,
but
then
we
need
to
switch
it
once
it
starts
being
built
nightly.
We
need
to
switch
it
to
use
the
nightly,
builds.
A
C
B
B
A
A
C
Here,
let's
see
so
yeah,
okay,
the
first
pass,
the
front
end
for
assignees
has
been
merged
in
he
linked
to
the
M.
Are
there
and
Heinrich
enough
yep
and
update
later
on
the
back
end,
but
it
looks
like
that
has
also
been
merged
in
and
both
can
be
tested
now,
with
the
both
behind
a
feature:
fight
and
I'll
point
to
the
name
of
the
future
flag.
I
like
that,
the
agenda.
A
Thanks
so,
like
I
have
one
question
on
this,
and
it
was
kind
of
related
to
Mathias
comment
below
this.
If
you
read
this
summary
that
he
wrote
at
the
minute,
it
seems
like
they're
quite
tightly
coupled
so
if
there's
a
problem
with
action
cable
and
we
try,
we
can't,
for
whatever
reason,
broadcasts
the
change
like.
So,
if
I
assign
myself
to
an
issue-
and
we
can't
broadcast
us,
the
whole
assignment
will
fail,
which
means
that
I
don't
think,
there's
a
way
to
switch
this
off
at
the
minute
right.
I,
don't.
D
A
If
the
future
flights
off
it
won't
broadcast
but
say
there
was
a
problem
with
action,
cable
or
with
broadcasting.
Right
so
say
the
feature
flags
on,
but
there's
a
problem.
The
exception
there
will
cause
the
whole
assignment
of
these
are
to
fill
rather
than
falling
back
gracefully
to
the
old
behavior
I.
D
Haven't
actually
checked
but
I'm
not
sure
if
we
do
a
transaction
there
and
rollback
or
something
like
that,
but
I
added
it
sa
after
update
hook,
only
issue
issue
update
service,
so
I'm
not
sure
if
it's
part
of
the
transaction
and
rollback
thing
or
if
it's
just
you
know,
give
us
a
500.
But
then
the
assignee
assignment,
actually,
you
know,
happens
at
the
DP.
A
Yeah,
that's
a
good
point.
I'm
not
sure
I
did
I
noticed
that
originally
because
I
forgot
like
it
was
me
like
I,
forgot
to
create
a
cable,
the
animal
file
and
or
hacking
after
that.
Yet,
and
so,
when
I
tried
to
assign
a
user,
it
failed,
but
you're
right,
I
didn't
actually
refresh
the
page,
so
I
have
no
way
of
knowing
if
the
actual
assignment
works
or
if
it
was
a
transaction
and
the
whole
thing
was
rolled
back
as
a
signer
and
okay.
E
F
E
E
E
E
Down
and
it's
all
in
the
thicket,
if
you
look
at
the
numbers,
what
will
be
much
harder
going
forward
is
to
really
so
there
will
be
some
trade-off
if
we
want
to
like
read
more
memory,
benefits
between
having
a
single
configuration
that
we
would
run
for
everyone
or
having
multiple
options
right
so
that
you
can
really
say.
For
instance,
we
want
to
run
basically
the
web
server
and
action
cable
server.
E
If
we
spawn
them
from
the
same
parent
process,
it
can
be
memory
savings
that
way,
because
there's
a
larger
amount
of
memory
they
can
share,
but
that
would
require
that
will
require
more
work.
We
don't
have
that
set
up
currently,
but
there
was
I
think
a
pretty
promising
idea,
because
there
could
be
a
couple
hundred
megabytes
we
might
be
able
to
save,
but
it
would
be
something
that
you
really
need
to
explicitly
turn
on
or
off,
because
I
don't
think
this
is
something
I
do
on
comm.
E
B
B
E
E
B
E
B
E
E
So
what
is
unclear
definitely
to
me
and
I
think
other
developers
as
well
is
so
what
what
it's
like?
To
what
extent?
Let's
assume
we
would
be
able
to
break
down
gitlab
the
app
into
smaller
chunks
that
are
maybe
more
organized
around
features
right,
because
we
know
like
the
actual
cable
functionality,
it.
E
Me
require
access
to
a
certain
portion
of
the
whole
suite
of
functionality
that
we
offer
so
just
in
terms
of
the
code
that's
been
written
and
all
the
extra
data
that's
being
used
around
the
particular
features
we
use.
We
don't
actually
know
how
much
that
would
be.
So,
even
if
we
were
now
today
being
able
to
like
load
only
modules
x,
y&z
assuming
we
had
those
I'd
say
the
issues
Sybok
or
whatever.
We
don't
actually
know
how
much
memory
that
would
require
that's
something
we
haven't
looked
into
yet.
B
E
E
Is
really
this
is
like,
like
the
big
architecture
discussion,
to
have
right
to
what
extent
to
be
one
a
shrink
on
earth?
This
is
not
action,
cable,
specific,
because
that
comes
with
so
many
strings
attached
right.
If
you
want
to
install
a
clear
like
context,
boundaries,
and
then
you
need
to
have
a
well-defined
API
between
about
your
future
verticals,
then
we'll
introduce
friction
in
other
locations
right.
B
E
D
E
B
F
B
And
on
and
on
the
docker
point
as
well
like
I,
don't
think
and
I.
This
is
what
you've
got
in
your
mouth
as
well.
John,
right,
like
the
docker
model,
would
never
be
start
a
web
server
and
the
WebSocket
server
in
the
same
container.
You
would
always
be
starting
them
in
separate
containers
anyway.
So
yeah.
A
Yeah
I
think
as
well
like
on
on
the
sort
of
broader
point
like
we.
We
should
hopefully
like
save
some
resources
from
not
needing
to
do
long
pulling
anymore
for
a
lot
of
things.
Unfortunately,
that
doesn't
include
the
feature
that
we're
releasing
first
as
we
doing
any
polling
on
assignees,
but
when
it
comes
to
things
like
notes
or
even
the
fact
that
we
pulled
for
real-time
changes
regularly
on
the
pair
I,
don't
know,
but
it
seems
like
pretty
often.
B
That
polling
is
pretty
cheap,
but
it's
still
not
not
as
cheap,
hopefully
as
a
WebSocket
connection,
especially
as
that
connection
be
shared,
but
hopefully
I
think.
The
idea
here
is
right
but
like
this
would
be
pretty
underutilized
initially,
but
in
a
way
that
we
could
like
scale
it
out
fairly
easily
in
future.
Right,
like
the
whole
point
of
this,
is
to
get
some
kind
of
WebSocket
thing
out
there.
A
E
Was
also
the
open
question
if
we
forget
about
like
memory
consumption
for
a
second
like
if
you
do
roll
it
out,
it's
like
if
we
move
this
out
to
companies
like
we
would
have
a
bunch
of
pods
running
that
I
just
specifically
serve
WebSocket
connections
right.
So
the
question
was
then:
well,
you
know
how
would
we
support
the
traffic
on
the
users
being
connected?
You
know
listening
for
updates
for
particular
issue.
How.
E
E
E
E
Or
like
on
a
smaller
scale,
roll
out
in
production
and
go
from
there,
rather
than
trying
to
like
estimate
upfront
how
much
that
would
mean
in
terms
of
extra
unknowns.
The
point
they
I
talked
to
Nate
about
this
is
what
because
he
was
still
around
until
the
thirties
I
think,
and
he
also
said
so
so.
Basically,
the
restricting
factor
here
is
the
number,
because
these
are
long-running
connection.
E
It's
really
like
how
many
of
these
uses
we
will
have
to
hold
connections
open
to
you
know
as
they
keep
as
they
remain
online
friends
to
the
issues
page
if
they
have
a
browser.
King
browser
browser,
tab,
open
and
yeah.
It's
like
really
like
hard
to
estimate
this
I,
don't
know
if
we
even
have
numbers
around,
like
maybe
from
usage
things,
something
like
how
how
many
like
what
is
the
like
time
uses
spent
on
the
issues,
patience
right.
That
might
be
something
that
might
be
interesting
to
look
at,
but
it
will
be
all
like.
A
E
It
be
interesting
to
look
at
I
mean
we
should
be
able
to
figure
out
how
many,
how
many
updates,
how
come
you
changed,
requests
there
are
on
average
for
for
an
issue
right.
You
know,
basically,
at
what
frequency
would
we
send
out
these
updates
like
a
sign
each
Ange
and
in
terms
of
events,
if
we
then
had
an
idea
of
on
average
how
many
users
might
be
listening
to
this,
and
this
we
could,
you
know,
arrive
at
some
kind
of
ballpark
around
how
many
connections
would
have
to
maintain.
A
D
Yeah
I
guess
we
could
have
a
rough
number
from
counting
posts
to
the
you
know.
A
big
issue
end
point.
Actually
the
broadcast
we're
doing
right
now
is
for
any
issue
update,
would
issue
the
broadcast
to
make
it
simpler,
because
we're
planning
to
do
this
anyway
for
the
whole
issue.
So
even
if
you
update
another
part
of
an
issue,
it
would
still
broadcast
this
same
event
that
an
issue
was
updated
so
yeah
we
have
more
actionable
events.
Our
messages
broadcasted
then
necessary
right
now
for
this
initial
feature,
but
yeah.
A
D
Yeah
I
mean
we
listen,
it
listen
on
it,
for
you
know
any
for
that
event,
and
then
we
fest
assignees,
even
if
it
didn't
change.
But
what
this
means
is
that
when
we
enable
this
feature
for
other
for
other
parts
of
the
sidebar
or
for
the
title
and
description,
we
don't
actually
add
any
overhead
anymore
or
something
it's
the
same.
You
know.
A
Cool
yeah,
the
last
item-
I,
don't
know
what
else
to
say
on
this
is
just
that
looks
like
the
delivery
team
have
scheduled
the
real-time
work
on
kubernetes
for
the
next
thing,
they're
going
to
work
on.
So
that's
great.
That's
all
the
information
I
have
on
it.
They're
still
working
on
a
psychic
and
production
I
think
so
it
may
be
a
while
yeah
but
we'll
hopefully
have
the
darker
stuff
by
then
yeah.
B
A
Cool
we're
nearly
a
time
anyway
and
I
just
want
to
check
I
know
it's
kind
of
a
kind
of
selection
bias,
but
is
this
meeting
time?
Does
this
actually
work
for
anyone?
Is
it
for
everyone?
It
seems
like
we're
moving
into
a
stage
where
a
lot
more
of
the
backend
stuff
is
done,
and
we
should
try
to
cater
for
slightly
different
audience.
So
I,
don't
know
the
people
like
this
time
or
you
want
to
change
it
maybe
later
earlier.