►
Description
Discussion on secure analyzer and orchestrator versioning strategies and upcoming deprecations
Relevant issues:
- Replace x-y-stable docker images with major tag for Security Products https://gitlab.com/gitlab-org/gitlab/-/issues/207128
- Pin minor version of SAST, DS analyzers https://gitlab.com/gitlab-org/gitlab/issues/10290
- Pin the minor version of Security Products (tools and analyzers) in the vendored templates https://gitlab.com/gitlab-org/gitlab/-/issues/9725
B
A
This
currently
is
a
bit
of
a
misnomer,
since
it
is
not
stable
in
any
real
fashion.
It's
quite
fluid
and
we
retake
it
with
each
major
push
of
a
release.
So
we
should
drop
that
this
just
simplifies
everything
more
globally.
So
that's
a
pretty
easy
change.
If
we
actually
look
at
in
our
templates,
it
would
basically
be
replacing
anywhere
that
has
that
in
the
SAS
version,
it's
just
called
SAS
version,
I
think
with
two,
because
everything
is
really
just
version
two
right
now.
A
That
means
that
we'll
release
an
analyzer
or
an
orchestra
version
of
like
2.3.
We
also
retake
it
as
two
so
cool.
That's
a
really
really
quick
change
we
can
make
in
1210
and
because
we
don't
document
what
these
things
are,
we
can
change
it
quickly
and
we
don't
really
need
a
deprecation
notice
for
that
portion.
May.
C
A
C
Yeah
I
run
into
an
issue
recently
where
it
made
like
a
significant
change
to
the
license
compliance
a
I
made
it.
It
went
from
version
to
version
3
because
they
dropped
the
image
size
from
X
to
Y,
and
so
that
got
picked
up,
but
also
got
picked
up
in
all
the
older
versions
of
the
images
because
we
rebuilt
the
11
one
or
I.
Don't
know
how
far
back
it
was.
It's
like
12,
1,
12
to
12
3
12
for
12
5,
so
wondering
the
new
direction.
C
A
C
C
A
It's
worth,
it's
been
hashed
out
in,
like
seven
different
issues
in
different
threads
that
haven't
had
a
single
conversation
so
yeah,
it's
worth
it
so
two
things
one.
If
you
are
talking
about
us
introducing
new
vulnerabilities
new
rule
sets
into
our
analyzers
old
versions,
we'll
get
those
new
rule
sets.
So
it's
a
feature
in
the
sense
that
we
provide
more
coverage
for
old
versions
with
new
rule
sets,
but
it
also
provides
a
greater
liability
in
terms
of
breaking
older
things.
A
So
that's
the
thing
that
we
lose
if
we're
pinning
to
a
major
number
instead
of
the
ex-wife's
table,
it's
the
exact
same
behavior.
So
this
is
just
simplifying
the
way
that
we
build
things
and
the
next
step
would
be
pennies
to
the
minor
version,
at
which
point
we
would
lose
that
like
hot
upgrade
logic,
but
there's
discussion
about
that.
A
C
If
we
were
to
like
increment,
let's
like
get
live
rails,
1210
was
then
to
pin
to
major
version
of
SAS
200,
and
then
we
go
to
get
lab
rails
13.0
and
we
release
SAS,
2.0
or
3.0.
Customers
would
still
be
able
to
opt
in
if
they
wanted
to
by
overriding
the
image
name,
but
the
default
behavior
for
that
version
of
that
installation
would
be
whatever
the
major
version
was
pinned
at
right
and
so
we're
not
okay.
Okay,
let's.
A
C
Far
right
as
you
go,
that
is
that's
what
you're
pinning
to,
and
so
the
obligation
to
the
analyzers
is
to
make
sure
that
you
have
a
image
that
is
tagged
to
the
major
so
anytime,
a
new
version
of
2x
X
comes
out.
It
has
to
also
upgrade
or
create
a
tag
for
two
so
that
we
can
pull
that
him
to
give
a
browse
and.
A
C
Major
minors
for
area
lasers
and
so
that
people,
because
the
major
minor,
gives
you
the
ability
to
receive
new
features
without
breaking
changes,
and
so
there
Mike
I'm
guessing
the
rationale
behind
also
wanting
to
pin
that
is
so.
Customers
have
the
ability
to
opt
in
to
that
specific
new
addition
in
that
image,
because
today
they
don't
have
that
choice.
It's
either
the
latest
major
or
a
specific
bug.
Patch
for
version
is
that
correct,
yeah.
A
That
hasn't
been
how
we've
historically
referred
to
it
in
the
issues
and
that's
one
source
of
why
we
have
three
issues
here:
whether
we
need
to
have
that
conversation
like
two
of
these
issues
are
over
a
year
old
before
doctor
and
doctor
deprecation,
and
things
like
that.
I
think
that
with
our
password
right
now,
it
doesn't
really
matter
but
I
think
that's
something
that
we
should
all
be
on
the
same
page
of
for
this
conversation.
I
think
that.
D
Had
a
good
question
on
the
versioning,
so
if
you
have
a
version
of
a
doctor
image,
it's
version
two
without
any
minor
version
on
there
or
patch,
and
then
you
overwrite
that
image
will
the
will
doctor
cash,
the
previous
version
or
how
does
caching
work
because
it's
looking
at
the
exact?
Does
it
look
at
the
fingerprint
or
does
it
we'll
get
a
version
number,
because
it's
one
concern
I
have
about
just
linking
to
version
two
yeah
I
think
that's.
D
C
Okay,
go
ahead,
pull
policy,
so
it
might
be
dependent
on
the
way
the
gate
lab
runners
are
run.
If
they're
ephemeral,
then
they
won't
have
a
cache.
They'll
have
to
pull
the
latest.
If
they
are.
You
know
long
running
on
an
instance
then
well
I,
guess
like
as
Lucas
mentioned,
we'll
have
to
double-check
the
poll
policies
that
they
do
get
the
latest
otherwise
you're
right,
Seth
I
think
it
will,
depending
on
the
poll
policy
it
could
default
to
whatever
was
in
the
local
cache,
because
it'll
satisfy
the
constraint.
Okay,.
C
A
Was
a
big
source
of
the
air-gap
discussion
around
should
pull
the
bus
policy,
be,
if
not
present,
or
should
it
be
always
wear
for
a
air-gap
instance.
The
thinking
was,
if
not
present
meant
don't
reach
outside
the
system
to
pull
new
images
because
which
should
be
air
gaps,
but
we
decided
it
should
be
always
because
we
always
want
to
be
pulling
images
from
the
latest
get
from
the
gitlab
instance
to
ensure
they're
up
to
dates.
Whenever
someone
pushes
a
new
version
of
the
tag,
yeah.
C
How
are
we
recommending
people
configure
their
pull
policies
today?
Is
that
something
that
we
provide
in
documentation,
or
is
there
some
sort
of
configuration
or
settings
that
they
can
set?
This
is
a
question
for
the
audience.
I
know.
Lucas
has
been
answering
everything,
but
I'm
googling
it,
but
someone
else
can
answer
if
they
know
okay,
so
that's
maybe
something
to.
E
A
F
A
C
Different
analyzer
tools
need
to
start
producing
images
with
the
appropriate
tags
that
we
can
move
to
this
scheme
and
I'm
quite
sure
we're
not
doing
that
in
license
compliance
yet
or
the
license
scanning
image.
So
we
may
have
to
do
that.
There
I
see
Dayton
as
and
you
don't
publish
just
a
two
or
three
yes,
I'm,
quite
sure
that
is
the
case,
but
that
is
a
solvable
problem.
C
We'll
just
have
to
make
sure
that
it's
there
so
that
when
we
do
start
updating
this
job
templates,
we
do
have
the
appropriate
images
and
I
don't
know
if
we
need
to
retro
actively
create
the
older
missing
tags
like
for
the
one
and
everything
else
before
this
dish
isn't
going
forward
or
if
we
can
leave
it.
As
is
we
can't
really
change
the
templates,
at
least
not
that
I
know.
E
C
At
it,
I
see
just
major
latest
and
then
each
of
the
stable
tags
so
yeah
we
don't
have
a
major
minor
patch
tag,
but
it
looks
pretty
to
reveal
to
add
so
we
do
have
major.
So
then
is
this
has
been
done
for
all
the
tooling
like
it
sounds
like
the
tooling
might
be
already
ready
to
go.
It's
now
just
a
matter
of
updating
the
job
template
and
we're
hesitant
to
do
that,
because.
A
A
The
next
one
is
the
one
that
were
ok,
so
so
I
these
ABC
under
point.
One
is
the
three
issues
we're
talking
about
the
first
one
is
the
easy
one
replaced
with
two.
The
second
one,
I
think
should
be
straightforward,
but
it
just
requires
a
little
bit
more
discussion,
which
is
pin
to
the
minor
version
within
templates,
so
that
provides
people
the
same
behavior
of
like
slightly
more
stability
and
that
one,
the
question
I
heard
Fabien
was
whether
or
not
we
wanted
to
why
he
thought.
We
should
do
that.
A
B
A
B
C
B
C
And
I
think
that's
what
I'm
getting
at
like
does
this
decision
need
to
be?
Do
we
need
consensus
across
everybody
before
any
action
can
start
or
let's
say,
if
you're
already
ready
to
go
in
SAS?
Is
it
okay
for
you
to
start
moving
forward
on
the
templates
without
getting
answers?
I
think
we
had
this.
We
started
to
have
this
conversation
because
we
were
stuck
on
making
a
decision
and
I'm
trying
to
like
be
couple
that
decision
from.
A
Action
I
think
that
this
is
a
good
use
case
for
the
distinction
issues
and
he'll
ours.
It's
a
fairly
trivial
code,
change
that
I'm
happy
to
bump
all
the
templates
to
major
versions.
Indistinct
merger
quest
by
which
we
can
bring
the
subject
matter,
experts
into
those
discussions
for
that
specific
piece
of
code,
so
I
think
the
units
of
work
can
be
reviewed
separately
by
the
people
who
know
what
they're
doing
but
I
don't
see
a
reason
to
break
this
into
distinct
issues
for
separate
discussion.
Oh.
C
B
B
B
C
B
B
That
the
update
frequency
of
of
people
running
get
lab
is
very
infrequent
they're,
not
keeping
up
with
a
monthly
update
cycle
of
this
tooling
and
so
as
such.
If
we
pin
to
miner
now,
then
we
are
sued
than
we
are
effectively
pinning
every
customer.
We
have
to
a
specific
release
of
every
tool
that
we
have,
because
the
pinning
is
done
in
a
vendor
template
within
the
gitlab
repository
itself
without
without
mom,
so
there.
A
I
feel
like
it's,
the
mr.
senior
I
feel
like
it's
the
opposite,
where,
by
pinning
to
miner,
we
are
providing
more
stable
configurations.
So,
if
we
pin
to
a
minor
version,
then
a
customer
who
has
not
upgrade
to
30,
no
will
not
there.
Their
code
won't
change
and
there
the
analyzers
won't
change.
I
agree.
B
With
that
wholeheartedly
and
I
think
that's
where
we
need
to
get
to
the
issue
that
we're
going
to
run
into
is
that
there
is
a
there
is
a
lifespan
of
how
useful
these
tool
is.
Tooling
is
with
the
with
the
detection
rules
that
are
shipped
with
them.
We
need
to
externalize
the
rules,
and
once
we
do
that,
then
we
were
providing
a
mechanism
for
new
detection
without
revving
the.
B
B
C
In
a
place,
I
can
play
in
them,
so
we
keep
the
same
engine,
but
you
have
ability
to
fill
it
with
gas
outside
of
the
engine
without
having
the
drop
of
the
new
injured,
meaning
the
gasoline
being
the
detection
rules
that
we
were
saying
and
the
engine
being
the
actual
analyzer
and
how
it
operates.
Okay,
yeah
I
have
to
ask:
why
would
we
like,
when
you,
when
we
say,
pin
to
a
another
way?
Okay,
when
we
describe
pinning
the
way
I
interpret?
That
is
like
we're
pinning
to
a
very
specific
version
in
the
job
template.
C
So
this
discussion
says
that
we
agree
on
pinning
to
a
major
version
which
means
that
any
minor
or
patch
versions
that
are
happened
to
be
the
latest
in
that
major
is
what
you'll
get
is
a
major.
Now
when
we
say
pinning
to
minor,
are
we
talking
about
pinning
to
a
specific
patch
version
in
the
job
template?
Is
that
what's
being
discussed
here,
because
it
would
be
we're
pinning
to
the
minor.
B
D
B
C
B
A
An
alternative
proposal
in
point
five
that
we
could
explore,
which
is
we
pinned
a
minor
and
we
introduced
something
like
like
a
variable
that
is
essentially
keep
hot
updating
our
code,
so
we're
providing
a
more
user
configurable
option
to
pin
diviner
the
problem.
Is
that
like,
if
we're
not,
if
we're
deferring
the
work
of
pinning
to
miner
I,
think
that
we're
deferring
stability
for
our
customers
at
present
focus.
C
But
I
just
published
a
new
version,
major
3,
which
then
went,
and
you
know,
updated
12
1
12
to
12
3,
which
I
haven't
spun
out
the
12
1
12
to
image
to
make
sure
it's
working.
We
have
a
good
set
of
unit
tests
and
integration
tests,
but
I
would
argue
by
pinches
even
moving
from
like
12
X,
stable
major
adds
value
and
then
from
there
we
can
see
if
we
need
to
add
more
value,
because
I
think
the
use
case
you're
talking
about
it's
like
almost
like
it's.
C
A
Minor
I
think
license
met
compliance
or
management
or
scanning
I
I'm.
Sorry,
I,
don't
remember
what
that
one's
called
that
one
is
me
is
the
only
security
product.
We
have
right
now,
where
major
matters
currently
major
doesn't
matter
at
all
for
sassed
or
dependency
scanning.
Both
just
rely
on
for
the
major,
so
there's
absolutely
no
difference
there
so
pinning
to
to
is
exactly
a
stable
as
XY
stable
right
now
and
they're,
both
just
constantly
rechecked.
A
The
likelihood
of
us
bumping
that
past
2
to
3
at
some
point,
I'm,
not
sure
but
like
I,
completely
agree
that
externalize
the
rules
would
be
really
helpful.
I
just
I
can't
imagine
doing
that
greater
than
maybe
14.
Oh,
maybe
12
5,
like
that's
a
significant
amount
of
work.
That
would
either
require
a
generic
SAS
engine
for
all
of
our
analyzers
or
significant
changes.
Every
single
one,
so
I'm
just
wondering
if
we're
deferring
it
in
favor
of
a
direction.
I,
don't
know
where
what
okay
the
time.
A
D
B
I'm
sorry
I
know
we're
off
script.
No
great!
Here's
here's
my
question
and
how
are
we
deferring
work
by
declaring
which
major
version
of
every
analyser
we're
using
within
a
vendor
template
today?
If
the
path
forward
to
penned
a
minor
is
to
simply
declaratively
do
so
with
the
Bert,
with
the
with
the
configuration
options
we
would
be
exposing
and
this
work
today.
A
With
this
I,
so
so
we
do
not
I
do
not
think
that
in
twelve
ten
we
should
be
doing.
We
should
be
releasing
individual
variable
configurations
per
analyzer
version.
That's
something
that
we're
discussing
in
10
to
90,
so
I
would
not
consider
that
to
be
part
of
the
work
there.
I
don't
know.
Sas
image
tag
I
think
is
the
variable
that
we
currently
pin
to,
which
is
not
documented.
So
we
just
dropped
that
in
favor
of
two,
because
it's
not
documented
later
the
idea
is.
A
All
of
this
is
pretty
poorly
worded,
because
we
we
use
the
word
stable
when
we
shouldn't
and
thanks
yeah,
so
I
think
that
we
should
we
replace
all
of
the
variables
in
our
templates
that
are
all
undocumented.
As
far
as
I'm
aware,
with
the
number
two,
so
we
pin
everything
to,
except
for
license
management
and
whatever
the
deal
is
with
gust.
That's
that's
one
we're
removing
a
ton
of
there
area
below
that
we
provide
for
configuration
that
are
undocumented.
As
far
as
you
know,
no
one
is
using
those
step.
A
Two
is
to
pin
to
the
major
versions
in
all
the
templates
and
that's
simply
replacing
the
two
with
two
point
one
and
we
have
to
release
those
docker
tags.
If
a
customer
wants
to
configure
that
or
override
it,
there's
rather
than
introduce
xx
environment
variables
that
map
to
those
values
they
can
just
override
the
image
line,
which
is
effectively
the
same.
It's
just
like
slightly
less
nice
to
being
UI.
B
A
Change,
it
provides
stability
for
all
previous
versions,
but
it's
going
to
hurt
customers
and
if
they
are
on
a
previous
version,
they're
not
going
to
get
the
last
rule
set.
Maybe
that's
a
feature.
Maybe
it's
not
I
think
that
that's
the
biggest
point
of
contention
by
a
proposal
for
fixing
that
problem
is
to
Brian
a
top-level
variable
called
something
like
pin
to
major,
which
could
probably
be
worded
better.
But
that's
going
to
default
to
true
and
that's
going
to
ensure
that
it
will
use
I.
Guess
it
be
pinned
minor,
it
would
use
a
minor
version.
A
B
Me
ask
a
hypothetical
and
see
if
I've
got
your
argument.
Internalized
so
end,
result
of
this
we're
gonna
how
you
the
proposal
is
we're
gonna,
have
one
top-line
variable
you
SAS
as
an
example
SAS
the
image
tag,
2.40
as
an
example
with
pin
to
major
equals
true,
which
means
that
it's
going
to
do
the
same
behavior.
It's
gonna,
look
for
major
version,
two
for
every
single
thing
that
we
have
and
that's
the
end.
That's
the
dozer!
That's
the
version!
That's
how
the
upgrade
password
remains
consistent
and
the
same
behavior
for
customers.
B
A
G
A
B
Okay,
here's
where
I'm
lost
on
that
particular
item,
so,
let's,
okay
as
a
hypothetical,
let's
use
two
dot
one
dot
o
is
where
what
we
have.
The
version
number
in
the
vendor,
template
in
pens
and
minor
equals
false.
If
that
or
pintu
major
equals
false,
so
we're
getting
we're
getting
2.1
of
every
single
analyzer
we
have.
Why
do
we
want
to
couple
the
versioning
scheme
of
all
14,
different
sassed
analyzers
to
that
one
vendor
template
with
that
one
setting
2.1
dot.
A
O
because
2.1
dot
would
not
be
for
everyone,
if
you,
if
you
abandoned
a
2.1
0
and
you
have
brakeman
2.2
dot.
Oh
then
setting
it's
a
false
means
that
each
one
of
them
have
their
specific
minor
version
that
they're
pinned
to
so
we're
pinning
a
minor
within
the
jobs
at
the
template
level,
but
there's
a
top-level
variable
that
is
saying
if
this
is
true
use
the
major
for
each
one
of
these.
Instead,
okay,
that's.
A
B
A
From
and
I
think
a
lot
of
these
issues
deal
with
that
and
say
like
yes,
lint
image
tag
and
I
think
that
I
really
really
don't
want
us
to
have
40
different
in,
like
40
different
environment
variables,
that
we
need
to
manage
and
support
for
each
one,
because
honestly,
I
don't
see
why
customers
would
care
about
these
things.
If
they
actually
need
a
very,
very
specific,
yes
lint
image
version,
then
they
can
just
replace
the
image
line
in
the
job
definition.
A
B
C
B
B
B
A
A
A
And
that's
actually
that's
part
of
the
reason
that
we
should
proceed
with,
pin
minor
versions
obsess
DDS
analyzers.
So
so
my
proposal
was
kind
of
a
stopgap
to
get
there,
but
we
should
be
penny
of
minor
versions
because
it
gives
us
that
granular
control
and
currently
we
cannot
release
a
pre-release
of
any
analyzer
without
shoving
it
on
to
our
customers.
A
Theoretically,
we
should
be
heading
that
the
published
job
the
day
of
the
release,
which
is
essentially
what
we
do
with
the
SAS
or
with
the
release
process
from
the
orchestra,
but
it
doesn't
really
necessarily
work
out
for
the
and
layers
themselves.
No,
but
if
we
pinned
to
the
minor
version
we
actually
can't
handle
that
scenario,
so
I
think
that
we
need
to
do
10
to
90
to
get
there.
A
B
A
B
The
objection
that
will
keep
coming
up
on
as
the
upgrade
cycle
of
our
customers
on
self-managed
civically
is
that
it's
too
infrequent
you're
looking
at
it
probably
an
annual
release,
update
cycle
as
opposed
to
monthly.
That's
the
that's.
The
objection
that's
hard
to
overcome
without
that
new
capability
at
least
I
haven't
found
a
way
to
overcome
it
without
it.
If
you
and
I
would
love
to
hear
all
turn
cuz,
that's
not
an
easy
bit
of
work.
A
B
A
Think
that
I
mean
the
big
point
being
whether
or
not
hosted
offerings
differ
significantly,
namely
Gilad
calm
and
how
that
affects
a
release
cycle.
Okay,
so
sorry,
we
do
not
need
no,
oh
good
I'm
just
trying
to
go
over
these
notes
to
make
sure
that
everything
we
need
to
cover
is
covered
orthogonal
to
darker
and
darker
I'm,
not
sure
that
this
I
think
that
the
only
reason
way
that
this
is
related
to
that
in
this
case
is
whether
we're
talking
about
analyze,
our
tooling
versus
analyzers
or
security
product
versus
analyzers
I.
A
C
Know
that's
what
you
think
yeah,
because
I
don't
have
the
same
context
as
you
I
think
I'm,
realizing
that
through
this
conversation,
especially
with
amongst
the
other
tooling
I'm
I'm
comfortable
moving
forward
on
major,
because
I
think
that
I
have
an
understanding
of
what
that
means.
But
it's
hard
for
me
to
commit
to
something
I,
don't
fully
understand
yeah,
so
in
terms
of
moving
towards
major
I.
Do
think
that's
an
advantaged
from
where
we
are
today.
It
allows
us
to
continue
grow
so
I'd
like
to
help
support
that
for
minor
I.
C
A
A
C
G
C
B
There
is,
but
not
within
the
analyzer
itself,
in
the
integration
to
legacy
versions
of
kit
lab
that
you
are
now
providing
a
new
version
of
the
analyzer
okay,
integrating
against
so
by
your
own
admission,
yummy
and
everybody's
admission,
the
verification
step
for
release
of
the
new
analyzers
against
current
one
kid
lab
calm,
it's
not
against
12.0
or
12.1
and
so
forth.
There's.
A
E
A
A
A
A
C
A
C
A
C
Is
like
it
seems
like
there's
a
bit
of
urgency
now
for
this,
which
is
a
little
uncomfortable,
because
there's
all
these
things
with
offline
air
gap
stuff
happening
at
the
same
time,
so
I'm
happy
to
help
contribute
to
make
this
go
because
it
seems
like
it's
important.
It's
going
to.
You
know
help
our
customers
we've
been
working
on
this
for
a
long
time.
C
A
A
License
management
is
actually
the
one
thing
that's
worth
calling
out
here
where,
when
we
pin
to
my
major
now
we're
going
to
update
the
license
management
template
to
pin
to
the
number
three,
that
means
that
we
are
breaking
the
behavior
currently
with
the
release
of
twelve
ten,
because
previously
twelve
nine
twelve
nine
instances
would
not
be
pulling
on
the
latest
license
management
version
of
it
after
this.
So
we're
we're
not
back
reporting
for
license
management
specifically
because
there
is
actually
breaking
like
a
major
version
bump,
but
all
the
rest
and
be
hey.
C
And
then
the
impact
going
forward
is
when
we
release
a
new
version.
We
have
to
stop
releasing
new
versions
of
the
old
images,
so
stop
retaking
the
old,
twelve
X,
whatever
images
so
there's
a
bit
of
work
to
be
done,
they're
still
in
the
pipeline,
because
we
want
to
be
able
to
release
a
new
version
and
stop
updating
the
old
images.
So
that
changes
how
we
sorry.
What.
B
A
C
A
A
A
Don't
want
to
have
three
separate
issues:
2:07
one
to
eight
is
fine,
that's
isolated.
It
has
its
well
described
in
minor
version
which
is
10
to
90,
that
one
I
think
that
we
can
continue
having
the
conversations
that
we
need
to
at
that
issue,
and
then
9
7
2
5
is
more
epic
like
and
972
5
has
enough
conversation
I,
don't
really
want
to
keep
it
around
so
I'm
trying
to
figure
out
if
there's
any
tasks
in
that
one,
that
we
need
to
break
out
or
just
close
out
so
I'm.
A
Updated
the
vendor
templates
to
use
major
Meyer
tag.
Instead,
that's
gonna
be
covered
in
the
pin
minor
version
issue
up
to
release
process.
Documentation
is
kind
of
covering
both
I'm
trying
to
figure
out.
If
that
last
supergroup
is
there
anything.
Is
there
any
reason
we
need
975,
open,
I,
think
it
lady
is
saying
we
should
closed
out,
so
I
think
I.
Don't
think
he
thinks
so.
B
A
A
B
Yeah,
if
we
do,
if
we
get
to
those
points,
then
yeah
I
think
we're
good
to
kill
this
one
with
fire
cool.
Ok,
the
bias
of
action
I
am
I,
am
Gary.
I
am
almost
guaranteeing
that
there
is
going
to
be
dissent
about
closing
this
out.
But
you
know
if
we've
captured
the
work
that
needs
to
occur
and
we're
setting
ourselves
up,
for
we
don't
we're
giving
ourselves
the
flexibility
we
need
for
tomorrow,
even
if
we're
not
Dave,
but
we're
doing
it
a
different
way.
B
A
B
A
The
only
point
of
the
only
way
I
would
consider
disagreeing
is,
if
that,
should
it
almost
feels
like
a
separate
unit
of
work
where
it
would
essentially
be
contributing
towards
the
vision,
opinions,
a
minor
boat
without
having
a
pin
tube
minor
one?
Oh
I,
guess
it
would
be
because
because
we,
the
prerequisite
work
would
be
penny
two
minor
with
us.
So
yeah
all
right,
I'll
just
leave
a
note
on
10
to
90
values.
Okay,.
B
A
I'll
start
cleaning
up
these
issue,
descriptions,
yay,
okay
and
are
ya
blocked.
Yes,
I!
Don't
think
that
there
is
207
1
to
8,
it's
going
to
be
really
quick.
So
that's
that's
fine
and
then
I
think
the
other
thing
that
is
a
completely
separate
conversations,
I'm
gonna
turn
my
attention
back
to
rules
exists
and
what
we're
doing
over
there,
which
we
need
to
talk
about
next
word
34
in
two
weeks.
B
Yeah
and
there
might
need
to
be
a
conversation
between
you,
Zack
and
myself-
on
rules
exists
and
also
detect
by
file
type,
because
I
started
realizing
the
mess
as
well.
So
what's
on
the
board
behind
me,
so
if
it
is
so
pay
no
attention
to
the
what's
behind
the
curtain,
so
they're
color
coded
the
green
is
darker
and
darker
removal.
I
was
trying
to
get
all
of
the
issues
that
were
spread
out
everywhere
and.
B
A
I
think
that
that's
basically
my
understand
for
composition.
Analysis
is
that's
just
entirely
fabien
right
now
it
sounds
like
he
was
essentially
tasked
with
figure
out
how
all
this
works
together,
which
in
I
think
in
his
opinion,
documentation
and
the
rules
exist.
Just
came
out
of
kind
of
left
field
because
we
had
that
issue
that
I
got
assigned,
but
it
became
apparent
that
that's
more
relevant
globally,
but
I
think
that
he's
on
board
with
that
too,
okay
yeah.