►
From YouTube: Octant Community Meeting - January 27th, 2021
Description
Octant community meeting is held weekly. We discuss and talk about the current state and future of Octant, demo upcoming features and releases, and preview new ideas we are considering for Octant.
Meeting agenda: https://hackmd.io/CzaPxtmXT_SW8nEpdwvGzw?view
A
Hello
and
welcome
everybody
to
the
january
27th
octane
community
meeting.
We
have
some
updates
to
talk
about
today,
we'll
be
talking
about
electron
again,
we'll
also
be
talking
about
what
we're
going
to
be
doing
after
this
electron
release,
and
then
we
want
to
show
just
some
community
membership
stuff
around.
We
finally
put
towards
what
it
like
how
and
what
it
means
to
become
a
like,
approver
or
contributor
to
to
octan.
So
with
that,
I
will
get
started
electron
again.
Yes,
that
is
that
is
true.
A
We
have,
let's
see,
we
have
a
project
board
which
is
actually
linked
down
here,
but
I'll
re-link
it
again,
but
this
is
our.
This
is
our
0.17
project
board,
which
is
on
github,
and
it
shows
the
issues
that
are
in
progress
and
outstanding.
A
So
a
couple
of
these
are
not
blockers
to
the
o
dot
17
release.
They
just
happen
to
also
be
in
progress.
So
if
they
happen
to
finish,
then
they
will
be
part
of
the
release.
But
if
they
do
not
finish,
then
they
won't
be.
But
these
are
the
currently
known
yet
to
be
started.
Work
that
we
want
to
make
sure
is
part
of
the
odot
17
release,
and
this
is
what
we
have
in
flight
right
now.
The
couple
things
that
milan
and
sam
are
working
on,
so
it
is
very
close.
A
We
just
just
yesterday
and-
and
this
morning
started
merging
in
a
lot
of
just
like
the
quality
of
life,
fixes
that
came
up
pretty
immediately
after
we
did
our
build
sam
and
and
milan
and
myself.
We
just
you,
know,
fired
it
up
and
found
some
of
these
things.
So
you
know
you
can
see
these
pr's
that
are
landing
are
very
small,
they're
just
little
things,
but
they
do
make
the
experience.
Just
actually,
you
know
feel
like
an
application
and
better
so
we're
making
sure
that
those
get
put
in
there.
A
I
think
that
this
is
pretty
up
to
date,
we've
been
updating
it
almost
daily
with
any
new
issues
that
come
up
as
we're
using
it.
So
my
sense
on
this
is
that,
barring
any
major
discoveries
that
we
just
weren't
expecting,
we
should
be
looking
pretty
good
to
to
release
0.17
very
very
soon
been
saying
soon
for
a
long
time,
and
it
also
feels
longer
than
it
actually
really
has
been
because
of
the
holiday
break.
That
was
in
there,
where
it's
like.
A
So
two
two
of
the
weeks
since
oh
16-3
have
were
people
were
completely
off,
but
still
it
definitely
longer
the
one
of
the
longest
ones.
I
think
the
only
one
that
was
longer
than
this
was
our
very
like
was
0.10,
which
was
like
one
of
the
very
first
ones
so
be
glad
to
get
back
to
a
little
bit
more
tighter
release
cycle
a
little
more
iterative,
so
anything
that
you
or
milan,
sam
or
milan,
that
you
all
wanted
to
add.
B
I
just
want
to
say
it's
a
it's
a
big
release
too
right,
I
mean
one
once
it's
available,
there's
a
lot
of
new
things,
so
I'm
excited
about
that
and
I'm
also
worried
about
monaco.
I'm
still
working
on
that
monaco,
it's
just
his
usual
pain.
So
hopefully
what
is
all
that
and
some
other
things
and
release
soon.
A
All
right
so
with
that
I
I
was
called.
B
A
Am
I
still
me
now,
okay
yeah,
so
with
that
I
was
gonna,
do
a
quick
demo
of
of
the
octant
or
electron.
So
let
me
let
me
see
if
I
can
get
that
pulled
up
here.
A
Oh
yeah,
I
see
I
see
my
so
there's
there's
I
will.
I
will
say
that
there
is
going
to
be.
Actually
let
me
you
know
this
won't
take
long.
What
I'm
gonna
do
is
I'm
going
to
just.
A
A
So
while
that
is
building,
I
will
re-share
the
the
notes
and
we
can
cover
cover
kind
of
what's
coming
up
next
after
electron.
Well,
that
builds
so
after
electron.
So
that's
kind
of
a.
A
A
I
highly
recommend
folks
go
and
take
a
look
at
the
specific
issues
if
they're
interested
and
there's
something
that
maybe
is
a
priority
to
you
that
you
don't
see
in
this
list.
Yet
I
highly
recommend
just
commenting
on
the
issue
and
say
hey.
This
would
be
great.
You
know
I
would
like
to
be
able
to
use
this
in
the
next
release,
or
this
is
a
blocker
for
me
or
this.
This
is
just
something
we've
been
wanting
to
do.
A
That
is
that
would
help
us
a
lot
just
your
feedback
on
that.
The
other
thing
is
we've
been,
we've
been
talking
about
it
for
a
while
and
it
the
odd
18
release
will
be
the
you
know,
just
like
that
famous
clip
of
steve
ballmer
saying
developers
will
be
doing
plug-ins.
A
Plug-In
api
plug-in
documentation
getting
test
harnesses
for
plug-ins,
improving
the
experience
of
using
some
of
the
components
within
the
plugins,
mainly
around
the
stepper
component,
forms
handling
actions,
doing
multi-step
type
interactions
like
like
stateful
type
actions
with
the
user.
We
know
right
now,
it's
a
little
difficult
to
do
and
requires
you.
A
Basically,
I
have
like
a
lot
of
intimate
knowledge
of
octant
and
know
kind
of
how
it
how
its
internal
request
loop
works
and
know
to
like
store
that
state
off
somewhere
in
global
state
of
your
plugin,
and
then
you
manage
it
as
the
actions
requests
come
in
and
and
then
you
have
to
make
sure
that
your
action
names
are
like
action
step.
One
action
step,
two
action
step
three,
so
you
like
know
what
step
a
user
might
be
on
we'll
we'll
be
able
to
make
that
whole
experience
a
lot
better.
A
Just
we're
just
kind
of
I
think
the
stepper
component
is
kind
of
going
to
end
up
getting
revamped
a
little
bit
to
just
have
a
a
more
opinionated
way
to
use
it
for
the
most
common
work
case,
which
is,
I
have
a
step
and
that
step
either.
Has
some
local
validation
and
or
an
action
to
validate
it
and
that
action
must
return?
A
You
know
a
positive
response,
a
true
like
a
valid
like
true
or
false,
and
then
I
will
the
the
like.
I
can
pass
that
into
my
stepper,
which
is
being
rendered
every
on
the
pulling
loop,
and
then
it
will
render
step
one
or
insert
the
error
messages
into
a
render
step
two
or
insert
the
air
matches
into
step,
one
just
to
go
over
that
again,
the
stepper
component,
each
step
for
those
who
haven't
seen
it.
Actually.
Let
me
just
pull
it
up.
It's
it's
probably
probably
easier
to
do
so.
A
This
is
what
I'm
talking
about.
Is
this
stepper
component
and
you
can
see
like
right
now
we
can
do
local
validation
and
there
are
actions
associated
with
that,
but
the
the
way
it
currently
works
right
now
is
when
you
like,
when
you
actually
do,
fill
this
thing
out
and
also
if
I,
if
I
get
this
wrong,
someone
correct
me,
but
when
you
fill
this
out-
and
you
hit
next-
that
clicking
of
that
next
button
doesn't
send
an
action
anywhere.
A
Yet
it's
the
actual,
submit
button
that
will
then
take
all
of
this
and
send
it
to
this
action,
because
you
see
the
the
actions
at
the
config
level,
not
at
the
step
level
and
and
that
action
will
stay
but
we'll
also
be
adding
actions
at
the
step
level.
A
You
kind
of
have
to
build
it
yourself
and
we
want
some
way
to
make
that
easy.
I
don't
know
what
that
api
looks
like,
yet
I
don't
know
exactly
how
that
flow
is
going
to
work,
but
we
we
know
that.
That
is
something
that
a
lot
of
people
want
to
be
able
to
do.
It's
something
that
I
personally
wanted
to
be
able
to
do,
and
my
plugins
is.
A
A
I
want
to
be
able
to
do
like
okay,
I
enter
the
name
wayne
and
then
I
click
next
and
that's
supposed
to
be
a
unique
field
on
the
server
side
right,
instead
of
allowing
the
user
to
go
through
to
step
two
and
three
and
four
and
then
you
send
them
all
the
way
back-
and
you
say
this
is
not
a
unique
name
right
that
that's
a
just
a
bad
experience,
so
we
want
to
enable
more
like
rich
experiences
like
that,
and
then
there's
also
some
inconsistencies
with
the
plugin
api.
A
These
are
all
it
is
that
one's
in
our
backlog
right
now,
the
list
behavior
is
inconsistent,
which
is
absolutely
true
right,
because
this
is
a
side
effect
of
the
what's.
The
word
I
want
to
use
to
this,
we'll
just
say
the
attempt
to
better
handle
permission,
access
denied
to
resources
that
the
current
attempt
that
is
in
octant
that
I
did
is
not
great.
It's
slow
has
a
lot
of
overhead,
and
it
does
this
here,
which
is
it
makes
the
list
behavior
inconsistent.
A
A
So
then
your
plugin
could
be
written
to
just
handle
the
error
and
move
on.
We
change
the
behavior
and
it's
inconsistent
it's
awful.
So
this
is-
and
this
is
100
my
fault.
So
that's
those
kind
of
inconsistencies
in
behavior
are
things
we're
going
to
fix
up?
I
believe
all
of
our
api
endpoints
suffer
from
this
because
of
the
way
we
do
access
checking.
A
So
we're
going
to
audit
that
and
make
sure
that
the
you
can
depend
on
on
the
behavior
and
that
the
errors
are
getting
surface
to
you,
even
if
we're
not
getting
them
from
the
api
in
real
time,
because
we
don't
want
to
spam.
The
api
you'll
still
get
the
previous
error
or
some
like
there'll,
be
some
method
where
you'll
get
you'll
get
the
error
that
was
originally
returned
and
then,
when
the
back
off
timer
kind
of
expires
and
it
tries
again
that'll
up
either
work
or
you'll
get
the
updated
error.
A
Adding
some
consistencies
between
our
go
plugin
api
and
the
javascript
one,
the
javascript
one
had
some
newer
features
like
link
refs,
and
what
else
was
there?
Is
it
deleting
or
applying?
That's
not
on
the
go
side.
I
can't
remember
exactly,
I
think,
there's
there's
a
couple.
Api
calls
that
are
not
on
the
go
side
of
things
and
folks
would
like
to
use
them,
and
that
makes
sense
so.
A
Oh,
the
plug-in
state
right
now,
the
plug-in
when
you
start
up
a
plug-in.
This
is
this
is
mostly
for
the
javascript
ones,
but
when
you
start
a
plug-in,
if
it's
at
launch
time
like
you're,
just
launching
octane
and
you
load
the
plugin,
it
gets
all
the
information
it
needs.
It
knows
the
context
and
the
name
space
and
all
this
stuff,
because
that
gets
sent
in
from
the
client
on
the
first
request.
A
And
then
we
pass
it
into
the
action
handler
and
you
can
capture
it
if
you're
working
like
if
you're
developing
your
plugin
and
it's
hot
reloading
when
it
hot
reloads,
it's
not
going
to
receive
that
event,
because
there
was
no
set
name,
space
event
fired,
and
now
it
has
no
idea
what
the
namespace
is.
So
you
you
just
have
to
wait
until
a
set
namespace
event
happens
or
until
a
request
comes
in.
That
has
a
namespace
with
it.
A
And
then
you
assume
that
that's
the
namespace
you
want
to
be
on,
but
again
the
more
inconsistent
behavior.
So
we're
going
to
add
a
initialization
event
that
plugins
can
subscribe
to
and
they
will
then
anytime
they're
reloaded
so
on
their
first
initial
load.
That
event
will
always
fire.
So
it'll
come
from
the
plug-in
api
side,
the
plug-in
manager
we'll
make
sure
that
anytime,
it's
loading,
a
plug-in,
it'll
fire
this
event
and
that
event
will
include
the
current
contacts.
A
The
namespace,
probably
like
the
current,
the
current
path
that
that
the
because
we
we
know
the
content
path
as
well.
Basically,
all
the
things
any
any
action
that
is
configurable
by
a
user
during
their
time
running
octant.
So
setting
the
namespace
switching
context
is
changing
paths.
Things
like
that
that'll
be
part
of
so
anything
that
gets
sent
into
octant
that'll,
be
part
of
that
initial
context
and
that'll.
Let
plugin
authors
actually
like
be
able
to
to
keep
in
sync
with
what's
happening
in
octane.
C
Yeah,
I
don't
want
to
derail
from.
I
guess
to
just
like
what
the
issue
of
5
15
13
too
much.
I
think
it's
that
problem
is
more
of
a
symptom
of
something
bigger,
something
that
I've
noticed
when
writing.
Plugins
myself.
Is
that,
because
often
it's
always
polling,
all
the
code
in
a
plug-in
is
pretty
much
run.
Every
time
often
pulls
which
is
like
once
every
five
seconds
or
something
right
and
really
the
thing
that
we
want,
or
I
feel
like
the
thing
that
I've
been
wanting.
C
There
is
just
a
some
sort
of
init
loop
right
like
some
code
that
I
can
only
expect
to
run
once
when
it
is
starting
and
to
do
all
like
all
the,
for
example,
just
setups
like
if
I'm
connecting
to
api,
make
sure
it's
connected
and
make
sure
it's
good
and
that
same
logic
with
initializing
plugins
like
say
the
names
current
namespace
and
path
could
all
live
there
right
like
just
just
place
in
a
plug-in
where
I
can
expect
things
to
run
only
once
like
kind
of
like
a
main
function,
as
opposed
to
something
that
I
have
to
just
make
sure
it
doesn't
get
caught
again
and
again.
C
For
example,
john
was
harris.
I
believe
he
was
running
trying
to
do
a
harbor
plugged
in,
and
he
once
said,
I
guess
pretty
basically
like
spammed
the
harbor
api
as
a
result
right
so
just
like
having
making
that
explicit.
I
think
would
also
be
helpful
to
help
a
lot
of
plug-in
authors
develop
the
mental
model
of
what
a
plug-in
is
actually
doing.
A
Yeah,
I
think
that
that's
a
great
call
out
that
to
me
that's
a
that's,
definitely
a
documentation
issue
unless
implementation
issue,
because
I
have
examples
of
plugins
both
in
go
and
typescript,
where
I'm
I
have
out
of
band
initialization
and
state,
and
I'm
using
like
I
in
my
main
before
I
before
I
kick
off
my
my
server
process
and
my
plugin,
I
fire
off
my
go
routine.
A
That's
going
to
run
in
its
own
time
and
doesn't
is
not
interrupted
by
the
requests
that
come
in
by
the
you
know
in
the
handlers
right
like
it's
really,
the
the
handlers
are,
what
are
gonna
get
called
every
every
second
but
like
in
the
javascript
plug-in
the
constructor
only
gets
called
once
and
in
the
go
plugin
that
main
routine
only
gets
called
once
right.
A
If
you
need
to
do
things
on
a
different
cycle
than
that
one
second
loop,
you
can
spin
off
your
own
go
routines
to
manage
to
manage
that
that
other
event
loop,
so
that
to
me,
that's
the
the
solution
is
getting
that
pattern
documented
both
in
the
so
that
plugin
authors
understand
that
the
handler
methods
are
going
to
get
called
once
a
second,
but
also
here
are
the
places
in
both
run
times
where
you
can
set
up
and
manage
your
own
state
and
event
loops.
C
Yeah,
probably
yeah
doc
I
mean
we
can
always
yeah.
Documentation
is
always
a
thing
right
like
it's
something
that
we
always
need
to
improve
upon,
and
I
know
you
have
those
examples
I
was
wondering,
if
maybe
perhaps
like.
Maybe
we
even
like
expose
it
as
a
first-class
thing.
Right
like
not
even
have
to
have
authors
create
their
own
go
routines
or
maybe
it
maybe
it
is
fine.
The
way
it
is
I'd
have
to
think
about
that.
C
A
little
bit
more
like
I'd
even
say
like
have
like
a
very
explicit,
or
I
guess,
maybe
what
I'm
trying
to
say
is
like
an
explicit
plugin
structure
that
says
this
is
going
to
run
once
rather
than
actually
having
to
think
about
it,
but
maybe
that's
just
adding
complexity
to
places
where
it
doesn't
need
to
be.
A
Yeah,
I
think
I
think
convention
here
is
probably
the
best
choice,
because
by
just
creating
by
by
making
sure
that
authors
the
that
anyone
who's
writing
a
plugin.
A
Just
knows
that
knowledge
right,
like
that
knowledge
is
right
in
your
face,
any
handler
method
is
going
to
get
called
once
a
second
and
action
handlers
are
only
going
to
get
called
when
an
action,
an
action
that
you've
registered
your
plugin
for,
is
broadcasted
right
and
then
we
can
show
patterns
of
like
in
it
in
it
once
or
run
once
whatever
and
then,
like
you,
have
your
run
once
method,
that's
in
main
that
runs
once
and
and
does
your
setup
or
kicks
off
your
event,
loop,
and
I
think
just
just
like
making
that
such
a
common
convention
that
it's
just
the
way
people
do
it
when
they,
when
they
copy
the
example
plugin
or
when
they
copy
like
getting
into
the
example.
A
Plugin,
I
think,
would
be
a
big
benefit
right.
Just
getting
some
out
of
band
event,
loop,
processing
and
state
holding
in
the
example
plugin
would
be
a
good
first
step.
A
lot
of
people
use
that
as
like
their
boilerplate
to
get
started,
so
I
think
putting
it
there
would
would
kind
of
create
that
convention
and
then
the
nice
thing
about
that
is
then
we
don't
have
to
there's.
A
No
there's
literally,
the
interpreter
doesn't
care
what
you
call
it,
but
literally
everyone
does
it,
and
I,
like
any
time
you
can,
you
can
get
that
that's
way
better
than
having
some
explicit
model
that
might
not
work
for
other
people.
A
A
So
yeah,
what
else
were
we
plugins
inconsistencies?
New
api,
oh
yeah?
This
is
this
again
goes
back
to
the
state
thing
but
currently
like
if
you
do
like,
if
you've
restarted,
a
plug-in
and
or
like
labels,
filters
stuff
like
that,
there's
no
real
good
way
to
observe
labels
and
filters
changing
from
a
plug-in
you
can
kind
of
like
you
can
be
on
the
actions,
but
then
again,
if,
if
it
reloads
and
those
are
set,
then
you
then
you're
not
using
the
right
label
filter.
So.
A
A
So
yeah,
lots
of
plug-in
stuff
lots
of
resource
viewer,
stuff,
isha
and
milan
have
been
doing
a
lot
of
work
around
resource,
viewer,
visualization
and
updates,
and
we
are
going
to
start
kind
of
writing
out
the
first
step
issues
like
hey.
What
are
the
incremental
steps
that
we
can
take
to
to
realize
our
resource
viewer
dreams?
So
I'm
not
sure
if
there's
anything
milan
wanted
to
add
there,
but
that
that's
coming.
A
And
this
is
my
favorite
part,
honestly,
so
after
0.17
and
we
are
producing
this
electron
binary
everyone's
going
to
be
like
there'll,
be
a
host
of
people
who
are
going
to
be
still
running
the
old.
You
know
binary
where
you
open.
My
browser
and
that'll
still
exist
in
for
a
while,
but
we're
letting
you
know
that,
eventually,
the
only
release
we
will
ship
will
be.
A
The
electron
release
eventually,
so
just
know
that
that's
coming,
there
will
still
be
binaries
of
the
octant
runtime
in
our
nightly
builds
and
those
will
always
be
available,
but
to
simplify
our
release
pipeline
and
to
make
things
easier
when
it
comes
to
package,
managers
and
installs,
and
and
all
of
that,
as
we
as
we
continue
down
this
path
of
electron,
we
will
be
oh
in
the
in
the
release
tag
so
like
when
you
go
and
you
come
into
octant
and
you
go
to
releases
right.
This
will
be.
A
This
will
be.
The
eventually
will
be
the
electron
binaries.
Probably
my
guess
is
either
we'll
start
to
be
louder
about
it
in
18,
we'll
be
even
louder
about
it
in
19,
and
then
we
will
probably
do
something
like
that
for
either
whatever
whatever
the
release
is
before
we
go
to
1.0,
we'll
we'll
it'll
already
be
hap.
It'll
have
already
happened
so
by
the
time
1.0
comes
out,
the
only
release
asset
will
be
an
electron
build,
but
we'll
be
very
loud
about
it
and
continue
to
yell
about
it.
A
Both
on
our
we're
gonna
have
blogs
and
also
the
stream
here.
The
blogs
they're
everywhere
we'll
be
yelling
about
it,
so
know
that
it's
coming,
but
the
advantage
of
that
and
and
why.
I
think,
a
lot
of
people
will.
A
People
hate
change,
but
ultimately,
I
think
they'll
see
the
advantage
of
this
change
in
a
lot
of
a
lot
of
ways
and
the
first
ways
what
we're
going
to
what
I'm
hoping
to
target
frod18,
which
will
be
the
second
release
in
the
since
we're
moving
to
electron,
auto
updates.
A
I
think
it
I
think
it's
like
a
fundamental
part
of
of
why
we
want
to
be
on
electron
is
to
be
able
to
do
that,
because
that
will
really
there's
two
parts
of
this.
The
one
is
just
you
know
for
us.
It
will
really
tighten
up
our
ability
to
release
quickly
like
we.
A
This
last
release
was
not
slow
because
of
anything
in
our
pipeline.
This
wrassles
was
slow
because
the
electron
stuff
took
longer
than
we
planned
for,
but
in
the
past,
we've
definitely
had
like
point
releases
and
security
fixes
where
it's
like
a
whole.
A
Like
the
fix
the
issue,
the
report
comes
in,
the
thing
gets
merged
within
an
hour,
and
if
we
had
an
auto
update
system,
we
could
get
that
out
to
people
and
what
happens
now
is
we
the
all
the
package
managers
have
to
update,
and
some
of
them
are
faster
than
others
and
they're
great
tools,
but
they
some
of
them,
can
be
painfully
slow
to
get
the
update
in
there,
and
so
you
know,
even
when
we
do
get
quick
turnaround
on
a
bug,
fix
we'll
get
the
same
report.
A
The
same
report,
the
same
report
for
two
three
days
even
after
the
release
is
out
and
then
like.
Oh,
have
you
updated
your
cache
and
clear
or
cleared
your
cache
and
refreshed
and
fetched
a
new
list,
and
then
you
know,
then
it
kind
of
whittles
down
and
people
have
the
latest
release
and
so
just
being
able
to
get
things
out
quicker.
Write
directly
to
folks
and
take
advantage
of
of
that
tighter,
like
cycle
will
be,
I'm
very
excited
for
it.
A
Like
I
yeah,
I
think
I
think
it
will
really
change
the
way
we
we
ship
a
lot
of
stuff
with
octane,
we'll
be
we'll
we'll
hold
on
to
less
for
a
period
of
time,
because
another
part
of
kind
of
just
how
I
I
like,
because
we
have
to
go
through
all
the
steps
of
updating
all
the
package
managers.
I
prefer
releases
to
be
like
of
substance
right
and
so
I'm
like.
Oh,
we
did
this
little
incremental
thing
that
maybe
a
couple
people
care
about
we'll.
A
I
don't
want
to
go:
do
the
brew
and
chocolatey,
you
know
so
we'll
we'll
just
hold
it
until
we
get
a
few
more
things,
and
I
this
will
for
me.
This
will
remove
that
barrier
where
I'll,
just
yeah,
let's
fire
out
an
update,
so
not
that
we
won't
update
those
package
managers,
but
people
who
are
on
a
release
that
has
auto
update,
enabled
will
get
the
change
right
so
and
then
the
thing
that
I'm
excited
for
as
well
is
just
the
better
system.
A
Tray
having
getting
to
a
point
where
octant
is
just
kind
of
there
running
is
something
that
I'm
excited
about
getting
to
a
point
where
octant
is
there
running,
and
then
this
pipe
dream
I'm
about
to
talk
about,
but
like
octant's
there
running
in
the
system
tray
you
ins,
you
run
a
g
cloud
command
which
puts
in
a
new
cube
config
in
place,
and
then
you
get
a
little
system
notification
that
says:
octant
octane
now
has
access
to
this
cluster.
A
Would
you
like
to
view
it
and
you
click
and
you
pull
up
your
new
cluster
and
it's
there
or
you're
in
octant,
and
you
have
some
resource
that
you're
working
on
and
you
click
it
and
you
say,
notify
me
if
this
thing
returns
anything
but
okay
and
then
you
just
minimize
octane,
go
away
right
and
you
start
hacking
and
hacking
and
you're
deploying
and
your
rest
and
then
it
pops
up
and
it
goes
up.
There's
an
error
and
you're
like
oh,
my
apply
command
messed,
something
up.
A
There's
the
red
item
and
and
you're
in
right
like
having
these
integrations
into
the
operating
system,
having
octet
running
and
being
tied
into
the
notification
system
and
and
having
a
tray
like
it,
really
is
really
going
to
enhance
the
experience
like
this,
this
operating
environment
that
that
we
can
kind
of
provide
around
kubernetes
and
development.
So
I'm
really
excited
for
that.
A
This
is
it's
very
exciting
to
me
and
the
last
one
is:
is
plugin
management,
even
just
a
simple
being
able
to
like
go
to
a
thing
in
the
in
the
file
drop
down
that
says
plugins
and-
and
it
opens
up
the
folder
right
and
just
being
like
even
that's
better
than
what
we
have
now,
which
is
like
go
find
this
dot
folder,
that's
hidden
away,
or
this
app
data
folder,
that's
hidden
like
little
simple
things
like
that
will
will
be
a
huge
advancement.
A
I
know
sam
had
some
ideas
around
plug-in
management
once
we're
running
an
electron,
I
think
being
able
to
like
drag
and
drop
and
manage
the
actual
binaries
and
and-
and
things
like
that
directly
from
octane,
which
I
also
think
would
be
great.
So
is
there
anything
else
that
that
other
folks
are
excited
about
as
we
move
to
this,
you
know
being
an
an
actual
application.
B
C
Mean
like
so
like,
I
think
the
coolest
part
about
this-
is
that,
like
a
lot
of
what
we've
been
doing
up
to
this
point,
right
is
kind
of
like
almost
even
prep
work
right
like
like.
We
haven't
really
cashed
in
on
why
we
think
this
client-sided
model
is
great
up
until
now,
which
sounds
crazy
to
talk
about
right,
but
it's
almost
even
like
a
year
ago,
we
said
we
had
to
have
all
these
things
done
before.
We
could
even
do
electron
and
now
we're
here
and
now.
C
This
is
kind
of
like
the
point
where
we
can
really
start
taking
off
and
start
putting
in,
like
the
kubernetes
smarts
right
like
up
until
now.
Even
like
you
know,
like
we've
been
like
writing
printers
right,
like
I
really
hated
when
we
have
to
say,
octane
is
kind
of
like
an
augmented,
cube
config
because
yeah
that's
technically
what
it
is
now,
but
it's
not
really
selling
the
it's
not
really
selling
the
project
very
well
and
even
like
up
until
this
point
right.
C
I
want
to
run
octan
in
a
pod
and
really
it's
it's
like
that's
missing
the
whole
point,
and
by
forcing
this
model
we're
gonna
lose
some
users,
but
at
the
same
time
we're
really
gonna
start
diving
into
why
we
did
things
the
way
we
did
and
start
really
cashing
in
on,
like
the
whole
point
of
this
model
and
there's
some
really
cool
stuff,
like
you
know,
like
we're,
we're
gonna
actually
add
the
kubernetes
smarts.
A
Okay,
so
I
think
I
actually
forgot
that
I
was
gonna
gonna
do
this
demo.
So
let
me
let
me
make
sure
that
that
works,
and
then
I
will.
A
A
You
can't
I'm
typing
into
a
terminal,
I'm
just
trying
to
you
know
it's
par
for
the
course.
Okay,
I
will
try
one
more
build
on
that
and
then,
if
anyone
else
has
it,
has
it
running
and
and
wants
to
show
it.
Let
me
know
off
the
latest
master
in
particular,
because
it
has
all
of
those
quality
of
life
things
we
merged
in
in
the
meantime.
C
A
The
last
item,
which
is
a
very
important
one
to
me-
I
mentioned
it
earlier
in
the
year.
I
think
at
our
first
community
meeting,
when
we
were
back
from
the
new
year,
specifically
around
community
membership.
So
this
was
published
just
today,
but
what
the
goal
here
was
to
kind
of
define?
Okay,
what
what
role
do
we
have
in
the
octan
community
and
honestly,
with
being
a
smaller
community
and
and
not
really
having
the
need
at
this
moment
for
a
whole
expansive
set
of
roles?
A
We
settled
kind
of
just
on
this,
like
approver
role,
which
is
where
most
people
end
up
falling
if
they
contribute
to
the
project,
enough
and
approvers
can
can
review
and
approve
contributions,
and
but
now
we've
we've
put
to
that
kind
of
like
okay.
What
are
the
requirements?
A
Well,
you
you're
sponsored
by
two
approvers
and
you
have
multiple
contributions
to
the
project
and
what
does
it
mean
to
get
this
role?
It
means
you
get
commit
access
to
the
octan
repository,
so
one
of
the
one
of
the
things
about
this
is
we've
also
kind
of
outlined.
A
Okay
here
are:
the
here
are
the
actual
requirements
for
this
in
in
like
concrete
numbers
like
here's,
you
do
these
things
and
you,
you
know,
get
sponsored,
and
then
you
go
open,
an
issue
right,
which
we
added
an
issue
template
for
to
make
it
really
easy.
So
when
you
go
new,
there
is
now
this
become
an
auction
approver.
A
I
wonder
if
there's
a
way
to
reorder
these,
I
think
they're
alphabetical,
which
is
fortunate,
but
so
that
one's
at
the
top.
But
when
you
click
here,
you
now
get
this
template
right
and
that
template
has
the
kind
of
the
checklist
to
go
through
the
sponsors
to
list
your
username
and
then
your
list
of
contributions
and-
and
so
this
is
exactly
the
one
way
to
to
you-
know-
become
an
official
approver
for
the
acting
project.
It's
very
exciting.
A
We've
never
really
had
language
around
it
before,
and
I
think
that
has
caused
a
lot
of
folks
to
kind
of
just
be
hesitant
to
get
involved
and
like
not
understand
their
impact
and
and
what
it
means
to
be
a
contributor
to
octet
and
approver
on
octa,
and
so
we
fixed
that
and
yeah.
I
think
it's
I
think
it's
really
great.
I
think
I
think
this
will
encourage
folks
to
kind
of
get
a
little
bit
more
involved
and
and
understand.
A
All
right
cool,
oh
and
we
put
in
explicit
language
around
an
activity
as
well.
Just
you
know,
if
you're
inactive
for
12
months,
then
we
we
don't
we
don't
remove
you
from
the
record.
We
do
remove
your
access,
but
so
it's
it's
kind
of
catalogued.
Here
we
have
these
these
folks
who
previously
contributed
to
the
project
as
at
the
approver
level,
and
so
the
the
your
your
name
is
still
here
and
you're.
A
Still,
you
know
remembered
as
someone
who
is
approving
contributing
at
a
high
level
to
the
project,
but
you
know
we
don't
want
to
have
a
bunch
of
people
just
hanging
out
with
with
access.
So
it's
all
there
trying
to
think.
I
think
that's
that
covers
everything
on
the
agenda
that
I
had
were
there
any
before
before
we
try
to
put
together
a
demo.
Were
there
any
questions
for
the
open
q.
A
A
All
right,
let
me
I'm
gonna,
try
running
mine
one
more
time
and
see
if
it's
works.
C
All
right
cool,
you
know
what
I'll
share
everything
I
have
nothing
to
hide
all
right.
Let's
see
this
window,
all
right
is
this
zoomed
in
okay.
I
have
to
share
everything
because
there's
the
menu
stuff
up
top
here
that
needs
to
be
sharing
okay
cool.
So
this
is
the
electron
build
so
biggest
things
here.
Are
that
one
it's
running
electron?
If
you
look
at
here,
it's
actually
got
the
icon
tray,
so
it
actually.
A
C
Could
make
it
go
away?
It's
not
going
to
go
away,
it
doesn't
want
to
go
away.
C
It's
minimized
already:
okay!
Well
too
bad,
it's
hanging
out
now
yeah,
so
you
can
kind
of
see.
You
know
it's
got
the
sis
icons.
My
side
tray
won't
pop
up
right
now,
because
I
guess
I'm
sharing
the
screen,
but
you
can
see
the
octane
logo
on
your
system
tray,
that's
pretty
dope
cool
stuff,
let's
see
so
going
through
this
menu.
That
was
added
recently.
I
think
scott
was
the
one
who
pointed
out
that
we
used
the
default
menu
and
went
to
electron.
C
now
goes
to
octan.dev
got
the
zoom
controls
here.
We've
got
the
logs,
let's
see,
and
it
would
just
pop
out
and
takes
you
to
your
logs
in
temp
it's
in
root.
I
actually
don't
even
know
if
these
would
open,
but
we'll
just
leave
that
alone.
For
now
quit
so
yeah
we
added
the
quit
menu
yesterday.
C
What
other
things
do
we
want
to
see?
The
scroll
bars
are
implemented,
but
it
specifically
looks
nicer
on
electron.
I
guess
so,
like
you
used
to
have
the
browser
scroll
bars
and
now
you
have
the
minimalist
simple
bar.
That's
kind
of
used.
Also,
a
few
places
quick,
switcher
still
works.
We've
got
cluster
api
set
it
set
up
here.
C
C
So
yeah
sample
plugin
is
running
and
you
know
it's
the
same
old
often
you
know
and
love
the
new
nav
is
still
here.
We're
probably
gonna
have
to
bubble
up
the
keyboard
shortcuts
or
have
some
duplication
to
show
it
up
here
as
well,
or
we
can
even
actually
remove
it
all
together.
So
this
is
another
case
of
having
both
the
web
app
and
the
electron
can
potentially
clash-
or
maybe
not,
I
think,
like
other
electron
applications-
also
show
this
menu
twice.
C
So
we
can
start
deciding
like
what
things
should
belong
up
here
and
there's
no
system
often
tray
yet,
but
we
can
add
that
pretty
soon
and
then
you
can,
but
we
can
also
decide
what
belongs
up
there
right.
It
would
be
like
quit
or
it'd
be
kind
of
cool
if
we
could
have
like
a
jump
to
context
situation
same
old
thing,
and
we
can
look
at
things
like
you
know
like
say,
like
these
docker
machines
cube
atom.
I
think
machine
deployments.
C
That's
the
one,
that's
interesting
to
people,
because
it's
got
the
most
stuff
right,
but
we're
still
working
on
resource
vr.
We
have
yaml,
as
we
know
the
monocle
editor
isn't
working,
so
it
just
kind
of
hangs
out
here
forever.
You
can
still
use
dev
tools
if
you
want
to
see
console
logging
and
know
what
happens
in
the
background.
C
A
Screen
it'll
remember
its
size
when
you,
if
you
resize
the
window
and
close
it
and
then
reopen
it,
it'll
kind
of
remember
its
size
and
position.
Oh
yeah.
C
A
Please
work
yeah,
I
think
long
term,
we'll
probably
end
up
removing
the
like
the
file
edit
help
bar
and
putting
in
like
like
similar
to
what,
like
slack
and
other
applications,
do
where
they
just
they
put
in
their
own
custom
menu.
A
I
think
I
think,
for
us,
that's
going
to
overall
work
better
because
we
there's
going
to
be
things
in
that
custom
menu
just
like
those
shortcuts
and
other
things
that
we'll
want
to
have
be
part
of
the
it'll
be
easier
to
have
be
part
of
the
web.
App.
C
Yeah,
that's
pretty
much
it
any
questions
or
anything
specifically.
People
want
to
see.
A
D
D
A
D
Yeah
the
one
thing
that
did
come
up
because
I'm
now
running
it
on
my
windows,
machine
and
I've
always
been
running
it
just
on
a
linux
machine.
With
the
with
the
initial
asking
for
a
cube
config.
The
first
time
that
I
ran
it,
which
was
great.
D
It
takes
a
long
time
on
windows
to
find
where
that
cube.
Config
is
saved
in
the
app
data,
local
and
not
in
a
really
findable
location,
and
I'm
wondering
if
it's
possible
or
something
that
would
be
useful
for
others,
possibly
to
have
the
ability
to
either
have
that
form
come
up
as
a
manual
task
in
an
action
form
of
apply
a
new
cube
config.
D
If
it's
coming
from
that
app
data
location
or
to
allow
where
it
should
be
saved,
or
at
least
have
it
documented,
where
it
gets
saved
on
windows,
because
it's
not
straightforward
that
it's
in
the
app
data,
local
temp
location,
where
it
saves
that
temp
cube
config.
A
Yeah,
no,
that
makes
sense.
Would
you
mind
putting
that
into
a
an
issue
that
because
then
we
can
like
just
essentially
what
you
just
described.
I
think,
because
I
think
we
can
come
up
with
a
with
a
good
fix
for
that.