►
From YouTube: 2023 05 19 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
Welcome
it's
19th
May
2023.
This
is
the
gitlab
plug
plug-in
modernization.
Weekly
Google
summer
of
code
status
check
it's
Community
bonding
period.
Let's
see
harsh
we've
got
that
checkbox
item
from
so
from
our
past
action
items.
I've
still
got
to
revise
the
project.
Page
and
I
did
create
the
Community
page
and
upload.
The
recordings
I
believe
so.
I
think
that
part
we've
got
all
right.
So
harsh
I
think
we're
ready
to
talk
about
project
plan
review.
A
B
Yeah
so
related
to
the
dependencies.
The
like
We'll
add
the
GitHub
project
dependency.
So
I
wanted
to
ask:
how
will
I
check
the
compatibility
issues
like
I
from
the
maven
repositories,
I
added
the
link
for
the
dependencies
like
what
dependencies
is
git
apology
using
so
how
I?
How
am
I
going
to
test
the
compatibility
thing?
A
A
So
so
Basel
and
I
were
discussing
and
one
of
his
recommendations
was
for
compatibility.
One
of
the
best
things
you
can
do
is
use
your
debugger
to
actually
watch
the
product,
execute
watch
the
plug-in
execute
using
the
old
code
so
that
you
become
familiar
with
it,
understand
exactly
what's
happening
inside
that
old
code
and
then,
as
you
implement
one
one
replacement
of
something
you
can
watch
the
execution
of
that
same
thing
from
a
debugger
and
see
okay,
does
it
behave
the
way
I
expected?
Is
it
getting
the
expected
return
values?
A
B
More
already
thought
of
doing
that
and
I
will
be
asking
more
questions
related
to
the
debugger
thing.
I
have
specific
problems
using
the
debugger
when
I
was
trying
to
debug
the
web
hook
thing
and
the
proxy
settings
thing.
So
it's
it's
down
there,
but
now,
let's
don't
talk
about
the
debugger
right
now,
it's
down
so
regarding
the
compatibility
issue.
B
Okay,
so
I'll
see
through
it
like
the
idea
that
you
told
that
how
having
both
at
the
time
of
migration,
that's
what
I
also
thought,
but
once
I'll
remove
the
rest
easy,
then
the
problem
will
start
happening.
That
gitlab
4J
will
be
having
compatibility,
may
have
compatibility
issues.
So
that's
what
I
was
talking
about,
but
yeah
I
think
this
answers.
My
question.
B
Implementation
so
the
rest,
easy
used,
a
used,
client
based
things
and
the
gitla
project
is
using
API.
So
a
lot
of
things
has
to
be
removed.
I
want
to
discuss
on
almost
every
class
that
has
to
be
removed,
like
we
don't
need
to
build
a
client
right
now.
You
can
directly
use
the
gitlab
API
for
that
and
as
the
version
3
is
depreciated,
we'll
be
using
version.
4
and
gitlab
4G
already
uses
version
4
as
its
default
API
so
other
than
that.
The
auto,
detecting
gitlab
client
Builder.
B
C
What
I
think
I
think
you
are,
and
so,
in
addition
to
so,
the
existing
code
has
a
bunch
of
model
classes
to
represent
the
various
objects
that.
B
Are
prescribed,
I
think
required
because
because
already
provides
that
so
I
will
be
removing
the
removing
them
I
think
right,
except
I'll,
check
I'll
check
if
something
has
to
be
done
with
that.
If
some
extra
models
are
used
but
I
think
almost
all
Replacements
are
available
in
GitHub
version.
That's.
C
B
A
Will
be
harsh
before
we
go
on
from
there.
I
I
need
to
pause
for
a
question
on
this
one,
and
it's
probably
both
you
and
Basel,
so
I've
been
terrified
in
the
git
plug-in
of
deleting
any
class
for
fear
of
somebody
else
depending
on
me.
In
this
case,
with
this
one,
it's
it
sounds
like
it's.
A
reasonably
safe
choice
is
that
because
we
think
nobody
else
should
have
been
using
these
classes
as
a
published
API.
C
Yeah
I
think
that
is
a
safe
assumption.
I
mean
if
anyone
is
is
using
these
classes
in
a
pipeline
job,
for
example,
it
would
be
extremely
unusual
now
I
think
there
is
probably
at
least
one
person
out
there
who
is
doing
it,
because
I
did
once
get
a
pull
request
to
expand
the
model
to
add
additional
things
to
it
and
I
thought
that
was
very
strange
because
we're
not
we
weren't
using
that
part
of
the
API
in
our
own
code.
C
C
A
A
Now,
one
of
one
of
my
worries
in
the
git
plugin
is
that
there
are
actual
plugins
that
depend
on
the
plug-in
I
just
checked
and
for
the
gitlab
plugin
there's
only
one
dependent
plug-in
and
it's
optional,
it's
an
optional
dependency.
Therefore
they
I
think
that
means
we're
it's
further
indication.
We
should
be
safe
thanks,
harsh.
B
So
yeah
connection
and
proxy
settings
so
gitlab
API
token
implementation
won't
require
any
change
because
it
is
getting
it
from
Jenkins
credential
manager,
which
I
don't
think
so
it
requires
any
change
now,
gitlab
connection.
So
instead
of
getting
the
client
we
are
going
to
get
the
API
and
the
proxy
settings
which
are
which
were
implemented
in
the
rest
is
a
gitlabs
line.
Builder
I
think
we
will
be
implementing
it
in
the
gitlab
connection,
and
can
you
can
you
scroll
down
a
bit
more
yep?
B
So
here
are
some
questions
like
we
have
to
discuss
about
the
alternative
Constructors
which
were
available
in
the
gitlab
connection.
Like
I,
don't
know,
let
me
check
what
they
were
actually
look
at
lab
connection
right,
so
there
were
three
Constructors
as
I.
Remember:
yeah
I
got
them.
One
was
using
Auto,
detecting
gitlab
client
Builder,
which
I
don't
think
so
will
be
required.
Now
second
was
client,
Builder
ID,
which
extra,
which
was
using
client,
Builder
ID
and
third
one
was
using
client
Builder
itself.
B
C
C
Not
being
called
and.
B
Yeah
because
I
I
thought,
if
we
could
create
some
problem,
if
I
remove
those
Constructors,
maybe
programmatical
issues
may
happen.
That's
why
I
was
asking
because
right.
C
Normally
we
do
care
a
lot
about
compatibility
issues
like
this
in
Jenkins,
so
it's
good
that
you're
thinking
about
it,
but
in
the
case
of
this
gitlab
plug-in
there
there
really
isn't
any
other
consumer.
If
this,
if
this
gitlab
plug-in
you
might
you
know,
if
you're
thinking
about
compatibility
issues
like
this,
the
only
place
where
it
does
matter
is
in
code
that
could
be
called
by
user.
C
So,
for
example,
if
there
are
things
like
pipeline
steps
that
have
data
bound
Constructors,
those
are
things
that
could
be
called
by
a
user
who's.
Writing
a
pipeline
job,
so
compatibility
matters
in
that
case,
but
in
terms
of
some
internal
class
that
isn't
exposed
to
a
user,
it
doesn't
matter.
B
Yeah,
that
clears
a
lot
of
things
for
me
yeah.
So
the
next
question
that
I
wanted
to
ask
was
how
do
I
debug
this
proxy
thing,
which
is
currently
implemented
using
the
HTTP
client
engine,
because
I
can't
really
do
that:
I'm
not
able
to
do
it
and
it
will
be
required
because
I
need
to
really
what
what
can
I
say
imitate
the
same
thing
that
has
been
that
is
being
done
using
the
rest,
easy.
So
when
using
The,
Clapper
J
proxy
client
configuration
thing
so.
C
Proxy
servers
yeah
because
I've
I
found
a
couple
of
good
ones:
I,
don't
remember
now
what
what
their
names
were,
but
there's
like
one
that
I
found
that
allow
you
to
just
Define
the
password
and
yeah
just
run
one
Docker
command
to
start
up
the
proxy
server
with
authentication,
and
you
know,
even
though
I
wouldn't
use
that
image
in
production
without
looking
at
it
more
closely.
C
It
was
certainly
good
enough
for
testing
purposes
and
saved
me
a
lot
of
time
from
having
to
learn
how
to
set
up
a
proxy
server
from
scratch.
On
my
computer.
B
A
A
B
B
That's
enough
yeah,
authenticated
and
authenticated
proxy.
So
maybe
we
can
read
through
this,
and
maybe
basil
can
tell
us
if
it's
a
right,
because
that's
what
I
thought
and
that's
what
I'm
thinking
right
now.
I
think
this
is
correct
according
to
me
at
least
so
like
can
you
scroll
a
bit
more
down
because
I
had
those
I
think
it
was
called
mid-10
proxy
or
something
like
that
which
I
wrote.
C
Image:
I,
don't
remember
the
name
of
the
ones
that
I
used
in
the
past,
but
they
sound
these.
These
sound
reasonable
at
face
value,
so
the
the
the
proxy
settings
come
from
Jenkins
itself.
You.
C
Don't
need
to
detect
whether
and
well
I
mean
there's
basically
there's
basically
a
a
page
in
the
Jenkins
UI,
which
is
it's
it's
in
like
that.
B
I
think
we
can
set
up
the
HTTP
proxy
and
HTTP
https
https
proxy
through
that
yeah.
C
Mark
knows
where
it
is
it's
that
advanced
settings
page
here-
and
this
is
where
this
is-
where
Jenkins
user
can
go
in
and
configure
the
proxy
by
putting
something
into
that
server
value
and
then,
if
they,
so
you
know,
if
they,
if
that
setting
is,
is
not
null
or
empty,
then
a
proxy
is
being
used
and
then,
if
they,
if
they
have
something
specified
in
the
username
and
password
that
that
would
indicate
that
you
need
to
authenticate.
B
C
Anything
yeah,
so
basically
what
you
do
is
once
you
start
that
Docker
image
you'd
put
inside
of
the
server
box,
you
know
localhost
and
you'd
put
inside
the
port
box,
whatever
Port
docker
has
given
you
and
then
for
username
and
password.
That
would
depend
on
you
know
what
you
set
it
to
when
you
start
up
the
docker
image.
Do
you
see.
A
C
This
is
the
this:
is
the
primary
proxy
configuration
page
for
Jenkins
for
all
of
Jenkins
it
doesn't.
It
doesn't
really
make
a
whole
lot
of
sense
that
it's
in
the
plug-in
manager,
because
it
really
applies
to
everything
that
that
every
everything
within
Jenkins,
so
it
could.
It
could
more
properly
be
placed
on
the
global
configuration
page.
A
B
B
Go
proxy
thing
so
yeah
regarding
the
trust
manager
like
in
the
plugin
I
saw
that
the
trust
manager
was
disabled
like
so,
are
they
going
to
use
some
self-assigned
or
because
the
It
Was
Written
in
the
project
project
idea
that
TLS
certification
will
be
required?
So
how
am
I
going
to
set
up
the
trust
manager
because
I
think
gitlab
plugin
is
using
some
Excel
build
I,
don't
know
I,
don't
really
remember
the
name,
but
it
is
overriding
all
those
methods
and
it
was
not
returning
anything
technically.
C
Yeah
for
for
for
configuring,
HTTP
clients
there's
we
we
usually
want
to
just
use
the
default
Behavior,
but
some
sometimes
our
users.
Sometimes
our
users
complain
about
the
fact
that,
like
you
know,
sometimes
sometimes
our
users
have
Target
machines
that
don't
have
proper
TLS
certificates,
so
they
usually
want
some
kind
of
check
box
to
be
able
to
disable
TLS
verification,
and
it's
not
considered
a
good
practice
to
do
that.
C
B
Yeah
I
think
I
get
it
now.
Okay,
that's
great
yep,
so
this
section
is
over:
let's
move
to
models
in
enum
section,
so
the
most
fundamental
thing
here
will
be
that
we
are
not
passing
any
Json
now
Jackson
Json
is
already
available
in
the
gitlab
4G.
We
will
be
using
events
instead
of
hooks
and
we
will
be
getting
data
out
of
it
and
filling
the
up
the
cause
data
using
that.
B
B
No
I
guess
so
it
is
good.
Those
Support
classes
of
publisher
classes
and
all
I
wrote
the
code
for
everything
like
so
that
you
could
check
if
things
are
working
properly
or
not,
some
utility
classes
that
were
also
there.
One
of
things
one
of
the
utility
classes
was
commit
status,
publisher,
I,
don't
think
so.
It
will
be
required
because
no
that
was
a
publisher
class.
The
the
class's
name
was.
Let
me
check
what
was
the
class
name,
the
utility
class.
B
Id,
no
no
update
commit
status.
I
think
I
didn't
write
it
in
the
project
plan
for
some
reason,
update,
commit
status
so
I,
don't
think
so.
Update
commit
status
will
be
required
because
we
can
change
the
commentators
using
gitlab
4J,
also
so
I
think
that
will
also
be
removed
and
related
to
this
I
wrote
the
code
for
my
just
migrating,
the
SDC
client
to
using
the
killer.
4G
API,
that's
nothing
of
a
woman,
so
we
can
scroll
down
more.
B
B
Data
for
different
events,
but
I,
don't
think
so.
It
will
be
required
much
as
I
saw
that
in
the
gitlab
brand
Source
plugin
as
I.
Remember
but
I,
don't
think
so.
It
will
be
required.
We
we
will
be
using
events
instead
of
hooks
and
that's
the
main
Crux
of
the
web
hook
thing
that
we
will
that
we
will
be
implementing
and
related
to
the
web
host
things.
A
lot
of
things
has
to
be
changed
because
we
are
not
using
hooks
now
so
listener
will
be
implemented
and
the
trigger
will
be
fired
through
it.
B
The
handlers
will
be.
The
handlers
will
be
preserved
because
I,
don't
think
so.
It
requires
any
change
related
to
the
trigger
conflict
chain.
It
is
using
the
hook
models
which
were
used
by
rest
easy.
Now
now
we
will
be
using
the
models
which
are
available
for
gitlab
available
by
gitla
4J,
so
that
is
a
whole
cross.
B
C
I,
don't
really
understand
the
question
I
mean.
Are
you
saying
that
when
you
you
use
the
debugger
you're
missing,
stack
frames
and
you're
going
too
deep
or
something.
C
A
C
B
A
In
in
next
week's
session
or
in
a
future
session,
we
could
actually
do
a
shared
session
and
have
you
share
your
screen
and
and
actually
talk
through
a
debugging
session?
So
so
there's
there's
no,
no
shame
in
US,
looking
together
at
what
you're
experiencing
and
seeing
Oh
can
we
help
understand
what
you're,
seeing
and
see?
Is
that
what
we
expected
you
to
see,
or
was
there
some
surprise
in
what
you're
seeing.
B
Okay,
yeah:
that's
that
would
give
great
so
yeah
I
think
this
is
the
complete
migration
and
the
bird's
eye
view
on
a
high
level
view
that
I
have
shared
related
to
the
timeline.
I
want
to
finish
it
faster,
of
course,
and
I
broke
it
into
small
PR
that
I
will
be
making.
So
this
I,
don't
think
so.
I
need
to
discuss
about
this.
So
any
questions
that
you
guys
have.
C
C
B
B
C
I
see
yeah
I
mean
it's
equal,
I,
think
we'll
know
how
long
it's
going
to
take
to
do
all
of
these
things.
Once
we
have
some
kind
of
working
test
of
an
end
to
end
I
mean
Maybe,
not
maybe
not
necessarily
converting
every
single
caller,
but
once
once
you
get
to
the
point
where
you
can
submit
a
request
with
gitlab
for
J
and
get
a
successful
response
from
the
server
for
at
least
one
end
point
yeah,
you
know
once
you
get
to
that
point,
I
think
you'll.
A
So
so
I
liked
how
Basel
described
it
as
end-to-end,
reaching
from
the
gitlab
plug-in
all
the
way
into
gitlab.
The
server
with
gitlab
for
Jay
feels
like
a
very
important
important
step
and
a
good
thing
to
do
as
soon
as
you
reasonably
can
right
that
hey.
We
want
that
long,
that
long
thin
thing
that
gets
all
the
way
into
gitlab
and
that
gets
comes
to
the
gitlab
plugin
as
a
pull
request,
so
that
we
can
look
at
it
together.
B
C
No
no
you're,
both
correct,
but
so
I
think
Mark
is
correct
in
the
sense
of
wanting
to
see
that
code
earlier,
rather
than
later,
in
order
to
make
sure
that
we
correct
any
problems
before
it's
too
late,
but
you're
also
correct
that
pull
request
would
be
too
large
to
to
possibly
review
and
merge
so
that
the
the
compromise
or
the
the
way
to
blend
these
two
concerns
is
to
make
that
a
draft
pull
request
which
we
can
start
to
look
at.
C
But
then,
as
you
extract
pieces
of
fit,
you
can
create
separate
non-draft,
pull
requests
for
every
piece
as
you're
ready
to
merge
it,
and
what
that
will
mean
is
that
you're,
very
large
draft
pull
request
will
start
shrinking
over
time
as
pieces
of
fit
get
extracted
and
merged
separately.
So
the
goal
is
for
that
draft
pull
request
will
eventually
shrink
to
a
size
zero
as
all
the
pieces
of
fit
are
individually
merged,
but
in
the
meantime,
having
it
having
the
large
draft
is
valuable
for
others
to
be
able
to
collaborate
and
see
what
you're
doing.
A
Yeah
I
hadn't
thought
of
that
I
like
that
very
much.
Okay,
so
start
with
a
start
with
it's
okay
to
go
big
on
the
initial
draft,
but
we
know
we're
not
going
to
merge
a
draft
pull
requests
but
we'll
we
can
use
it
for
conversation
for
discussion
for
education
on
on
my
part
on
others,
for
debugging
and
exploration
I
like
that.
That
sounds
really
great.
B
C
Yeah
no
I
wanted
to
go
back
and
I
know.
Mark
mentioned
this
at
the
beginning,
but
I
wanted
to
emphasize
how
valuable
I
think
it
is
to
step
through
the
current
logic
in
the
debugger
before
you
start
testing
the
migrated
logic
whenever,
because
I've
done
a
lot
of
migrations
like
this,
and
it
helps
to
be
familiar
with
the
old
execution
path
or
you
start
writing
the
new
execution
path,
and
in
this
case,
most
of
the
code
in
the
old
execution
path
is
not
barcode
in
the
gitlab
plugin.
C
It's
you
know
when,
when
when,
when
you're
stepping
through
the
existing
execution
in
the
debugger
you'll
go
from
Jenkins
gitlab
plug-in
logic
into
Jersey
and
Jackson
and
then
into
rest,
easy
and
then
eventually
into
you,
know
something
very
low
level
like
a
socket
API
or
something,
and
just
going
through
that
whole
path
and
becoming
familiar
with
it
is
I.
Think
it's
it's
gonna,
be
a
valuable
exercise.
C
C
What
is
it
like
when
the
when
the
server
returns
an
internal
error,
there's
like
a
code
path
that
displays
the
error
to
the
user
and
prints
out
the
the
it
prints
out
what
the
server
provided
as
the
result
and
I've
had
a
bug
in
that
I've
had
a
bug
there
in
the
past,
where
I
was
close,
I
was
reading
the
response
from
the
server
and
then
closing
the
socket
and
then
rest
easy
was
trying
to
do
the
same
thing
and
finding
the
socket
already
closed,
and
then
it
was.
C
It
ironically,
was
losing
the
error
message
because
it
was
displaying
its
own
error
rather
than
the
one
that
I
was
trying.
To
so
I
mean
that's
the
kind
of
thing
where
you
really
have
to
be
familiar
with
the
internals
in
order
to
kind
of
replicate
that
behavior
in
the
in
the
new
version
and
it
gets
the
current
code-
is
pretty
tricky
because
it
uses
Jackson
and
Jersey
to
kind
of
convert
these
models
into
Json.
C
So
you
know
you
don't
have
to
study
that
too
closely,
but
studying
the
path
of
how
that
request
gets
sent
to
the
server
and
how
the
you
know
how
the
response
gets
converted
back
and
how
errors
get
propagated
just
being
familiar
with.
That
is
helpful
knowledge
to
have
before
where
you
go
and
write
work
on
the
Rewritten
migrated
version.
So
probably
you
know
spending
spending
a
short
amount.
C
I
mean
not
not
a
huge
amount
of
time,
but
spending
some
amount
of
time,
just
familiarizing
yourself
with
and
don't
be,
don't
be
afraid
to
step
into
rather
than
stepping
over
when
you're
looking
at
the
old
code
and
the
debugger,
you
know
it's
stepping
into
Jersey
Jackson
West
easy
just
getting
that
bird's
eye
view
of
how
this
whole
thing
is
working
is
is,
is
time
well
spent.
In
my
opinion,.
A
Well
so
one
of
the
one
of
the
suggestions
I
had
seen
previously
was:
you
may
want
to
actually
configure
your
own
gitlab
server
so
that
you
can
and
so
that
you've
got
a
local
thing
that
you
can
use
for
experiments.
Don't
be
shy
about
exploring
that
I
think
that
kind
of
idea
sure
use
use
the
get
the
public
server
as
much
as
you
reasonably
can,
but
don't
hesitate
to
familiarize
yourself
with
gitlab
itself,
because
you're
going
to
be
interacting
with
it
a
lot
yeah.
C
It's
very
easy
to
do
that.
You
can
you,
can
you
can
easily
set
up
a
local
version
of
gitlab
because
they
have
a
Docker
image
that
yeah.
B
D
D
C
D
B
I,
don't
think
it's
realistic,
I
tried
to
create
an
ideal
timeline
because
I
was
not
able
to
get
to
the
realistic
picture
of
this
thing,
as
basil
actually
said
that
we
will
have
to
implement
first
in
a
draft.
We
are
then
only
we
can
say
that
what
time
it
will
take
if
this
is
an
ideal
situation.
This
is
not
a
realistic
situation
of
the
timeline
that
I
can
say
for
sure.
D
Do
you
have
like,
like
a
confirmed
list
of
items,
we
must
do
and
the
West
like
nice
to
have.
C
D
A
C
Masters
are
getting
getting
the
entire
thing
working
with
with
the
gitlab
API
and
then
deleting
the
rest,
easy
client
and
there'sn't
really
much
of
a
there's
really
much
more
after
that,
I
mean
if
we
have,
if
we
have
extra
time,
I
can
think
of
other
bugs
to
fix,
but
that
isn't
part
of
the
core
project.
So
the
court
project
is
really
fairly.
There's
really
only
one
core
deliverable
here.
D
A
Yeah
that
that
was
my
assumption
as
well
is
that
the
the
we've
we've
achieved
success
if
we
successfully
get
rid
of
this
dependency
in
the
Palm
file,
eventually,
not
not
now
not
immediately
right.
We
want
plenty
of
time
to
do
it
compatibly,
but
if
we
compatibly
remove
this
dependency,
that's
a
big
victory.
C
Yeah
and
then,
as
far
as
those
dates
are
concerned,
I
think
we'll
we'll
have
a
more
realistic
understanding
of
how
long
this
will
take.
Once
we
once
once,
we
have
a
working
end-to-end
test
with
Rusty
with
gitlab
for
Jay,
and
that's
what
that?
That's,
why
it's
so
important
to
get
to
that
to
get
to
that
first
draft
or
first
end-to-end
test,
because
that'll
inform
us
how
long
all
this
other
stuff
is
going
to
take.
A
A
A
So,
let's,
let's
do
that
in
the
conversation
in
the
chat
channel
to
see
if
we
can
find
a
time
I've
I
deeply
appreciated
that
Basel
was
here
today.
I
want
to
be
sure
that
we
find
a
time
that
works
for
him
on
the
west
coast
of
the
United
States,
so
west
coast
of
North,
America
and
I
would
love
to
have
Fram
here
as
well
and
Chris.
We
want
to
be
sure
you're
here
also.
C
Also
I'm
also
fine,
with
asynchronous
asynchronous
questions
as
well.
I
mean
you
know,
especially
if
they,
especially
if
there
are
debugging
issues.
If
they
can
be
described
in
writing
with
a
lot
of
detail,
then
I
could
just
reply
to
that
whenever
I
get
the
message
which
could
be,
you
know
different
a
different
time.
C
B
Thanks
for
that,
and
one
more
thing
that
I
would
like
to
discuss
is
regarding
the
what
yeah
in
the
gsoc
office
hours
Chris
said
to
in
what
was
that
I
wrote:
yeah
development,
the
mailing
list
yeah.
So
what?
How
are
you
planning
to
engage
the
community
more
in
this
project
because,
like
something
on
that
sort
was
discussed
in
the
gsoc
office
hours.
D
Yeah
so
Mark
What
opinion
about
this.
A
D
A
C
Good
I'm
afraid
you
might
not,
you
might
not
be
able
to
find
too
many
people
who
are
willing
to
do
that.
In
my
experience,
I've
I've
begged
people
to
make
to
test
changes
to
this
plugin
and
gotten
very
few
responses
in
the
past.
So
it
doesn't
hurt
to
ask,
but
you
might
have
to
prepare
yourself
for
the
answer
that
you'll
have
to
do.
The
testing
on
your
own
yeah.
A
That's
been
my
Universal
experience
with
the
git
plug-in.
Is
I
I
regularly
ask
oh,
could
you
please
test
this?
This
unreleased
thing
and
yes,
they'll
all
test
it
after
I've
released
it
and
they'll
test
it,
and
then
they'll
complain
that
I
made
a
mistake
by
releasing
it
before
you
know,
and
that's
just
the
nature
of
it
right.
A
B
A
It
looks
great
now
I
did
have.
We've
got
this
Mentor
checklist
that
I
put
on
the
list.
I
wanted
to
be
sure
we're
okay,
oh
oh,
we've
got
one
open
question
still
how
your
time
works
out
in
terms
of
when
you
are
on
vacation
breaks,
Etc
so
exams.
Is
that
already
covered
in
your
timeline?
If
so,
then
we
can
call
that
done.
If
not,
we
probably
want
to
be
sure
that
that
we
know
when
you're,
when
you're
not
available.
So
we
don't
don't
get
surprised.
B
So
I
I'm
I
will
be
visiting
the
coding
phase,
one
with
my
examination
from
July
I
I.
Think
I
wrote
it
somewhere
less
less
available
due
to
end
semester,
examination
July.
B
Unavailable
I,
don't
think
so.
I
will
be
doing
some
things,
because
this
is
quite
a
frustrating
project.
To
be
honest,
I
have
a
lot
of
errors
in
debugging.
This
and
I'll
have
to
work
pretty
hard
on
this.
Otherwise
this
can
get
messy
a
lot.
I
don't
want
any
regression.
So
yeah.
D
Okay,
I
have
I
actually
have
something
to
add
because,
like
we
got
in
community
feedback,
we
already
have
some
because
like
if
we
go
to
together
Channel
oh
can
we
go
and.
D
Gotta
bug
you
told
yeah
because,
like
like
the
mic
like
the
commenter,
he
actually
got
back
to
us
saying
like
that,
might
be
a
like
a
list
so
like
they
want
to
follow
up
on
this.
So
if
we,
if
we
go
to
yeah,
that
would
reply
so
last
one
last
review,
so
you
may
want
to
play
for
ask
him
like
what
kind
of
issues
he
has
in
mind.
You
may
want
to
work
on
my
juice
on,
so
this
is.