►
From YouTube: 2023 05 05 GitLab Plugin Modernization
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
Thing
is
on
welcome
everyone.
This
is
May
the
5th
2023.
It's
the
get
lab
plugin
modernization
welcome
to
the
community
meeting
all
right.
So
first,
stop
was
a
meeting
with
all
team
members
to
be
sure
we
know
each
other
and
show
personal
expectations
and
goals.
Let's
start
that
so
harsh
you
want
to
go.
First,
tell.
B
Us
something
about
yourself:
Etc,
currently,
a
freshman
I'm,
currently
a
freshman
at
an
Institute
of
Technology,
kanpur
and
I'm.
Actually
here
to
code
I,
actually
started
learning
Java
from
January.
During
the
midst
of
my
exams
and
I
started
finding
organizations
I
read
a
bit
of
books
and
I
found
Jenkins
and
I
thought
that
it
would
be
better
to
learn
it
and
then
I
started
contributing
and
I
got
into
gstock.
Somehow
I
was
not
even
expecting
it,
but
yeah
grateful.
C
Right
I
would
just
like
to
point
out
that
I'll
have
his
enthusiasm
as
well.
Like
you
know
the
fact
that,
like
he's
so
excited
to
be
here
and
at
the
same
time,
oh
yeah,
so
who
am
I
I'm
I'm
going
to
be
in
there
in
this
project
as
well?
I,
don't
really
have
any
expectation
from
you.
I
mean
I.
C
Obviously
do
have
some
like
those
days
and
expectations
that,
like
you,
should
fall
they'll
have
with
open
source
that
you
have
to
complete
the
project
within
the
set
amount
of
time,
but
at
the
same
time,
I
have
this
one
very
specific
expectation
that
is
just
communicate
with
us,
because
I
think
this
is
the
most
important
part
of
about
the
entire
project,
and
this
is
something
which
is
going
to
help
you
throughout
the
cardio.
It's
not
just
for
the
next
two
months
next,
three
months.
It's
also
going
to
help
you
throughout
your
whole
life.
C
So
yeah,
that's
kind
of
about
it.
If
you
ever
have
any
like
even
the
smallest
of
the
patients
feel
free
to
ask
any
of
us.
D
Sure
so
my
name
is
Chris
I'm
based
in
Hong
Kong,
currently
and
I'm.
A
software
engineer
professionally
for
at
least
I
said
three
years
and
I
think
for
expectations.
I
just
want
to
have
a
successful
outcome
and
I'll
do
anything
possible
to
assist
in
that
goal.
A
Thank
you
thanks
very
much
Chris,
so
I'm
Mark,
I'm
I've
been
doing
software
for
a
while
and
I'm
very
interested
in
git.
I've
got
some
interest
in
the
get
hosting
providers
because
of
my
interest
in
git
and
not
as
deeply
experienced
with
gitlab
as
I'd
like
to
be
so
I'm
going
to
use
this
project
to
be
sure
that
I
learn
more.
That
I
understand
better.
That
I've
done
some
exploration.
A
A
If
it's
broken
and
that's
okay,
we're
going
to
have
those
conversations,
I
think
my
primary
role
will
be
one
code,
read
code
review
so
that
we
can
see
and
discussion
review
on
things
that
you
how
you're
approaching
things
which
things
you're
doing
when
Etc
you're
the
implementer
and
we're
here
to
help,
but
that
help
from
my
case
will
probably
be
strongly
oriented
on
testing
to
be
sure
that
I
understand
what
you're
doing
and
then
on
code
review
where
code
review
is
is
vital
and
healthy.
B
A
Oh
I
love
questions
like
that.
That's
the
way
you're
trying
to
seduce
me
with
really
good
questions
very
good,
harsh
way
to
go
all
right,
so
I
am
I,
am
strongly
in
favor
of
test
driven
development
and
have
been
repeatedly
proven
that
I,
probably
don't
do
enough
of
it,
so
so,
even
as
strongly
as
I
believe
in
test
driven
development.
A
A
Every
time
we
release
a
new
version
and
so
I
like
tests,
because
they
give
us
confidence
that
we
can
release
the
next
version
and
the
next
version
and
the
next
version-
and
we
didn't
regress
it
now
that
was
kind
of
a
cheat
answer,
harsh
because
when
I
say
I
like
test
driven
development
and
I've
done,
presentations
on
test
driven
development
and
I
live
test
driven
development.
Personally
still,
sometimes
you
may
find
in
the
Jenkins
code
base,
that's
really
uncomfortable
and
and
you'll.
A
You
have
to
ask
for
help
or
say:
hey,
I,
don't
know
what
to
do
with
this.
How
do
I
test
this
thing
and
we
as
mentors
may
have
to
do
some
research
as
well
to
find
ways
to
do
test
driven
development
in
what
is
fundamentally
an
integration
machine
right,
Jenkins
is
an
integration
engine
and
the
word
integration
hints
that
there's
a
lot
of
integration
tests
that
happen
right.
It's
it's
not
well
oftentimes
well
suited
to
just
simple
unit
testing.
A
You've
got
to
do
integration
or
I
have
tests
in
the
git
plug-in
that
I
maintain
that
actively
call
production,
servers,
right,
I,
call
right
to
github.com
and
ask
questions,
and
that
is
a
total
cheat
in
test
driven
development,
but
I
do
it
anyway,
because
I
need
it.
Did
that
answer
your
question
yeah.
A
Yeah
yeah
so
so
test
driven
development
is
certainly
I.
Consider
test
driven
development
necessary,
but
not
sufficient
right.
You
must
have
checked
interactively
it's.
The
Jenkins
code
base
is
just
too
complicated
for
us
to
think
that
we
can
do
something
purely
with
automated
tests
and
it
will
just
magically
work.
A
No,
no
I
guess
one
other
area
is
I
really
like
having
online
help
with
every
single
change.
So
with
every
every
edition
of
a
new
capability,
we
need
to
be
sure
it
has
online
help
for
it,
because
users
read
it
and
we
need
to
be
sure
that
we
document
it.
So
so
again,
those
are
places
where
it's
surprisingly
important
that
we
document
this,
because
other
people
are
going
to
want
to
use
it.
A
Not
as
worried
about
a
design
document,
I
think
you're,
you'll
Your
Design
document
has
already
been
been
very
nicely
started
in
your
project
plan
and
that's
that's
great
I'm
not
worried
about
individual
design
documents
for
steps
along
the
way.
The
working
code
is
much
more
important
than
than
writing
about
code.
C
C
I'm,
actually,
a
protest,
Venezuela
I
I
just
feel
that
it
just
makes
it
very
easy
in
the
long
term,
as
well.
I
think
like,
as
your
code,
basically
evolves
throughout
the
years
it
just
it
just
keeps
I
mean
it's
just
easy
to
keep
track
of
all
the
changes
and
all
the
updates
that
are
happening
all
the
time
yeah,
so
I'm
also
Pro,
test
driven
but
yeah
at
the
same
time,
at
the
same
just
so
one
one
more
time.
C
At
the
same
time,
as
you
said,
it
is
quite
uncomfortable
at
times
so
I
think
there's
this
trade-off
as
well
to
keep
in
mind,
but
I
I
guess,
like
overall
I
think
we
should
always
just
like
try
it
out
first
and
then,
if
it,
if
it
actually
creates
this
friction
in
that
case,
then
you
can
just
like
adopt
a
much
simpler
way.
At
that
point,.
D
So
I
think,
like
unit
tasks
are
definitely
necessary,
but
for
integration
tasks
we
should
try
to
do
just
what's
needed
because,
like
otherwise
it
might
slow
down
the
whole
like
application.
So
that's
all
not
what
we
want.
Yeah.
C
Also,
could
you
actually
share
the
like
the
document
with
us
so
like
even
we
will
have
access
to
it.
A
A
A
All
right
so
communication
channels,
next
topic,
I
assume
everyone's
okay.
If
we
go
ahead
with
getterchat
in
the
get
lab
plugins
in
the
gitlab
plugin
chat
Channel,
where
we've
been
chatting
already
yep,
okay,
great
next,
clarify
sync
and
asynchronous
communication
method.
So
harsh
I
think
ask
a
question:
ask
questions
in
the
in
the
in
the
chat
Channel
right
if
they
are
and
if
they
are
even
remotely
close
to
being
workable,
publicly
ask
them
there
that
way.
Others
can
learn
from
them
and
we'll
answer
there.
A
B
D
A
And
let's
look
for
a
time:
does
this
time
work
for
everyone
in
general,
or
is
this
a
bad
time
for
the
Friday?
Maybe
a
time
when
you
wish
you
were
having
a
beverage
or
something
and
so
I
I,
don't
know
if
your
your
character
is
like
mine.
So
does
this
time
work?
Would
you
prefer
a
different
time
and
day
no.
B
A
Works
yeah,
okay,
great
so
I
will
schedule
Friday
at
this
time.
At
the
same
time,
Mark
scheduled
a
session,
the
repeating
session,
great
Excellence,
now
unavailability,
so
holidays,
exams,
Etc.
So
harsh
I
believe
you
started
this
in
the
in
the
project
plan
and
we
should
continue
it.
There.
B
Yeah
I
actually
mentioned
all
those
the
breaks
which
I'll
require
in
the
project
proposal,
and
it's
not
like
I
won't
be
working
on
that
on
these
things.
But
my
workload
will
be
reduced
like
from
35
to
40
hours
to
around
20ish
hours,
because
I
won't
be
able
to
give
up
my
full
time
to
it
because
of
exams.
A
A
B
A
Okay,
so
now
the
there
are
some
key,
some
key
things
here
in
terms
of
deliverables,
John
Mark
in
this
original
document
called
them
soft
deliverables
I'm
not
comfortable,
calling
them
soft
at
all.
These
are
mandatory
deliverables
that
we
absolutely
must
have
during
this
time.
It's
it's
kind
of
him
to
use
the
word
soft,
but
it's
crucial
for
me
and
I.
Think
for
you
harsh
that
you
do
you
complete
these
pieces,
because
it's
very
becomes
very
clear
to
everyone
that
they
know
who
you
are,
that
you're
that
you're
getting
started.
A
B
A
A
Comfortable
with
those
two
yeah-
okay,
great
all,
right,
okay
and
then
stretch
goals.
This
is
when
I
feel
like.
Could
we
set
our
goal
that
next
week,
in
our
meeting,
we
will
review
the
project
plan
in
detail
with
you
harsh,
giving
you
a
chance
to
prepare
to
do
one
review
of
it
before
we're
ready
for
before
we
review
it
next
Friday,
and
we
will
talk
it
in
depth
next
Friday
as
make
that
the
primary
focus
of
next
Friday's
meeting
I.
B
A
B
A
A
Let's
see
so
the
actually
that
so
this
is
the
starting.
This
is
the
blog
post
that
John
Mark
nope
nope,
so
maybe
well,
let's
see
Chris
help
me
with
this
one
I
think
we've
had
contributors
do
a
midterm,
blog
post
and
an
end,
but
not
a
start,
blog
post
or
did
we
also
do
a
start,
blog
post
I?
Don't
remember
harsh
good.
A
D
D
A
Okay,
so
let's
let's
look
for
rishabh
nope,
oh
shoot:
okay,
harshit
Chopra!
So
let's
see
what
what
harshit
wrote
so
harshit
only
did
one
blog
post
so
go
ahead.
Chris.
A
Others
there's
others.
A
D
Oh
g-o-n-j.
A
Costume,
okay,
good
and
where
is.
A
That
would
be
an
end
of
blog
end
of
a
wrap-up
blog
post
at
the
end,
so
no
need
for
a
blog
post
immediately
now,
I
think
it
would
be
healthy
if
we
had
you
do
a
midterm
blog
post,
but
the
minimum
is
the
end
of
block
and
you'll
you'll
absolutely
have
to
do
a
midterm
presentation
and
absolutely
do
an
end
of
end
of
cycle
blog
post.
If
you
did
a
midterm
blog
post,
it
can
help
you
organize
your
presentation,
okay,
yeah
and
any
other
questions
on
the.
What.
D
A
A
A
Okay,
then,
on
the
how
topic
so
Define
and
put
in
place
the
technical
Logistics
so
issue
tracker.
Thus
far,
the
gitlab
plugin
has
been
tracking
its
issues
in
get
GitHub.
If
I
remember
correctly,
Chris
is
that
right?
Yes,
here
we
go
and
it
has
lots
of
them
so
I
propose.
We
continue
that
any
objections.
A
Good
good
choice:
git
repository
to
use
the
same
okay
work,
environment,
so
harsh
I
assume
you've
got
a
development
environment
at
least
Linux
based
or
Windows
based
one
of
the
two
help
the
rest
of
us,
which
is
it
are
you
Linux,
Windows
or
Mac,
OS
user
Macos,
oh,
oh,
very,
good,
okay,
all
right
so
and
Mark
is
using
Windows
and
Linux
frame.
What's
your
preferred
development
I.
D
A
Good
all
right,
so
we
have.
We
have
a
nice
platform
mix,
that's
very
healthy,
great
all
right
now,
harsh
I
assume
you
have
Docker
on
your
Mac
OS
machine.
Is
that
correct,
yeah,
okay,
good
all
right
and
I've
got
Docker
on
all
of
mine,
I
assume,
freyjam
and
Chris.
Likewise,
yep,
okay,
good
all
right!
Okay,
how
and
where
meeting
notes
are
recording
or
recordings
are
kept
so
I
propose
meeting
notes
in
this
document.
D
D
A
Mark
to
post
them,
Mark
has
a
bunch
that
he
hasn't
posted
yet
I've
got
a
lot
to
do.
Is
that,
okay
for
the
rest
of
you.
B
C
A
A
A
Harsh
you're,
okay,
with
that
I
assume
yep
all
right
and
project
page
on
jenkins.io,
updated,
yes
linked
to
the
biography,
upgrade
the
update
the
to
be
described
section.
So
that's
this
all
of
this,
and
this
is
effectively
a
transposing
and
possibly
simplification
of
your
project
plan
and
if
you
could
put
in
there
that
we
will
be
meeting
every
Friday
at
the
time,
we've
agreed
to
that's
great.
A
And
a
link
to
the
getter
Channel
and
the
project
proposal.
Oh
yes
notice!
Here
it's
the
submitted
project
proposal.
So
if,
if
we
have
to
Archive
a
copy
of
the
PDF,
that's
that's
great
I,
don't
remember
how
that's
been
done
in
the
past
harsh.
It
may
be
simplest
to
to
save
an
archive
copy
of
the
PDF
of
your
proposal.
A
And
then
the
current
project
project
plan,
okay
and
this
one.
How
shall
we
do?
What's
the
in
the
past,
I've
preferred
to
have
project
plans
that
were
in
a
Google
doc
that
we
could
revise
and
refine,
but
that
doesn't
make
for
a
really
easy
way
to
track.
History.
Are
you
okay,
if
we
use
Google
doc,
for
that,
or
do
you
want
to
do
something
more
formal
put
it
in
the
GitHub
repository
Etc.
D
A
A
D
A
A
D
A
A
D
D
D
D
C
A
A
A
B
A
So
I
would
prefer
to
retain
that
branching
pattern,
harsh
where
we
keep
it
nice
and
simple:
no,
no
extra
branches,
just
we
merged
to
master
when
we
believe
it's
ready
and
we
try
to
do
merges
to
master
very
frequently.
So
we
we
want
you
to
do
small
chunks
of
work
that
we
can.
We
can
roll
out
so
that
we
can
do
incremental
releases
as
well.
D
D
A
My
my
preference
personally
is
to
not
have
long-lived
branches
because
they
tempt
me
to
make
other
choices
which
are
flawed,
so
I
I,
I
I,
it's
it's.
It's
hard
work
to
find
ways
to
assure
that
each
step
is
incremental
and
can
be
released,
but
I
think
it's
worth
the
hard
work,
because,
at
least
in
the
past,
when
I've
chosen
to
use
long-lived
branches,
I've
had
very
poor
experiences
with
the
results
from
it.
Okay,.
A
D
A
Now,
those
are
very
famous
words
to
say
and
they're
very
as
far
as
I
can
tell
very
challenging
to
do.
There's
a
lot
of
learning
to
go
through
that
process,
and
so
harsh
don't
be
shy
as
we
as
we
talk
through
these
things
together
we're
going
to
have
to
find
together
what
what
sequence
of
steps
should
be
taken
to
do
this
the
most
reasonably.
A
A
So
so
that
means
x,
dot
y
dot,
Z,
where
the
X
version
means
we
were
breaking.
The
Y
version
means
we
did
a
a
bug,
fix
or
functional
change,
and
the
Z
is
no
no
change
in
functionality,
but
at
otherwise
an
improvement.
A
A
A
C
A
I
I'm
I'm
open
to
I'm
open
to
either
so
harsh
harsh.
This
is
a
this
is
a
fun
software
engineering,
question
I'd
say:
let's:
let's
leave
it
as
it
is
for
today
and
let's
see
how
it
evolves
in
our
discussions
that
way.
Harsh
you'll
hear
us
as
Mark
and
Chris
have
the
discussion
back
and
forth.
Ooh
I
like
it.
For
this
reason,
I,
don't
like
it
for
that
reason,
and
then,
as
a
group
we'll
decide
as
we
go
forward,
we'll
stay
with
the
current
pattern
for
now.
C
B
Yeah
supports
gitlab
version,
API
version
three
also,
so
it
doesn't,
it
requires
to
be
removed
during
the
migration
or
we
are
keeping
the
version
three,
because
the
warnings,
the
gitlab
4J,
has
some
warnings
written
there
that
this
thing
the
conversion
table
will
be
discontinued.
So,
what's
your
thought
about
that.