►
From YouTube: Real-Time Working Group 2020-07-29
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
Okay,
what
date
is
it
29th
of
july
29th
of
july
real-time
working
group?
We,
it
was
a
weekly
meeting,
it's
more
like
a
monthly
meeting.
Okay,
so
we
thought
we'd
start
with
a
demo.
So
heiner
do
you
want
to
give
it
a
go.
B
B
B
On
this
issue,
yeah,
you
could
like
so
one
thing
that
used
to
not
work
was
when
you
assigned
an
issue
to
someone
using
quick
actions.
It
wouldn't
show
up
here
on
the
sidebar,
because
we
don't
do
some
special
javascript
to
do
it
and
we
don't
update
these
in
real
time.
So
now,
if
you
do
this,
you
should
see
it
update
instantly
and
the
same
thing
happens
if
we
like
open
a
new
tab
here,.
C
Love
it
it's
great,
it's
a
fantastic
feature,
especially
since,
like
sometimes
you
are
still
editing
the
mr
description
and
you
use
the
label
command
or
something,
but
then
danger
kicks
in
and
auto
assigns
labels.
So
whatever
you
will
do,
you
will
then
undo
the
work
danger
did
like,
while
you
were
updating
the
mr
description
or
otherwise
updating
the
issue
or
mr.
So
this
is
really
great.
B
Yeah,
it
helps
with
these
like
multi-value
fields
on
the
sidebar,
because
you
kind
of
override,
like
some
others,
values
right,
because
we
send
like
the
complete
list
of
new
values,
so
that
works
for
assignees,
which
are
like
multiple
assignees
and
labels.
A
A
Yeah
no
worries
so
yeah.
I
had
a
couple
of
questions
heinrich
we
mentioned
before
about
the
possibility
of
like
in
order
to
consider
this
like
shipped
as
a
feature.
We
normally
have
to
have
the
feature
flag
defaulted
to
on
or
removed
entirely.
A
So
I
mentioned
in
a
couple
of
meetings
ago
about
the
possibility
of
having,
instead
of
a
feature
flag,
having
the
whether
action,
cable
is
configured,
be
the
condition
upon
which
the
feature
is
shown
or
not.
What
do
you
think
of
that?
Does
that
sound
reasonable,
or
is
that
a
really
bad
idea.
B
Yeah-
I
was
thinking
about
this
and
then
we
wanted
to
keep
the
feature
flag
right,
because
you
know
when
we
deployed
to
gitlab.com
like
we
wanna,
you
know,
stagger,
maybe
and
just
send,
updates
or
you
know
just
enable
connections
without
sending
the
updates-
and
you
know
that
sort
of
thing.
So
I
was
thinking.
Maybe
we
could
do.
We
could
make
the
condition
something
like
action,
cable,
in-app
or
feature
that
enabled
something
right.
B
So
if
it's
enabled
in-app
meanings
of
managed
instances
and
they
enabled
it
on
omnibus,
then
the
feature
would
be
enabled,
regardless
of
the
feature
flag,
but
for
com
where
we
want
to
do
standalone
yeah,
it
depends
on
the
feature
flag.
I
think
you
know
that's
like
a
compromise,
although
I
don't
know
we
do.
We
need
to
document
on
omnibus,
like
if
you
enable
in-app.
It
enables
this
feature.
B
A
B
Yeah,
I
guess
we
could
add
it
because
definitely
we
have.
We
have
to
add,
like
a
feature
dock
right
about
like
side
sidebar,
it's
real
time
or
something,
and
then
we
could
just
add
a
small
note
there
that
this
feature
is
enabled
by
default
when
action,
cable
in
app
is
enabled
or
something
like
that
right.
A
B
Yeah,
okay,
so
yeah,
so
I
could
make
the
feature
check
some
conditional
like
get
that
in
app
or
feature
that
enabled
so
it
will
be
enabled
by
default
for
in-app
users
anyway,
in
omnibus
in-app
isn't
like
enabled
by
default.
So
this
shouldn't
like
immediately
break
installs
or
some
or
you
know
or
anything
they
should
still
like
explicitly
enable
it.
So.
A
Just
while
we're
on
that,
actually,
what
what's?
What
was
the
process
to
get
this
working
on
on
dev.getlab.org,
specifically,
like
did?
B
Cookbooks,
basically,
two
mrs,
were
needed
yeah
if
at
first
I
didn't
know
so.
I
had
to
like
ping
input
folks
and
like
yeah.
A
B
A
Okay,
cool-
I
was
just
curious
and
then
so
the
the
other
point
I
had
here
was
about.
We
mentioned
in
the
last
meeting
about
getting
qa
involved,
and
I
know
gabe
mentioned
that
he
would
talk
to
kia.
I
don't
know
if
he's,
if
he's
done
that
but
like
this
is
the
point
probably
at
which,
like
the
latest
point
at
which
we
should
like
inform
them
of
what
we're
doing
our
plan
to
release
this.
A
So
this
that
should
probably
be
done
before
we
enable
the
feature
in
in
the
way
we
just
mentioned
like
conditionally,
on
the
configuration,
because
that's
going
to
switch
the
feature
on
for
everyone,
so
should
probably
get
docs
involved
as
well
and
to
help
write
the
documentation
for
customers.
So
I
guess
just
an
fyi,
but
I
don't
know:
do
you
know
if,
like
any
qa,
work
has
been
done
on
this
so
far?.
B
I
don't
think
there
is
any.
You
know,
qa
work,
that's
already
been
done
because
we
haven't
really
like
talking
to
them
or
like
mentioned
to
them
or
something
but
yeah,
I'm
not
sure
what
we
do
have
like
feature
specs
for
it.
I
guess
we
want
some
end-to-end
tests,
maybe.
A
Yeah,
I
can't
think
of
how
this
would
affect
any
existing
end-to-end
tests
unless
we're
doing
some
tests
around
quick
actions.
For
example,
I
don't
know
how
it
would
break
anything.
Any
existing
yeah.
C
C
Okay,
got
it
yeah.
Okay,
I
had
another
question
about
so
my
understanding
of
because
we
talked
a
little
bit
about
how
in
which
order
we
should.
You
know,
enable
this
to
make
it
available
to
to
users.
So
I
mean
usually
the
way
we
roll
out
features.
C
We
don't
we
don't
really
communicate
widely
that
this
is
a
thing
and
until
the
feature
flag
has
already
been
lifted,
basically
right,
so
that
we're
really
sure
you
know
it's
there,
it's
working
for
everyone,
so
I'm
wondering,
but
we're
not
not
at
this
stage
yet
right.
So
I'm
wondering
like
to
what
extent
we
should
even
like
start
advertising
this
and
also-
and
maybe
that's
like
a
maybe
that
needs
to
be
discussed
separately,
but
I'm
wondering
for
ford.com,
so
we've
only
deployed
it
to
to
dev.
A
C
A
I
don't
I
don't
know
like
the
the
purpose
of
shipping,
something
to
you
know.
Sorry,
it's
shipping
something
to
small
cluster
and
single
instance.
Customers
was
just
to
get
something
out
the
door
demo
able
and
provide
sort
of
some
value
to
someone
whether
or
not
we
want
to
actually
make
a
big
deal
out
of
it
until
it's
available
in
other
environments.
I
don't
know
I
actually
would
probably
defer
to
gabe
on
that
one
and
see
what
he
wants
to
do
about
it.
Yeah.
It's
a
good
question.
B
B
Don't
want
it
on
release
post,
maybe
because
it's
not
you
know,
like
usually
we
add,
to
release
post
when
it's
like
default,
enabled
or
like
we
tested
in
some
way
already
right,
so
probably
not
release
post,
but
also
the
problem
with
not
advertising
it
anywhere
or
saying
anything
about
it.
It's
like
it's
no
use
right,
nobody
could
use
it
and
nobody
could
give
feedback
and
yeah.
A
I
think
as
well,
I'm
not
sure
the
exact
statistic,
but
I
think
it's
somewhere
around
20
to
30
percent
of
self
self-hosting
customers
report,
telemetry
data
or
report
usage
ping.
So
it's
not!
You
know
it's
not
we're
not
going
to
collect
a
huge
amount
of
data
from
from
this,
like
so
yeah
there
was
also
something
came
up
in
a
retrospective
on
the
planned
team
about
possibly
using
secondary
items
in
the
release
posts
to
announce
features
like
this
that
are
shipped
into.
A
I
guess
in
this
case
it
would
be
a
cohort
of
customers
rather
than
the
entire
customer
base,
but
yeah
I'll
ask
gabe
to
come
in
on
that
async,
because
that's
really,
I
guess
something
he
would
want
to
have
an
input
on.
But
it's
a
good
question.
C
And
just
to
clarify
so
so,
assuming
like,
we
would
be
happy
with
how
it's
working
currently
and
we
would
be
looking
at
communicating
it
to
customers.
Do
we
have
a
feeling
already
for
like
what
what
the
next
steps
are
then,
like
would
be
like
how
far
away
would
we
be
from
from
dot
com
supporters
as
well?
Is
that
now
like?
C
Because
I
do
remember-
we
decided
okay,
let's
focus
on
self-managed
first
and
it
makes
makes
perfect
sense,
but
I'm
just
wondering
like
how
is
it
a
totally
different
initiative,
or
will
that
be
just
definitely
the
next?
The
next
step
here.
A
Yeah,
so
I
have
a
short
update
and
agenda
just
on
what
I
can
see
for
what
the
delivery
team
are
working
on.
It
seems
like
the
web.
Sockets
work
has
been
moved
into
in
progress
and
they're
actually
working
on
it,
which
is
awesome,
they're
going
to
focus
on
what
is
it
the
online
terminal?
That's
used
in
ci
pipelines
to
debug
jobs,
and
things
like
that
that
actually
all
is
already
set
up
to
use
web
sockets
and
they
already
write
that
traffic
through
hi
proxy
in
a
particular
way.
A
So
they're
going
to
start
by
supporting
that
webstop
socket
traffic
and
then
I
believe
the
next
thing
is
action,
cable.
So
if
that's
in
that's
more
or
less
actually
exactly
to
the
estimate
that
they
gave
us.
So
we
can
like
sort
of
assume
that
things
will
go
to
plan
there,
but
expect
like
in
the
couple
in
a
couple
of
milestones,
hopefully
that
workforce.com
will
really
start
to
ramp
up
but
you're
right
that
it
is
kind
of
unless
we
were
to.
I
suppose,
find
that
this
has
a
seriously
low
impact
on
on.
A
C
C
Of
course,
I
don't
know
if
you've
looked
at
anything
already
and
I'm
not
even
sure
how
the
how
like
how
sensible
the
dev
docket
lab
data
is
to
look
at,
because
we
can't
really
compare
that
to
too
much
else.
I
suppose,
because
it's
a
very
constrained
environment
right,
but
I'm
so
curious
just
to
see
in
general
like
if
we
already
have
a
feeling
for
like
where
we
landed
on
like
things
like
resource
usage.
Is
that
anywhere
in
the
ballpark
of
what
we
had
anticipated?
C
B
Yeah
I
haven't
looked
into
I'm
sure,
I'm
pretty
sure
we
have
like
grafana
chart
or
something
about
the
resource
usage
of
dev
right,
and
I
think
the
current
expectation
for
us
is
like
there
should
be
very
little
to
no
change
right
with
the
in-app
mode
in
terms
of
memory
and
in
terms
of
cpu,
but
still
it's
a
very
low
traffic
instance.
So,
probably
you
know
can't
really
conclude
anything
there.
C
Yeah-
and
I
actually
know
that
you
mentioned
it-
I
don't
do
do
we
do
do.
We
have
dashboards
for
dev
and
ops
and
all
these
secondary.
I
don't
think
we
do.
I
think
we
have
for
staging
and
fraud,
but
I
don't
think
we
actually
have
any
dashboards
either
so
yeah.
I
I'm
not
even
sure,
like
what
we
typically
use
depth
for
because
we
don't
use
it
for
things
like
performance
tests
right.
I
think
we
use
ephemeral
environments
for
performance
tests.
B
C
C
A
I
wonder
as
well
about
you
know:
we
won't
get
this
data
from
from
the
dev
environment,
but
I
do
kind
of
have
the
sneaking
suspicion
that
we'll
see
fewer
page
requests
like
full
page
requests.
That's
like
the
more
features
we
ship
on
the
sidebar,
the
fewer
times
you
have
to
refresh
the
page
to
see
who's
assigned
to
see
what
labels
are
attached
to
see
when
the
due
date
is
you
can't
it's
not
something
that's
going
to
be
easily
quantifiable,
but
you
know.
B
C
A
good
point,
I
also
wonder:
do
we
what
kind
of
metrics
do
we
have
for
self-managed,
because
one
of
the
bigger,
like
epics
I've
been
working
on
for
the
past
two
months?
C
Actually
we're
about
to
we've
shipped
a
bunch
of
stuff
and
we're
about
to
kind
of
conclude
we're
like
in
the
last
you
know
on
the
the
last
mile
now,
but
so
we
started
to
track
topology
data
for
self-managed
into
into
sci-sens
via
usage
thing,
so
that
we
get
a
better
idea
of
like
how
customers
deploy
gitlab
like
so
currently
it
only
works
for
a
single
node,
but
we
are
looking
right
now
into
expanding
it
into
multi-node
as
well,
but
it
yeah.
C
C
How
how
does
their
no
hardware
look
like
you
know,
you
know
like
how
many
cpus,
how
much
memory
do
they
have,
and
we
also
want
to
use
this
data
to
map
the
spectrum
reference
architectures
to
see
how
closely
our
customers
follow
our
recommendations,
but
yeah
long
story
short.
I'm
now
I'm
thinking
if
this
could
use
that
to
somehow
also
get
a
bit
more
insight
into
action,
cable
related
stuff.
C
It
might
be
tricky
just
because
it
is
embedded
because
we
kind
of
currently
only
track
on
a
service
level,
so
it
would
all
kind
of
disappear
behind
what
we
call
web
right,
which
is
just
the
rails,
app
basically
but
yeah.
But
I
can
think
about
this.
A
little
bit
more,
it
might
be,
might
be
good
because
we
can.
We
can
you
know,
because
we
can
performance
tests
here
all
day
long,
but
at
the
end
of
the
day,
all
that
counts
is
like
how
it
will
perform
for
the
customer
right.
C
So
that's
that's
exactly
why
we're
doing
this
to
get
a
bit
more
insight
into
that.
B
B
C
That
definitely
sounds
like
a
very
good
idea.
We
should
probably
do
that
yeah,
because
that
will
give
us
an
idea,
because
what
we
could
then
do
is
we
could
write
an
etl
that
kind
of
breaks
down
yeah
what
we
call
the
web
deployment
the
web
service
by
has
action,
cable,
enabled
and
does
not
have
action,
cable,
disabled
enabled
and
then
we
could
see.
Does
it
does
that
have
any.
A
C
On
like
things
like
service
memory
used,
we
don't
have
many
metrics,
like
it's
still
a
very
sparse
model
right
now,
so
we
really
only
have
memory,
consumption
and
like
as
I
speak,
I'm
working
on
getting
cpu
and
memory
utilization
as
well,
which.
C
B
C
I
think
so
yeah.
I
would
think
so
because
that
data
will
enter
the
data
warehouse
right.
I
have
no
idea
what
our
like
data
retention
policies
are.
I
don't
know
if
that
data
will
be
wrong
forever
or
if
they
have
to
delete
it
after
zones
many
weeks,
so
that
I
I
can't
speak
to
that,
but
generally,
I
would
think
that
we
yes
keep
keep
some
some
some
degree
of
history
should
be,
should
definitely
be
there.
A
The
question
about
enabling
in-app
mode
for
cloud
native
good
lab
and
I'm
not
I'm
not
sure,
because
I
I
don't
have
the
information
I
need.
I
don't
know
where
client
native
get
lab
is
actually
deployed.
I
know
it's
used
in
ci
cd
pipelines,
but
apart
from
that,
do
you
know
where
this
project
is
used
like?
Is
it.
B
B
A
B
Also
yeah,
my
question
was
I'm
not
too
familiar
with
docker
compose
and
like
how
it
works,
but,
like
I
know,
we
added
an
action,
cable
container
to
docker
compose
right
and
the
thing
with
in-app
is
like.
We
don't
want
to
start
that
action,
cable
service,
anymore
right
if
in-app
mode
is
enabled,
so
I'm
not
sure
how
to
make
that
like
conditional
based
on
a
config
somewhere
or
like
I
don't
know.
C
A
Yeah,
I
think
it
would
be
to
do
with
the
like
how
how
the
containers
are
actually
deployed
like
so
you
would
pass
the
environment
variable
into
the
container
or
like
sites
of
kubernetes
pods.
You
can
have
some
configuration.
There
switch
it
on
in
one
container,
like
the
web
service
container
and
simply
not
deploy
the
action.
Cable
container.
C
C
B
C
I
I'm
not
sure
I
don't
want
to
make
assumptions,
because
I
have
not
worked
with
the
cng
stuff.
I'm
just.
C
So,
but
I'm
just
like
thinking
generally
in
terms
of
how
you
would
use
a
container
to
run
this,
so
it
looks
like
okay,
so
so
these
are
docker
files
defining
service
containers,
but
it
sounds
like
the
actual
services
are
still
installed
in
that
container
via
omnibus
right.
So
so
I'm
wondering
oh.
B
C
Name
so
omnibus
is
has
is
not
a
container
per
se
right.
It's
just
a
way
to
package
up
your
application,
so
so
whether
you
put
that
in
a
container
or
not
doesn't
really
matter,
you
can
also
just
install
it
on
your
host
machine
via
omnibus.
C
So
by
default
we
run
a
pipeline
that
creates
a
docker
container
from
this.
But
and
honestly,
like
you
know,
don't
quote
me
on
this.
I
mean
like
I
said,
I'm
just
looking
at
this
for
the
first
time,
but
I
I
I
it
sounds
like
I
mean
it
says
here,
built
using
the
official
source
installation
instructions
with
some
alpine
specific
fixes.
This
independence
accumulation
tweets
picked
up
from
the
omnis
build
packages.
A
Yeah,
I
think
you
can,
I
think,
with
the
web
service
container,
which
just
wraps
the
the
rails
app
you
could
pass.
There's.
Maybe
a
small
configuration
to
allow
that
value
to
be
passed
to
the
container,
but
I
think
it'd
be
a
very
small
job.
The
one
that
might
be
a
problem
is
the
router
the
container
with
the
rider
in
it.
What's
the
name
workhorse
is
it
at
the
minute?
A
I
think
that
it
automatically,
with
the
last
update
automatically
routes,
websocket
traffic,
to
the
action
cable
to
the
action
cable
container,
which,
if
you're
running
an
app
that
traffic,
would
need
to
be
routed
to
the
web
service
container
instead.
But
I
still
think
it's
quite
a
small
small
update.
C
By
the
way,
I
think
hiring
here
right,
I'm
just
looking
at
the
erb
that
renders
the
docker
file
for
gitlab
rails
and
it's
not
based
on
device.
It's
basically
like
from
source
yeah,
what
it's
at
so
it
just
downloads
gitlab
and
sets
everything
up
manually
so
you're
right.
So
we
would
probably
have
to
change
it
if
we
wanted
to
control
that
via
an
environment
variable
somehow.
B
C
Yeah,
I
think
I
think
it
would
be
the
same
container.
It
would
probably
it
would
just
be
the
gitlab
rails
container.
I
would
imagine,
but
we
would
have
to
make
sure
that
you
can
yeah
enable
disable
action,
cable
via
an
environment,
variable.
B
Yeah,
I
think
the
thing
here
is
like
you
configure
it
once
I'm
not
sure
how
you
deploy
the
cng
thing
right,
but
you
set
one
setting
once
and
it
it
configures.
The
corresponding
settings
right,
like
adds
the
environment
environment
variable
to
gitlab
rails
and
then
changes
how
gitlab
workhorse
proxies.
You
know
you
don't
want
the
user
to
be
configuring
these
separately
right
because.
A
A
So
it
might
be
worth
I'll
look
into
this
anyway,
because
I
did
the
containerization
work
for
action.
Cable
originally
for
the
standalone.
So
I'll
look
at
I'll
revisit
that
mr
and
see
if,
if
there's
a
quick
change
that
can
be
made
to
run
it
enough.
Hopefully
there
is
we're
pretty
much
over
time,
but
heinrichy
had
the
last
item.
B
Yeah,
it's
nothing
urgent,
but
I
was
just
wondering
like
getting
extra
fields.
Real
time
in
the
sidebar
would
be
like
a
front-end
only
work,
because
right
now
we're
just
sending
the
websocket
message
that
the
issue
changed.
You
know
when
anything
in
the
issue
changed
right,
so
we're
sending
more
than
we
need
to
and
the
front
end
just
needs
to
react
to
it
right
right
now.
It
only
reacts
by
querying
the
signees,
although
it
reacts
every
time
every
every
time
anything
changes
it
like
queries
actually,
but
then
it
only
queries
as
I
need.
B
So
if
it
just
if
we
just
add
a
query
for
labels,
for
example,
or
like
some
other
thing
in
the
sidebar,
then
that's
basically
making
the
other
parts
inside
by
real
time
so
and
the
other
my
I
was
only
thinking
of
this
is
because
it's
related
to
how
we
were
like
going
to
deploy
this
right
or
tell
users
about
it.
It's
kind
of
a
weird
thing
to
say,
like
oh
assignees,
are
now
real-time.
It's
like
it's
a
super
small
thing
like
maybe
to
a
user
and
like
a
re,
the
sidebar
is
real-time.
A
Yeah
fully
fully
agreed
with
that,
like
I
don't
see
any
additional
complexity
from
doing
other
parts
of
the
sidebar
as
well,
we
already
have
the
graphql
queries
for
all
parts
of
the
sidebar
are
just
not
mutations.
That's
only
queries
that
really
matter
so
yeah.
That
gets
a
big
thumbs
up
for
me
like
well.
I
would
suggest.
B
C
A
But
yeah
yeah
all
right
cool
we're
out
of
items
unless
anyone
is
anything
else,
oh
okay.
Hopefully
the
demo
brings
in
the
audience
for
this
video
like.
That
would
be
great
thanks
for
your
time
and
have
a
great
day.