►
From YouTube: Essentials: Open Planning Meeting (2018-05-07)
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
So
hello,
everyone.
So
this
is
the
weekly
meeting
for
Jenkins
essentials,
open
planning,
so
we're
going
to
discuss
the
status
of
the
project
so
who
is
present
so
Jenkins
Tyler,
Jesse,
Oleg
I'm,
not
sure
always
this
is
going
to
join
so,
let's
just
head
over
status
is
so
Tyler.
Maybe
you
want
to
get
started.
Yeah.
A
So
I've
made
a
significant
amount
of
progress
last
week
on
the
delivery
of
updates
using
a
stubbed-out
update,
manifest
as
bits
east.
You
and
I
were
discussing
a
little
bit
in
chat,
I've
been
having
some
difficulty
with
the
integration
tests,
but
as
it
stands
right
now,
the
two
things
that
are
outstanding
for
that
pull
request
for
a
70
I
mean
the
integration
tests.
I
have
to
have
to
work.
A
Obviously,
both
before
we
merge
anything
and
then
I
have
one
more
it's
a
test
case
to
add,
and
that
is
right
now
the
state
level
is
not
being
stored
for
anything,
and
so,
if
you
turn
the
Evergreen
client
off
and
bring
it
back
on,
it
will
just
redownload
everything.
So
it's
not
the
client
side
isn't
doing
the
update
level
check
just
yet
that's
fairly
straightforward,
but
I
can't
really
I
can't
do
that
successfully
until
I
get
the
integration
tests
actually
to
cooperate.
Mm-Hmm.
C
A
B
No,
no,
that
I
was
just
going
agreeing
and
saying
yeah
from
what
I
could
tell
in
your
PR.
Indeed,
there's
probably
only
left
something
like
laughs
because
you've
already
written
the
war
and
plugins
download.
So
now
we
need
to
say:
okay,
please
supervise
our
dearest
Argentine,
so
it
would
work
and
so
yeah
it's
look.
It's
looking
very
promising.
B
B
A
A
D
B
B
D
B
D
For
essentials,
this
weight
has
been
fire
fighting
on
other
sites
regarding
the
key
plug-in
they
teach
and
P
City,
which
is
already
running
empirically.
This
is
it
working
now
we
have
detected
some
instability
on
get
flying
drunks,
so
a
mark
is
going
to
do
some
changes
regarding
the
param
pum
version.
D
You
see
that
and
after
that
he
has
requested
me
to
help
in
case
there
are
some
problems
with
PCP
or
88,
which
is
something
that
I'm
going
to
do
and
very
used
to
fear
with
88
or
visiting,
so
that
is
both
in
going
to
probably
this
is
with.
Regarding
those
two
to
two
issues
and
after
that
I'm
going
to
start
with
the
other
way
work
on
the
custom
work
package
it
and
improve
the
form
deploying
the
ticket
is
not
yet,
but
it's
greatly
technician
and.
C
B
D
B
C
I,
don't
have
specific
updates
for
essentials,
but
I
have
updates
for
related
things
like
Bill
of
Materials,
so
one
of
good
news
that
we
have
definite
implementation
for
you
of
materials
and
custom
work
packages
which
supports
both
inputs
and
outputs.
I
have
integrated
this
pull
request
to
be,
and
I
will
be
a
second
couple
of
pipeline
students
so
that
we
can
create
it
in
our
flows
for
testing
purposes
to
each
other.
B
E
They'll
have
time
to
work
on
that
this
week,
main
status
for
me
as
I
have
a
tool
in
progress
which
looks
for
the
most
recent
applicable
incremental
or
other
version
of
a
given,
artifact
and
initially
I.
Have
it
set
up
as
a
maven
plugin
to
do
a
palm
update
similar
to
the
versions
to
various
mojo's
and
the
versions
maven
plugin,
and
it
tends
like.
We
now
have
concrete
llamo
format
from
custom
or
packager
that
I
could
use
to
prototype
similar
change
in
that
format
as
well.
So.
C
B
I
think
since
last
week,
for
four
people,
possibly
watching
he
now
or
later
just
sees
you're
kind
of
talking
what
what
you
did
like
Friday
or
something.
But
you
did
a
lot
since
lights.
Last
Monday
I
think
whether
are
to
incrementals
and
checking,
and
so
now
it's
kind
of
working
and
more
merging
the
core
and
so
on.
Yes,
it
is
in.
C
B
That's
great
because
for
for
outsiders,
I
would
say
you
would
see
that
indeed
now
even
the
core
is
deployed
automatically
for
each
PR
that
gets
merged,
so
that's
great
and
that
just
works
for
everything
not
only
the
in
swore
it
can
work.
It
works
now
already
for
some
plugins,
the
ones
who
are
being
having
configured
to
check
those
things.
So
that's
great
yeah.
C
D
E
E
E
E
B
E
C
E
Deployment
evergreen.
Yes,
there
will
be
a
matching
core
PR
to
pick
up
that
version.
But
the
point
is
that
if
we
used
incremental
versions
from
remoting
and
stapler
the
closet
or
ease,
then
then
we
had
them
being
built
properly.
Then
it
would
be
easy
to
do
that.
You
know
it
and
get
that
going
live
in
a
matter
of
hours.
D
Comment
now
to
talk
about
incremental,
just
like
to
ask
what
would
you
think
about
you,
team
de
ATH
itself
under
incrementals
I
mean
at
this
moment
you
seen
a
concrete
commit
on
the
meta
data
files
to
run
in
a
gate
and
that
commit
has
to
be
updated
regularly.
So
I
think
it
makes
sense
to
use
the
incremental
system
to.
B
B
B
D
B
E
B
You
do
Rao
for
ATH
is
automatically
maybe
file
PR
on
the
core,
or
something
like
this
to
test
when
there
is
a
new
commit.
You
know
when
we
detect
that
the
SHA
being
pointed
to
for
the
version
of
a
th
on
the
core
there's
some
new
version
of
you
know
that
some
new
siya
for
the
latest
tip
of
ATS,
then
file
automatically
PR
to
test.
If
a
th
is
as
stable
as
before,
and
then
you
know
bump
the
Darden
version
so
that
everything
uses
the
latest
latest
of
a
th.
C
E
And
practice
acceptance
test
pretty
frequently
break
for
kind
of
silly
reasons.
Like
somebody
you
know,
somebody
makes
this
slight
change
to
the
format
if
it
config
le
and
some
plug-in
and
and
then
the
selector
doesn't
match
anymore.
And
so,
if
you
look
through
eth
history,
we
have
a
lot
of
places
where
it's
doing
like
this
long.
E
If
then
switch
where
it's
trying
to
deal
with
2
or
3
different
versions,
the
same
config
file,
which
were
up
the
same
config
screen,
which
is
hard
to
maintain,
so
it
would
be
nice
to
just
be
able
to
say
you
know
this
is
the
version
of
the
test
that
I'm
using
this
is
the
version
of
the
plug-in
that
I'm
testing.
If
you
change
the
plug-in
format.
Well,
okay,
you
can
make
a
change
to
the
test
and
you
can
pick
those
both
up
in
one
commit.
C
B
D
B
So
we
have
a
bit
more
than
ten
minutes
left.
Don't
think
I
gave
my
own
status,
so
I'm
going
for
that
very
quickly.
So
last
week,
main
thing
was
to
basically
work
on
the
whole
error.
Telemetry
story.
So
now
the
chap
for
the
client-side
was
merged
a
bit
before
I've
been
writing
some
no
J's
code,
and
now
we
have
the
full
story,
running
I
would
say
at
the
prototype.
So
we
we
have
Jenkins.
B
That
is
so
writing
logs
in
JSON
format,
as
per
the
chap
305,
three
or
four
I
think
on
the
disk,
and
then
the
Evergreen
client
is
reading
those
and
pushing
those
into
the
backend
of
evergreen.
So
the
backend
that
will
in
the
future
be
deployed
behind
something
like
every
current
object
in
stock
I
or
something
and
now
I'm
writing
the
jab
for
actually
gathering
feedback
and
so
on,
because
I've
already
prototype
for
this.
But
what
will
the
API
for
pushing
those
logs?
Look
like
for
real
and
I'm,
almost
hopefully
done.
B
B
B
So
that's
why
we
were
discussing
how
the
those
things
are
set
up
right
now,
so
that
we
don't
do
things
in
a
bad
way,
so
for
people
interested
as
always
as
we
are
following
refor
opens.
We
have
ducts
meetings,
and
so
I
put
a
small
summary
here
about
what
we
discussed
this
morning
and
basically
I
think
it's
likely
to
be
that
the
backend
service
that
will
receive
the
lock
then
will
push
those
in
in
fluently.
That
is
already
existing
component
in
the
current
infrastructure
for
Jenkins.
B
And
so
then
we
will
have
those
logs
probably
push
in
the
azure
log,
who
is
called
see
as
your
log
analytics,
probably
at
least
in
the
short
term,
but
from
lesson
shows
clients,
I,
would
say,
client
perspective,
I,
guess
it's!
It's
not
a
big
deal,
because
the
most
usual
thing,
I
would
say,
is
more
to
design
how
the
end
point
with
low
like
so
look
like,
so
that
the
instance
around
the
world
can
push
the
logs
and
then,
if
we
change
in
things
behind,
then
it
shouldn't
have
any
impact.