►
From YouTube: Infra and Applied ML discussion
Description
https://gitlab.com/groups/gitlab-org/-/epics/5794#note_592129663
Discuss Applied ML reviewer/maintainer assignment architectual plan and PoC with the infrastructure team
A
A
So
we
had
some
pre-read
in
the
document.
I
think
is
it
worth?
I
don't
know
if
everybody
had
a
chance
to
go
through,
is
it
worth
doing
a
quick
overview
of
the
components
of
unreview
and
milestone
one,
or
should
we
just
skip
to
the
discussion
of
the
questions
happy
to
do
it
happy
to
do
an
overview
if
everybody,
if
anybody
would
like.
A
Okay,
awesome,
so
the
if
you
look
at
the
epic
it
is
linked
in
the
doc
epic
5794,
and
that
picture
that
I
linked
to
the
direct
comment
is
I'll
turn
it
over
to
alexander
and
others.
To
do
more
is
milestone.
One
is
a
proof
of
concept.
It
is
not
integrated
into
the
gitlab
product.
It's
a
proof
of
concept
to
use
on
review
on
the
gitlab
product
itself,
so
we
can
dog
food
it
ourselves
and
when
doing
that,
you
know
there's
a
number
of
components
that
are
part
of
unreviewed
today.
A
The
data
we
need,
probably
through
graphql,
then
run
it
in
this
separate
instance,
and
then
then
so
we
can
do
recommendations
via
applied
machine
learning
of
maintainers
and
reviewers
and
then
pass
that
back
to
the
product
either
where
it's
displayed
in
under
view
itself
or
perhaps
in
the
product
as
comments
or
something
like
that,
so
that
git
lab
team
members
can
use
it
and
dog
food
it
ourselves
as
we
develop
gitlab,
not
customer
used
yet,
and
that
is
the
initial
idea
alexander.
What
part
of
that
and
taylor
and
others?
A
C
A
B
C
Understood
so
I
think
during
the
first
milestone,
we
just
need
to
find
some
equivalents
on
the
google
cloud
platform
because
I
used
to
azure
to
build
some
components.
So
we
need
to
find
some
some
other
tools
just
to
replace
during
the
first.
As
long
as
unreview
uses
the
the
api
of
gitlab.
So
I
think
we
just
need
to
find
how
to
replicate
like,
for
instance,
kafka
or
azure
data
factory,
and
and
that's
all
for
the
first
milestone.
As
I
see.
A
Yeah
is
that
so
it
seems
like
you
know,
there's
a
number
of
open
source
components
in
unreviewed,
so
there's
kafka,
there's
hive,
there's
mongodb
and
they're
all
just
general,
open
general
open
source
things
that
we'd
want
to
implement
in
gcp.
Just
just
for
this
proof
of
concept.
Adf,
the
you
know
is
your
data.
A
A
So
we'll
need
to
find
a
replay.
I
think
the
only
thing
we're
going
to
have
to
find
a
replacement
for
for
the
proof
of
concept
is
adf,
the
others
hive
and
kafka.
We
should
be
able
to
implement
ourselves,
but
by
we
I
mean
the
development
team
should
be
able
to
implement
at
gcp.
If
we're
given
by
infrastructure
the
the
kind
of
the
space
to
do
that
and
separate
from
you
know
the
rest
of
the
product.
D
Yeah
so
question
there
and
take
the
opportunity
to
say:
welcome
alexander,
it's
great
great
to
have
you
and
great
to
have
this
as
a
part
of
our
our
future
part
of
the
product.
So
that's
awesome,
so
wayne
you
were
saying
milestone
is
as
a
poc.
I
just
want
to
kind
of
understand
like,
and
I
think
I
I
got
it
from
something
you're
mentioning
there.
D
It
is
one
difference,
there's
probably
many
differences,
but
there's
one
difference
in
thinking
about
this
is
a
poc
versus,
like
the
you
know,
initial
nbc
of
a
of
a
feature,
the
intent
that
it
it's
not
going
to
be
share.
It
basically
available
to
customers
for
use
it'll
only
be
used
by
git
lab
is
that
is
that
part
of
it?
Or
am
I
thinking
about
that
wrong?.
D
A
Yes,
and
so
milestone
two
is,
I
remember,
is:
is
the
beginning
of
customer
use
or
have
the
ability
with
actually
is
that,
let
me
make
sure
that's
accurate.
I
have
the
milestones
linked
to
each
other,
so
milestone
two,
which
is
two
months
after
milestone.
One
is
customer
facing
mvc
integration,
so
milestone
two
is
which
is
linked
to
my
to
the
that
first,
epic
and
second
epic
is
customer
facing
for
com
customers
only
not
for
self-hosted
and
mvc,
some
minimum
viable
change,
and
you
know
controlled
by
a
feature
flag.
A
Two
is
dot
com,
customers
only
and
probably
a
relatively
small
number
to
start
ourselves.
Dog
booting
it,
but
also
we
haven't
talked
through
this.
But
definitely
not
you
know
roll
it
to
one
customer
on
day
one
and
then
you
know
100
on
you
know
day
10.
It
would
be,
I
think,
it'd
be
a
slow
roll
out.
We
haven't
worked
those
details
out
yet,
but
it
wouldn't
be
a
fast
pull
out,
because
also
machine
learning
workload
takes
up
a
lot
of
cpu
power,
of
course.
E
B
Yeah,
I
just
wanted
to
recommend
an
approach
that
we
take
from
milestone
one
and
that
similar
to
what
we've
done
for
other
teams,
where
we've
set
them
up
with
a
an
isolated
gcp
project
where
they
have
full
access.
We're
doing
this
for
sharding
a
couple
other
efforts.
So
my
suggestion
here
for
milestone
one
is
we
do
the
same,
but
then
also
figure
out
a
time
when
it
makes
sense
to
begin
in
a
readiness
review
and
just
from
a
high
level.
Readiness
review
allows
us
to
start
having
for,
for
an
alexander,
welcome
for
alexander's
benefit.
B
Here.
Irenaeus
review
allows
us
to
start
having
a
an
asynchronous
slash,
synchronous
discussion
about
like
architecture,
thoughts
and
stuff,
and
things
like
that,
so
that
we
can
get
prepared
as
we
get
a
bit
as
we
get
into
progressive
milestones,
and
we
start
to
incorporate
more
and
more
things
and
and
align,
because
one
of
the
big
things
that
we
need
to
do
from
the
infrastructure
side
from
delivery
also
within
reliability,
is
get
ready
for
like
how
we
deliver
this
and
get
it
to
production.
A
A
So,
there's
one
of
the
tasks
in
milestone.
One
is
to
do
that
evaluation
of
what
you
know
we
have
these.
Various
components
like
with
mongodb,
which
is
a
great
document
store
you
know,
is
that
we
want
to
make
that
part
of
the
gitlab
architecture,
or
do
we
want
to
use
something
that
exists
today,
like
the
postgres.
A
Maybe
it
is
maybe
different,
you
know
and
and
other
than
so
there's
gonna
be
a
lot
of
discussions
there
and
we
definitely
like
your
or
somebody
from
your
team's
input
on
those
as
we
work
to
try
to
make
those
decisions
with
you,
and
I
will
tag
you
brent
in
that
specific
issue
to
make
sure
you're.
If
I
haven't
already
make
sure
you've
seen
it
and
then
you
know,
definitely
get
it
to
your
team
as.
A
C
I'm
just
trying
to
understand
okay
during
the
first
milestone,
we
will
use
the
public
api
like
like
it
has
right
now:
okay,
but
during,
for
example,
during
the
next
milestone,
how
we,
how
are
we
going
to
integrate
so
through
the
public
api
as
now
or
we'll
find
another
solution,
because
there
is
also
another
issue.
For
example,
we
need
to
retrain
the
model,
for
example
each
week
each
day,
so
we
have
to
find
this
interval.
A
It's
a
great
question.
We
often
use.
I
don't
think
we
can
answer
today,
but
it's
definitely
definitely
a
question.
We
need
to
answer
so
we
often
use
the
graphql
api
inside
the
product
itself
with
the
various
apis
to
do
things.
So
we
could
go
directly
to
the
database,
though.
If
we
chose
to
we'd
have
to
maybe
the
graphql
api
doesn't
have
the
features
we
need
to
do
it
at
scale.
Maybe
it
does.
F
My
guess
is
that
using
the
database
directly
would
probably
give
us
the
least
work
required
if
we
want
more
data
than
the
graphql
api
exposes,
I
mean
if
graphql
does
exposes
everything
we
want,
we
can
use
it.
On
the
other
hand,
it
has
limits
like
we're
going
to
be
issuing
hundreds
of
queries
against
it,
because
there
is
a
limit.
How
many
results
can
you
graph
your
api
input
return
so
we'll
be
like
issuing
several
longer
query,
bigger
queries
or
hundreds
of
smaller
graphql
queries
and
also
depends
on
the
data
we
want
from
the
api.
F
D
A
A
C
Yeah
going
back
to
to
graphql,
for
instance,
I
didn't
find
a
way
how
to
identify
is
a
user,
a
bot
or
not,
and
for
instance,
we
have
to
do
that
if
we,
if
we
make
recommendations
because
right
now,
if
we
check,
for
instance,
sometimes
in
the
top
10
recommendations,
we
see
bots
and
I
didn't
find
a
way
how
to
remove
them.
How
field
right
now
so.
A
C
F
F
B
Oh
I'm
like
I
didn't.
I
don't
want
a
solution
here,
but
we
I
did
want
to
mention
that,
based
on
my
previous
experience
in
the
admin
this
weekend,
there
is
no
differentiate
differentiation,
at
least
in
the
admin.
What
surface
there
between
a
bot
or
not-
and
I
don't
want
a
solution
here,
but
my
recommendation
would
be
that
maybe
we
suggest
a
feature
where
bot
users
don't
have
a
password,
they
are
merely
created
and
they
have
api
keys.
So
anyway,
as
a
another
mechanism
to
dylanate
sorry
steve.
D
C
A
A
You
know
be
asked
to
be
a
maintainer
or
reviewer,
so
I
think
the
history
will
show
that
they're
not,
but
that
doesn't
mean,
but
that's
not
the
only
criteria
for
you
know
determining
if
somebody
should
be
maintain
being
maintainer
or
reviewer
of
a
change
is
if
they've
done
one
before
that's,
not
the
only
thing
so
yeah
good
things
to
consider.
I'm
sure
we're
gonna
have
another
20
questions
like
that
of
what
do
we
do
in
this
situation?
What
do
we
do
in
that
situation,
etc?.
F
F
A
I
think
actually
it
might
be
good
to
capture
these
in
an
issue
linked
off
of
milestone.
One
or
two
is
and
then
it'd
be
great,
create
that
issue
and
just
start
putting
you
know,
questions
we
want
to
answer.
It
can
be
very
open-ended
and
then
we
can,
you
know,
keep
that
issue
public
as
well,
so
we
get
feedback,
not
only
you
know
this
group
and
other
team
members,
but
the
public
yeah.
What
if
you
could
create
that
issue-
and
these
are
great
things
to
put
in
it.
A
A
B
No,
I
I
mean,
from
my
end,
I'm
satisfied
with
a
deeper
understanding
of
like
what
milestone
one
versus
milestone.
Two
represents
and-
and
I
I
see
a
collaborative
path
forward
on
like
how
we
can
enable,
in
the
similar
fashion
that
we
did
for
like
the
sharding,
poc
and
other
teams
to
have
an
area
to
start
developing
milestone.
One
in.
A
B
D
A
To
do
there
there's
a
lot
there,
that's
for
sure
all
right!
Well,
you
everybody
great
discussion
and
alexander
and
taylor,
and
me
we'll
be
talking
with
our
first
actually
group
meeting
tomorrow,
but
it's
great
to
get
a
head
start
on
that
and
talk
about
the
infrastructure
team
so
have
a
great
day.
Everybody
cheers
bye,
cheers.