►
From YouTube: Essentials: Open Planning Meeting (2018-04-23)
Description
This is a weekly meeting to discuss the progress and plan for Jenkins Essentials, an automatically updated Jenkins distribution.
Find us on GitHub: https://github.com/jenkins-infra/evergreen
Join our Gitter chat: https://gitter.im/jenkins-infra/evergreen
Jira board: https://issues.jenkins-ci.org/secure/RapidBoard.jspa?rapidView=406
B
A
A
C
A
Yeah
so
Jeff
305
is
and
in
draft
state,
and
we
looked
through
it
a
lot
last
week
and
it
looks
really
good
to
think
you'd
think
you
were
doing
that.
Jesse
I
just
merged
Jeff
306,
which
was
the
instance
health
checking
that
you
had
worked
on
batiste
and
so
that
at
least
as
far
as
a
draft
goes
that
looks
correct,
but
the
one
thing
that
I
wanted
to
call
everybody's
attention
to
if
they
haven't
had
a
chance
to
look
at
it
was
this
bill
of
materials
Jeff.
A
E
B
B
B
E
A
Well,
I
think
and
I
didn't
think
we
would
resolve
any
of
the
overlap,
but
I
wanted
to
call
this
to
your
attention
ro,
because
these
two
I
think
will
have
a
strong
impact
on
how
we
do
the
test.
Automation,
workflow
for
Jenkins
essentials.
This
the
theory
being
at
least
as
far
as
I,
am
understanding
how
this
is
all
going
to
interact
these
interlocking
pieces
as
we're
going
to
have
our
bill
of
materials
and
we're
going
to
you
know
that
will
be
in
the
master
branch
and
then
a
pull
request
will
get
automatically
fired.
A
That
says:
hey,
there's,
new
plugin
changes
that
have
been
built
in
this
incrementals
repository
or
someone
files
it
manually.
They
want
to
promote.
One
of
you
know
a
new
incremental
build
of
the
plugin,
and
that
would
be
a
pull
request
like
the
production
branch
and
jenkins
essentials
and
that
are
in
the
Evergreen
repository
really,
and
then
we
would
need
to
run
some
of
the
test.
E
B
E
E
Then,
with
3:05
deployed
this
exact
same
workflow
ought
to
work
exactly
the
same
way
with
any
commit.
You
know
with
any
individual
commit
without
having
to
run
maven
release
plug
in
at
least
four
things
on
the
master
branch
I
mean,
but
currently
it
allows
you
to
deploy
commits
that
come
from
any
branch
or
pull
request,
probably
for
purposes
of
the
essentials
manifest.
We
would
want
to
have
a
enforced
rule
in
place.
That
says
you
know
if
you're
deploying
to
the
production,
then
it
has
to
be
a
commit.
That's
actually
in
master
itself.
E
A
Think
the
the
stuff
that
you're
Jessie
is
gonna
be
really
interesting
for
testing,
as
as
we
start
to
adopt
it
more
and
more
is
what
this
basically
mean
install
is.
We
will
have
the
machinery
to
drop,
builds
from
pull
requests
and
from
branches
into
this
maven
repository
directly
from
you,
someone
directly
there's
a
little
bit
of
sleight
of
hand,
but
someone
directly
from
CI
that
Jenkins
IO.
A
A
E
B
A
A
And
so,
outside
of
that
last
week,
the
other
thing
that
was
going
on
is
I
started
to
work
on
this
client-server
lifecycle
for
updates,
which
I
think
you
know.
Batista
and
I
have
spent
quite
a
bit
of
time.
Last
week
talking
about
it,
I've
been
working
on
the
on
actually
rationalizing
how
we're
going
to
manage
these
update
levels
that
I
had
posted
to
the
mailing
list,
and
so
Jenkins
CI
dev
there's
a
thread
where
I
continued.
A
Some
of
the
it
I've
learned
some
of
the
in
person
discussions
that
p'tee
stand
I
had
last
week
and,
as
you
know,
you
all
saw
this
morning
is
really
trying
to
rationalize
how
these
things
are
all
gonna
fit
together
with
the
channels
so
I'm
expecting
this
to
get
wrapped
up
from
an
implementation
standpoint
probably
later
today.
Well,
you
know
when
everybody
else
here
is
it
you
know,
goes
to
sleep
basically,
but
I.
A
Think
from
the
from
the
testing
perspective,
for
you
roll
the
the
thing
that
really
changes
for
the
thing
that
I'm
the
update
levels
really
allow
us
to
do
is
test
every
single
potential
upgrade
from
from
one
level
to
the
next.
So
we'll
have
a
pretty
strong
audit
trail
so
where,
if,
if
Battiste
starts,
with
version
zero
that
and
then
he
disconnects
for
two
weeks-
and
we
don't
see
him
and
the
current
update
level
is
14
and
then.
A
When
the
teeth
instance
comes
back
online,
it
will
update
to
update
level
1,
then
2,
then
3
and
4,
etc,
so
that
we're
not
actually
delivering
an
untested
update
to
to
an
end
user,
which
it's
gonna
take
a
little
bit
a
little
bit
of
time
for
Batista
instance
to
update
if
he
disappears
for
two
weeks.
But
we
decided
to
go
the
safe
route
rather
than
trying
something
different.
B
D
More
creative,
maybe
later
but
I
guess
for
now
it's
better
to
try
and
you
know,
goes
follow
the
same
path
for
everybody.
Yes,
though,
though,
I'm
pretty
worried
about
the
same
path
for
everybody,
when
actually
everybody
could
instill
different
plugins
and
could
make
you
know,
situations
very
different,
but
well
that's
kind
of
the
result.
A
D
D
A
Was
looking
at
the
you
know,
plan
milestone
and
how
this?
How
these
things
always
always
typically
work
out?
You
you
learn
more
once
you
go
into
it,
I
think,
towards
the
end
of
the
week
and
early
into
next
week,
I'd
really
hoped
at
the
beginning
of
this
project
that
we
would
have
the
full
update
cycle
working
I,
don't
know
how
realistic
this
is
right
now,
and
it
sounds
like
the
the
things
that
stand
between
us
and
milestone,
one,
the
client
health
stuff.
Have
you
implemented
that
batiste.
D
No
no
divinity
notes,
because
I
think
I
think
we
discussed
that
some
time
ago.
I
think
it
was
mostly
on
the
air
or
telemetry
thing,
I
think
it's
another
story
and
I
always
not
started
yet
the
clients
health
checking
I
had
put
that
from
some
time
ago,
but
it's
kind
of
table
down
for
now,
because
right
now
we
are
sitting
on
the
tarot
telemetry
and
basically
we
need
to
find
a
way
to
test
things
locally
and
finish.
D
The
registering
registration
and
logging
in
like
in
local
mode,
to
be
able
to
then
test
thing
in
it
right
which
we
don't
have
right
now,
I
think
and
then
we
should
be
able
to
start
playing
with
that.
I
tend
to
think
we
could
have
a
pretty
thing:
Paul
version
anyway.
The
health
checking
is
on
tapas
right
now,
pretty
simple,
so
it
could
be
feeble
pretty
soon,
but
it's
not
started
yet
bottom
line.
So
the.
A
D
Identity
degree
depends
on
well
because
it's
if
you
look
into
the
jab
306,
you
will
see
the
relationship
between
that
and
the
309
you're
sure
I,
think
scroll
in
the
very
bottom
I
think
a
relationship
between
a
no-no
really
but
on
bottom
bottom,
reference.
Okay,
so
basically
we
need
that
I
think
to
be
able
to
coordinate
updates,
which
is
the
thing
you're
working
right
now
on,
and
we
definitely
need
some
form.
I
mean
yeah.
We
could,
for
instance,
they
choose
to
implement
only
the
slash
instanceid
identity
check
for.
D
The
health
checking
part
of
the
update
and
roll
back
or
not
system
for
now
and
not
you
know,
consider
the
metrics
URL.
If
possibly
it
can
save
us
some
time
to
just
it
right
now,
but
if
we
don't
consider
the
health
of
a
given
instance,
when
we
update
then
I
think
we
are
really
going
to
to
take
a
big
risk.
Isn't
it
or
no?
That's
that's.
D
A
And
I
think
there's.
So
if
we
need
the,
where
did
that
go?
We
need
this
guy
I
think
that's
that's
reasonable.
It
sounds
like
the
things
that
we
we
have
to
do
to
get
to
milestone.
One
is
air
telemetry.
It
has
to
actually
be
delivered.
The
instance
health
checking
has
to
work.
We
need
a
essential
zmo,
manifest
with
actual
incremental
commits
that
are
in
the
or
incremental
builds
the
updates
has
to
work
and
then
I
need
to
work
on
the
infrastructure
side
to
actually
deliver.
D
Order
to
depends
because
306
is
actually
kind
of
split.
There
is
really
only
the
clients,
health
checking
and
right
now,
even
if
it's
in
flight
there
is
no
API
right
now
yet
defined
to
push
the
around
log
into
the
server
side.
Okay
and
I.
Suppose
we
need
that
to
be
able
to
push
it
somewhere.
That
was
something
that
you
were
gonna
take
on
was
now
yeah
I.
Think
I
will
do
that
soon.
That's
nice,
for
here,
I
was
going
to
say
the
xxx
xxx
xxx
of
April
is
still
slightly
ambitious,
but
well
yeah.
D
A
D
A
A
A
For
now,
I
mean
we're
not
delivering
any
plugins
through
updates
right
now,
so
this
list
is
gonna
get
longer
once
I
actually
have
an
instance.
That's
downloading
this
and
actually
getting
started.
What's
missing
from
this
and
I
was
starting
to
think
about
this
over
the
weekend.
Is
these
are
sort
of
root-level
dependencies,
and
that's
all
fine
and
good,
but
the
thing
that
I
need
to
actually
deliver
to
an
instance
has
to
be
the
full
list
of
dependencies
as
well,
and
so
what.
E
A
The
first
sketch
that
I
had
in
my
mind,
was
that
on
when
we
do
that
this
file
should
be
somewhat
generated
and
when
we
generated
this
file
that
were
actually
let's
say,
you
know
workflow
aggregator,
for
example,
when
would
generate
this
file,
we're
going
to
the
incrementals
repository
and
considering
the
palm
of
that
and
then
filling
in
whatever
we
need
here.
I,
don't
know
if
that's
a
bad
idea
or
not
yet
because
there
you.
E
C
E
C
C
A
Gist
of
the
problem
here
and
this
this
looks
actually
useful
for
the
doctor
plugin,
but
the
gist
of
the
problem
here
is
that
we
need
to
perform
the
duties
of
the
update
center
effectively
with
the
incrementals
repository
being
considered,
and
so
I
mean
I,
don't
know,
I,
don't
know
how
I'm
gonna
solve
this.
If
anybody
wants
to
take
that
problem
off
my
plate,
I'd
be
happy
to
give
it
to
them.
E
So
I'll
just
I'll
just
mention
and
you
can
consider
it
or
reject
it,
but
when,
when
I've
worked
on,
docker
images
think
food,
a
long
list
of
plugins
like
this
blue
ocean
and
all
of
that
other
stuff.
One
thing
that
I
found
works
is
you
can
just
have
a
dummy,
maven
pom
that
basically
declares
all
declares
core
and
all
the
best
plugins
and
whatnot
as
test
dependencies,
and
you
mark
it
as
a
plug-in
pom.
E
Even
though
it's
not
a
plug-in
you're,
actually
producing
that
automatically
takes
care
of
all
of
the
upper
bound
dependency
checking,
and
you
can
also
use
the
maven
goal
to
form
versions,
display
dependency
up,
and
it
will
show
you
all
outstanding
updates,
based
on
maven
metadata,
which
would
work
transparently
with
incrementals
repository.
Also
interesting.
If.
E
I
mean
there's
more
stuff.
We
need
to
do
because
there's
some
technical
issues,
core
DEP
being
provided
that
maven
doesn't
rock
very
well
and
you'd
also
want
to
do
that.
Like
I
was
talking
about
the
verification
that
a
proposed
releases
actually
in
master
branch
and
so
on,
so
that
doesn't
solve
all
of
it,
but
some
it's
at
least
one
approach
and.
A
B
A
B
A
C
A
Right
thanks,
everybody
all
sooo.
This
is
their
first
experiment
using
hangouts
on
air.
For
this
meeting
and
I
think
it
works.
The
only
problem
is
the
URL
I
had
updated
the
meeting.
Events
in
the
Jenkins
calendar
with
the
new
hangout
URL
and
guessing
for
you,
oh,
like
that,
didn't
show
up
properly,
so
I'm
gonna
try
to
find
a
better
way
to
make
this
under
make
it
known
what
the
with
the
hangout
on
air
URL
is
before
we
start
yeah.