►
From YouTube: 2020 04 02 CI Minutes Rapid Action Sync
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
All
right,
welcome.
Everybody
didn't
have
any
topics
on
the
agenda
item
today.
Does
anybody
have
anything
to
talk
about
so
reason
we
set
this
up.
We
weren't
getting
a
lot
of
updates.
Originally,
we
wanted
to
make
sure
we
were
all
on
the
same
page,
so
set
up
a
weekly
thing
to
talk
about
any
topics
that
have
come
up.
It's
been
some
good
communication
on
the
issues
this
week
and
it
seems
like
we're
making
some
good
progress.
So
anything
we
need
to
cover
today,
probably
Kenny
and
Alexia,
are
the
most
involved
in
Camille's
here,
yeah.
B
Camille
and
I
had
a
good
discussion
on
one
of
those
threads
where
I
was
just
a
little
bit
concerned
about
us.
Having
scope
creep
are
putting
blockers
to
the
beginning
of
accumulation
of
minutes
on
public
projects
on
Caleb,
calm
I.
My
mind
is
clear
of
that
now,
so
yeah
I
think
we're
good
moving
forward.
I
do
think
that
over
the
last
week,
since
our
last
sink
that
the
addition
of
that
issue
about
adjusting
which
runner
tags
were
using
for
gitlab
projects
itself
has
kind
of
expanded
to
it
now
include
folks
from
various
other
teams.
B
C
D
B
E
E
Yeah
I
was
gonna,
say
that
documentation
issue
and
then
keeping
track
of
the
projects
in
the
issue
that
Remy
co-created.
Those
are
the
two
items
that
I
think
we
need
and
then,
as
maybe
measurements
so
like
things
in
periscope,
like
Remy,
was
just
active
in
creating
a
view
to
help
provide
some
insight
into
something
you're
asking
about
in
slack
I.
Think
that's
where
engineering
productivity,
we're
really
looking
to
help
is
those
three
facets:
I'm,
not
sure
if
it's
necessarily
blocking
like
what's
blocking
so
that
we
can
prioritize
accordingly.
D
C
Beck
does
that
as
I
can
help
clarify
yeah,
just
I
think
we
were
here
to
help.
So,
let's
make
it
scope
clear
what
we
need
to
deliver
for
this
team
and
then
prioritize
and
make
sure
that
this
this
group
is
successful.
One
question
to
follow
up
I
think
from
our
conversation,
because
we
also
gave
an
update
on
on
this
effort
is:
do
we
know
why
the
costs
are
different
between
internal
and
external
runners,
I.
E
Was
pretty
sure
I
was
mistaken
when
I
spoke
on
that
so
I
think
I
said,
private
runners
were
cheaper
and
I.
Think
it's
the
opposite,
I
think
it's
just
the
Machine
specs
that
are
used
Camille.
Do
you
Camille
or
Tomas?
Do
you?
Can
you
speak
better
to
the
cost
difference
in
private
versus
the
existing
shared
runners.
D
F
The
difference
between
machine
specs-
it's
not
big,
because
we
use
l1
standard
one
for
runners
and
then
one
standard
for
the
private
and
GSM
runners.
Also
the
private
runners,
are
highly
we
used.
While
for
the
shirt
runners
each
one
is
removed
after
the
job
is
executed,
so
that
difference
is
created
by
several
variables
and
Counting.
This
is
not
not
really
easy.
D
So
I
mean
like
it's
pretty
much
like
also
from
what
I
learned
from
you
as
part
of
the
bigger
effort
we
really
want
in
the
end,
to
have
all
get
love
or
Kroners
in
a
separate
beading
group
from
general
purpose.
Third
runners
kind
of
have
this
very
clear
distinction
between
the
cost,
which
is
kind
of
like
how
to
have
today
yeah.
B
Exactly
that's
been,
my
understanding
is
that
we
cannot
make
clear
distinctions
on
our
internal
costs
for
select
external
costs
on
them,
like
per
total
minute
consumed
basis,
because
we
don't
have
these
distinctions,
so
it
does
help
our
business
to
be
able
to
have
a
better
understanding
by
making
these
distinctions.
I.
Thank.
C
You
for
that,
thanks
for
the
colors,
all
the
the
execrated
here
will
be
I
would
say
once
you
have
done
all
this
change.
Let's
do
a
review
of
all
the
offending
I.
Don't
want
to
use
well
in
turn
that
the
the
projects
that
needs
to
be
moved
and
if
they're
out
on
the
correct
wonders
and
I
think
this
is
good
for
our
site
to
help
move
this
forth.
Yeah.
B
And
I
do
want
to
echo
Camille's
point
the
the
overarching
kind
of
like
immediate
desire,
and
there
is
some
engineering
work.
That's
that's
in
the
pipeline
today
to
enable
this
is
to
start
accumulating
minutes
on
public
projects
that
we
haven't
been
accumulating
for
babcom
first,
and
so
you
know
Camille's
point
about
making
sure
we
focus
first
on
adjusting
those
projects
that
have
community
contributions
and
I
always
start
with
the
ones
that
have
the
highest
number
of
community
contributions.
B
That's
what
we
want
to
do
is
we
don't
want
to
break,
say
community
contribution
fork
process
by
starting
to
accumulate
minutes
on
those
public
projects.
So,
from
my
perspective,
this
efficiency
effort
with
scopes
just
to
to
that.
So
the
additional
hey,
there's
a
bunch
of
projects
that
also
aren't
doing
community
contributions,
but
should
be
because
we
can
account
for
them
better
is
kind
of
a
secondary
benefit.
A
B
They
question
the
Kenny:
oh,
my
desire
is
as
soon
as
possible.
I
think
that
my
understanding
of
the
sequencing
is
Alexi
is
working
on
the
code
that
enables
the
accumulation
and
the
feature
flags
to
do
that
at
the
group
level.
Then
we
need
to
ensure
that
we're
not
going
to
break
any
forks
by
adjusting
the
project's
appropriately
and
have
some
documentation
for
how
to
do
that
on
existing
Forks.
And
then
we
need
to
roll
that
out
and
I
think
I'm
of
its
Alex
or
tomash.
B
G
Well,
a
couple
weeks
is
fine
I,
for
it
sounds
so
it
sounds
like
accumulating.
These
minutes
is
like
going
to
be
like
a
rake
task
or
something
or
is
it
going
to
be
just
an
update
to
the
database
I'm,
not
clear
on
other
than
building
the
new
runners
I'm,
not
clear
on
what
the
infrastructure
involvement
is
going
to
be.
D
G
Yeah,
then
that
should
be
fine.
You
know,
building
the
new
runner
is,
probably
you
know
week
or
two
I
would
say
I'm
on
call
this
week.
So
problem,
probably
nothing
gonna
interesting
happen
until
at
least
Tuesday,
but
other
than
that
building
out
the
new
runners
shouldn't
take
a
super
a
long
time.
G
G
B
H
Heard
so
much
pay
me
to
finish
it
next
week,
I
mean
to
those
troll
reviews
and
try
to
merge
it.
Okay,
so
that's
my
target
and
since
since
I
started
to
talk,
I
wanted
to
ask
a
bit
about
documentation.
So
maybe
you
give
some
advice.
So
if
you
could
open
my
two
links,
I
printed
in
my
comment
above
yeah,
we
have
these
two
dogs
and
we
discussed
that
we
want
to
adjust
this
dog
first
shared
rather
spec.
Five
minutes
quota,
but
I
believe
it's
related
to
self
managed
installs.
H
H
G
Okay,
yeah
the
gitlab
calm
settings
page
can
be
whatever
we
want,
but
originally
it
was
to
document
the
differences
between
the
default
config
and
what
Ghaleb
calm
uses.
It
seems
to
have
had
a
bit
of
change
quite
a
bit
over
the
years,
also
including
things
like
our
SSH
key
fingerprints
and
whatnot,
but
I
definitely
think
we
should
document.
B
I
think,
there's
not
sufficient
documentation
of
how
the
accumulation
of
those
shared
one
or
minutes
works,
and
and
in
what
cases
we
do
them
and
when
we
add
these
minutes
factors
I
think
that
we
would
wants
to
document
how
you
use
the
minutes
factors,
and
then
we
could
document
in
the
get
lab
comm
page
the
settings
that
we've
put
for
those
minutes,
factors
that
enable
our
accumulation
on
get
lab
calm.
So
I
was
kind
of
trying
to
separate
the
difference
between
those
two
does
that
make
sense.
Alexi
yeah.
B
H
H
B
Maybe
I
need
some
education
here.
I
was
assuming
that
that
meant
the
code
would
ship
is
part
of
our
distribution,
but
we
would
have
it
behind
some
feature
flag
that
maybe
get
lab.
Comm
is
the
only
one
whose
flips
that
feature
flag
that
says
enable
shared
runner
minutes
quota
accumulation?
Yes,
that.
C
E
B
B
D
So
can
there
is
like
we
have
something
in
the
key
lock.
That
is
part
of
the
main
application
that
allow
us
to
distinguish
that
some
features
are
only
visible
on
kake.com,
okay,
but
so
it's
still
part
of
the
same
codebase
when
we
make
here
these
things
from
the
Disco's
wiki
club.com,
a
specific
thing
that
is
being
okay.