►
From YouTube: Custom Distribution Build Service kickoff 2020 05 08
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
A
A
A
A
A
C
A
So
looking,
can
you
see
it
yeah.
C
A
Yep,
so
I
just
wanted
to
go
over
a
couple
of
things
since
this
is
the
kickoff
meeting
like
what
is
this
I've
written
it
down
in
their
meeting,
so
I'll
just
go
over
some
of
the
items
and
if
time
permits,
I
could
just
go
over
the
design
right,
yeah.
So,
first
of
all,
we
would
like
to
finalize
the
days
and
times
of
the
two
meetings
with
the
mentors
per
week
so
because
Oleg
said
it's
up
to
the
team
according
to
them
Alec.
A
C
Sometimes
we
see
very
successfully
because
I
know
that
you'll
be
iterating
over
stuff
really
quickly,
and
it
just
gives
you
a
chance
to
ask
like
questions
twice.
So
you
know
you
have
you
know
we
can
work
on
things
and
then
you
know
you
feel
worth
it
then
like
an
easier
chance
just
to
sync
up
in
person.
Okay,
if
that
works,
your
UI
I
feel
good
twice
a
week
is
good
I,
don't
know
I,
don't
know
whose
it's
a
CD
foundation.
B
C
C
A
A
C
C
A
C
A
So
we'll
have
to
add
that
until
you
decide
the
timings
we'll
add
it
to
the
Jenkins
event
calendar
the
project
page
and
this
meeting
yeah.
Of
course
we
have
got
at
this
meeting
notes
to
the
page,
so
yeah
I'll
do
that
and
I
would
be
using
this
color
scheme.
If
you
guys
are
just
copied
from
the
last
times
I
guess
it
was
a
multi
branch,
github
sauce,
plugin
yeah.
They
use
the
kind
of
done
working.
Progress
not
started
yet
I.
A
Think
I
have
that
already,
but
I
just
put
it
on
the
side
of
the
items
so
that
I
don't
have
to
assign
everything
by
myself.
So
I
can
just
throw
you
know
you
can
whenever
you
log
into
this
document
is
easier
for
you
to
know.
What's
being
done
and
what's
in
progress
and
what's
not
started
you
so
once
the
meetings
and
I'll
just
put
them
down
I'm
giving
you
ready.
C
A
C
A
I
drew
up
this
mailing
list.
I
think
I'm,
not
sure,
if
you're
a
part
of
this
discussion,
when
the
initial
project
idea
came
out
like
yeah.
So
this
was
the
initial
discussion
that
happened.
I
put
it
in
a
meeting
like
then
have
a
look.
This
was
the
one
yeah
we
had
a
huge
I
mean.
I
should
call
quite
a
huge
discussion
on
this
yeah.
It's
a
huge
thread.
You
don't
have
to
read
all
of
it
but
yeah.
These
are
kind
of
the
stakeholders
that
were
quite
interested.
One
was
Chris.
A
C
A
Yeah,
so
he
was
Lee
was
another
one,
so
they
were
quiet.
A
couple
of
stakeholders
interested
in
this
project
idea
I'm,
not
too
sure
exactly.
How
do
you
want
to
proceed?
Do
you
wanna
send
out
a
general
statement
in
the
mailing
list
introducing
the
stakeholders
to
the
so
that
if
interested
they
could
just
join,
you
know
you
want
to
send
out
and
in
personalized
email
I'm,
not
too
sure
how
it
goes
on.
So,
if
you
guys
would
guide
me
on
that,
that
would
be
amazing.
D
D
C
Right,
that's
nice
thinking!
It's
like
they're
already
interested
in
threat,
so
they're
gonna
be
a
following
update.
Sense,
always
good
to
just
continue
to
say:
hey!
This
was
actually
selected.
This
is
working
on.
You
can
join
our
jitter
channel
if
you
would
like,
because
that
helps
a
lot
to
the
community
gives,
maybe
if
they
don't
really
sound
of
meetings,
but
they
can
provide
some
asynchronous.
A
I'm,
not
too
sure
how
relevant
it
is
now
but
discuss
with
Mendez
about
code
reviews,
and
he
also
reissue
trackers,
because
I'm
hoping
that
the
project,
since
the
back
end
would
be
Britain
spring
good,
a
Java,
that's
up
for
discussion
still
but
yeah
whether
we
should
use
how
element
is
it
to
discuss
it?
Now,
you
want
to
defer
it
for
later.
A
So
tell
me,
or
so
since
I'm
the
student
that
would
be
expected
to
derive
this
but
I'm
comfortable
with
using
both
the
github
issue.
Tracker
I've
seen
a
lot
of
discussions
happening
on
the
Jenkins
mailing
list
as
to
whether
the
github,
which
there's
been
a
lot
of
discussion
on
using
just
yet
how
about
using
just
you
know,
I,
don't
have
any
strong
opinions
on
them,
but
if
you're
using
github
then,
since
both
the
code
and
issues
can
be
kept
in
the
same
place,
I
think
that's
a
good
idea.
What
do
you
guys
think.
D
B
B
D
So
a
second,
this
recommendation,
github,
which
is
a
quite
convenient
for,
is
a
little
project.
Why
we
used
children.
Jenkins
heavily
is
because
we
need
a
changes
across
projects
comprehends
misdirecting.
It
hop
was
pretty
weak
about
that,
but
now
even
there
it
makes
sense
and
for
the
dated
project
like
a
distribution,
build
service,
it's
much
easier
to
use
it
hot
wishes,
and
if
you
want
to
reference
something
in
Jenkins
Judah
used,
you
still
can
do
that.
D
B
D
So
I
can
provide
you
some
examples.
You
know
a
Windows
service
record
project.
We
have
already
agreed
to
move
forward.
Github
wishes
in
Jenkins
ax,
most
likely
they
will
be
using
github
issues
as
well,
and
it's
highly
unlikely
that
they
will
be
using
Jenkins
JIRA
and
for
other
projects
is
basically
up
to
project
contributors
and
the
maintainer
to
choose
so
and
person
expect
that
many
projects
will
go
for
this
github
wishes
for
this
year.
D
A
B
A
It's
not
going
to
follow
the
normal
plug-in
life
cycle
right
because
it's
not
a
plug-in
and
wouldn't
plug
into
the
Jenkins
ecosystem.
Right,
yeah
yep,
it's
going
to
be
a
it's
going
to
be
a
separate
project,
so
I
don't
think
we
would
I'm
not
sure
how
to
go
about
the
hosting
I've
included
in
my
proposal.
Since
it's
a
bit
different
mentioned
that
there
are
had
childhood
is
to
launch
services
using
the
junk
in
the
infrastructure.
I'm
assuming
it
won't,
follow
the
this
part
here.
D
Generally,
we
go
through
this
process
anyway.
Obviously
we
didn't
apply
at
the
same
checks
if
the
repository
isn't
the
plug-in
so
how
we
usually
approach
it
for
new
projects.
You
create
a
repository
skeleton
in
your
own
repository
and
then
once
you're
ready.
We
host
it
on
Jenkins,
so
preferably
to
do
it
before
the
end
of
the
community
Banach
phase,
so
that
we
have
both
admissions
and
others
areas
fixed
before
you
start
coding,
but
it
shouldn't
take
long
for.
D
A
Assuming
since
because
this
really
cool
and
a
LeBron
James,
it's
kind
of
odd,
the
banner
will
be
separate
from
the
front
end.
Initially,
I
was
thinking
that
would
be
two
different
repositories
because
then
it's
easier
to
pack,
the
JavaScript
HTML
ends
yes
or
whatever
it
you're
going
to
use
in
wonderful
and
then
the
back-end
service,
in
the
other
episode
that
they
are
quite
modular
and
separate.
But
if
that's
what
that's?
What
the
way
I
was
thinking
about
it.
D
Don't
think
too
many
benefits
on
dirt,
because,
whatever
you
do,
you
already
have
custom
work
package,
a
custom
work
megachurch
is
going
to
be
a
part
of
the
backend
and
most
likely
you
will
have
to
submit
some
fixes
or
patches
to
custom
or
package.
A
new
project
I
wouldn't
expect
everything
to
be
in
a
single
repository,
and
it
may
also
influence
your
decision
about
where
you
put
the
project.
A
C
B
C
D
Yeah,
maybe
we
will
need
to
update
our
documentation
soon.
We
have
just
created
a
hosting
team
one
week
ago,
and
one
of
responsibilities
of
first
empty
more
would
be
to
improve
documentation
equivalent
to
removing
this
hosting
plugins
wiki
page
to
JSA
or
and
breaking
it
our
developer,
documentation
pages,
but
in
principle
it's
the
same
and
more
awaits
were
straight
forward
for
JSOC
projects
because
on
JSOC
projects
already
considered
percepted.
So
it's
not
something
we
will
be
discussing
feasibility.
C
A
I
think
we
discussed
the
hosting
new
plugin
since
it's
a
project
we'll
be
following
the
similar
workflow
we'll
get
that
up
before
the
coding
phase
starts.
Apart
from
the
idea
of
this
numbered,
so
I
guess
we're
not
going
to
be
using
I
guess.
Last
year,
Oleg
the
entire
G
sub
team
I
mean
that
ring
so
projects
use
the
JIRA
scrappin
the
JIRA
boards.
So
would
would
it
be
following
the
same
procedure
this
time
around,
so
we.
D
D
D
C
C
I
think
that
was
me
singing,
because
it's
really
no
you
get
it's
very
easy
to
get
very
excited
about,
because
you're,
like
oh
I,
can
do
all
this
these
things,
and
maybe
things
take
longer
than
you
originally
thought,
or
it's
like
you,
just
let
just
put
too
much
and
it's
just
impossible
to
get
it
done
easy
to
translate
it
to
the
next
forward.
Then
I
think
I
just
don't
have
to
create
birth
twice.
That's
pretty.
A
C
A
D
If
you
use
github
project
github
project,
you
can
put
code
tusks
and
non
code
tusks,
so
poor
tusks
can
even
have
automation.
So,
for
example,
it
have
wishes.
They
can
believe
to
pull
the
requires,
put
requests
in
there
to
make
it
remote
between
stages
and
all
there
are
other
things.
But
if
you
need,
you
can
just
add
a
task
which
is
not
really
implying
code
and
you
cannot
add
a
task
which
also
doesn't
get
officious.
If
you
want
to
avoid
putting
tasks
or
create
a
blog
post,
there.
C
A
So
trainings
I
mean
knowledge,
structures
or
training
sessions.
I
think
that
applies
if
I
need
anything
like
bring,
like
maybe
I,
think
last
year
there
was
one
of
those
training
sessions
that
just
in
for
debugging
in
Java,
so
it
will
discussed
in
yesterday's
G.
So
I
mean
it's
not
yesterday's.
They
were
meeting
on
Wednesday
that
there
would
be
common.
A
There
would
be
common
knowledge,
transfer,
search
means
like
who's
like
creating
a
plug-in
or
some
thought
so
I
think
that
really
is
on
demand.
So
if
at
all,
I
need
something
that
that
team
could
have
a
training
session
on,
then
I
could
request
it.
Otherwise
that
topic
is
really
is
really
personal.
I
get.
D
You
know
this
so
and
specifically,
your
project
guide
for
creating
plugins
won't
really
how
you
see
objects.
So,
for
example,
if
you
want
to
have
a
good
day
for
custom
work
packager.
Firstly,
there
should
be
already
recording
somewhere.
If
you
want
to
have
a
fresh
recording
together,
we
can
organize
that.
D
Well,
I
think
because
we
get
contributions,
focus
on
work
packager.
This
project
was
slightly
abundant
by
any
different
past
six
months,
due
to
some
issues
non
related
to
technical
ones,
but
yeah
right
now,
I'm
fully
able
to
contribute
the
editable
patches
and
if
somebody
else
wants
to
contribute
a
will
doesn't
appreciate
you
doing
Kokoda.
If
makes
the
bull
sense,
yep.
D
A
D
A
A
The
first
meeting
with
the
hive
but
yeah
the
advices
I,
guess
that
pertains
to
stakeholders
of
experts
in
the
domain
or
whatever
we
are
dealing
with
hosta
for
the
multi
branch
by
plugin
plugin,
forget
lab
I
think
it
was
because
he
was
doing
most
of
the
reviewing
and
I'm
that
but
I
still
in
our
case,
we
already
have
Rick,
oh,
maybe
because
per
packet,
if
at
all
you're
making
patches,
we
have
Oleg
so
I
guess
those
would
be.
That
in
question
obviously
would
be
reviewing
code
yeah.
A
A
D
A
Yes,
I
think
we've
discussed.
The
last
topic
is
the
new
github
repository
when
the
junk
in
CIO
I
think
Rick.
You
put
this
on
right,
not
sure.
If
we
should
interviewing
the
14
I
think
that's
already
answered.
It
would
be
nice
to
do
it
before
the
community
bonding
phase.
So
here
I'm
just
taking
this
comment
out
since
the
questions
already
answered.
A
Okay,
cool
yeah,
so
that's
about
all
of
the
I
mean
that's
about
all
of
the
topics
that
we
have
to
comfort
in
the
kickoff
meeting.
Is
there
okay
yeah
one
more
thing
before
you
move
on
to
maybe
the
design
of
the
zoom
link,
so
I
guess,
since
Rick
already
has
access
to
the
CD
foundation,
but
we
might
have
conflict
so
is
assuming
going
to
be
given
to
one
of
on
Windows.
D
D
A
D
A
B
A
C
A
A
C
A
B
C
D
D
A
Yep,
so
this
was
one
of
the
discussion
that
we
had
initially
when
the
project
was
announced.
I
think
Rick
mentioned
Bolin
because
he
was
very
familiar
with
it,
but
then
electoral
does
that
it
might
be
a
bit
think
it's
advisable
to
choose
a
certain
language
that
then
you
get
a
lot
of
community
feedback
comments,
easier
to
code
reviews
and
to
deploy
so
spring
actually
yeah.
We
can
actually
have
a
Java
based
solution
as
well,
but
yeah.
This
was
the
reason
we
were
thinking
of.
A
Spring
Buddha
was
because
it's
just
I
mean
it
could
easily
integrate
with
the
front
end
and
it's
it's
almost
judged
Java
actually
just
put
annotations
and
just
the
ease
of
deployment.
And
now
we
have
a
lot
of
easy
to
spin
up
us
over
and
you
know
have
a
container
and
stuff.
So
that's
what
that's
the
reason
I
wrote.
The
Java
Springwood
bye
dear
I'm,
open
to
suggestions
before
we
yeah
before
we
we
can
so
yeah,
just
just
throw
in
a
tidy.
D
C
So
I
just
don't
think
I
like
it
most
like
what
would
be
the
best
thing
to
be
able
to
encourage
usage
her
or
like
continued
development
and
I
think
it
might
be,
and
I
don't
know
it's
like
we
Java
I,
don't
know
Oh
like
brick
like
if
there's
an
PNM,
oh,
it
would
be
able
to
go
huge,
encourage
feature
development
for
this
or
like
to
be
able
to
yeah
Selena's
gonna
knock.
It
he's
gonna,
be
well
over
the
summer.
C
D
C
D
A
C
A
C
A
A
So
yep
maybe
decide
yeah
as
and
when
we
finalized
the
technical
details.
We
could
come
up
with
maybe
double
its
the
Sailor
thing.
So
that's
like
suggest,
if
you
use
Java,
then
really
have
the
liberty
of
using
some
of
the
most
developed
I've
reason.
Now
we
can
stick
with
that
yeah.
So,
apart
from
that,
so
I
not
just
part
of
the
design
document.
Obviously
so
the
next
steps
would
be
do
we
as
we
decide
on
the
next
meeting
slots.
A
We
could
finalize
till
you
in
this
design
document
to
select
the
work
that
we
are
going
to
be
doing
over
there
coming
I
mean
coming
weeks
filled
up
into
the
community
bonding.
If
at
all,
the
design
document
gets
over
early,
maybe
we
can
subtype
for
for
the
first
stage,
so
yeah
I
think
that
that's
the
next
step
any
other
next
step.
So
anything
you
want
me
to
discuss
before
me
finish
it,
because
we
can
move
on
to
the
next
meeting
so
yep
anything
else.
B
A
Language,
okay,
yeah,
yep,
cool
yeah.
That's
all
another
thing
that
we
need
to
consider
because
the
initial
problem
is
getting
the
UI
generated
as
we
as
well
EXO.
Just
didn't
his
meetings
that
we've
had
in
the
the
doc
serious
we
still
don't
exactly
know
is
that
we're
gonna
get
all
of
the
field,
so
we
could
create
scale
it
in
the
nap.
So
once
we
actually
have
that
we
can,
you
know,
have
the
localization
done
so
I'll.
Add
that
point,
since
you
mentioned
DUI.