►
From YouTube: Feature Flags Deep Dive
Description
Feature Flags Deep Dive
https://about.gitlab.com/direction/release/feature_flags/
B
A
Have
it
being
recorded
dimitri
right
on
time
anything
that
happened
before
the
recording
doesn't
count
so
welcome
to
feature
flags
deep
dive.
The
original
intent
of
this
meeting
was
kind
of
chase,
had
reached
out
to
me
and
asked
to
get
up
to
speed
with
feature
flags,
and
we
thought
a
good
idea
would
be
to
go
through
the
future
flags
direction
page,
but
I
don't
promise
not
to
go
off
queue.
A
So
we
have
here
on
the
call
chase,
who
is
the
engineering
manager
mike
and
dimitri?
Mike
is
the
original
designer
of
feature
flags
and
dimitri
is
taking
over
feature
flags,
and
actually
this
is
really
a
great
opportunity,
because
the
previous
steam
dive
that
we
that
we
had
was
outdated.
So
it's
really
a
good
time
to
to
create
a
new
one
and
and
formulate
a
discussion.
A
The
word
runtime,
where
the
unfinished
features
are
hidden,
so
they
don't
appear
in
the
user
interface.
So
a
really
really
nice
example
of
this
would
be
I'm
a
developer.
I'm
working
on
my
development,
it's
time
to
release
the
code,
but
I
haven't
finished
developing
my
feature,
but
instead
of
like
taking
out
my
entire
development
code
base,
all
I
do
is
turn
on
off
a
feature
flag.
A
So,
in
theory,
if
this
is
an
isolated
feature,
this
doesn't
do
any
harm
to
the
to
anything,
and
I
don't
need
to
do
like
additional
testing
over
anything,
because
because
I
took
code
out
because
we
know
that
bugs
are
introduced
also
when
code
is
introduced,
but
also
when
code
is
taken
out.
So
this
kind
of
gives
you
ease
of
peace
of
mind
if
you're,
a
qa
tester
and
you
tested
a
specific
build
but
there's
a
specific
feature:
that's
not
ready,
just
turn
it
off
and
you're
ready
to
go.
So
it's
not
exposed
to
anyone.
A
A
This
allows
many
small,
incremental
versions
of
software
to
be
delivered
without
the
cost
of
constant
branching
and
merging.
So
we
are
the
progressive
delivery
group
and
the
reason
why
feature
flags
is
developed
by
me
by
this
group
specifically,
is
because
it
ties
into
progressive
delivery
concept.
The
progressive
delivery
concept
means
that
it's
kind
of
on
top
of
after
I
have
a
working
cd
solution.
A
Now
I
want
to
do
like
small
little
deliveries
and
small
little
developments,
and
I
want
to
test
that
everything's
working
properly
on
that
without
needing
these
huge,
you
know,
complete,
builds
to
test
that
everything's
working
properly.
I
can
just
you
know,
develop
something
and
quickly
test
it
so
future
flags,
since
it's
really
easy
to
manage
them
and
turn
them
on
and
off
if
needed
and
even
control
the
amount
of
audience.
A
That's
getting
this
new
feature,
whether
it's
by
percentage
or
by
specific
customer
indication
which
may
be
a
user
id,
it
could
be
some
other
characteristic
like
they're,
a
premium
user
or
they're
in
this
tier
or
maybe
they're,
a
new
user
in
the
system.
Someone
that's
under
30
days
and
you
want
to
you
know,
guide
them
in
some
way
or
maybe
expose
specific
features
for
beginners.
A
Okay
again,
the
ultimate
goal
is
to
provide
an
easy
way
to
configure
and
monitor
future
flags
that
integrate
in
the
continuous
development
life
cycle.
So,
as
git
lab
is
a
single
tool
for
the
entire
devops
tool
chain.
The
idea
that
we
have
visual
ties
from
feature
flags
to
ongoing
issues,
merge,
requests
and
helping.
You
understand
the
state
of
everything
with
a
comprehensive
dashboard
that
a
lot
will
allow
developers
to
take
action
if
necessary
is
like
the
key
go
of
where
we
want
to
go
at
the
end
of
the
day.
A
A
A
How
who
is
exposed
to
this
new
feature
so
like
really
making
it
super
easy
to
understand
what
is
going
on
there
and
then
the
last
sentence
is
to
allow
developers
to
take
action
when
necessary
in
order
to
minimize
risk
and
technical
debt
is
future
flags
adds
some
complexity
of
the
code.
It
does
add
technical
debt
to
your
code,
because
you
have
this
thing
that
you're
experimenting
with
enabling
a
feature
and
then,
at
the
end
of
the
day,
when
everything's
working
properly,
you
don't
really
need
a
flag.
A
You
can,
in
theory,
expose
it
to
all
the
users.
There
may
be
feature
flags
that
you
want
to
live
forever
and
we'll
talk
about
that
soon,
but
in
general,
we're
talking
about
a
use
case
where
you're
trying
out
something-
and
you
want
to
gain
confidence
and
slowly
introduce
this
feature
to
more
users
until
you
finally
hit
100.
B
A
D
C
A
Yeah,
definitely
it's
a
very
good
call
out
from
from
both
jason
mike
yeah.
So
when
we
started
exploring
future
flags,
we
decided
on
an
open
source
solution
called
unleash
and
the
reason
that
we
did.
That
was
because
it
supports
it's
multi-language
support.
It
doesn't
support
everything,
but
it
supports
a
wide
range
of
solutions
and-
and
we
I
love
open
source.
So
if
we
look
at
the
languages
supported.
A
A
A
Another
interesting
thing
to
note
is
that
unleash
recently
announced
that
they
are
setting
up
a
hosted
option
so
there's
so
there
still
is
the
open
source
offering,
but
for
enterprises
they're
offering
to
manage
as
the
server
all
the
feature
flags
and
and
that's
something
that
is
very
interesting
for
us.
While
we,
you
know.
D
A
A
C
A
Kind
of
solving
the
majority
of
the
use
cases
we're
not
there
yet
and
then
at
the
end,
we
have
lovable
as
a
maturity,
so
we're
currently
viable
and
we're
working
really
hard
to
get
to
a
solution
that
covers
more
use
cases,
but
one
that
we
mentioned
now
is
you
know
we
don't
support
all
languages.
That's
like
one
gap
that
we
have
there's
additional
gaps
that
we
have
from
competitors.
A
D
A
A
So
this
is
right
for
13.2
and
I
will
update
this
after
13.2.
So,
let's
see
in
13.2,
we
are
working
on
feedback
that
we
received
on
the
new
version
of
feature
flags,
because
you
know
we
first
dog
food
everything
we
got
a
bunch
of
feedback
from
internal
customers
and
we
want
to
make
them
happy
so
that
everyone
is
happy.
So
we
worked
on.
You
know
there
was
some
problems
with
deleting
featureflex,
for
example,
wasn't
very
consistent
and
things
like
that,
so
everything
there's
an
epic
that
I
opened.
C
A
A
And
let
me
get
it
don't
mind
me
of
the
way
that
I'm
looking,
but
I'm
gonna
go
from
a
planning
issue,
because
we
just
talked
about
that.
So
this
is
the
gap
display
strategy,
information
on
feature,
flag
list
view
and
what
we
can
see
here.
This
is
the
way
that
the
old
ui
looks.
So
you
can
see
that
for
old
feature
flags.
You
can
see
the
environment
specs
here,
including
the
strategy.
That's
that's,
joined.
D
A
Them
so
you
can
see
that,
for
example,
in
the
testing
environment,
this
flag
is
enabled
for
50
and
on
production
15,
but
for
the
new
flags
that
are
created,
there's
no
data.
Okay.
So
it's
hard
to
understand.
What's
going
on,
you
have
the
data
in
the
edit,
but
it's
really
inconvenient
and
this
just
adjusts
the
way
that
it
looks
so
we're
adding
this
data.
That
gives
you
all
the
information
on
the
flag.
A
A
A
A
So
we
would,
I
we
would
theoretically
just
create
one
list
called
future
flags
d
dive
that
contains
the
list
of
of
all
of
us
and
if
we
needed
to
modify
them,
you
only
do
it
from
that
list
from
one
spot
and
you
don't
need
to.
You
know:
go
every
single
flag
and
and
and
redo
them,
so
managing
it
from
one
location.
A
A
So
if
we
open
the
issue-
oh,
I
didn't
mean
to
open
it
up
on
the
same
page,
but
no
worries.
This
is
an
extension
of
our
current
percent
rollout.
So
we
already
support
percent
rollout,
which
means
that
you
can
decide
to
expose
your
feature
to
50
of
your
of
your
users
on
production,
okay,
and
what
what
is
confusing
about
that
is
that
you.
A
A
So
in
order
to
to
commit
to
consistent
behavior,
we
now
allow
the
users
to
choose
their
stickiness
based
on
either
the
user
id
the
session
id
or
random,
which
means
you
don't
care
just
50
of
the
population,
whatever,
which
means
that
if
you
refresh
your
button
several
times,
you'll
see
different
behaviors
if
it's
random
at
the
moment,
the
percent
rollout
goes
by
user
id.
If
I'm
not
mistaken,
which
means
the
user
needs
to
be
logged
in
anonymous
users,
there's
no
commitment
into
having
any
stickiness
whatsoever.
A
A
A
The
maturity
plan
is
it's
kind
of
the
list
of
the
most
important
issues
that
I
think
will
bring
us
to
the
next
maturity
level
of
complete
okay.
I
I'm
extending
an
invitation
for
you
to
comment
or-
or
even
you
know,
make
changes
to
this
page.
If
you
think
there
are
important
issues
that
I
had
forgotten
to
add
here
or
if
you
want
to
create
new
ones
or
request
two
ones,
then
then
please
go
ahead
and
do
that
so
so
what
do
we
have
here?
A
So
I
have
been
maintaining
this
page
for
a
year
or
so
so
I
kind
of
make
it
a
point
of
also
adding
the
complete
once
we
deliver
an
issue
just
to
see
how
how
we're
progressing
in
the
maturity
plan,
not
all
the
teams
do
that.
This
is
just
my
way
of
doing
it,
so
in
case
you
saw
other
direction
pages.
It's
not
something
required
from
the
handbook.
It's
just
something
that
I
like
to
do
so.
The
key
deliverables
were
adding
percent
rollout
and
user
id,
which
we
did
multiple
strategies
for
feature.
A
Flags
is
what
we
delivered
in
13.
feature:
flag,
gradual
rollout
based
on
lists,
which
I
just
mentioned.
What
it
is
we
just
delivered
and
now
we're
we're
completing
it,
with,
with
added
support
in
the
ui,
add
ability
to
associate
future
flags
with
contextual
issue,
epic
and
mr,
so
we
have
a
different
issue
for
each
one
of
these.
A
If
it's,
you
know
in
the
backlog,
if
it's
targeted
to
a
milestone,
if
it's
closed,
if
it's
open
things
like
that
and
then
connecting
it
also
from
the
other
side,
so
from
the
issue
list,
we
can
see
all
the
linked
feature
flags.
So
let
me
open
it
up
and
I'm
pretty
sure
that
we
have
a
mock
here.
So
the
idea
is
that
you
know
from
the
issue
itself.
D
A
So
I
don't
have
a
map,
but
the
idea
is,
since
we
have
linked
issues
in
regular
issues,
you
would
have
another
linked
feature
flags
section
very
similar
to
this.
That
will
list
all
the
feature:
flags
that
are
related
to
this
issue,
because
there
may
be
more
than
one.
So,
just
from
every
point
of
view
you
can
see,
what's
going
on,
you
know
holistically
throughout
the
system.
D
B
To
lovable
right,
I
think,
and
is
so
I'm
just
wondering
about
like
percent
completion,
so
if
we
do,
we
complete
all
the
the
the
tasks
here
that
are
outlined
in
this
list.
Does
that
make
us
complete
or
does
that?
How
do
does
that
are
the
two
things
not
associated
like?
This
is
just
a
a
fraction
of
the
list
that
gets
us
to
complete,
or
what
do
you.
A
Think
that's
an
actual,
that's
an
excellent
question,
so
I'm
going
to
answer
and
then
I'm
going
to
move
it
over
to
dimitri
and
mike
to
expand
on
my
answer.
But
if
you
would
have
asked
that
a
few
months
ago,
the
answer
would
be
yes,
we
would
complete
this
issue
list
and
we
would
mark
ourselves
as
complete,
but
we
have
changed
that
and
now
I've
decided
that
our
scorecard
is
based
on
user
research,
which
I'm
going
to
let
them
answer.
E
Yeah,
I
think
mike,
please
feel
free
to
to
add
to
me,
but
I
spoke
this
morning
with
orrit
on
jobs
to
be
done
and
it
kind
of
exactly
kind
of
broadens
this.
This
conversation
a
little
bit
instead
of
like
a
list
of
check
boxes
to
either
it
is
there
or
it
isn't
there
to
all
right
it
isn't
there
it's
there,
but
now
how
good
is
it?
Because
are
we
actually
delivering
value
to
our
users
or
are
we
thinking
we
are
delivering
value
to
our
users?
E
E
A
Okay,
great
okay.
So
that's
about
contextual
connection,
and
this
is
a
really
big
differentiator
that
that
competitors
don't
necessarily
have
so.
We
have
two
two
that
are
mentioned
on
the
direction
page.
One
of
our
biggest
benefits
as
git
lab
being
a
single
tool
is
exactly
this
having
the
ability
to
connect.
You
know
your
entire
devops
cycle,
so
all
the
way
from
plan
where
you're
planning
issues
up
until
the
delivery
you
can
monitor
what's
going
on,
so
it's
a
big
advantage
that
we
have.
A
I'm
not
saying
that
we're
the
only
ones,
but
it
is
an
advantage.
Okay.
Next
we
have
move
features
to
core,
which
is
you
know
our
most
popular
issue
in
future
flags,
and
the
idea
is
to
allow
more
tiers
and
more
users
to
to
use
feature
flags,
and
when
I'm
saying
this,
I'm
go,
I'm
saying
this
a
little
bit
hesitant
because
not
all
the
functionality
of
feature
flags
is
going
to
be
available
for
core
the
basic
functionality.
Everything
that
we
support.
A
Currently,
you
know
configuration
configuring
feature
flags
is
going
to
go
to
core,
but,
for
example,
this
contextual
issue
plan
itself,
I
think,
is
a
higher
tier,
so
that
automatically
makes
it
a
paid
feature
and
not
something
that
we
get
free
and,
for
example,
the
next
section,
which
is
a
b
testing.
We
may
not.
We,
we
have
decided
already
to
deliver
to
higher
tier
dashboarding
capabilities
that
you
know
anything
that's
outside
of
a
single
ic,
that's
using
future
flags
may
go
to
a
higher
tier.
A
E
Yes,
I
can,
I
can
talk
a
little
bit
here.
I
think
this
is
a
whole
category
on
itself,
but
in
order
to
allow
an
organization
to
kind
of
make
experimenting
part
of
their
your
development
process,
ap
testing
is,
is
a
core
part
of
that
and
it
relies
on
feature
flags,
but
it
is
I
I
would
say
it
is
kind
of
a
different
purpose.
Right
where
feature
flags
is
there
to
reduce
risk
and
make
deployment
easier.
D
A
Yeah,
it's
a
very
interesting
opportunity
for
two
reasons:
one
this
targets,
even
new
personas-
that
we
didn't
that's
not
in
our
you
know
natural
space.
Usually
all
our
features
are
dedicated
to
around
devops
engineers
and
developers,
and
this
kind
of
opens
up
a
whole
new
line
of
targeted
personas,
because
also
less
technical
users
may
use
this
and
a
b
test
may
be.
You
know
business
value,
so
maybe
it
would
be
interesting
to
the
sales
team
or
to
a
growth
team
or
to
marketing.
A
A
And
another
really
interesting
thing
is.
This
is
very
very
similar
to
our
thinking
around
post
deployment,
monitoring,
because
basically
you're
deploying
a
feature
to
gradual
to
a
gradual
audience
or
maybe
different
features
to
different
audiences,
and
then
you
need
to
collect
feedback
back
from
those
users
and
take
action
on
it.
So
it
ties
nicely
to
another
theme
that
we're
exploring
and
it
also
connects
us
to
the
monitor
stage
as
well,
so
really
really
interesting
opportunity
and
it's
huge.
A
So
this
specific
epic
is
a
very
general
idea
and
I'm
sure
we're
gonna
make
it
more
specific
and
open
a
bunch
of
issues
related
to
it,
based
on
the
on
the
user
research.
Another
thing
that
I've
been
doing
in
the
direction
page,
which
is
also
really
important
to
note,
is
that
this
used
to
be
this
huge
list
of
items
and
very
slowly.
A
A
Theoretically,
right
now
we're
bought.
We
support
you
know,
tiers,
not
here's
user,
id
and
percent,
but
we
kind
of
want
users
to
use
whatever
they
want.
One
of
the
really
powerful
things
about
feature
flags
is,
since
it's
done
on
an
application
level.
You
can
create
rules
based
on
things
that
are
specific
for
your
application.
A
So
imagine
that
you're
creating
some
kind
of
application
or
website
that
creates
playlists
for
songs,
and
you
decided
to
group
people
by
the
amount
of
playlists
they
have
in
their
amount
of
songs.
They
have
in
the
playlist,
and
you
decided
to
give
a
specific
feature
for
everyone
that
has
100
songs
or
or
more
in
their
playlist.
A
A
A
A
On
the
one
hand,
it's
really
convenient
because
they're
responsible
end
to
end
on
you
know
their
deliverables,
on
the
other
hand,
taking
gitlab
as
an
example.
If
you
speak
to
the
delivery
team,
we
have
about
a
thousand
developers
in
gitlab
each
one
developing
their
own
thing.
Each
one
of
them
sees
their
own
feature,
their
own
deployment
and
the
only
people
who
actually
see
gitlab.com
or
the
delivery
team
where
they
see
all
the
features.
A
So
this
is
like
a
huge
issue
which
deserves
its
own
research
on
how
to
approach
this,
and
I'm
sure
that
the
solution
is
give
granular
permissions
for
the
admin
to
set,
but
exactly
how
that
would
look
like.
I'm
not
sure,
and
the
way
that
we
overcome
this
in
gitlab
is
that
in
gitlab
everyone
has
permissions
for
everything,
including
deploying
a
future
flight
to
production,
but
the
way
that
you
deploy.
This
is
through
chat
ups
and
the
chat
ups
product
project.
D
A
Oh,
I'm
scared
about
that
one.
Okay,
so
there's
really
big
epics
that
I
have
here
that
that
you
can
that
you
can
check.
I
think
I
need
to
change
it
to
generic
and
not
granular,
I'm
not
sure,
but
basically
I
have
different
different
epics
here
that
mike
and
I
had
created
in
the
past,
where
we
grouped
a
bunch
of
different
issues
that
are
related
to
a
specific
topic
like
the
refactoring
that
we
just
did
so.
A
A
A
A
We
try
to
minimize
the
audience
that
is
the
first
responders
of
the
future,
get
feedback
and
based
on
the
feedback,
take
action.
An
action
may
be,
you
know,
continuing
rolling
out
gradually
until
we
hit
100.
If
that's
what
we
want
or
if
we
need
it,
turning
it
off
and
rolling
back
fixing
the
problems
and
then
of
the
rollout.
A
A
I
have
things
to
update,
so
some
of
the
issues
are
consistently
here
because
we
just
haven't
worked
on
them
yet,
but
they're
still,
the
top,
so
we
have
gitlab
serves
as
a
single
application
tool
and
the
customer
success
really
want
to
see
the
association
issues.
So
what
we
discussed
about
tying
into
feature
flags
with
contextual
issues
or
merge,
requests
or
epics,
which
we
have
just
started
like
we
have
just
in
production.
A
The
tough
customer
issue,
not
surprisingly,
is
the
most
popular
issue-
is
to
open
source
feature
flags
which
we
should
be
working
on.
This
quarter
top
internal
customers.
So
this
is
actually
a
really
interesting
one.
Adding
a
web
hook
for
feature
flags
that
will
trigger
a
pipeline
and
slack
notification.
In
case
a
flag
was
toggled,
so
people
really
want
to
know
you
know.
What's
going
on
with
my
flag,
what's
whether
it
was
turned
on
or
off
which
environment
other
things
like
that
really
interesting,
and
we
kind
of
touch
on
this.
A
I
should
definitely
update
this,
so
we
already
have
some
feedback
coming
up
from
from
our
versions
that
we
just
released
in
the
previous
milestone
and
that's
actually
the
feedback
that
we're
working
on
now.
Making
it
really
easy
to
work
with
v2
feature
flags
which
again
support
multiple
strategies
per
flag
per
environment.
B
A
B
It
just
feels
like
the
most
open-ended.
You
create
a
title
for
the
flag,
and
you
put
some
text
here
and
like,
and
we
will
you
know
it's
kind
of
up
to
them.
I
think
a
lot
of
these
things
of
of
you
can
set
that
you
know
feature
flag
based
on
tier
feature,
flag
engine
replies
with
said
tier,
and
it's
up
to
them
this.
B
This
one
feels
to
me
like
it's
super
useful
and
the
most
flexible,
but
the
like
I'm
wondering
how
like,
if
the
unleash
engine
or
anything
else
like
supports
this
or
if
it's
just
something
that
we
will
return
to
the
client,
whatever
whatever
is
consuming
the
feature
flag,
api
and
it's
like,
and
it's
just
up
to
them,
to
figure
out
how
to
to
deal
with.
I
think
it's
different
than
say,
like
user
id
or
something
else
where
there
needs
to
be
some
matchingness
like
geolocation,
some
others.
B
A
You're
spot
on
jason
and
you're
absolutely
right,
so
I
would
split
this
up
into
two
categories.
One.
This
issue
is
huge,
so
it
probably
needs
to
be
split
up
anyway,
but
I
would
split
the
world
into
two
things
that
I
know
based
on
my
application
and
things
that
I
don't
know
right.
So,
like
understanding
geolocation
requires
me
to
know,
you
know
other
kind
of
apis
that
I
need
to
read
from
the
client,
and
the
client
needs
to
give
me
this
information,
so
it
could
be.
A
Type,
it
could
be
an
ip
geo
location
things
that
the
client
needs
to
send
me
me
not
being
gitlab,
but
me
as
the
application
that
is
using
feature
flags
in
order
for
me
to
distinguish
anything
about
it,
and
I
may
already
have
this
data
because
you
know
a
lot
of
websites
they
today,
you
know,
are
compatible
to
mobile
and
they
get.
You
know
some
kind
of
http
response
that
tells
them.
I
am
an
android.
A
I
am
chrome,
I
am
you
know,
so
maybe
they
have
this
information,
and
I
can
leverage
that
information
for
creating
a
rule,
but
the
rule
needs
to
make
sense
for
my
application.
We
have
no
way
as
gitlab
of
validating
you
know
this
group
or
rule
and
making
sure
that
it's
right
user
ids
also
we
have
no
way
to
validate
these
user
ids,
actually
exist,
they're
third-party
user
ids,
so
it's
kind
of
similar.
A
A
But
theoretically
you
could
say
you
know
if
I
already,
if
my
application
already
has
a
database
that
has
all
the
user
ids,
for
example,
in
a
column
of
the
database,
I'm
going
to
use
sql
just
for
for
an
example,
but
it
doesn't
have
to
be
that
that's
my
database
and
I
want
to
know
all
the
users
that
that
have
a
domain
domain
that
that
are
at
gitlab.com,
because
that's
my
user
id
my
identifiers
are
email
addresses.
Okay,
I
could
basically
do
some
kind
of
you
know.
A
E
A
C
D
C
D
A
C
I
mean
they
have
a,
they
have
an
where
you
can
basically
just
write
a
rule
and
then
that
rule
gets
passed
in
and
I
I
think
you
would
have
to
execute
that
rule
on
the
client
side
and
your
client
would
obviously
need
the
appropriate
parameters
to
be
able
to
evaluate
that
rule.
But
it
basically
is
just
like
you.
D
D
C
C
C
A
A
A
B
C
C
I
got
my
way
pretty
good
on
this
one
I
got
I
got.
I
got
most
of
most
of
the
dream
made
its
way
into
the
epics
and
stuff
so
happy
about
that.
I
guess
if
there
was
one
thing
as
you
were
going
through
there
like
moonshotty
kind
of
down
the
road
right
like
once,
we
have
the
concept
of
associating
with
feature
flags
with
issues
and
epics,
and
mrs
I
I
know
it's
very
early
on
in
the
stages
there,
but
maybe
even
requirements
we
have
requirements.
C
A
Oh
yeah
100
I'll,
we'll
I'll
open
up
an
issue
for
that.
That's
a
good
point
and
we
actually
have
another
connection
that
we
made
with
the
release
management
team
that,
on
the
release,
page
itself,
you'll
also
be
able
to
see.
You
know
the
feature
flags
that
are
associated
to
the
release
that
was
released.
So
you
actually
know
what
you
released
with
was
the
flag
on
or
off.