►
From YouTube: Flux investigation decision - follow-ups
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
Another
team,
besides
the
previous
video
I,
would
like
to
share
a
bit
more
details
that
I
think
are
more
interesting
to
to
us.
Primarily.
This
is
how
I
want
us
to
proceed
from
here.
A
At
the
same
time,
today,
again
I've
been
through
all
the
comments
tried
to
close
the
ones
that,
where
my
impression
was,
they
are
really
bad
handled,
or
they
are
just
simple
comments
around
something
was
well
put
or
or
thank
you
message
and
stuff
like
that,
but
I
still
left
quite
a
few.
That
I
think
we
should
keep
on
discussing
how
I
want
us
to
move
forward.
A
I
think
this
first
message
says
it
very
bad
from
Hunter.
This
is
exactly
what
I
plan
to
have
is
that
first,
let's
consider
simply
documenting
how
to
Specs
manually
with
gitlab.
That's
it
nothing
more
and
at
the
same
time,
I'm
going
to
open
a
few
issues
first
and
likely
epics
later
around
the
topics
you
can
see
right
now
on
your
screen.
One
is:
how
do
we
want
to
manage
flux
and
agent
gate
together?
Are
they
managed
together?
Are
they
managed
independently
of
each
other?
A
Do
we
bundle
Agent,
K,
with
flux
or
and
then
try
to
contribute
stats
to
reflux
I
mean
the
installation
of
agent
gate
to
happen
together
with
the
flux
setup,
or
should
it
happen
the
other
way
around
or
any
other
options
there?
The
second
topic
is
access
management
for
flux
through
costs.
This
has
many
layers
in
itself.
A
There
are
plenty
of
comments
related
to
this
in
the
dock,
and
I
do
want
us
to
discuss
this
further.
Actually,
I
mentioned
this
to
audio
as
well
to
as
we
should
try
to
come
up
with
various
Solutions
builds,
testable
prototypes
or
descriptions
of
those
and
and
have
them
validated
with
our
users
as
well,
because
this
is
one
of
the
riskiest
riskiest
options
for
us.
A
A
third
item
is
to
think
about
how
we
can
instrument
the
usage
of
flux.
A
fourth
one
is
how
to
reuse
the
agent
channel
for
flux
to
gitlab
communication.
This
is
related
to
access
management
partially,
but
this
is
really
about
the
that
we
don't
go
through
the
gitlab
front
door,
but
we
go
through
cast
even
to
retrieve
git
repositories
in
the
docs.
A
If,
knowing
that
there
might
be
a
flux,
resources
and
flux
deployments
at
the
cluster,
so
I'm
going
to
create
all
these
issues
and
I
will
prioritize
those,
so
we
can
work
in
them.
Followingly
from
here
on,
I
would
like
to
ask
Nico
to
to
help
us
first
of
all
goes
your
interests
where
you
think
the
most
important
would
be
to
have
a
technical
validation
on
those
these
topics
and,
after
that
too,
to
have
likely
even
to
technical
validation
sessions.
A
Actually,
that's
four
sessions,
the
in
this
milestone
and
basically
I'm
just
asking
you
to
to
start
refining
these
issues.
I
will
prioritize
them,
so
you're
not
expected
to
refine
all
of
them
at
once,
but
we
should
start
this
work
besides
documenting
how
to
use
gitlab
with
flux
with
gitlab
once
again.
I
know
this
was
a
really
controversial
topic
for
all
of
us,
even
though
I'm
not
100,
convinced
that
flux
is
the
right
direction.
A
At
the
same
time,
I'm
not
100,
convinced
that
the
in-house
the
GitHub
solution
would
be
the
right
approach,
primarily
because
of
the
business
risks
that
I
see
there.
The
product
risks
not
the
Tactical
risks
and
I.
Think
very
much
I
think
that
we
will
be
better
off
actually
with
flux,
even
though
it's
not
a
clear-cut
thing
feel
free
to
reach
out
to
me
or
to
Nico
I'm,
definitely
happy
to
discuss
any
of
your
frustrations
and
I
even
understand
your
frustrations.
A
I
think,
let's
keep
an
open
eye
here
and
continue
discussion
in
these
epics.
Please
thank
you
for
all
your
effort,
your
questions
and
everything
and,
as
I
said,
I
don't
want
to
close
all
these
many
comments
here,
because
I
find
them
very
valuable
and
I
think
they
are
they'll,
be
great
inputs.
Even
for
some
of
these
issues
have
a
nice
rest
of
your
day.