►
From YouTube: GSoC Office Hours [EMEA] - March 10, 2022
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
Okay,
good
so
good
evening,
good
day
good
morning,
everybody
thank
you
for
joining
this
edition
of
the
google
summer
of
code
office
hour
office
hour
means
that
we
meet
every
two
week
or
every
week
to
just
discuss
and
answer
whatever
question
you
have
related
to
the
google
summer
of
code
program
managed
by
the
jenkins.
A
So
let's
quickly
walk
through
the
agenda.
A
The
first
thing-
and
I
can
immediately
jump
in
it.
So
I'm
happy
and
proud
to
say
that
the
jenkins
project
has
been
officially
accepted
as
part
of
the
google
summer
of
code
2022
as
a
mentoring
organization.
A
C
A
A
Don't
forget
that
if
you
want
to
use
this
channel
as
efficiently
as
possible,
you
can
always
submit
your
questions
directly
in
this
document
as
comments
or
mention
your
question
in
the
getter
channel
and
say
I
would
like
this
discussed
in
depth
during
the
office
hour.
I
want
to
add
and
to
remind
of
what
are
the
upcoming
dates.
What
is
the
schedule
in
front
of
us?
What
are
the
important
milestone?
A
A
There
was
a
very
good
demo
done
last
week
on
the
recording,
but
we'll
come
back
to
that
so
opening
to
the
the
floor
to
whoever
is
here.
What
are
your
questions.
D
My
first
question
is:
it
is
possible
to
bring
a
new
ideas
or
these
ideas
fixed
for
the
2022
google
summer.
Of
course,.
A
The
answer
to
that
questions
are
two
no's,
so
or
yes
depends,
depends
shouldn't
do
too
much
fun
about
that.
So
the
first
one
is,
it's
not
closed
at
all.
Okay,
we
still
have
time.
We
are
not
limited
to
the
existing
project.
Ideas
that
are
registered.
A
A
No,
you
still
can
go
on
the
the
end
date.
I
think
further
than
that
would
not
go
is
when
all
the
submissions
are
registered.
So
this
is
end
april.
Okay.
Now
so
you
have
one
month
to
to
create
your
project.
Discuss
it.
Have
it
give
it
substance,
prepare
your
your
submission
and
then
have
it
discussed
by
the
the
community.
A
E
I
have
a
doubt
regarding
the
automatic
get
caching
maintenance
thing,
so
basically
yeah
I've
gone
through
the
entire.
You
know
get
maintenance
thing
on
the
get
sem
website,
okay
and
then,
after
that,
I
thought
we
are
going
to
implement
it
via
the
cli
okay,
but
then
mark
stated
it
in
the
chat
that
we
won't
be
using
the
cli
version
we'll
be
have
to
we'll
have
to
be
coding
it
okay,
so
I
am
not
sure
like
what
is
the
exact
architecture?
E
B
Good
question
john
mark
you,
okay,
if
I
answer
yeah
sure
I
just
wanted
to
okay,
so
so
my
my
assumption
is
that
we
would
use
command
line
git
to
perform
the
operations
because
it's
the
most
reliable
and
it's
the
reference
implementation
for
all
git
operations
in
the
get
plug-in.
B
E
B
So
so
we
lost
your
sound
you,
you
asked
the
question
you
asked
seemed
to
be
hey,
since
we
can't
use
the
git,
since
we
need
to
support
old
versions
of
command
line.
Git.
E
Yeah
yeah
as
we
actually,
you
stated
that
we
have
to
support,
send
os
ubuntu,
18
ubuntu
version
18.,
so
basically
that
so
in
those
operating
systems
by
default
it
doesn't
support,
get
maintenance.
Okay.
So,
regarding
that
I
haven't
have
an
issue
like
how
are
we
going
to
implement
that?
Are
we
going
to
use
like
alternatives
for
that
or
how.
B
Most
of
the
operations
that
are
implemented
in
get
2.30
and
later
as
get
maintenance
are
actually
can
be
expressed
with
more
fundamental
git
commands
in
the
earlier
versions
of
git.
So
what
has
to
be
done
is
identify
which
maintenance
operations
we
want
to
do
and
how
we
express
those
maintenance
operations
as
fundamental
get
commands.
That
will
work
with
a
specific
those
specific
git
versions
so,
for
example,
get
maintenance
to
schedule.
Gc
can
be
done
just
by
a
jenkins
conceptually
by
a
jenkins,
cron
schedule
or
a
scheduled
task
that
performs
calls
the
command
git
gc.
B
So
because
of
that,
we
can
support
those
old
old
environments,
even
though
they
don't
provide
the
get
maintenance
command.
They
do
provide
the
other
baseline
commands,
and
one
of
the
important
explorations
is
to
be
assured
that
we
get
what
we
want
out
of
calling
get
gc
so
does
does
that
answer
your
question.
Khrushchev.
E
B
Correct
it's
that,
in
order
to
do
the
maintenance
operations,
we
will
use
foundational
git
commands
that
have
been
there
for
a
very
long
time.
Now.
Part
of
the
exploration
may
discover
that
command
line
get
1.8,
which
is
still
bundled
with
centos
7
is
so
old.
It
doesn't
have
certain
operations,
and
in
that
case
then
we
would
have
to
show
the
user
on
the
ui.
This
operation
is
not
available
because
the
get
version
you're
using
can't
do
it.
B
B
And-
and
so
the
git
plug-in
actually
already
has
logic
inside
of
it
that
detects
the
version
of
command
line,
git
that's
available
to
it,
and
it
can
do
logic
based
on
that
saying,
hey
this
version
is
new
enough.
I
can
use
these
new
modern
commands
or
it's
older.
I
have
to
do
some
ugly
work
around
or
I
have
to
change
and
tell
the
user.
I
can't
do
this
work
at
all,
because
your
command
line,
get
version
is
too
old.
Martin
does
was
that
sort
of
the
the
idea
you
were
suggesting.
D
Yeah
or
or
just
make
it
configurable
that
when
you
start
this
checkout
function
that
you
want
to
use
the
cache
or
not
by
default,
yes,
fine,
but
when
you
doesn't
not
want
you,
then
you
just
use
the
old
one
things.
B
E
Thank
you
mark
that
has
addressed
my
question.
E
Yeah
there
was
another
question
related
to
the
git
plugin
and
the
get
client
plugin.
Okay,
like
can
you
like?
Can
you
suggest
me
where
to
start
like
exploring
from
because
I'm
not
getting
a
starter
class
like
there's
so
many
classes,
and
I'm
I'm
trying
my
level
best
to
keep
searching,
but
then
I'm
not
finding
anything
to
start
from.
A
If
I
because
I've
been
discussing-
and
I
understand
the
question
the
following
way
is-
and
it's
also
a
general
question-
you
discover
a
new
plugin
and
you
want
to
understand
its
logic
and
to
see
where
is
the
head?
Where
is
the
tail
and
and
where
the
legs,
and
so
where
do
you
start?
Where
do
you
start
exploring
the
code
of
of
a
plugin,
so
my
general
hint
is
look
at
the
tests.
B
Okay,
all
right,
exploring
the
javascript
so
then
yeah
so
then
exploring
the
java
code
yeah,
that's
at
least
for
me.
I
tend
to
do
it
in
a
debugger.
I
tend
to
do
it
by
running
the
tests
I
tend
to,
but
pretty
quickly
I
get
bored
with
that
and
have
to
go
using
it
interactively
to
see
what
the
features
are
at
the
user
level.
B
You
had
asked
a
question
in
getter
just
10
or
12
hours
ago.
That
was,
I
thought,
a
user
question
and
there
I
can
point
you
to
some
good
videos
and
to
some
some
good
introductory
materials,
some
tutorials
that
will
let
you
see
how
users
use
it
now,
that's
different
than
the
code
right
that
won't
introduce
you
to
the
core
code
in
the
plugin,
but
it
will
introduce
you
to
the
user
concepts
and
for
me
those
are
probably
as
valuable
for
a
new
person,
starting
as
anything
about.
What's
inside
that
code,.
E
B
A
Do
you
want
to
add
more
question?
I'm
sorry,
I
butchered
the
pronunciation
of
the
name,
so
I
apologize
for
that.
But
do
you
have
other
questions
related
to
that
yeah?
That.
A
Okay,
great,
I
see
that
vihan
raises
in
vyan.
You
can
go
ahead.
G
Yes,
so
I
had
a
question
regarding
the
scope
of
the
project
of
pipeline
step:
documentation,
generator
improvements
so
from
where,
for
from
what
I
understand
of
the
project
is
the
pipeline
step
generator
repo
is
fetching
the
documentation
for
the
pipelines
and
it
is
feeding
it
to
jenkins
dot
io
correct,
and
what
does
what
this
project
wants
us
to
do?
Is
we
want
to
improve
how
we
treat
that
data
which
is
fetched
and
not
how
we
face
the
data
right.
B
D
Exactly
is
there
any
things.
F
F
B
G
Yeah,
so
whatever
changes
we
would
do
is
how
we
would
read
that
data
and
basically
represent
that
in
a
much
better
way.
So
the
user
can
read
it
easily.
B
Correct
right,
so
so
we
believe
that
most
many
of
the
problems
there
are
related
to
presentation
as
to
how
does
the?
How
does
the
poor
user
consume
this
material?
Now
there's
plenty
of.
We
need
a
lot
more
material,
but
with
the
current
presentation
it
has
many
weaknesses
that
are
identified
in
that
idea.
G
Okay,
so,
regarding
that,
the
question
I
had
was
like,
for
example,
we
make
some
changes
to
how
we
present
the
data,
so
won't
that
look
odd
on
the
jenkins
or
io
website,
because
that
is
only
the
pipelines
that
documentation
has
been
changed.
The
way
we
present
the
data,
but
the
others
are
still
in
the
similar
format.
Basically,
I
was
thinking
of
trying
to
put
some
visual
aids
for
the
user
to
for
them
to
follow
the
links
to
some
other
pages
and
not
just
keep
the
data
on
the
same
page.
G
So
will
that
disturb
the
behavior
of
the
whole
website,
for
example,
the
flow
of
the
whole
website?
I
don't
want
to
decide.
B
Good
question:
I
don't
think
it
will
disturb,
because
the
pipeline
stepped
dock
generator
continues
to
generate
ascii
dock,
it
will
generate
a
dock
and
that
ascii
dock
it's
perfectly
valid
for
it
to
contain
links
and
and
if
you're,
generating
ascii
dock
and
they
link
to
other
things
that
that
seems
like
a
very
helpful
helpful
way
to
do
it,
and
if
we
discover
by
the
work
on
this
that
we
should
also
do
similar
improvements
elsewhere
on
the
jenkins
dot
io
site.
That's
a
great
outcome.
B
G
Yeah,
actually
so
what
I
was
doing
was
like
I
was
browsing,
the
documentation
for
various
different
technologies
frameworks,
and
I
was
like
finding
which
one
was
more
visually
appealing
and
which
one
I
found
to
be
like
easier
to
comprehend.
So
one
such
experience
for
me
was
studying
django,
so
I
started
in
a
project
which
was
like
from
scratch,
and
I
found
the
documentation
to
be
really
helpful
and
like
most
of
the
people
who
would
help
you
would
directly
point
you
out
to
the
documentation,
because
it
was
very
easy
to
read
and
so
yeah.
G
C
Yes
mark,
I
would
like
to
talk
about
automatic
specification
generator
for
jenkins
rest
api,
and
this
is
my
first
office
hour
and
I
would
like
to
know
much
about
this
problem
statement
from
you
guys.
First
of
all,.
B
Talk
about
what
what
the
general
overview
is
so
jenkins,
a
rest
api
that
is
derived
from
simple
annotations,
that
developers
add
to
their
plug-in
source
code
to
declare
that
something
should
be
a
rest
api
endpoint.
It's
got
all
sorts
of
automatically
naturally
created
rest
api
endpoints
and
you
can
see
those
as
you
start
your
own
jenkins
and
at
the
bottom
right
hand,
corner
of
the
page.
You'll
see
a
hyperlink
rest
api
and
you
can
get
some
very
fast
exploration
of
what
are
the
rest
apis.
B
B
So
there's
a
lot
of
rest
api
documentation
already,
but
what
there
isn't
is
a
a
formal
description
and
especially
not
a
formal
description
in
open
api
format
of
those
rest
apis
and
and
that
lack
of
a
formal
description
means
there's
it's
also
more
difficult
for
people
to
consume
the
rest
api,
because
there
are
things
they
may
not
discover,
simply
because
they
don't
know
where
to
navigate
in
the
jenkins
pages.
So
a
formal
description
of
the
rest
api
would
have
to
be
extracted
from
jenkins
and
its
plugins.
B
It's
somewhat
similar
to
the
the
pipeline
step.
Documentation
generator
that
was
described
earlier
to
in
response
to
vihan's
request
is
that
what
that
thing
does
is
it
looks
at
all
the
jenkins,
plug-ins
and
extracts
pipeline
documentation
from
them.
What
this
would
be
doing
is
look
at
all
the
jenkins
plugins
and
extract
the
rest,
api
definition
from
them.
C
Okay,
after
yeah
that's
pretty
much
clear
after
extracting
those
apis,
we
would
be
you
know,
making
use
of
those
for
documentation
and
swagger
right.
B
C
New
to
me,
yeah.
B
Yeah,
so
so
I
think
my
answer
is
that's
when
you'll
have
to
explore.
I
I
would
not
expect
it
jenkins
is
a
mature
application.
Mature
is
a
polite
way
of
saying
that
its
source
code
was
created
15
years
ago,
and
it
has
evolved
over
15
years,
so
it
was
well
before
the
concept
of
microservices,
right
and,
and
so
so,
you're
certainly
correct.
It
won't
look
like
current
microservice
based
rest
apis.
B
However,
the
the
crucial
thing
here
is
not
to
make
it
look
like
current
micro
services,
but
rather
to
to
document
and
describe
what
is
there
so
that
people
can
use
it
more
effectively
and
and
when
I
say
document
the
awkward
part
there
is
many
people
think
document
means
write
documentation.
In
this
case,
it's
really
not
right
documentation.
C
Yes,
yes,
I
have
actually
gone
through
java
documents.
We
have
this
website
right
stapler.
I
have
gone
through
java,
docs
page
and
I
started
inspecting
in
that
those
urls
yeah
when
we
inspect
on
ui,
we
get
the
urls
right
and
I
have
gone
through
the
code
and
I
can
relate
the
packages.
Whatever
are
there
in
the
jenkins
core
and
in
the
ui.
Are
these
aps?
Are
we
going
to
you
know
document
I
mean
swagger
or
are
there
anything
different.
B
I
think
the
answer
there
is
yes,
we
would
want.
We
would
want
an
api
document
that
we
would
want
a
swagger,
slash,
open
api
description
of
all
the
rest
apis
that
jenkins
can
provide
with
its
set
of
plugins
loaded.
So
I'm
not
sure
I'm
answering
your
question
baru.
Could
you
give
me
more
clarification.
C
Probably
I
need
to
do
more
homework
before
actually
asking
this
question
I'll,
come
up
for
next
episode
and
shoot
you
with
more
questions
but
yeah.
This
actually
made
me
a
bit
clearer
morning.
I
was
so
bewildered.
I
was
like.
Am
I
going
to
do
this
or
not?
I
explode
and
explore,
and
I
said
okay.
This
is
not
my
thing
probably,
but
right
now
it
gave
me
a
bit
of
hope
at
least
yeah,
so.
C
Oh
yeah,
that's
great
to
hear
actually
regarding
this
gcos
proposal.
My
question
is:
when
you
start
a
problem
statement,
you'll
start
with
one
solution.
In
your
mind
I
mean
to
say
before
writing
a
proposal.
I
should
have
some
idea
right.
Okay,
this
is
what
I'm
going
to
do.
This
is
my
way
of
approach,
but
especially
when
you
start
and
when
you're
in
the
middle
of
something
some
things
may
deviate
something
or
some
other
thing
will
come
up
in
the
middle.
C
So
then
it
is
not
going
to
be
what
we
have
started
at
first
right.
Maybe
it
won't
be,
as
we
have
mentioned
in
the
proposal.
So
how
would
it
be?
It
is
fine.
B
Excellent
question:
yes,
it
is
fine,
so
so,
to
give
a
very
specific
example,
last
year
we
defined
we
defined
and
accepted
a
project
plan
to
do
some
particular
improvements
to
the
get
plug-in,
and
we
realized
roughly
halfway
into
it,
that
we
had
to
change
the
definition,
and
it
was
perfectly
fine.
We
agreed
with
discussed,
did
did
the
modifications
and
implemented
the
modification
modified
version.
So,
yes,
we
realized
that
project
plans
do
change.
B
The
the
research
up
front
helps
us
reduce
the
volume
of
project
change
right
and
and
many
times
the
projects
complete
exactly
as
expected,
and
that
says
we
did
really
good
research.
But
if
something
surprises
us
during
the
execution
of
the
project,
we
have
full
flexibility
to
make
changes
as
needed.
A
Just
to
to
to
position
the
the
first
part,
the
research
so
as
mark
stated,
the
the
research
is
subject
to
change,
because
you
discover
things
in
this
modern
way
of
developing
the
document
that
you're
going
to
write
is
very
important
for
us
to
see.
Did
you
understand
the
problem
that
we're
trying
to
that?
We
are
trying
to
solve.
A
Do
you
own
it?
Do
you
know
what
are
the
different
pieces
of
it?
Do
you
come
with
something
positive
and
creative
to
to
answer
it?
So
it's
just
one
step
in
the
complete
building
process
of
the
project,
but
there
is
an
intermediate
step
where,
as
we
don't
have
place
or
room
for
every
candidate,
we're
going
to
use
this
first
analysis
and
study
to
select
the
people
that
will
continue
together
with
us
in
this
adventure.
C
Yeah,
thank
you
both
actually
like
coming
to
your
question.
Mark
I
mean,
did
you
understand
the
problem
statement
completely
so
currently
there
are
some
parts
from
the
problem
statement
which
I
am
not
clear
right
now
so
going
on.
It
may
take
some
days
to
completely
understand
and
come
up
with
the
solution.
Actually
time
answers
everything
as
far
I
know.
C
So
what
my
question
is:
what
are
the
other
ways
of
talking
to
mentors
or
like
whoever
can
help
us?
Are
those
only
g-shock
ours
and
guitar
channel,
or
do
we
have
any
other
calls
even.
A
A
Can
you
comment
on
it,
and
this
is
also
the
way
open
source
works,
and
this
is
the
complete
purpose
of
google
summer
of
code
is
to
teach
the
ways
of
open
source
and
a
very
important
element
of
that
is
that
you
we
work
publicly,
and
that
means
you're
going
to
write
your
ideas
and
share
them
and
propose
them
for
discussion.
Somebody
will
will
will
come
with
with
corrections,
or
did
you
think
about
that
or
it's
this
process
that
you
should
start
as
early
as
possible.
C
C
Thank
you
all
so
much
so
I
yesterday
I
have
actually
raised
a
pr
on
genuine
migration.
I
actually
started
off
contributing
you
know
small
one
by
one
probably,
and
I
have
seen
a
video
on
hacktoberfest,
which
was
phenomenal.
I
actually
loved
that
video
and
I
have
seen
there
are.
C
There
can
be
done
something
more.
It
is
actually
now
there's
something
called
adoption
right.
So
can
we
go
on
and
contribute
simultaneously
along
with
these
writing
the
proposal-
and
this
would
add
some
benefit
to
the
proposal.
B
B
To
that
question
is
an
unequivocal
yes
now,
in
the
case
of
this
specific
example,
I
it's
not
immediately
clear
to
me
how
adopting
a
plug-in
will
help
you,
but
it's
certainly
in
on
this
specific
example,
but
it
will
certainly
help
you
understand
how
the
community
interacts.
It
will
unders
help.
You
understand
what
it
means
to
release
a
version
of
a
plugin
to
merge
pull
requests.
Those
are
all
good
things
to
learn,
so
so
no
dispute
that
adopting
a
plug-in,
I'm
not
sure
how
the
rest
api
specification
generator
will
directly
be
assisted
by
that.
B
C
Oh
wow,
wonderful
mark,
I
am
going
to
start
with.
You
know,
running
junkins
in
my
locally
so
that
I
would
understand
exactly
right
for
my
problem
statement
to
start
with
automatic
specification
generator
for
jenkins
yeah.
A
Good,
this
is
generally
the
path
that
we
recommend
that
was
also
described
in
some
documents,
so
first
run
a
local
jenkins
instance
get
familiar
with
it,
start
study
the
problem
statement
explore
and
explore
the
product
and
the
various
plugins
and
start
to
interact
with
the
community.
You
need
to
be
familiar
with
prs,
who
is
doing
what
how
it
all
works
together-
and
this
is
all
this-
this
learning
process
you
are
in
and
they
should
now
work
during
the
months
of
april.
C
Yeah,
thank
you,
but
and
that's
all
I
have.
A
Okay,
I'm
just
going
to
cover
the
two
last
points.
I'm
sorry
if
there
are
still
open
questions
we'll
have
to
push
them
for
another
session,
because
I'm
respectful
of
everybody's
time
here,
the
things
that
I
want
to
remind
everybody
is
so
the
timeline.
So
what
is
coming
next
is
described
in
the
link
that
I'm
showing
here
in
the
screen
share
the
next
import.
So
the
next
phase,
where
and
we're
started
started
march
7-
is
that
the
contributors
start
to
discuss
the
applications
ideas
with
the
mentoring
organization.
A
This
course
so
community.jenkins.io
getter
channel
these
meetings
here
and
a
very
important
mean
friend,
is
start.
Writing
ideas
start
to
flash
or
to
flesh
out
the
is
the
correct
expression,
your
project,
what
you
want
to
do
and
make
the
community
interact
with
it,
get
ideas
get
correction
for
that.
This
is
really
what
you
should
focus
on
the
deadline
for
that
is
well
the
intermediate
that
I
said
from
april
4th.
A
This
is
when
you
start
submitting
your
applications
on
the
google
system
to
declare
your
your
application,
and
normally,
if
I.
A
The
deadline
for
ending
the
application,
so
the
final
deadline
is
somewhere
in
the
april.
If
I
remember
well,
I
didn't
write
it
here,
but
in
my
memory
it's
not
good
anymore,
but
and.
A
Edition
mark
made
a
demo
we're
completely
out
of
time.
Here
we
can
revisit
it.
The
next
emea
or
europe
asia
office
hour
in
two
weeks,
or
watch
carefully,
the
the
recording
from
the
march
4
edition,
where
mark
made
the
demonstration
a
strong
reminder,
don't
try
to
edit
the
template
and
it's
no
need
to
request
editing
requests
for
it.
So
you
need
to
duplicate
the
template.
Oh.
F
A
A
And
taking
so
careful
and
well-made
notes
so
that
I
could
concentrate
on
the
conversation.
Thank
you.
Thank
you
very
much
chris
for
you
for
your
help.
I
thank
you
all
for
attending
this
session,
making
it
interestingly
interactive
and
wish
you
good
luck
and
good
work
and
meet
you,
then,
on
getter
or
other
channels.
So
I'm
going
to.