►
From YouTube: EOS MANDEL Meeting #15 (May 18th 2022)
Description
This week the EOS Network Foundation discusses the Platform Support survey results, updates the community on the D.U.N.E release, goes over Transaction Lifecycle features and Testing on Jungle 4.
Github - https://github.com/EOS-Nation/mandel/issues/74
Summary
🟢 In progress action items are on track:
#55
D.U.N.E., the new development environment is ready
33 EOS developers responded to the platform support survey
17 of those respondents selected "purely native" as their preferred development environment
1 of the respondents who prefer a native development environment said that a well documented docker image would not be an acceptable alternative for the Mac, with the following reason: Docker too slow and created a lot of trash on local machine. Also running native unit tests and each time rebuild docker image is worst dev experience.
12 of the respondents who prefer native development environment said that a docker image would meet their needs and 2 said maybe.
We will share D.U.N.E. with respondents and ask for feedback on the experience.
Screen Shot 2022-05-18 at 9 50 27 AM
#41
API+ Transaction Lifecycle features have been delivered by OCI and are being tested on Jungle4.
Long list of bug fixes have been completed and are being documented
Block log splitting in progress, will be delivered close to June 1
80% complete analysis on 2.1 and 2.2 features and all PRs and prioritized and logged issues for Mandel (2500 PRs)
Mandel 3.1 contains all of 2.0 and the key features of 2.1 plus a bunch of bug fixes
#44
EOS Nation is continuing to test transaction lifecycle features - testing is going well
EOSphere is now producing on 3.05
EOS USA is looking forward to testing 3.1 features
There's an opportunity to think about what role Kylin plays in testing - does it mirror EOS current state or future state?
Participants (20)
Host: Daniel Keyes | EOS Nation
Matt Witherspoon
Ted Cahall
Vlad
Bucky Kittinger
Aleksandr Aksenov
cmadh - liquiid.io (Corvin Meyer auf der Heide)
Jeff Werner
Max_Cho EdenOnEOS Member-South Korea
Dario | EOSsupport.io
Andriy Cryptolions (Andriu Bobrovych)
junhank | NodeONE
Hau | EOSNation
swatanabe
Brian Johnson
Zack Gall
EOSUSA Michael
Ross (EOSphere)
Kevin Heifner
Denis Carriere
00:00:00 Intro
00:00:08 Recap of last week by Daniele Keyes
00:01:29 Platform Support survey results by Daniel, Jeff, and Buckey
00:02:35 Native Support vs Docker Image
00:10:01 Docker Utilities for Node Execution (D.U.N.E) by Buckey Kittinger
00:11:37 Mandel Development and Prioritization update 3.1 by Ted, Kevin, and Matt
00:12:20 Transaction Lifecycle features are completed by Ted, Kevin
00:15:42 Block log splitting and PR list analysis by Matt Witherspoon
00:24:09 Testing Mandel on Jungle 4 by Ross and Michael
00:25:52 Testing EVM on Jungle 4 feedback by Daniele Keyes
00:33:14 End
Everything EOS is the official media channel of the EOS Network Foundation (ENF). The EOS Network Foundation coordinates financial and non-financial support to encourage the growth and development of the EOS Network. We’re harnessing the power of decentralization to chart a coordinated future for the EOS Network as a force for positive global change.
// EOS Network Foundation //
https://eosn.foundation
https://twitter.com/EosNFoundation
https://www.linkedin.com/company/eos-network-foundation
https://t.me/EOSNetworkFoundation
https://discord.gg/eos-network
info@eosn.foundation
#EOS #EOSIO #ENF
A
All
right
welcome
everybody.
It
is
week
15
of
the
mandel
check-in
meetings.
It's
may
the
18th
I'll
quickly
recap
what
we
went
over
last
week.
Last
week
we
talked
about
the
progress
being
made
on
the
docker
images,
looks
like
we've
got.
It's
evolved
from
a
just
a
set
of
docker
images
to
a
full
blown
dev
environment,
including
web
ide.
So
that's
that's
great.
It
looks
like
we're
close
to
being
able
to
share
that
more
broadly
mandel
development.
A
A
We
had
ross
report
that
now
eosphere
is
is
running
mandel
3.05
and
there
was
a
question
raised
by
eve
about
the
I
guess:
the
stability
of
jungle,
four,
which
we've
we've
gotten
a
response
from
matthew.
I
can.
I
can
share
his
thoughts
when
we,
when
we
cover
that,
so
we
can
continue
looking
in
the
progress
there.
Are
there
any
other
new
items
to
add
to
the
agenda
today.
A
I
have
oh
yeah.
I
have
some
news
to
report
also
on
the
on
platform
support
the
we
have
results
now
for
the
survey
that
was
sent
out
by
eosupport.
I
won't
there's.
I
want
just
to
make
sure
I
don't
share
any
private
information.
I
won't
share
the
results
directly,
but
I
can
speak
to
the
aggregated
kind
of
insights
and
maybe
we
can
work
on
putting
together
something
that
that
we
can
either
share
everything
more
privately
with
this
group
or
hide
the
private
information
just
to
get
the
insights
we
need
publicly
so
yeah.
A
Maybe
we
can
start
with
that.
We
so
the
the
survey
went
out
to
hundreds
of
eos
support
contacts.
We've
gotten
34
responses
back
the
it
looks
pretty
good
in
terms
of
so
we
there's
a
pretty
big,
a
pretty
good
mix
of
what
platform
people
are
using,
whether
linux
mac
windows,
it's
a
pretty
broad
range.
One
of
the
questions
we
asked
of
for
those
who
are
running
native
rather
than
in
a
dot
would
a
docker.
A
We
had
every
pretty
much
everybody
say.
Yes,
there
was
one
person
who
said
no,
they
meant
they
said.
Docker
is
too
slow
and
created
a
lot
of
trash
on
local
machines,
also
running
native
unit
tests
and
each
time
rebuild.
Docker
image
is
the
worst
dev
experience
and
we
had
a
couple
people
say:
maybe
native
support
is
always
better
than
docker
was
one
comment.
A
C
Yeah,
I
mean
it's
pretty
surprising,
because
you
know
I've
gotten
the
so
I'm
done
with
the
platform
support
part,
so
we
can
kind
of
cross
that
off
the
list
there.
So
I've
I've
been
running
this
dune
tool
on
a
on
a
wind,
microsoft,
surface
tablet.
You
know
what
I
mean
like
it's,
it's
perfectly
fine
with
running
it
on
that.
C
Secondly,
docker
itself
really
shouldn't
be
putting
that
much
of
a
of
a
performance
penalty
on
anything
because
it's
not
you
know
unless
if
they
are
running
wind
like
maybe
the
thing
was
that
they
were
trying
to
like
they're
on
a
modern,
m1
and
they're
running
docker,
with
an
x86
image.
Yeah,
it's
gonna
emulate
x86
and
that's
a
pretty
atrocious
amount
of
performance
that
that's
why
we
now
have
the
arm
images
so.
D
C
I
mean
it
depends
on
what
you
mean
by
vm
right,
like
there's
hardware,
virtualization,
that
it
does
kick
in
same
thing
on
windows.
So
yes,
but
it's
a
fairly
thin
layer.
You
know
I
mean
like
the
the
the
amount
there
that
it's
doing
is
pretty
minimal.
It's
not
like
a
full
blown
you're
running
this
thing
in
virtualbox.
C
Sure,
but
I
mean
I
haven't
really
seen
that
much
of
a
performance
penalty
across
any
of
the
platforms.
You
know
I
mean,
like
that's
the
the
point
I'm
trying
to
get
to
there's
like.
I
think
that
there's
some
degree
of
either
people
have
been
using
this
incorrectly
or
or
they're
running.
You
know
arm
images
on
an
x86
or
or
x86
on
an
arm
image
or
on
a
arm
machine.
You
know
I
mean
that
that
does
greatly
increase
the
amount
of
performance
penalty
that
you
have,
but
it's
also
going
to
depend
on
it.
C
Are
they
planning,
like
there's
the
big
issue
there?
Are
they
planning
this
for
dev
usage?
Only
or
are
they
planning
this
for
running
like
a
full-blown
nodeos
node
right
to
sit
there
and
run
a
network?
You
know
I
mean
that
that's
this.
It's
been
the
other
sort
of
big
question,
because
this
is
this
is
designed
for
you
know
dev
support
and
I
would
say,
if
they're
planning
on
running
nodes,
then
I
don't
know.
I
think
I
thought
the
I
think
the
the
the
answer
to
that
was
linux.
You
know
I
I
don't
know.
A
A
Does
your
team
do
tomorrow
and
the
the
question
was
framed
for
smart
contract
developers
so
yeah
this
this
person
who
said
no
by
the
way
we
had
again
34
responses,
15,
who
had
indicated
they
they
do
use
native
and
all
of
them
said
yes,
docker
would
meet
their
needs,
except
for
the
one
person
who
said
no
and
two
people
who
said.
Maybe
so
it's
pretty
good,
I
would
say
you
know
most
people
believe
a
docker
will
will
suit
their
needs
again.
A
What
this
this
dune
thing
is
probably
better
than
what
any
of
these
people
are
expecting
from
their
experience
of
of
using
dockers.
So
we
could
I've.
We've
got
the
contact
information
here
for
the
folks
who
responded
we
could
when,
when
we
have,
you
know
a
working
version
of
this
of
this
dune
system
ready.
Maybe
we
can
have
some
of
these
teams.
Try
it
out
the
teams
that
have
the
concerns
on
these
and
see
see
if
it
does
indeed
meet
their
needs.
Maybe
they'll
be
pleasantly
surprised.
C
B
A
A
B
A
A
Great,
so
we
can
wow
beautiful
wow
bucky.
Well,
the
fancy
thing
nice
very
nice
great,
so
that's
yeah,
so
we
can
still
I'll
we
can
start.
Maybe
we
can
get
eo
support
to
help
reach
out
to
these
folks
who
participated
in
a
survey
and
and
say:
okay,
great
now,
try
it
out.
Let
us
know
that'd,
be
awesome,
cool
anything
else.
To
add
on
that
topic
of
of
platform,
support.
A
B
It's
going
very
well
we're
the
oci
guys
are
just
crushing
it
they're
doing
an
amazing
job
of
cleaning
up
stuff
matthew,
darwin
is,
is
feeding
them.
Some
things
that
block
producers,
you
know
feel
that
would
be
helpful
and
they're
just
crushing
those
as
well
we're
we're
coming
down
to
the
line,
but
I
think
we're
great
on
the
block
log
splitting
I
think
I'm
kevin
is
on
the
call.
B
B
A
B
A
B
Notes
that
that
kind
of
made
it
into
the
cleanup
of
3.1
there's
a
lot
a
lot
more
in
there
than
I
think
we
were
expecting
because
oci
has
just
just
gone
down
a
massive
list
and
closed
out
items
and
and
matt
also
made
a
list
from
all
of
the
kind
of
open
requests
back
in
the
2.1
2.2
days
and
and
matt
also
has
gone
and
gunned
down
and
crushed
a
whole
bunch
of
those.
So
there's
a
lot
of
cleanup
and
loose
ends
that
have
been
kind
of
fixed
and
gone
into
3.1.
B
E
Yeah
I
mean
there
are,
there
are
features
in
there.
You
know
technically,
there
are
features
in
there.
Most
of
them
are,
you
know,
pretty
small.
It's
not
like.
You
know.
Large
features
like
big
sweeping
changes.
They're
mostly
I
categorized
as
bug
fixes
and
even
the
ones
that
are
like
technical.
You
might
technically
call
a
new
feature
like
a
new
new
option
or
those
sorts
of
things.
They're,
they're
mainly
focused
on
on
bug,
fixes
that
have
that
are
in
two
one.
E
A
B
D
Yeah,
I've
kind
of
waffled
a
bit
on
what
I'm
ultimately
going
to
do
here,
but
it's
just
to
ensure
we
get
this,
I'm
sure
we
have
something
before
we
went
to
make
the
release,
I'm
probably
going
to
take
the
implementation,
that's
in
two
one
at
least
initially,
and
bring
that
over.
I
was
hoping
to
get
something
a
lot
simpler,
but
there's
a
lot
to
it,
so
I
think
to
make
sure
we
have
something
ready.
That's
the
strategy,
I'm
taking
at
the
moment.
B
D
You
know
I
I
haven't
actually
looked
at
that
in
the
past
few
days
as
I've
been
kind
of
heads
down
with
the
block
clog
and
chip
blog
stuff,
but
yeah.
You
know
it
really.
What
that
list
was
is
just
a
a
dump
of
all
the
pr's
that
went
into
the
old
block,
one
eos
repo
after
the
two
oh
release-
and
I
mean
kevin
already
kind
of
did
a
great
summary
about
him.
You
know,
there's,
there's
bug
fixes
in
there.
There's
minor
features,
there's
just
some
general
improvements.
D
There's
removal
of
old
deprecated
features,
it's
just
a
whole
smoggers
board
of
of
of
of
various
things
and
yeah.
I
mean
we're
getting
close
to
at
least
getting
some
sort
of
disposition
for
all
of
them,
whether
it
be
don't
take
or
pour
them
over
or
create
an
issue
that
we
can
reference
and
decide
what
to
do
with.
You
know
not
necessarily
this
release,
but
at
least
we
don't
lose
track
of
it.
We
can
decide
what
to
do
in
a
you
know
in
a
future
time
frame.
B
Yeah,
I
really
appreciate
you
doing
that
what
what
matt
basically
did
was
he
grabbed
everything
from
where
we
snap
shotted
2.,
whatever
2.0.14,
whatever
we
took,
that
became
the
mandel
3.0
and
he
looked
at
any
pr's
that
were
applied
to
two
any
later
releases,
2.1
2.2.3
and
grabbed
those
and
just
made
a
list
out
of
them.
That's
as
forward-looking
as
things
that
we
want
to
either
just
say:
we're
not
taking
them
or
we
will
pull
them
in
and
those
are
the
things
that
a
bunch
of
those
did
make
it
into
this
3.1
release.
D
The
big
thing
with
that
list
was
just
to
make
sure
nothing
fell
through
the
cracks,
and
I
think
it
was
very
useful
in
that
sense,
because
there
were
some
things
in
there
that
I
didn't
really
even
remember
that
I'm
glad
we
we
looked
through
and
and
found.
So,
if
you're,
if
you're
worried
that
oh
I
haven't
seen
the
list,
I
want
to
go
look
at
the
list.
Well,
you
know
it's.
The
list
is
more
of.
D
Let's
just
make
sure
we
we
see
everything
and
and
get
get
appropriate
issues
logged
and
and
things
of
that
nature.
It
wasn't
like
a
a
working
like
a
long
term
working
list
of
any
sort
but
yeah.
You
know
I
think
it.
It
served
us
well
in
making
sure
we
didn't
lose
anything
through
the
cracks,
because
I
mean
you
know
we're
talking
thousands
of
prs
that
went
into
the
old
block,
one
repo
after
the
2-0
release,
which
is
what
mandel
was
originally
forked
off
of
guys.
E
E
We're
not,
I
don't
know
like
we're,
not
really
counting
it.
In
that
way
I
mean
you
could
go
through
there
and
see.
There's
we've
marked
things
as
merged,
which
means
it's
already
in
either
as
part
of
some
other
effort
or
was
you
know,
brought
over
in
some
other
way.
So
there's
a
lot
of
those
there's
there's
a
lot
of
there's
still
a
lot
marked
with
tvd
that
that
we
need
to
either
create
issues
for
or
make
a
decision
for,
there's
a
lot
of
them
just
mark.
No,
it's
like
one
of
them.
E
I
think
I
wrote
hell.
No,
so
you
know
some
of
that
sort
of
thing,
but
yeah
and
then
there's
some
that
just
have
an
issue
in
an
issue
number
and
then
others
that
have
that
were
actually
just
worked
right.
We
didn't
have
a
pr
number,
so
there's
a
smorgasbord
in
there
and
we're
still,
you
know
we're
only
working
off
off
of
that
for
a
while
longer
until
at
some
point
we
can
then
say:
yes,
every
line
in
the
spreadsheet
either
has
an
issue
created
or
we've
decided
it's
no
or
it's
already
yet.
B
Right,
great
and
we'll
continue
three
dot,
we'll
start
3.2
planning.
In
a
couple
of
weeks,
we've
been
running
the
meeting
looking
at
3.1
and
then
we'll
kind
of
look
at
you
know
a
what's
going
on
with
all
of
the
rfps
and
stuff
that
might
make
it
into
3.2,
then
plus
additional
issues
that
are
coming
from
that
list
or
other
ideas
that
other
you
know,
developers
are
coming
up
with
that.
A
B
E
B
E
Although
then,
after
that,
we
did
go
ahead
and
merge
in
the
head
of
eosio
release
a
2-0
x,
so
it
has
the
very
latest
including
a
few
unreleased
things
in
the
release
of
zero
x
branch
and
and
then
we've
been
working
like
mad
to
pull
in
stuff
from
from
two
one
to
get
in
into
3.1.
And
you
know
again,
we
won't
have
that
complete
by
the
time
of
3.1.
So
what
you're
gonna
get
in
3.1
is
somewhere
between
eosio
2.0
and
3,
and
and
2.1
plus,
a
bunch
plus
the
other
stuff.
E
B
E
Yeah
plus
a
time-
and
I
would
say
you
know
if
people
start
evaluating
3-1
rc
or
you
know,
or
just
main
at
the
moment,
you
know
if
you
want
to
start
looking
at
something.
Obviously,
if,
if
there's
some
2.1
feature,
we
missed
or
you
you
notice
that
hey
where's
this,
certainly
let
us
know,
and
we
can
you
know,
obviously,
sooner
better
than
later,
we
can
try
to
get
that
in
there
right
away.
A
A
A
And
in
terms
of
testing,
I
don't
have
much
to
report
on
the
nation
side
of
things
besides
matthew
mentioned
so
far,
so
good
everything
looking
good
just
he's,
looking
forward
to
testing
the
lock
log
splitting,
but
everything
else
that
he's
tested
so
far
seems
to
be
looking
pretty
good,
ross
or
michael
or
anyone
else
have
any
anything
to
add
on
how
your
testing's
been
going.
Well,
we
we.
F
G
A
A
A
Getting
you
know
empty
blocks,
things
like
that.
The
feedback
I
got
from
matthew
was
yeah.
It's
a
test
net
people
are
people
are
testing
the
the
cutting
edge
things.
Things
are
gonna
break.
It's
not
jungle
force
seems
not
to
be
the
ideal
place
for,
if
you're
a
developer,
who
needs
a
stable
test
environment
to
test
your
smart
contracts
and
the
apps
jungle
fours
in
its
current
state,
not
ideal.
For
that
it's
it's
a
great
place
to
try
breaking
testing
the
latest
the
cutting
edge.
A
A
There,
perhaps
is
a
need
for
now
that
I
don't.
I
don't
think
b1
is
keeping
up
to
date
on
with
mandel
on
on
that.
Perhaps
it's
time
for
an
enf
test
net
or
something
like
that,
so
it's
sound.
I
did.
I
did
raise
that
with
with
eve.
It
sounds
like
it
is
something
enf
is
considering.
I
don't
know
if
he's
not
online
enough,
anyone
else
from
the
enf
can
can
speak
to
that
or
we
can
save
it
for
next
week.
A
A
G
G
Do
the
hardware
break
in
missing
blocks,
but
kylan
is
supposed
to
be
more
mirrored
like
eos
as
a
test
of
like
power
up
and
things
like
that
which
we
down
jungle,
because
that's
kind
of
where
it
was
that's
where
the
focus
was,
but
I
do
think
there
is
a
definable
difference,
potentially
between
kylan
or
the
idea
of
it
and
the
esio
test
net.
If
you're
looking
for
a
more
generic
stable
test
net
of
esio
versus
no,
no,
this
is
eos.
You
know,
maybe
even
seed
accounts
and
stuff
like
that.
G
A
A
It's
not
running
mandel.
Do
we
need
a
a
stable
environment
for
mandel
and
current?
You
know
the
a
stable
test
net
for
the
next
version
of
eos
main
net
and
also
a
stable
version
of
current
eos
mainnet
and
which
one
is
which
would
kylan
be
the
future
state,
and
perhaps
some
enf
or
some
other
developer
test
net
is
the
kind
of
the
current
state
mirror?
F
F
F
One
solid
one
running:
let's
just
you
know,
get
one
running
if
it
needs
to
be
something
different
other
than
jungle,
then
so
be
it,
but
just
get
this
get
one
running
and
you
know
start
to
test
some
stuff
rather
than
having
multiple
disparate
places
where
people
go
to
test.
If
you
want
to,
you
know,
break
something
you
know
I
I
don't
know,
I
don't
know
how
many
tiers
you
need.
That's
what
I'm
getting
to.
G
I
do
agree.
Jungle
I
think,
is
default.
Oh
break,
I
mean
that's
infrastructure,
don't
assume
it's
a
stable
test
net
even
from
a
development
aspect,
although
there
are
people
that
are
running
mainnet
applications,
because
jungle
was
free,
that's
a
separate
issue.
The
real
question
is:
is
that
is
kylian
designed
to
be
more
of
a
replica
of
eos?
G
Is
there
a
need
for
a
non-eos
clone,
stable
development
test
environment,
because
it's
not
jungle
and
if
you
want
kyle
into
more
represent
eos
and
more
be
stable
about
an
eos
testing
environment
where-
and
I
don't
even
know
which
bucket
it
may
fall
into
like
a
generic
eos
io
testing
chain,
which
is
what
the
eos
io
test
net
was
straight
up.
Free
accounts
test
accounts,
new
keys
block
one
two,
three
four.