►
From YouTube: Plan Stage Weekly - 2022-09-08
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
We
have
heinrich
with
the
first
point.
B
Yeah,
so
I
this
is
the
mix
deployment
compatibility
has
been
like
a
you
know
like
controversial
topic,
or
you
know.
I
just
also
wanted
to
hear
some
thoughts
from
other
engineers
here
in
plan.
B
Like
do
you
actively
think
about
this
when
you
develop
stuff
or
something-
and
here
I
just
wanted
to
share
like
one
example
where
we
worked
on
the
move
to
start
and
end,
and
so
basically
this
was
deployed
in
multiple
deploys
to
gitlab.com
right
back-end
was
deployed
first
to
gitlab.com.
B
A
few
weeks
later,
the
front
end
was
deployed
emerged.
It
was
just
merged
like
yesterday
or
something
so.
It's
gonna
get
deployed
in
a
few
days
or
today,
and
then
this
is
both
of
them
are
going
to
land
in
15.
B
What's
the
number
15
4,
so
it's
it
can
cause
multi
version
failures
in
south
hosted
because
they
would
upgrade
to
15
three
to
fifteen
four
and
that
would
contain
both
dmrs
right.
So
during
their
deploys
it
would
cause
problems.
But
then
I,
during
that
incident,
where
we
had
with
that
it's
a
different
multiversion
problem,
but
I
just
wanted
to
raise
it
it's
hard
to
get
to
be
perfect.
B
Where
we
have
100
compatible
milestones
and
sometimes
being
like
good
enough,
maybe
like
better
like
worth
it,
because
the
cost
to
be
100
is
really
high.
It's
like
very
hard
to
think
about
all
these
cases
that
don't
catch
them
and
so
yeah.
That
was
my
proposal
to
delivery
to,
like
maybe
lower
our
expectations
to
customers
about
these
things,
and
we
don't
even
know
if
customers
actually
depend
on
these
things
right,
customers
doing
no
downside,
deploys
yeah
and
sorry
about
that.
Crying
baby.
C
I
I
agree
with
this.
A
lot
like
cross
compatibility
is
a
huge
problem.
We've
had
these
conversations
honestly,
I
do
think
about
it
all
the
time,
but
most
of
the
time
I
just
have
to
ignore
it,
because
it's
just
too
hard.
There
are
some
ways
sometimes
to
mitigate
one
way
is
feature
flags
and
I'm
not
talking
development.
Teacher
flags.
I'm
talking
like
licensed
feature
flags,
but
we
can't
do
it
for
every
tiny
change
like
we
do
it
at
a
high
level.
It's
like.
Oh,
our
iterations
available.
C
C
I
thought
I
thought
we
were
okay
with
shipping
back
in
and
frontended
in
the
same
milestone.
C
I
know
it's
a
big
debate,
but
I
thought
it
was
okay.
I
didn't
realize
it
was.
This
was
gonna
cause
problems,
but
overall
I
agree
with
what
you're
saying
kind
of.
B
D
I
don't
think
it's
worth
the
velocity
slowdown
of
not
being
able
to
ship
a
feature
in
a
single
milestone
and
then
just
if
you
then
need
to
make
changes
once
the
front-end
is
rolled
out,
then
that's
another
two
milestones
before
you
could
deploy
your
fix
potentially
and
there's
also
that
if
it
affects
anyone
other
than
com
in
the
first
place,
then
there's
still
like
the
chance
that,
if
they're
not
updating
every
version
which
I
assume
most
people,
don't
then
they,
like
you,
wouldn't
be
able
to
skip
a
version
to
help
reinforce.
A
Yeah-
and
I
was
talking
to
heinrich
about
this
earlier,
but
I
I
I
know
we
haven't
been
so
yes
technically
we're
not
supposed
to
have
front-end
changes
and
back-end
changes
to
graphql,
to
like
add
a
field
or
anything
within
a
single
milestone.
It's
supposed
to
be
one
after
the
other.
So
the
two
milestone
requirement.
I
know
we're
not
following
that:
every
every
time.
A
That's
a
fact
that
we're
not
and
knowing
that
we
don't
do
that
and
we've
shipped
front
and
back
and
in
the
same
milestones,
and
we
haven't
gotten
a
customer
complaint
about
things
not
working
at
the
level.
That
would
that
it
would
be
broken
kind
of
tells
me
that
it's
not
like
we're
like
we're
optimizing,
something
that
doesn't
that's
not
worth
the
loss
of
or
for
something,
that's
not
worth
the
loss
of
velocity
that
we
that
we
have
with
waiting
for
two
milestones
there
yeah.
A
So
I
had
a
question
topeka,
I'm
only
picking
on
you
because
you
just
been
the
most
recent
onboarding
and
I
think
the
only
one
since
we
put
together
a
training
on
multiversion
compatibility.
Do
you
remember
going
through
that,
at
all,
through
the
onboarding
process,
like
viewing
the
training
on
all
day
yeah,
so.
E
I
haven't,
but
then
I
agree
there
have
been
talks
that,
upon
you
know,
whatever
coffee
chats,
whatever
I've
listened
to
the
past
whenever,
since
I've
come
here
that
the
front
end,
you
know
front
end
only
happens
under
the
back
end,
but
I've
seen
mrs
have
reviewed
natalia's,
mr
as
well,
where
heinrich
was
working
on
one
and
I've
seen
this
happening.
I
don't
know
about.
It
was
merged
in
the
same
milestone,
but
here
also
it
didn't
make
sense
to
just
not
merge
the
mr
just
because
it
is
in
the
same
milestone.
E
I
mean
we
tested
it
like
we
or
we
started
it
working
in
the
initial
phase
15.4,
so
it
has
been
like
two
or
two
and
a
half
weeks
since
then
it
was
tested,
it
was
like
the
ux
was
approved
and
it
was
working
fine
and
just
because
we
didn't
have
to
merge
it
in
the
same
milestone.
We
didn't
have
to
stop
so,
and
I
don't
know
so.
It
was
like
in
the
earlier
stages
when
I
was
like
every
time
I
was
re-racing.
I
was
having
issues
because
I
was
like
god
why
he
was.
E
Why
isn't
it
the
master?
Because
but
then,
after
that,
I
realized
that
this
feature
went
because
heinrich
is
very
fast
at
how
he
makes
changes,
so
it
only
helped
me
with
instant
feedback
and
instant
changes
so,
like
I'm,
pretty
happy
like
this
can
go
on
like
I'm
comfortable
with
this
life
cycle.
So,
if
like
if,
for
example,
in
iteration
with
what
I'm
working
on,
if
euler's
mr
would
not
have
been
merged,
then
also
it's
like
just
fine.
Now
it's
merged.
E
So
as
long
as
it's
smooth
enough
as
a
developer,
it's
fine
and
the
customer
facing
like
heinrich
said
that
it's
it
depends
on
how
critical
that
is.
You
know
if
it's
like.
We
have
to
be
very
cautious
about,
but
I
think
it's
just
smooth
enough.
I
need
to
know
more
about
critical
issues
that
customer
has
faced
at
gitlab.
Gitlab.Com
comment
more,
but
it
was
nice
like
it's
just
good
to
like
you
said
velocity
like
you
worked
on
it,
you
tested
it
works
fine,
let's
just
you
know,
deploy
it.
E
It
doesn't
really
matter
the
same
milestones
say
or
the
other
mindstorm.
So
for
me
personally,
like
I
have
that
view,
I
don't
know,
I'm
sorry,
no.
A
No,
no
and
that
that
that
makes
sense.
I
was
more
curious
just
because
we
we
spent
a
decent
amount
of
time
and
put
together
or
to
put
together
like
a
training
like
like
a
some
type
of
training
thing,
but
I
don't
know
if
anyone
outside
of
when
we
first
did
it
and
people
watched
it.
I
think,
then
I
don't
know
if
anyone's
watched
it
since
or
it
doesn't
sound
like
we're
requiring
new
engineers
to
to
see
the
training.
A
So
I
don't
know
where
the
like,
how
we
expect
everyone
to
kind
of
know
what
the
rules
are
if
we
did
want
to
figure
out
a
way
to
to
to
govern
this
or
to
require
that
the
the
milestone
delay
in
getting
graphql
features
out,
but
I'm
gonna,
I'm
gonna,
take
that
as
a
action
item
and
see
what's
going
on
there.
A
F
Yeah,
so
in
in
past,
milestone
like
I,
was
working
on
the
confidentiality
bad
support
on
you
know,
task
list,
and
one
of
the
other
features
that
we
were
supposed
to
work
on
was
to
basically
show
a
tooltip
of
creation
and
close
time
for
task
item
within
the
list
by
showing
the
timestamp
in
the
tooltip
for
the
icon
itself,
and
since
the
timestamp
connections
within
the
graphql
query
for
created,
add
and
closed
at
were
not
available
on
the
query.
F
So
in
the
same,
mr,
I
exposed
those
fields
on
graphql
and
then
started
using
it
on
front
end,
but
then
we
realized
that
we
cannot
merge
it
because
of
the
multiversion
compact.
So
I
had
to
remove
the
user
facing
part
of
it.
Just
introduce
the
graphql
change
it.
I
get
merged,
basically
created
a
backend.
Only
mr
and
then
in
15.4.
F
I
ended
up
using
those
new
fields,
so
basically
had
to
wait
for
a
full
milestone
to
have
it
running
so
yeah.
Certainly
and
again,
we
realized
it
on
very
last
day
of
the
freeze.
I,
like
we
already
were
part
of
that
thread,
and
we
were
discussing
that
the
maintainer
suggested
that
this
would
break
multiverse
and
compact,
so
I
had
to
basically
spin
out
a
separate
backend.
Mr
then
got
it
reviewed
and
merged
and
then
basically
had
to
drop
all
the
front-end
code.
F
That
was
basically
using
the
back-end
changes,
so
it
definitely
sucks,
and
I
I
hope
that
we
basically
get
around
to
it,
especially
like,
let's
basically
start
using
same
graphql,
newer
graphql
features
in
in
the
same
milestone,
and
there
is
this
unrelated
thread
on
on
the
graphql
channel,
which
was
basically
suggested,
so
it
basically
was
posted
by
charlie.
F
There
was
a
hacker
news
discussion
on
whether
graphql
after
all
these
years
is
still
a
viable
thing
to
do
and
like
there
were
some
thoughts,
and
one
thought
that
I
had
was
to.
Basically
what
is
the
usage
of
our
graphql
public
api
like?
Are
there
too
many
applications
written
on
the
graphql
public
api
similar
to
rest?
Because
if,
if
the
usage
is
not
that
much,
why
not
just
make
graphql
api
internal?
Only
I
mean
I
am
not
saying
we
should
drop
graphql
entirely.
F
We
should
definitely
use
it
because
it
allows
you
to
get
rid
of
a
lot
of
front-end
boilerplate
code,
but
if
the
community
users
are
not
using
just
the
api,
then
let's,
let's
make
it
just
a
private
api
internal
thing
and
we
use
it
for
ourselves,
but
for
public
a
rest
api
would
be
the
only
because
right
now
I
mean
when
you
look
at
rest
api
it
is.
F
It
is
so
flexible
to
a
point
where
you
can
basically
write
very
complex
call
scripts
using
a
rest
api
and
do
whatever
you
want,
which
is
not
the
case
with
graphql.
I
mean
I,
I
cannot
imagine
writing
a
shell
script.
That
would
send
a
graphql
query,
fetch
the
data
and
then
consume
it
to
my
own
liking.
So
I'm
sure
that
I'm
not
be
alone
to
feel
this.
C
The
problem
with
doing
that
is,
we
only
do
it
like.
We
currently
only
develop
new
features
in
graphql,
and
that
means
that
if
we
want
to
make
any
new
features
available
on
the
public,
api
we'd
have
to
duplicate
the
work
and
build
it
in
the
rest
api.
So
I'm
not
sure
it's
viable
in
terms
of
workloads
for
the
back
end
as.
F
But
aren't
we
on
already
doing
it
like
having
the
features
available.
F
Yeah
I
mean
I
I
it
would
be
disappointing
to
see
a
new
feature
not
available
on
rest
api
because,
like
I
have
a
ton
of
applications
on
mac
os
and
some
scripts
using
rest
api
extensively,
I
know
that
work
items
is
not
available
fully
on
top
on
rest.
Apis,
like
walk
items,
were
exclusively
designed
in
a
way
to
be
available
just
on
graphql
but
yeah.
If
we
aren't
doing
anything
on
rest
for
any
new
feature
that
we
introduced.
F
C
F
A
Way
outside
gitlab,
like
we're
going
into
the
the
pros
and
cons
of
graphql
versus
rest
hybrid,
mentioned
the
api
vision
working
group.
I
wonder
if
they're
working
on,
because
originally
the
plan
was
to
go
100
to
graphql
and
then
use
something
that
converted
graph.
You
like
use
a
layer
on
top
of
the
rest
api,
so
that
was
automatically
created
off
of
the
graphql
api.
Is
that
still
the?
B
Yeah,
that's
an
option
so
they're
looking
at
different
options-
and
I
saw
one
option
discussed-
I
haven't
been
really
updated,
but
I
saw
an
option
discussed
before
was
where,
like
the
rest,
api
v5,
we
could
introduce
v5
with
a
parameter
to
select
fields
that
you
want,
because
if
this
is
the
main
feature,
we
want
from
graphql
right,
like
smaller
payloads
and
selecting
the
fields
so
yeah.
That's
like
one
example.
B
No,
but
I
mean
you
could
implement
it
in
rest
right
nobody's,
nobody
prevents
you
from
adding
a
param
like
only
fields
equals.
You
know
something
right
and.
D
B
We
have
like
include,
subscribed
or
not,
because
subscriber
subscription
is
like
expensive
to
compute,
so
we
kind
of
end
up
with
something
like
that,
but
I
think
their
vision
is
more
like,
maybe
something
more
dynamic
where
you
could,
like
all
the
fields
are
automatically
like
selectable
or
something
maybe
or
I
don't
know,.
A
To
be
honest,
when
we
move
stuff
from
rest
to
or
internal
to,
graphql
oftentimes
we're
still
bringing
in
the
everything
from
the
payload
anyway
like
we're
requesting
all
fields
anyway,
so
our
payloads
aren't
really
much
smaller
than
they
than
they
used
to
be,
but
that's
more
of
just
our
doing
as
to
why
we
don't
have
those
benefit
benefits
of
smaller
payloads.
F
A
If
we
need
something
from
the
rest
api
and
it
isn't
there,
then
it's
a
lot
easier
to
gracefully
fall
back
just
if
we
don't
have
that.
Don't
don't
show
that
that
that
part
of
the
ui,
but
with
graphql,
if
it's
just
one
field
in
the
larger
query,
everything
fails.
B
Api
thing,
like
you
know,
we
can't
break
public
api
right
thing.
Compatibility
rest.
Api
also
has
the
same
problem,
because
we
make
the
same
guarantees
with
our
rs
api.
We
can't
make
breaking
changes
right,
so
it's
kind
of
annoying
also
when
we
work
with
rest
api,
like
that,
and
I
kind
of
preferred,
like
the
internal
rails
controllers,
where
we
don't
guarantee
that
this
is
going
to
be
public
and
so
yeah.
B
Although
one
thing
I
would
say
about,
graphqls
is
even
if
we
made
it
private
I'd
still
like
hate
it
somewhat
because
of
like
the
hoops
I
have
to
run
into
just
to
implement
something
like
in
the
rails:
vanilla
rails,
you
just
have
a
new
controller
action,
and
you
know
return
this
json,
all
that
and
then,
and
we
have
yeah.
I
had
to
create
a
resolver.
I
just
created
the
type
create
so.
B
A
B
The
graphql
implementation
of
rails,
the
ruby
implementation
of.
B
Know,
if
maybe
other
implementations
also
do
the
same
thing
just
because
to
accommodate
like
graphqls
like
queries
and
all
that
there
have
to
be.
C
F
So
I
think
a
graphql
was
developed
by
facebook,
basically
because
they
were
using
a
database
that
was
graph
based
like
it
was.
It
was
a
tree
based
database
and
not
the
relational
tables
right,
so
maybe
that
basically
was
a
natural
fit
for
them
and
we
are
trying
to
basically
build
a
graph
based
api
on
top
of
relational
database
and
just
guessing
I
mean
that
may
be
the
reason
that
we
have
to
do.
A
lot
of
you
know
boilerplate
code
on
top
of
postgresql.
E
I
just
want
to
say
I
don't
know
if
there
are
not
so
many
people
who
would
like
life
with
rapper,
but
I'm
I'm
loving
graphql,
because
I
don't
I
know,
but
there
is
always
stuff,
but
for
me
personally
for
the
rest
api,
when
I
was
working
with
it,
I
had
to
always
constantly
be
in
touch
with
the
back
end
about
you
know,
discussing
the
contracts
and
everything
now
here.
It's
like.
I
just
go
to
the
explorer
to
see
the
input
type
the
packet.
E
I
know
the
you
know
the
amount
of
work
that
goes
behind
it.
Like
you
said
you
have
to
write
the
results
and
everything,
but
for
me
as
a
developer,
now
it's
so
much
easier
than
I
can
like
and
especially
being
in
nursing
culture.
I
can
imagine,
if
would
have
been
a
rest
api.
I
would
like
to
have
pink
just
imagining
like
the
backend
development
and
waiting
for
the
next
day.
Now
it's
like
everything
is
available.
I
can
just
see
the
explorer
it's
merged.
E
E
I
don't
know
about
the
graph
based
like
why
if
you're,
especially
building
graph-based
tables
like
to
use
graphql
in
gitlab,
but
just
to
use
graphql,
but
I
like
it,
I
mean
it's
good
as
for
me
as
a
developer,
it's
just
easier
to
use
and
rest
because
I'm
not
dependent.
I
can
just
see
everything.
I
know
the
types
expected
output
and
it's
just
like
whatever
fields
I
want
to
take,
I
can
take
and
not
take
so
yeah
totally
unrelated,
but
then
I.
A
Just
really
like
the
the
tooling,
like
I
like,
using
graphical
over
like
postman
or
whatever
you
use
for
or
rest
or
yeah,
just
breast
tooling,
that's
probably
my
favorite
thing
about
red
fuel.
E
B
B
Yeah,
it's
also
good
to
hear
from
someone
like
new,
and
you
know
the
advantages,
because
we
don't
I
mean
I
guess
even
if
it's
rest
versus
crafty,
we
don't
have.
We
don't
feel
that
advantage
like
you
said
we're
exploring
things,
because
we
kind
of
already
know
the
rest
api
and
what
it
you
know,
looks
like
and
how
data
comes
out
from
that.
But
yeah
you
saying
that
it's
very
helpful
from
a
you
know,
newcomer
or
a
new
contributor's
perspective
is
also
yeah.
A
good
point
like.
E
For
example,
the
iteration
thing,
for
example
julian,
is
in
league
right.
I
just
looked
at
that
what
mr
he's
done.
I
just
went
through
I've
been
like
going
through
everything,
the
graphql.
What
he's
written?
I
can
see
the
types
I
can
see
like
it's
just
easier
for
me
to
see
things
had
it
been
rest
and
I've
been
I
had
been
like.
I
definitely
would
have
waited
for
him
to
come
to
you
know.
So
it's
just
like
I'm
not
dependent
on
on
asking
questions.
It's
just
there.
E
A
I
guess
it
is
the
first
of
the
month
kind
of
simon-
and
I
had
this
issue
that
we
talked
about
earlier
today,
where
it's
the
first
wednesday
of
the
month
for
me,
but
it's
the
second
thursday
for
you
all.
B
Well,
it's
our
first
apec.
B
B
A
There
have
been
some
cool
numbers
that
that
dave
and
melissa
have
been
sharing
around
task
usage.
The
last
one
gabe
shared.
A
I
don't
know
where
it
was.
Does
anyone
remember
where
he
posted
it?
Oh
yeah,
2500
2586,
unique
users
on
gitlab.com
created
a
task
in
august.
A
Yeah,
how
many
well
unique
users?
It's
probably
a
good
number.
A
I
don't
know
how
many
tasks
were
created,
but
I
think
it
was
something
like
her
issue
that
had
a
task.
There
were
three
forget
lab.com.
There
were
three
tasks:
yeah
2.9
tasks
per
issue.