►
From YouTube: 2022-03-09 Create:Source Code - Weekly Meeting
Description
Recording of the weekly meeting of the Source Code group
A
So
I
I
briefly
looked
at
you
know:
where
are
we
going,
and
I
thought
I'll
just
create
a
small
table
with
themes
coming
up
for
14.10
and
I've
noticed
that
in
the
past
this
has
been
very
directed
to
you
know
what's
in
engineering,
and
maybe
we
want
to
continue
doing
it
that
way,
but
I
was
thinking.
Maybe
we
put
more
clarity
on
you
know
what
are
we
doing
in
the
different
areas?
So
I
added
also
you
know
that
merge
strategies
is
now
in
design
and
probably
documentation.
A
Work
might
be
something
that
we
want
to
start
in
in
the
14.10,
I'm
not
sure
just
putting
it
here
as
an
idea
and
then
also
that
I
could,
for
instance,
be
starting
looking
at
code
owners.
So
there
are
millions
of
tickets
around
code
owners
and
I
could
start
looking
into
what
is
there
and
what
kind
of
problems
to
exist
and
kind
of
make
small
piles
and
do
that.
A
B
Yeah,
it
definitely
makes
sense
to
me
torsten.
Thank
you
very
much
and
just
just
to
mention
you
you
said
about
how
previously
this
was
you
know,
engineering
driven,
that's
something
I'm
really
happy
to
to
move
away
from
and
and
we
were,
as
we
mentioned
as
I
discussed
now
101
today,
you
know:
we've
just
had
like
one
after
another
engineering
allocations
and
I'm
sure
that
everyone
will
be
really
happy
to
get
onto
doing
feature
work.
So
thank
you
very
much.
A
A
A
You
already
mentioned.
You
know
their
the
weaknesses
in
our
documentation
around
merging
in
general,
so
I
think
it
makes
sense
to
start
there
and
then
phipps
compliance
has
been
ongoing
and
will
continue
to
to
have
to
be
worked
on.
Some
things
will
slip
and
likewise
sshd
right
sean.
This
will
both
slip
14.9.
Some
things
may
be
released,
some
not.
B
A
Yeah,
okay
and
then
finally,
we
talked
about
this
this
morning.
Sean
there
are
a
bunch
of
security
bugs
that
we
need
to
look
at.
I
started
trying
to
understand
those,
so
maybe
I
can
even
make
those
things
linkable
so
that
we
understand
what
are
the
different
things,
but
I'm
not
there
yet
so
right
now,
it's
only
a
text
table
yeah.
So
much
about
that,
I'm
much
deeper
in
the
weeds
that
I
could
talk
more
about
this.
A
A
Okay,
it
is
not
okay,
let's
then,
then,
let's
continue
with
merge
strategies
and
then
come
to
the
docs
related
questions.
Sure
so
I
have
shared
and
especially
nick
has
shared.
You
know
the
ideas
around
reorganizing,
the
merge,
merge
strategy
options
and
basically
there
are
two
approaches
that
we
can
take.
One
is
like
an
incremental
one
where
we
yeah
you've
read
what
I
put
in
there
right
and
the
other
one
is
the
all
in
one.
So
kushal
already
commented
that
he
would
like
to
have
the
all
in
one
sean.
B
I'm
happy
to
go
with
what
the
group
thinks.
My
opinion
is
that
we
might
want
to
that.
It's
a
very
big
change,
and-
and
so
I
I
I'm
sorry-
I
took
so
long
to
do
this,
but
I
just
put
some
comments
in
the
issue
just
before
this
meeting:
okay,
yeah!
No,
that's
not!
No
just
it's
I'm
the
one!
Sorry
so,
but
my
my
thoughts
are
that
it
is
a
big
change,
and
so
you
know
if
we
it
seems
like
we
have
a
clean
split
to
do
incremental.
B
The
thing
is,
there's
a
couple
of
things
I
I
wanted
to
point
out.
One
is
that
the
you
know
this
is
a
huge
improvement
and
I'm
really
glad
we're
doing
it,
but
the
ui
change
is
is,
is
you
know
not
insignificant,
and
so
that
might
require
some
user
education
or
or
some
way
to
to
make
that
transition
easier.
B
I
love
all
the
diagrams
that
mike
has
done
about
how
the
different
options
work,
and
so
we
actually
we're
adding
quite
a
lot
of
different
options.
I
can
really
see
that
those
I
can
see
a
large
documentation
effort
here,
because
I
think
that
we
should
capture
that
information
somewhere
in
our
documentation.
B
So
so,
while
we're,
you
know
adding
a
what
seems
to
be
a
simple
feature,
it
actually
adds
a
lot
of
stuff.
So
that's
why
I'd
be
inclined
to
to
go
slowly
if
possible,
and
I
don't
know
this
is
too
much
to
ask,
but
I
think
we
have
some
way
to
do
what's.
It
called
not
feature
flagging,
but
you
know
when
you,
you
expose
a
feature
to
a
small
group.
B
Yeah
like
if
we
could
do
perhaps
a
percentage
roll
out
and
get
some
evaluation
on
it.
I
don't
know
if
we,
if
we,
if
we
take
that
strategy
at
gitlab,
yes
yeah,
so
so
that's
that's
one
thought
and
the
other
thought
is.
I
think
the
way
this
is
planned
is
that
the
existing
functionality
of
of
the
additional
commit
will
will
still
be
the
default.
B
B
Oh,
no,
sorry,
because,
because
the
way
the
ui
has
changed,
so
that's
fine
as
long
as
the
functionality
is,
is
the
same
and
is
still
the
default,
and
then
we
could
you
know
we.
We
could
deprecate
it
right.
We
could.
We
could
say
that
in
16
you
know
the
the
additional
commit
will
no
longer
be
the
default,
but
I
think
we
have.
I
think
that
will
be
a
big
change
for
our
users,
so
we
should
kind
of
do
that
slowly,.
B
A
B
C
B
A
A
B
B
A
A
B
From
the
user's
perspective,
it
is,
we
do
not
expose
any
toggles
with
regards
to
feature
flag
on
user
settings
side
so
largely
it
would
be
the
admin
who's
in
control.
So
generally,
what
happens
is
if
they
are
on
sas,
then
we
just
enable
it
for
their
group
on
github.com
and
if,
if
they
are
self-managed,
then
our
support
team
works
with
their
ops
team
to
basically
have
it
enabled
on
their
instance:
okay,
okay
yeah.
I
just
I
guess
whatever
we
do.
B
B
A
A
C
A
Sorry,
when
I
meant
incremental,
I
mean
so
it's
not
about
who
gets
to
see
it,
I
meant
how
we
implement
it.
Do
we
implement
it
in
this
in
two
steps.
First,
step
is
just
add
the
squash
functionality,
the
proper
squash
second
one
is
to
add
more
freedom
to
for
the
for
the
admin
and
also
for
the
merger
to
choose
that
merge
time
right.
So
these
are
two
different
needs
and
we
could
satisfy
them
at
different
times.
A
I
was
hoping
that
maybe
we
could
do
the
squash
for
15
00,
but
yeah.
I
have
no,
no
sense
of
you
know
the
other
things,
okay
good,
but
we
kind
of
agree
and
this
I
think
this
is
important
for
for
for
mike
and
also
for
me.
We
agree
on
the
incremental
approach,
because
this
is
then
we
can.
You
know
progress
with
this
one
right,
so
we're
going
to
say:
okay,
this
is
the
design
for
step
one.
This
is
designed
for
step
two
and
then
from
that
on,
we
can
work
forward.
C
C
A
B
Yeah,
well,
that
was
also
you
know
me
so
and-
and
I
just
had
it
on
it-
for
a
while
so
thousand
I've
just
I've
done
a
emerge,
I'm
on
a
kind
of
mission
to
increase
the
technical
documentation
for
source
code,
which
I'm
mostly
doing
myself,
because
I
don't
want
to
burden
the
engineers
with
it,
and
so
it
should
be
up
there
soon.
I
guess
it's
been
merged.
I
guess
it'll
be
built
soon.
Yeah,
it's
interesting
to
see.
B
B
B
C
Well,
I
do
have
the
the
one,
the
doc's
question
for
okay,
that's,
okay!
That's
why
I
waited
till
the
end
sean!
I
am
going
to
be
looking
for
direction
from
you
about
a
timeline
for
when
you
want
the
workhorse
and
the
gitlab
shell
documentation
to
move
into
the
main
repository
from
your
previous
comments.
It
sounds
like
a
gitlab
shell
will
take
longer
for
reasons.
B
Yeah
sure
absolutely
so,
first
of
all
amy.
So
the
the
answer
is
up
to
you.
It's
something
so
yeah.
I
would
like
this
to
happen,
but
it's
been
sitting
out
there
for
for
years
literally-
and
I
know
it's
kind
of
a
big
job
because
we
need
to
not
only
move
over
and-
and
you
know,
clean
up
the
markdown
documents,
but
then
it's
going
to
need
to
go
through
pipelines
and
you.
C
B
Okay,
yeah
there's
no
there's
no
pressing,
there's
no
pressing
need.
You
know
we
can
do
it
as
as
we
want,
and
we
can
certainly
do
it
very
incrementally
and
and
yeah
so
gitlab.
Shell
is
more
complicated
because
when
we're
adding
in
this
major
piece,
gitlab
sshd
that
was
supposed
to
be
merged,
you
know,
but
it's
not
so
yeah,
maybe
maybe
workhorse
is
a
good
place
to
start.
I
think
what
I've
noticed
so
far
with
with
those
docks
is
they're
they're,
very
bare
and
they're,
also,
probably
quite
out
of
date,.
B
Yeah
so
part
of
the
driver
for
this
is
I
have
a
new
team
member
joining
oh
announce
this
there's
a
new
team
member
joining
source
code,
a
new
engineer
and
joining
source
code
on
the
12th
of
april
yay,
and
you
so
there'll
be
five
back-end
engineers
then-
and
I
am
actually
interviewing
another
person
tomorrow-
that
they
look
great
on
paper.
They've
passed
one
interview
already,
they
look,
they
were
great
in
the
first
interview,
so
they're
a
possible
second
new
engineer.
B
So
part
of
the
reason
for
this
is
to
give
them
something
to
work
with,
but
in
in
general,
it's
you
know.
I
I
myself
have
trouble.
You
know,
I'm
rambling.
Let's
go
back
to
the
start.
To
answer
your
question:
if
you
answer
the
question,
there's
no
timeline
on
it.
We
can
do
it
whatever,
whatever
milestone
makes
the
most
sense.
C
Okay,
so
I'm
doing
a
quick
tally,
looks
like
a
total
of
it's
currently
split
across
seven
pages.
It
may
in
fact,
be
smaller
than
that.
I'd
have
to
read
through
my
inclination
is
to
ask
that
we
call
this
a
deliverable
for
me
for
1410,
not
necessarily
because
of
your
needs,
but
because
of
what
I'm
aware
is
coming
okay
and
that's
for
another
group,
gitlab
pages
is
being
transferred
over
to
editor.
B
B
C
B
C
Let
me
get
you
the
url
for
the
issue,
because
sean
created
that
yesterday
that
way
we
can
account
for
it
on
the
page
yeah.
Let
me
see
if
I
could
write
to
the
page
sure
I'm
in
a
weird
situation
here,
where
I'm
downstream
from
your
deliverables,
but
sometimes
I
have
deliverables
of
my
own
and
I'd
like
to
surface
those
whenever
possible.