►
From YouTube: JCasC office hours
Description
Let's talk Jenkins Configuration as Code
- current issues
- hot topic
- plans for the future
Meeting is open to anyone who wants to join
A
Confirm:
okay,
okay,
so
hello,
hello,
everyone!
This
is
our
first
Jake
asked
office
hours.
Meeting
we've
decided
we
should
have
this
meeting
to
like
make
it
easier
to
communicate.
We
have
a
lot
of
different
communication
channels,
but
some
issues
we've
noticed
to
be
very
hot
and-
and
it's
probably
easier
to
discuss
it
when
we
can,
we
can
simply
talk
at
the
same
time
instead
of
using
github
issues.
So
the
plan
initially
is
to
have
this
sessions
be
weekly.
We
had
a
doodle
and
all
the
participants
agreed
at
9:00
a.m.
A
European
time,
I,
guess
or
Central
European
Time
is.
There
is
the
best
one
for
us,
but
not
many
people
participated.
We
can
still
adjust
if
there
is
a
need,
but
yeah.
Let's
start,
let's
start
with
that,
just
to
make
sure
we
we
all
know
where
to
look
for
the
information
when
it
comes
to
plug-in
development
and
issues.
We
are
using
github
github
issues
when
it
comes
to
communication
around
the
implementation,
whatever
whatever
it
should
not
end
in
in
github
issue
issues,
we
will
use
our
get
channel.
A
B
A
So
Jenkins
CI
configuration
is
called
plug
in
exactly
as
the
as
the
repo
location
in
github.
This
is
our
guitar
channel
and
we
have
a
lot
of
like
we
had
a
discussion
regarding
how
and
and
where
to
handle
the
Jake
asked
office
hours
that
we're
having
right
now,
and
you
said
Oleg
that
you
will.
You
will
post
the
links
in
on
YouTube
under
the
video
we
will
yeah.
A
A
E
A
I'm
not
sharing
now
God
is
not
sorry
but
like
we
learn
all
the
time
yeah
so
like
we
covered
the
communication
channels
and
yeah.
Let's,
let's
move
on
to
the
actual
meeting,
so
today,
I
want
to
talk
about
yeah
in
general.
What's
the
status
of
the
plug-in
development,
we
have
some
new
issues
that
Oleg
was
creating
yesterday
and
then
apologizing
for
spam.
A
So
so
I
would
like
to
like
have
a
look
at
those
and
and
see
if
we
can
reach
some
consensus
and
then
we,
it
would
be
great
if
we,
if
we
could
talk
about
the
actual
first
official
release,
if
any
of
you
have
any
comments
about
what's
missing
and
how
we
can
do
it,
and
so
this
is
my
first
real
involvement
in
the
open
source
project,
so
I
may
need
your
advice
regarding
how
to
handle
some
of
the
stuff,
but
yeah.
Well,
we'll
get
to
that.
So,
let's
start
with
the
status.
A
We
had
a
long
discussion
regarding
jab,
201,
Nicola
and
Liam
were
involved
and
it
all
started
with
the
feedback
we
got
during
or
after
Jenkins
online
meetup.
We
had
a
trio
and
the
result
of
discussion
is
that
we
have
decided
to
make
won
the
201
more
general,
something
something
very
high-level
and
we
had
we
had
a
session
when
were
we
decided
to
like
skip
some
part
or
move
some
parts
to
another,
another
jab
and
Liam?
You
you,
you
are
responsible
for
something
and
you
PR
with
in
your
more
general
version.
Am
I
right?
Yes,.
D
That
would
that
everyone
can
agree
on
and
that
cost
kickin
Marcus
accepted
that
we
can
really
say.
Yes,
this
is
the
direction
we're
going
and
then
have
the
a
little
more
of
the
the
implementation
details
of
how
we
achieve
that
in
two
separate
traps.
Currently
we
agreed
to
one
that
would
be
the
the
the
schema
and
the
other
won't
be
the
tooling.
D
D
A
D
That
his
request
yeah
as
the
PDF
l,
and
that
way
we
have
an
agreed-upon
plan
and
then
there'll
be
another
chap
opened.
There's
already
one.
The
tooling
chap
has
already
been
proposed
and
there's
been
some
discussion
on
it.
I
I
need
to
look
at
that
and
see
if
there's
a
way
that
I
can
get
it
to
draft
status.
I
I
think
there's
some
edits
to
be
made
in
typo
fixes
and
little
things
to
to
reach
that
to
get
that
to
reach
draft
status
and
then
we'll
have
another
chat
as
well
and
I
guess.
D
The
last
thing
I
would
say
on
that
is
all
of
this
has
been
a
you
know:
jeppeson
new
process,
so
there's
been
some
back-and-forth
and
this
is
there
been
some
improvements
to
the
jet
process
based
on
what
happens
to
a
1,
and
also
none
of
this
has
ever
been
a
problem
with
201
itself.
It's
more
just
like
some
of
the
implementation
sort
of
figuring
out,
just
as
you're
figuring
out
how
to
work
on
in
the
open
source
project.
There's
there's
parts
of
this
open
source
project
that
are
being
improved
by
the
the
jet
process.
D
A
And
that's
great
I
mean
it's
good
to
have
a
process
that
we've
all
kind
of
created
based
on
our
expectation
and
experiences,
so
so
I
think
we're
doing
it
right.
So,
a
anyway
the
configuration
is
called
tuning
proposal.
As
you
mentioned,
the
PR
is
already
there
it's
it's
pull
request
one
one,
one
in
inject
repository,
so
whoever's
interested
you
can
you
can
have
a
look
and
then
yeah
so
I
think
we
covered
the
jab
a
part.
A
Another
thing
that
I
think
is
it's
worth
mentioning
is
that
a
number
of
pragma
consultants
are
already
starting
implementing
the
solution
at
customers.
Even
if
we're
still
in
the
alpha
stage,
we
can
at
least
like
show
them
how
it
works,
some
kind
of
proof
of
concept,
and
it's
in
everyone.
It
seems
everyone
is
very
eager
to
have
it,
and
I
must
say
that
I
was
a
little
bit
skeptical
at
the
beginning,
because
I
get
I
get
notifications
every
time
new
issue
is
created
and
I'm.
A
Aware
of
all
the
features
we
want
to
have,
and
we
don't
have
so
I
did
not
feel
that
it's
it's
it's
production
ready
yet,
but
then
I
released.
It
really
said
III
configured
Jenkins
with
Jake
asked
at
one
of
my
customers
and
it's
just
working
and
it's
I
mean
I,
don't
want
to
say
unexpected,
but
but
from
a
user
point
of
view
I
it
looks
really
really
well.
So
so
I
just
wanted
to
point
out
that
well
we're
getting
there.
There's.
D
A
B
Wanted
to
say
that
if
we
talk
about
whether
to
release
and
what
would
be
the
past,
there
are
some
options.
If
you
want
to
boost
adoption,
it's
there
are
ways
to
release
in
public,
even
if
there
is
some
time
for
changes.
So
we
can
talk
about
it,
but
yeah
I
agree
that
there
is
a
huge
interest
in
the
project,
so
we
should
be
moving
forward
and
we
all
current
issues.
Yeah
there
are
some
design
concerns,
so
there
are
some
API
concerns,
but
we
can
postpone
the
most
of
them
till
the
next
phase.
Okay,.
A
That's
that's
very,
very
good
to
hear
so
I
guess,
since
we
already
started
talking
about
it.
Let's
move
to
that
point
to
how
what
what
do
we
have
to
do
to
release
the
first
version
and
I?
Have
this
milestone
that
I
have
created
some
time
ago
released
a
1,
1,
sorry,
1
0,
where
I
I
was
putting
all
the
issues.
I
believed
we
need
to
solve
before
moving
to
1.0
and
yeah.
It
was
changing
in
time,
but
now
more
or
less
it
contains
everything
that
I
would
like
to
have.
A
But
it's
not
a
complete
complete
list
and
most
of
those
those
issues
are
documentation.
Documentation,
related,
I
I
believe
we
need
to
have
a
documentation
improved
to
make
it
really
useful
and
then
what
we
have
here,
several
configurate
configurators
outside
of
jenkins
element.
No,
that's
not
the
one
that
I
want
that
this
already
happens
on
its
own,
so
documentation,
documentation,
documentation,
documentation,
yeah.
This
is
a
new
feature
that
I'm
awaiting
feedback,
which
means
that
I
want
to
discuss.
A
E
A
E
A
D
Yeah,
that's
the
I
was
going
to
say
you
can
direct
them
to
there's
a
Jenkins
online
meetup
that
we
did
I
guess
several
weeks
me
a
month
ago.
That
actually
shows
a
bunch
of
this
I.
Don't
know
that
trusted
getting
started.
Maybe
we
want
to
have
another
like
I
like
a
quick
video.
That's
a
that
shows
this
too
I
mean
that
might
be
also
useful.
B
D
Actually
going
to
ask
about
that,
do
you
think
that
this
this
plug-in
it's
a
single
plugin
really
should
be
considered
a
separate
sub
project
or
I
mean?
Is
it
it?
Does
it
what
I
mean,
there's
no
definition
as
to
what
that
what
that
means?
I
don't
have
any
particular
objection.
I'm,
just
wondering
what
the
the
the
reasoning
was
I
would.
B
Prefer
to
have
it
at
the
sub-project,
because
even
if
it's
a
single
plug-in
it's
effectively
an
akai
system
because
we
need
changes
in
Jenkins,
meaning
changes
in
Toulon
could
being
it
changes
in
other
plugins.
So
we
want
plugins
to
adopt
EPS
and
to
provide
configurators
and
other
integrations.
So
I
would
rather
start
from
sub-project
taking
the
community
interest.
So
then
yeah-
and
there
is
several
discussion
about
special
interest
group,
so
we
can
just
combine
it
together
and
yeah
with
that
kind
of
as
a
kind
of
entity
within
Jenkins
project.
D
Okay,
that'll
be
that
that'll
be
interesting
to
discuss
a
little
more
widely
with
you
might
want
to.
When
I
put
that
on
the
on
the
dev,
the
chain
can
see
I
Devlin
as
a
hate.
Should
this
be
a
sub-project
and
sort
of
gather
some
information
from
the
community
on
that
one
yeah,
okay,
I,
don't
know
what
I
don't
know
what
the
consensus
will
be,
but
I
just
like
to
make
sure
that
we
are
gathering
it
right
of.
D
Ever
think
I
was
gonna.
Ask
about
was
these
are
this?
Is
the
released
1.0
milestone,
I'm
I'm
wondering
if
you
want
to
if
it
would
make
sense
to
do
like
a
release
0.9
or
like
a
beta
effectively
and
shoot
for
like
getting
all
of
them
all
of
the
issues,
squared
away,
always
issues
that
we
know
about
squared
away
and
then
have
a
sort
of
blog
post
to
say
hey.
D
B
B
So
if
you
release,
but
it
will
go
there
as
well,
but
what
we
could
do
we
could
release
release
candidate,
1.0,
0.1
doesn't
really
matter
and
yeah
what
we
could
do
or
we
could
annotate
EPS,
like
I,
proposed
in
some
of
the
tickets
mm-hmm,
so
that
this
EP
is
a
market
tests
but
availability
and
we
restrict
all
other
classes
which
are
not
supposed
to
be
a
pianist
and
then
with
introductory
documentation.
It
can
be
shipped
as
release
candidate.
D
It
would
it
be
available,
but
it
also
communicate
prior
would
properly
communicate.
Okay,
we're
we
feel
strongly
about
it,
but
it's
we're
just
it
gives
you
know
the
wider
community
a
chance
to
get
in
on
it
and
really
pound
on
it
and
and
say,
and
and
give
you
a
lot
of
feedback.
And
then
you
can
then
you
that
that
1.0
non-solid
1.0
becomes
a
much
stronger
feeling
release
rights.
So.
A
A
A
B
Just
show
the
issues
which
I
can
see
the
important
ones
so
yeah
I've
created
some
issues
after
discussions,
so
is
Evelyn
and
mods
in
Sweden.
I
was
there
two
weeks
ago.
So
one
of
the
biggest
thing
which
concerns
me
is
compatibility
and
those
immigration
options.
So
yeah
there
are
some
tickets
like
allow
accepting
restrict
it
feels
as
obtained.
Allow
preventing
duplicated
feels
it's
nice
to
have
it.
It's
not
needed
to
release,
but
what
I
really
consider
is
required
is
making
extensions
and
Beth
API,
because
there
is
a
risk
that
we
change
them.
D
A
D
A
D
B
B
A
D
B
B
D
B
A
A
Understand
that
it's
a
it's,
because
that's
how
its
implemented-
it's
not
like
McCulloch
decided
that
he
moves
this
here
and
another
configurator
to
another
root
element,
but
I
think
we
at
least
should
discuss
how
we
handle
this
and,
what's
the
what's,
the
the
final
decision,
how
we
want
it.
So,
let's,
let's
get
that
one?
Definitely.
A
B
A
A
B
B
B
D
E
B
D
E
D
Of
tickets
here
and
there's,
why
don't
we?
Why
don't
we
not
try
and
cover
everything,
yeah
right,
it's
let's!
Let's
put
that
maybe
to
the
next
office
hours.
If
there's
a
other
things
that
we
or
we
can
do
that
sort
of
online.
That
say:
okay
are
the
things
that
you
want
in
there
and
make
some
choices.
Otherwise,
you've
got
60
bucks
to
go
through
and
I.
Don't
know
that
you
want
to
spend
the
rest
of
the
time
on
that
yeah
right.
So
why
you
just.
B
B
I
just
wanted
to
propose
some
foundation
work,
so
I
mean
that
you
have
a
street
with
no
public
PPIs
is
kind
of
no-brainer.
We
need
that
extension
points
is
better
I,
think
it's
something
which
would
help
a
lot
I
mean
once
you
should
Percy.
We
can
start
moving
code
out
of
the
plug-in,
for
example,
role,
strategy
and
integrations,
but
they
they
will
be
still
better.
So
we
have
a
scope
of
include,
will
be
limited.
B
A
B
Always
it
can
be
time-consuming,
or
would
it
be?
No,
it's
not
time
consuming,
I
think
so
yeah.
The
main
problem.
Now
with
that
we
have
Jenkins
rotation,
scott
plugin
and
nicola,
for
example,
is
working
on
versioning
support,
another
tooling,
and
if
we
need
to
bump
Jenkins
core
dependency,
it
may
be
a
problem
for
plug-in
developers.
So
my
proposal
would
was
to
split
to
two
parts
so
minimal
API,
which
can
be
used
by
developers
and
we
still
target
2.60
branch
and
all
your
front
end.
D
Probably
makes
sense
to
do
that
in
the
RC
I
mean
like
if
we're
gonna
do
beta
beta
api's
it
like,
but
let's
let's
make
let's
make
this.
It
seems
like
it
like
API
definitions
in
this
and
should
go
into
it
into
the
1.0
line,
I
mean
and
if
it's
not
super
time-consuming,
if
it's
kind
of
like
okay,
this
is
just
to
kind
of
move
things
around
mm-hmm.
B
A
I
I
was
thinking
it
is
a
little
bit
time
consuming
and
when
we
start
moving
things
around
it's
kind
of
dangerous
and
we
I
wouldn't
like
to
like
rush
the
solution
just
to
fitted
into
the
deadline.
We
haven't
the
deadlines
we
have
are
kind
of
determined
by
Jenkins
world
state.
Even
Nikola
is
saying
that
it
is
not
very
dangerous
or
time
consuming.
Then
I
used
to
believe
him.
So
I'm
perfectly
okay.
D
A
B
B
Yeah,
so,
regarding
the
rest
of
the
issues,
I
have
created
so
job
loading
because
I
said
yeah.
You
likely
need
to
fix
it
in
the
course,
but
it
can
be
done
even
after
one
to
zero,
so
I
would
prefer
to
not
touch
it
for
now,
especially
since
it
depends
on
me,
o
gs,
baselines,
etc,
but
yeah.
If
I
have
time,
I
will
try
to
get
it
I'll
end
it
by
the
next
time
she
has
baseline,
okay
and
custom.
B
B
Rc
or
not
so
it's
enhancement
in
API,
it
can
be
done
poster
see
so
I
think
that
yeah,
it
can
be
definitely
done.
Post,
obscene
or
post
are
1.0
or,
firstly,
a
even
post
100,
it's
doable,
but
yeah
that
the
main
problem
is
one.
You
should
wonder,
though,
than
the
current
configuration
export
logic
won't
be
really
helpful.
In
some
cases
it's
still
helpful,
but
the
whole
strategy
matrix
identification,
I
Keystone's
of
secure
changes,
instances
and
you
cannot
explore
them
now.
A
Have
you
have
two
interesting
issues
that
I
am
very
glad?
You
have
created
the
one
on
the
bottom
right
now,
because
there
was
a
lot
of
a
long
discussion
that
that's
the
hot
topic.
I
mentioned
this
deprecated
constructor
setters
to
allow
all
turning
behavior
and
and
what
about
restricted
fields
in
that
ability,
figuration
configurator,
those
are
both
both
kind
of
similar.
Am
I
right
yeah.
B
B
A
Could
have
is
perfectly
okay,
I
mean
if
we
don't
do.
If
we
have
timed
and
that's
great,
if
we
don't
have
time
the
world
won't
fall
and
what
I'm
interested
is
like
there
was
a
you
had
you
had
your
idea
and
your
opinion
about
it
and
Nicola
had
his
opinion
and
I
I
would
like
to
ask
if
those
issues
are
kind
of
something
what
you
both
agree
on,
or
there
is
still
no
agreement.
If
you
can
comment
on
that.
A
D
B
C
B
Yeah
Nicola
is
working
on
data,
bound
logic,
mm-hmm
the
main
use
case
yeah.
We
also
have
discussion
about
deprecated
data
bound
setter
mm-hm.
We
can
annotate
constructors
in
a
better
way,
but
I
think
we
still
have
a
use
case
for
this
compatibility.
So
what
I
do
here
is
I
say
that
there
is
an
extension
point
which
allowed
to
say
that
there
are
other
legacy
data
bound
constructors.
So,
for
example,
I
don't.
D
And
I
mean
there
to
sort
of
cut
you
sure
here
like.
Are
we
I,
just
wanna
kind
of
make
sure
that
we're
talking
about
are
we?
Are
we
going
into
design
details
here
or
are
we
trying
to
triage
what
bugs
go
into
RC
or
is
I'm
okay,
either
way
and
then
I
understand?
If
this
discussion
it
was
ranging
into
that
to
figure
that
out,
but
I
I
sort
of
lost
track?
Yes,.
A
D
A
D
B
D
B
We
still
have
some
cases
where
tooling
is
not
enough,
for
example,
when
we
support
all
the
releases
of
Jenkins
code
or
altered
releases
of
plugins,
which
just
cannot
be
fixed
due
to
whatever
reason.
So
this
solution,
just
it's
a
kind
of
silver
bullet,
so
within
Jake
asked
or
within
a
plug-in
or
within
a
whatever
other
thing.
We
can
declare
a.
B
We
can
just
declare
an
extension
point
which
provides
an
additional
list
of
constructors
and
lekha
setters
that
can
be
used
by
Jake.
Asked,
though
this
is
the
idea.
So
when
no
other
solutions
work,
we
can
use
that
in
order
to
declare
some
compatibility,
which
is
under
subject
knowledge,
for
example,
FFG
Nokia
launcher.
There
is
a
constructor
provider
which
says
that
this
particular
constructor
can
be
accepted
by
Jake
asked
because
yeah
we
know
that
it
can
be
accepted,
but
we
cannot
fix
weekly
releases
from
sorry
LTS
releases
from
2.73.
B
C
B
E
And
from
a
user
percent,
when
it's
very
important,
because
in
what
III
the
one
I
was
going
on,
that
wrote
the
original
issue
in
this,
that
I
saw
that
the
behavior
changed
after
I
operated
that
Jenkins
call.
So
so
this
is
a.
This
is
a
really
it's
really
good
for
the
user,
when
we're
trying
out
Jake
has
for
the
first
time,
just
in
case
they
use
a
slightly
older
Jenkins
call
exam.
B
A
B
C
B
A
Like
it
because
when
when
when
to
have
this
section
to
to
have
the
self
configuration
section,
because
I
have
some
ideas
about
how
it
should
work,
but
that
specific
features
but
I
inferred
people
having
different
opinions,
so
we
can
have
default
behavior.
But
if
we're,
if
it's
possible
to
change
the
default
behavior
and
let
people
overwrite
or
not,
overwrite
or
field
stuff
like
that,
then
that
would
be
great
to
have
it.
Yeah.
B
A
D
A
Okay,
because
I
mean
I
will
go
through
the
list
of
all
the
issues
and
make
sure
we
are
not
missing
anything
and
then
we
may
have
some
must
have
or
should
have
so
it's
it's
it's
kind
of
a
priority
but
expressed
in
the
like.
You
know
more
understandable,
a
way
because
what's
prior
1.2,
one
two
or
three
it
doesn't
say
much,
but
if
it's
like
must
have
should
have
could
have
you.
D
A
A
E
E
It
works
now
because
I
have
actually
I
have
actually
tried
to
like
upgrade
and
install
the
trend
like
more
complex,
plug-in,
like
a
bonnet
which
uses
the
analysis,
core,
etc,
and
that
seems
to
be
worthy.
So
so,
when
you,
when
you
add,
when
you
add
a
new
plugin
and
the
specific
version
and
you
press
reload
jinglun's
will
cannot,
we
cannot
deny
me
to
deploy
plugins
because
we
need
to
inspect
the
jar
afterwards.
So
cutting
out
words
with
you
update
your
your
genu
plugins
is
the
update
version
and
press
reload
and
test.
E
B
Oh
I
have
many
concerns
about
this
feature.
Actually,
I
believe
that
it's
not
going
to
work
in
many
cases,
architecturally
I
mean
even
with
at
the
start
of
Jenkins
instance.
You
get
into
so
many
dangerous
things,
for
example,
date,
immigration.
You
have
no
option
to
rollback
cookies
out,
whatever
backup,
tooling
and
until
it's
implemented.
My
suggestion
would
be
to
keep
this
option
even
better,
so
explicitly
said,
yeah
it's
available.
There
is
no
guarantee
for
that
and
it's
recommend
to
use
a
static
packaging.
B
A
So
why
I
started
talking
about
it
is
we
can
in
a
moment
go
back
to
your
concerns.
Is
that
it's
kind
of
a
workaround
what
we
have
now,
because
there
is
still
this
Jenkins
infra
PR,
waiting
to
be
merged
and
I'm
wondering
if
the
solution
we
have
now
is
something
that
we
should
put
in
the
RC
or
1.0.
Or
should
we
wait?
Should
we
hope
or
wait
for
the
Jenkins
infra
PR
to
be
merged
if
I
know
that
Nikola?
Has
that,
like
all
the
knowledge
regarding
that,
but
maybe
what.
B
D
D
A
D
A
So
yeah
it's
about
the
meta
data
in
an
update
center
and
there
was
some
discussion.
It
started
some
time
ago
and
yeah
so
and
it's
not
okay.
This
one
is
still
open
right.
Yes,
so
I
think
until
it
this
is
merged.
We
won't
have
a
final
solution
for
plugin
installation
and
I
was
I
was
wondering
if,
if,
if
any
of
you
have
any
opinion
about,
if
we
should
release
the
current
a
solution
or
is
it
something
temporary
just
to
like
make
it
easier
to
test
the
plug-in
now?
B
E
Can
I
interject
something
here?
Yes,
they
current
implementation
is
really
really
well
hidden.
You
can
actually
look
in
the
documentation,
see
how
plugins
work
at
the
moment.
So
this
feature
flag,
I,
don't
think
it's
necessary,
because
you
need
to
be
lucky
to
figure
out
that
connection.
Install
plugins
super.
D
Of
version,
like
version
numbering,
we
could
probably
you
know
adding
things.
This
is
a
safe
bet.
Changing
things
is
where
you
have
to
deal
with
a
breaking
change
right,
so
I,
don't
know
if
you,
if
that
matters,
but
it
might
be
some
marking
something.
This
beta
is
one
safe
way
to
say.
Okay,
if
you
use
this
it
might,
it
might
break
right.
D
E
E
B
So
I
totally
about
for
keeping
the
co2
available,
because
it's
nice
experiment
and
yep,
even
if
it
doesn't
work
in
all
cases,
it
allows
to
evaluate
possibilities
for
doing
such
updates,
yeah
and
plus
one
for
whatever,
but
availability
I
would
rather
disable
it
by
default,
assuming
that
the
documentation
gets
better
but
yeah
we'll
be
fine.
If
it's
enabled,
for
example,
for
every
candidate,
and
then
we
see
what
is
the
feedback
because
first
afford
release
candidate,
we
still
can't
change
the
behavior
if
needed.
Okay,.
A
B
B
A
D
A
Again
for
the
time,
but
the
scheduling
the
meeting
between
those
different
continents
is
complicated
anyway.
So
to
summarize,
thank
you
all
for
joining
for
those
who
only
watch
it
now
or
anytime
after
we
can
always
reschedule
a
meeting
if
there
is
an
it
if
you
could
not
join
the
meeting
and
you're
outraged
by
the
decision
we
made,
nothing
is
written,
written
in
stone,
as
I
already
said
today,
so
like
reach
out
to
us,
preferably
at
the
guitar
channel.
So
we
can
all
a
contribute
to
the
discussion
and
we
can
we
can
always
adjust.