Re: [E-devel] Current State and Future Direction of E/EFL

[The Rasterman]

On Sat, 10 Mar 2018 11:57:56 -0500 "William L. Thomson Jr."
 said:

> On Sat, 10 Mar 2018 16:35:02 +0900
> Carsten Haitzler (The Rasterman)  wrote:
> >
> > that's not how open source works. there is nothing keeping you around
> > unlike thew moral obligation you put on yourself to volunteer to
> > clean up after a disaster for example.
> 
> Yes and no. Not doing what you say you will, or following through
> publicly online can be a much more permanent visible record than not
> showing in person.
>  
> > they are very very very different things. also physically
> > volunteering means that walking away is something everyone sees you
> > do.
> 
> Who the internet? Nothing like saying online in archives you will do
> something and then not. Where strangers around the world can see you
> did or did not do something.

i notice people on line being far more flaky than in real life. maybe that's my
experience, but if they have to disappoint you to your face it tends to happen
less.
 
> > there is a face to it. walking away from an oss project is simply
> > stopping work. invariably there are not even real names let alone
> > faces associated. there e never many repercussions that you'd get
> > from the example above like your neighbours and community giving you
> > a hard time after walking off.
> 
> The chance of not seeing people in person, vs not coming across
> someones name online is not even in the same league. You can easily
> come across and find people online you cannot in person. You can move
> to a new town where your record as a flaky volunteer would not be known.
> Unless someone published it from physical to online.
> 
> Again I think people saying such haven't volunteered. People no show
> quite often. There is no peer pressure, etc. Most have no clue what
> anyone volunteered to do, said they would, etc.

Maybe our experiences differ - I've seen it through more structured
volunteering e.g. like volunteering days at school or via work as well as
conferences.

> > also cleanup after a disaster is doing what has to be done, not what
> > someone WANTS to be done. how would you like it if you volunteered to
> > clean up and the home owner comes by to the house you're cleaning
> > stuff out of and says "oh by the way. paint the walls lime green...
> > no not that green. this green. and can you rebuild my garage to be a
> > double instead of single, also use concrete instead of gravel on the
> > driveway..." any volunteer and organization will tell them to jump in
> > the lake. they get the cleanup they get. not just the exact way they
> > want it to be. the volunteers and organization decide what needs
> > doing. not the "users". they don't get a say.
> 
> Really you assume all things are rebuilt exactly as they were? Again I
> do not think you have experienced such first hand. They very much
> follow the requests of the home/property owner, etc.

No. I'm comparing volunteering for disaster recovery when it's more about just
getting things back to working rather than perfect vs. volunteer work on an
open source project. Disaster cleanup (2 of your examples) I think are vastly
different beasts to an OSS software project.

> The only time you have no choice, is like when there is debris that
> must be cleared. If you think people just go into others homes and do

That's what I'm thinking when you talk about hurricane and disaster recovery
volunteering. Debris everywhere, buildings damaged etc. etc.

> what ever with no direction. Again that shows more a lack of
> in person volunteer experience than reality.
> 
> > > When it comes to FOSS this gets lost. People think its my time, my
> > > volunteering, I am going to do what ever I want with my time. That
> > > is true within reason. But that also says they only care about
> > > themselves, not the project, or what ever they are volunteering
> > > for.  
> > 
> > that is absolutely correct. that's what it is. it's not a
> > humanitarian effort to clean up after a disaster. it's utterly
> > superfluous really to the daily trials and tribulations of life. it's
> > a luxury to get your software for free.
> 
> You would be surprised. There are many luxuries in life, such as a
> fence around your property. Nothing would effect daily life if that was
> missing.
> 
> I do not think it is a luxury to get software for free. If you think
> about what comes on say Apple or Microsoft to open source alternatives.
> Open source is not really that luxurious or feature rich in comparison.
> Not to mention your time you will spend, you would not otherwise. Its
> not like users do nothing in FOSS. They spend more time than they would
> with non-free software. Why despite free software, most run non-free.

Imagine if all the FOSS devs just never had released anything... :) Imagine the
only choices in the world were the software you describe above?

> > it is absolutely the job of users to convince the devs to do what
> > they 

Re: [E-devel] Current State and Future Direction of E/EFL

[William L. Thomson Jr.]

On Sat, 10 Mar 2018 16:35:02 +0900
Carsten Haitzler (The Rasterman)  wrote:
>
> that's not how open source works. there is nothing keeping you around
> unlike thew moral obligation you put on yourself to volunteer to
> clean up after a disaster for example.

Yes and no. Not doing what you say you will, or following through
publicly online can be a much more permanent visible record than not
showing in person.
 
> they are very very very different things. also physically
> volunteering means that walking away is something everyone sees you
> do.

Who the internet? Nothing like saying online in archives you will do
something and then not. Where strangers around the world can see you
did or did not do something.

> there is a face to it. walking away from an oss project is simply
> stopping work. invariably there are not even real names let alone
> faces associated. there e never many repercussions that you'd get
> from the example above like your neighbours and community giving you
> a hard time after walking off.

The chance of not seeing people in person, vs not coming across
someones name online is not even in the same league. You can easily
come across and find people online you cannot in person. You can move
to a new town where your record as a flaky volunteer would not be known.
Unless someone published it from physical to online.

Again I think people saying such haven't volunteered. People no show
quite often. There is no peer pressure, etc. Most have no clue what
anyone volunteered to do, said they would, etc.

> also cleanup after a disaster is doing what has to be done, not what
> someone WANTS to be done. how would you like it if you volunteered to
> clean up and the home owner comes by to the house you're cleaning
> stuff out of and says "oh by the way. paint the walls lime green...
> no not that green. this green. and can you rebuild my garage to be a
> double instead of single, also use concrete instead of gravel on the
> driveway..." any volunteer and organization will tell them to jump in
> the lake. they get the cleanup they get. not just the exact way they
> want it to be. the volunteers and organization decide what needs
> doing. not the "users". they don't get a say.

Really you assume all things are rebuilt exactly as they were? Again I
do not think you have experienced such first hand. They very much
follow the requests of the home/property owner, etc.

The only time you have no choice, is like when there is debris that
must be cleared. If you think people just go into others homes and do
what ever with no direction. Again that shows more a lack of
in person volunteer experience than reality.

> > When it comes to FOSS this gets lost. People think its my time, my
> > volunteering, I am going to do what ever I want with my time. That
> > is true within reason. But that also says they only care about
> > themselves, not the project, or what ever they are volunteering
> > for.  
> 
> that is absolutely correct. that's what it is. it's not a
> humanitarian effort to clean up after a disaster. it's utterly
> superfluous really to the daily trials and tribulations of life. it's
> a luxury to get your software for free.

You would be surprised. There are many luxuries in life, such as a
fence around your property. Nothing would effect daily life if that was
missing.

I do not think it is a luxury to get software for free. If you think
about what comes on say Apple or Microsoft to open source alternatives.
Open source is not really that luxurious or feature rich in comparison.
Not to mention your time you will spend, you would not otherwise. Its
not like users do nothing in FOSS. They spend more time than they would
with non-free software. Why despite free software, most run non-free.

> it is absolutely the job of users to convince the devs to do what
> they want. not to expect devs to line up and take orders.

Its the job of devs to be receptive to users. Users have no job. Their
sole role is to use. They could not say anything to devs and use
another product. That doesn't help developers or their products.

Users are very important. Why there is the saying, the customer is
always right. There is not a saying, the developer is always right,
etc. The user is the customer.

> > Which if they do not care about users, that also shows they do not
> > care about the entity, organization, or project over all. If users
> > must always convince others, that will not work, and tends to not
> > work for projects who go down that path.  
> 
> that is how almost every project works. do you think you can go to a
> kernel dev and tell them "i want you do add feature x for me" and
> they will just go do it? i can name almost every tingle oss project
> that if a user just tells a developer "i want x" and if the dev
> doesn't like x .. it's not going to happen. even if user does x and
> submits a patch .. it doesn't mean the patch is accepted.

That is the same for most anything in life 

Re: [E-devel] Current State and Future Direction of E/EFL

[Andrew Williams]

Hi,

I know I’m not really active here but I just wanted to agree with the
sentiment here. It’s a little blunt but overall Stephen has a point.

I still think that would could have helped is a shared understanding of
what is being done (& why) and who the project is aimed at. Armed with such
a “vision” or “roadmap” it would be clearer if contributions will be
welcomed or not. And if commercial sponsorship is taking the project in the
right direction...

Andrew
On Sat, 10 Mar 2018 at 09:28, Stephen Houston  wrote:

> There is so much I whole heartedly disagree with in your attitude and point
> of view in this thread that will take me too much energy and time and
> arguing to cover.  I think other developers are coming to this same
> realization and are leaving rather than trying to change your mind.  This
> project has become far more than just you and your opinion and what you
> think is right but every word you say is coming out with an arrogance to it
> that you can't possibly be wrong, and it seems this is why you don't want
> to add any structure because then there would be rules that you too would
> have to follow and decisions made that you would not like.  While having a
> free to work on and push whatever you like unless raster vetos it community
> works out really well for you, you are not the entire dev or users
> community and they are the ones being hurt.  Our community is clearly down
> and grasping for air.  I don't think arguing for the status quo is a good
> idea.
>
> On Sat, Mar 10, 2018, 3:43 AM Carsten Haitzler 
> wrote:
>
> > On Fri, 9 Mar 2018 11:28:01 -0500 "William L. Thomson Jr."
> >  said:
> >
> > > On Fri, 9 Mar 2018 13:38:36 +0900
> > > Carsten Haitzler (The Rasterman)  wrote:
> > >
> > > > a volunteer is not going to do something they dislike. certainly not
> > > > readily. users have to convince the volunteer to do it. not the other
> > > > way around (that volunteers need to be slaves to users and do work
> > > > for them even if the volunteer disagrees and dislikes it). volunteers
> > > > don't get paid... they do things because they desire and want to.
> > > > it's the user's job to convince them... or for the user to stand up
> > > > and do it themselves. :)
> > >
> > > Yes and no. Being a volunteer does not mean you just show up and do
> > > what ever you want to do. I do not think anyone who thinks along those
> > > lines has ever volunteered in person. In my area we do things like
> > > beach cleanup, hurricane and disaster recovery. You do no get to just
> > > show up and do what ever. You do get assigned things to do as a
> > > volunteer.
> >
> > that's not how open source works. there is nothing keeping you around
> > unlike
> > thew moral obligation you put on yourself to volunteer to clean up after
> a
> > disaster for example.
> >
> > they are very very very different things. also physically volunteering
> > means
> > that walking away is something everyone sees you do. there is a face to
> it.
> > walking away from an oss project is simply stopping work. invariably
> there
> > are
> > not even real names let alone faces associated. there e never many
> > repercussions that you'd get from the example above like your neighbours
> > and
> > community giving you a hard time after walking off.
> >
> > also cleanup after a disaster is doing what has to be done, not what
> > someone
> > WANTS to be done. how would you like it if you volunteered to clean up
> and
> > the
> > home owner comes by to the house you're cleaning stuff out of and says
> "oh
> > by
> > the way. paint the walls lime green... no not that green. this green. and
> > can
> > you rebuild my garage to be a double instead of single, also use concrete
> > instead of gravel on the driveway..." any volunteer and organization will
> > tell
> > them to jump in the lake. they get the cleanup they get. not just the
> > exact way
> > they want it to be. the volunteers and organization decide what needs
> > doing.
> > not the "users". they don't get a say.
> >
> > > When it comes to FOSS this gets lost. People think its my time, my
> > > volunteering, I am going to do what ever I want with my time. That is
> > > true within reason. But that also says they only care about themselves,
> > > not the project, or what ever they are volunteering for.
> >
> > that is absolutely correct. that's what it is. it's not a humanitarian
> > effort to
> > clean up after a disaster. it's utterly superfluous really to the daily
> > trials
> > and tribulations of life. it's a luxury to get your software for free.
> >
> > it is absolutely the job of users to convince the devs to do what they
> > want.
> > not to expect devs to line up and take orders.
> >
> > > Which if they do not care about users, that also shows they do not
> > > care about the entity, organization, or project over all. If users must
> > > always convince others, that 

Re: [E-devel] Current State and Future Direction of E/EFL

[Stephen Houston]

There is so much I whole heartedly disagree with in your attitude and point
of view in this thread that will take me too much energy and time and
arguing to cover.  I think other developers are coming to this same
realization and are leaving rather than trying to change your mind.  This
project has become far more than just you and your opinion and what you
think is right but every word you say is coming out with an arrogance to it
that you can't possibly be wrong, and it seems this is why you don't want
to add any structure because then there would be rules that you too would
have to follow and decisions made that you would not like.  While having a
free to work on and push whatever you like unless raster vetos it community
works out really well for you, you are not the entire dev or users
community and they are the ones being hurt.  Our community is clearly down
and grasping for air.  I don't think arguing for the status quo is a good
idea.

On Sat, Mar 10, 2018, 3:43 AM Carsten Haitzler  wrote:

> On Fri, 9 Mar 2018 11:28:01 -0500 "William L. Thomson Jr."
>  said:
>
> > On Fri, 9 Mar 2018 13:38:36 +0900
> > Carsten Haitzler (The Rasterman)  wrote:
> >
> > > a volunteer is not going to do something they dislike. certainly not
> > > readily. users have to convince the volunteer to do it. not the other
> > > way around (that volunteers need to be slaves to users and do work
> > > for them even if the volunteer disagrees and dislikes it). volunteers
> > > don't get paid... they do things because they desire and want to.
> > > it's the user's job to convince them... or for the user to stand up
> > > and do it themselves. :)
> >
> > Yes and no. Being a volunteer does not mean you just show up and do
> > what ever you want to do. I do not think anyone who thinks along those
> > lines has ever volunteered in person. In my area we do things like
> > beach cleanup, hurricane and disaster recovery. You do no get to just
> > show up and do what ever. You do get assigned things to do as a
> > volunteer.
>
> that's not how open source works. there is nothing keeping you around
> unlike
> thew moral obligation you put on yourself to volunteer to clean up after a
> disaster for example.
>
> they are very very very different things. also physically volunteering
> means
> that walking away is something everyone sees you do. there is a face to it.
> walking away from an oss project is simply stopping work. invariably there
> are
> not even real names let alone faces associated. there e never many
> repercussions that you'd get from the example above like your neighbours
> and
> community giving you a hard time after walking off.
>
> also cleanup after a disaster is doing what has to be done, not what
> someone
> WANTS to be done. how would you like it if you volunteered to clean up and
> the
> home owner comes by to the house you're cleaning stuff out of and says "oh
> by
> the way. paint the walls lime green... no not that green. this green. and
> can
> you rebuild my garage to be a double instead of single, also use concrete
> instead of gravel on the driveway..." any volunteer and organization will
> tell
> them to jump in the lake. they get the cleanup they get. not just the
> exact way
> they want it to be. the volunteers and organization decide what needs
> doing.
> not the "users". they don't get a say.
>
> > When it comes to FOSS this gets lost. People think its my time, my
> > volunteering, I am going to do what ever I want with my time. That is
> > true within reason. But that also says they only care about themselves,
> > not the project, or what ever they are volunteering for.
>
> that is absolutely correct. that's what it is. it's not a humanitarian
> effort to
> clean up after a disaster. it's utterly superfluous really to the daily
> trials
> and tribulations of life. it's a luxury to get your software for free.
>
> it is absolutely the job of users to convince the devs to do what they
> want.
> not to expect devs to line up and take orders.
>
> > Which if they do not care about users, that also shows they do not
> > care about the entity, organization, or project over all. If users must
> > always convince others, that will not work, and tends to not work for
> > projects who go down that path.
>
> that is how almost every project works. do you think you can go to a
> kernel dev
> and tell them "i want you do add feature x for me" and they will just go
> do it?
> i can name almost every tingle oss project that if a user just tells a
> developer
> "i want x" and if the dev doesn't like x .. it's not going to happen. even
> if
> user does x and submits a patch .. it doesn't mean the patch is accepted.
>
> if you believe projects are there to serve their users and just do whatever
> they say.. then that is a very wrong idea. it may apply to projects whose
> only
> goal in life is popularity. that's very few of them and i can tell you
> 

Re: [E-devel] Current State and Future Direction of E/EFL

[The Rasterman]

On Fri, 9 Mar 2018 11:28:01 -0500 "William L. Thomson Jr."
 said:

> On Fri, 9 Mar 2018 13:38:36 +0900
> Carsten Haitzler (The Rasterman)  wrote:
> 
> > a volunteer is not going to do something they dislike. certainly not
> > readily. users have to convince the volunteer to do it. not the other
> > way around (that volunteers need to be slaves to users and do work
> > for them even if the volunteer disagrees and dislikes it). volunteers
> > don't get paid... they do things because they desire and want to.
> > it's the user's job to convince them... or for the user to stand up
> > and do it themselves. :)
> 
> Yes and no. Being a volunteer does not mean you just show up and do
> what ever you want to do. I do not think anyone who thinks along those
> lines has ever volunteered in person. In my area we do things like
> beach cleanup, hurricane and disaster recovery. You do no get to just
> show up and do what ever. You do get assigned things to do as a
> volunteer.

that's not how open source works. there is nothing keeping you around unlike
thew moral obligation you put on yourself to volunteer to clean up after a
disaster for example.

they are very very very different things. also physically volunteering means
that walking away is something everyone sees you do. there is a face to it.
walking away from an oss project is simply stopping work. invariably there are
not even real names let alone faces associated. there e never many
repercussions that you'd get from the example above like your neighbours and
community giving you a hard time after walking off.

also cleanup after a disaster is doing what has to be done, not what someone
WANTS to be done. how would you like it if you volunteered to clean up and the
home owner comes by to the house you're cleaning stuff out of and says "oh by
the way. paint the walls lime green... no not that green. this green. and can
you rebuild my garage to be a double instead of single, also use concrete
instead of gravel on the driveway..." any volunteer and organization will tell
them to jump in the lake. they get the cleanup they get. not just the exact way
they want it to be. the volunteers and organization decide what needs doing.
not the "users". they don't get a say.

> When it comes to FOSS this gets lost. People think its my time, my
> volunteering, I am going to do what ever I want with my time. That is
> true within reason. But that also says they only care about themselves,
> not the project, or what ever they are volunteering for.

that is absolutely correct. that's what it is. it's not a humanitarian effort to
clean up after a disaster. it's utterly superfluous really to the daily trials
and tribulations of life. it's a luxury to get your software for free.

it is absolutely the job of users to convince the devs to do what they want.
not to expect devs to line up and take orders.

> Which if they do not care about users, that also shows they do not
> care about the entity, organization, or project over all. If users must
> always convince others, that will not work, and tends to not work for
> projects who go down that path.

that is how almost every project works. do you think you can go to a kernel dev
and tell them "i want you do add feature x for me" and they will just go do it?
i can name almost every tingle oss project that if a user just tells a developer
"i want x" and if the dev doesn't like x .. it's not going to happen. even if
user does x and submits a patch .. it doesn't mean the patch is accepted.

if you believe projects are there to serve their users and just do whatever
they say.. then that is a very wrong idea. it may apply to projects whose only
goal in life is popularity. that's very few of them and i can tell you that it
almost always ends in tears as the project falls apart technically.

> Just as devs/volunteers must be motivated to fulfill a users wishes and

and that is where i think you have it wrong. devs absolutely have no
requirement to fulfill users wishes. none. no requirement. if they do so it's
them being kind, or perhaps being inspired or motivated by an idea or a user.
unless their goal is pure popularity by saying yes to anything no matter what
it is or what the cost to them just for a bit of popularity.

> desires. A user has to be motivated to step up. They have to want to,
> and that can start with wanting to work with given developers. If they
> see those developers/volunteers are just self serving. They likely will
> not want to work with them. I see that to often. People with skill, but
> others avoid them and the distro. Then they use that to drive off
> others saying others are having that effect. Not realizing its them...
> Thus despite running others off, project still  suffers.

what you are describing is developer utterly ignoring users. i never said that.
i did say that listening is good. it does not mean they just do whatever a
user asks. it goes like this:

Re: [E-devel] Current State and Future Direction of E/EFL

[William L. Thomson Jr.]

On Fri, 9 Mar 2018 11:28:01 -0500
"William L. Thomson Jr."  wrote:

> The thing is I do need the filemanager running all the time. Icons on
> the desktop could be rendered otherwise. Like what Plasma has done as
> an example. That is not related to the file manager. Having the file
> manager running always just for desktop icons seems like a bit much.

Typo, I meant, I do NOT need the filemanager running all the time.

-- 
William L. Thomson Jr.


pgpb1te6KElRo.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[William L. Thomson Jr.]

On Fri, 9 Mar 2018 13:38:36 +0900
Carsten Haitzler (The Rasterman)  wrote:

> a volunteer is not going to do something they dislike. certainly not
> readily. users have to convince the volunteer to do it. not the other
> way around (that volunteers need to be slaves to users and do work
> for them even if the volunteer disagrees and dislikes it). volunteers
> don't get paid... they do things because they desire and want to.
> it's the user's job to convince them... or for the user to stand up
> and do it themselves. :)

Yes and no. Being a volunteer does not mean you just show up and do
what ever you want to do. I do not think anyone who thinks along those
lines has ever volunteered in person. In my area we do things like
beach cleanup, hurricane and disaster recovery. You do no get to just
show up and do what ever. You do get assigned things to do as a
volunteer.

When it comes to FOSS this gets lost. People think its my time, my
volunteering, I am going to do what ever I want with my time. That is
true within reason. But that also says they only care about themselves,
not the project, or what ever they are volunteering for.

Which if they do not care about users, that also shows they do not
care about the entity, organization, or project over all. If users must
always convince others, that will not work, and tends to not work for
projects who go down that path.

Just as devs/volunteers must be motivated to fulfill a users wishes and
desires. A user has to be motivated to step up. They have to want to,
and that can start with wanting to work with given developers. If they
see those developers/volunteers are just self serving. They likely will
not want to work with them. I see that to often. People with skill, but
others avoid them and the distro. Then they use that to drive off
others saying others are having that effect. Not realizing its them...
Thus despite running others off, project still  suffers.

I am also very much for PAID volunteers. Maybe not full time or part
time, but some bounty to help with motivation on things they want no
part of or not interested in doing otherwise.

> 
> e doesn't follow the "unix philosophy". quoting it doesn't work. i
> believe in efficiency. if it's something that can be controlled by
> the same group and thus can get attention and get fixed along with it
> and it needs to be integrated (desktop icons require this as does
> efficiency) then it should be part of the same process most likely.

Maybe it should, E runs mostly on *nix. Most of the world is *nix based
now, short of Microsoft. You also end up making someones focus to wide
vs narrow. Splitting ones time also  as a result. As things grow it
becomes to much for any one.

I think its better for development, as things can evolve on their own
and not be bound to constraints from other things.

> e has never been a "unix philosophy thing" for as long as it has
> existed. this is not a new thing. it's been the "have 1 process do as
> much of your day to day desktop as can be done/is sensible" and fm is
> sensible. it's not fundamentally that the shelf or e's menus or
> wallpaper handling etc. - if you want the unix philosophy then all of
> those move out to processes too. if you like that then kde is
> probably good for you. :) gnome used to be until gnome 3... :)

What E is today ans has been does not mean it has to be that way
tomorrow. Even Apple realized their old OS and ways were garbage, and
tossed them for older stuff. Look at the result

And what has happened since gnome? Less GTK3 dev, and more GTK2 dev and
desktops. Gnome did not help itself nor GTK. It just helped XFCE, Mint,
and others. That should be a learning lesson there.

> > I just do not like any one thing taking out other stuff. The more
> > things can be limited and only effect themselves, the better IMHO.  
> 
> that is why e has crash recovery... :) but everything being separate
> comes with a cost. it's not cheap to have lots of processes.
> especially for things you run all the time, like a filemanager (for
> the normal icons on desktop).

You would not need the crash recovery as such. In the past window
managers would crash and other stuff keep chugging along. Also that is
IF you can restart E in time. That is not always the case.

The thing is I do need the filemanager running all the time. Icons on
the desktop could be rendered otherwise. Like what Plasma has done as an
example. That is not related to the file manager. Having the file
manager running always just for desktop icons seems like a bit much.

> like arrows pointing in over a directory indicating you are going to
> drop the file into the directory? 

I guess not sure. There are for arrows, one in each corner, and they
like point in as part of their animation. Horrible description sorry!

I cannot easily replicate that animation. If I drag a file over a
folder nothing happens. Just noticed I cannot drag a file into a folder
or anything. I am not sure 

Re: [E-devel] Current State and Future Direction of E/EFL

[Jonathan Aquilina]

Any issues found on fedora I am willing with mentoring and help to fix those 
bugs :) 

Sent from my iPhone

> On 09 Mar 2018, at 10:36, Carsten Haitzler (The Rasterman) 
>  wrote:
> 
> On Wed, 7 Mar 2018 08:21:22 +0100 Jonathan Aquilina 
> said:
> 
>> Stupid suggestion probably if you are going to use opensuse as the base why
>> not maintain the existing code base and fork it and clean that up in a way
>> kind of start from scratch?
> 
> something to discuss. splitting resources, focus etc. is bad. but if it means
> more people involved who otherwise would not be... that's good.
> 
> so downsides:
> 
> 1. dividing resources
> 2. dividing public attention and thus creating confusion
> 
> upsides:
> 
> 1. probably bringing more resources in
> 2. possibly expanding public reach offering different base distros
> 
> it's something to discuss.
> 
>> Sent from my iPhone
>> 
>>> On 07 Mar 2018, at 07:40, Carsten Haitzler (The Rasterman)
>>>  wrote:
>>> 
>>> On Wed, 7 Mar 2018 12:03:27 +1030 Simon Lees  said:
>>> 
 On Wednesday, 7 March 2018 05:33:45 ACDT, William L. Thomson Jr. wrote:
> On Mon, 5 Mar 2018 20:57:17 +0900
> Carsten Haitzler (The Rasterman)  wrote:
>> 
>> h) I think at some point we may have to do our own distro that
>> integrates E well and shows it off out-of-the-box.
> 
> I would be interested in such. There are a couple existing.
> http://www.elivecd.org/
> http://www.bodhilinux.com/
> 
> If not using either of those, I could likely help with one based on
> Gentoo. Either livecd or stage 4 base system, etc.
 
 Neither of the 2 above ship the latest e, at some point I will start
 creating e images again to use with openQA as part of testing, the only
 thing I need before I can spin up an "Enlightenment OS" is probably
 matching Grub2, Plymouth and lightdm branding. I suggest we tackle that
 after we do e's theme though. But if someone wants to get to it sooner
 why not.
>>> 
>>> we were discussing on irc with you.. i thought i'd bring some of that here.
>>> 
>>> i think we should look into opensuse as a base. it will allow for a more
>>> minimal os than something like arch or gentoo (though maybe on par with
>>> debian). mostly because simon has been around with us for years and years
>>> and i trust him not to vanish. i think working with him to at least
>>> investigate would be good.
>>> 
>>> so my take also is to strip out as much as we can get away with. that would
>>> mean no lightdm. no plymouth. have the system boot right into a fixed user
>>> with no login (have e optionally ask for passwd on startup).
>>> 
>>> keep the thole thing as simple as needed then fill these things in as we
>>> have nice solutions.
>>> 
 I have made some raspberry pi images, but they are using an older efl
 from before I tried to switch to luajit on aarch64.
>>> 
>>> we can just stick to 32bit arm until this is resolved.
>>> 
 -- 
 
 Simon Lees (Simotek)http://simotek.net
 
 Emergency Update Team   keybase.io/simotek
 SUSE Linux   Adelaide Australia, UTC+10:30
 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
 
>>> 
>>> 
>>> -- 
>>> - Codito, ergo sum - "I code, therefore I am" --
>>> Carsten Haitzler - ras...@rasterman.com
>>> 
>>> 
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> enlightenment-devel mailing list
>>> enlightenment-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>> 
>> 
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>> 
> 
> 
> -- 
> - Codito, ergo sum - "I code, therefore I am" --
> Carsten Haitzler - ras...@rasterman.com
> 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[The Rasterman]

On Wed, 7 Mar 2018 08:21:22 +0100 Jonathan Aquilina 
said:

> Stupid suggestion probably if you are going to use opensuse as the base why
> not maintain the existing code base and fork it and clean that up in a way
> kind of start from scratch?

something to discuss. splitting resources, focus etc. is bad. but if it means
more people involved who otherwise would not be... that's good.

so downsides:

1. dividing resources
2. dividing public attention and thus creating confusion

upsides:

1. probably bringing more resources in
2. possibly expanding public reach offering different base distros

it's something to discuss.

> Sent from my iPhone
> 
> > On 07 Mar 2018, at 07:40, Carsten Haitzler (The Rasterman)
> >  wrote:
> > 
> > On Wed, 7 Mar 2018 12:03:27 +1030 Simon Lees  said:
> > 
> >> On Wednesday, 7 March 2018 05:33:45 ACDT, William L. Thomson Jr. wrote:
> >>> On Mon, 5 Mar 2018 20:57:17 +0900
> >>> Carsten Haitzler (The Rasterman)  wrote:
>  
>  h) I think at some point we may have to do our own distro that
>  integrates E well and shows it off out-of-the-box.
> >>> 
> >>> I would be interested in such. There are a couple existing.
> >>> http://www.elivecd.org/
> >>> http://www.bodhilinux.com/
> >>> 
> >>> If not using either of those, I could likely help with one based on
> >>> Gentoo. Either livecd or stage 4 base system, etc.
> >> 
> >> Neither of the 2 above ship the latest e, at some point I will start
> >> creating e images again to use with openQA as part of testing, the only
> >> thing I need before I can spin up an "Enlightenment OS" is probably
> >> matching Grub2, Plymouth and lightdm branding. I suggest we tackle that
> >> after we do e's theme though. But if someone wants to get to it sooner
> >> why not.
> > 
> > we were discussing on irc with you.. i thought i'd bring some of that here.
> > 
> > i think we should look into opensuse as a base. it will allow for a more
> > minimal os than something like arch or gentoo (though maybe on par with
> > debian). mostly because simon has been around with us for years and years
> > and i trust him not to vanish. i think working with him to at least
> > investigate would be good.
> > 
> > so my take also is to strip out as much as we can get away with. that would
> > mean no lightdm. no plymouth. have the system boot right into a fixed user
> > with no login (have e optionally ask for passwd on startup).
> > 
> > keep the thole thing as simple as needed then fill these things in as we
> > have nice solutions.
> > 
> >> I have made some raspberry pi images, but they are using an older efl
> >> from before I tried to switch to luajit on aarch64.
> > 
> > we can just stick to 32bit arm until this is resolved.
> > 
> >> -- 
> >> 
> >> Simon Lees (Simotek)http://simotek.net
> >> 
> >> Emergency Update Team   keybase.io/simotek
> >> SUSE Linux   Adelaide Australia, UTC+10:30
> >> GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
> >> 
> > 
> > 
> > -- 
> > - Codito, ergo sum - "I code, therefore I am" --
> > Carsten Haitzler - ras...@rasterman.com
> > 
> > 
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[The Rasterman]

On Thu, 8 Mar 2018 12:33:59 -0500 "William L. Thomson Jr."
 said:

> On Thu, 8 Mar 2018 17:14:21 +0900
> Carsten Haitzler (The Rasterman)  wrote:
> >
> > But that is the reality. They can call the shots and listen to users.
> > Users are not always right. But listening is good. In the end people
> > doing work make the final decisions. And I guess to some extent I
> > hold a veto power over those which I generally choose not to exercise
> > except on rare occasions when I think it is warranted.
> 
> Not for all, I think those that balance user needs the most tend to
> prosper the most. It is the same for companies that make products. They
> choose what to make, and how. But the ultimate decider if they were
> right or not is the market, the users.
> 
> Apple was never big on focus groups, but if a product hit market and
> did not do well. That was a tell as to product failure or success.
> Either method relies on the end user, before, during, or after. Users
> tend to make or break things, determine if it was successful or not.
> 
> Gentoo has had an ever increasing focus on those doing the work vs
> users and its not had a good effect. I try to always put users needs
> above my own. Even when I am the one doing the work.

a volunteer is not going to do something they dislike. certainly not readily.
users have to convince the volunteer to do it. not the other way around (that
volunteers need to be slaves to users and do work for them even if the
volunteer disagrees and dislikes it). volunteers don't get paid... they do
things because they desire and want to. it's the user's job to convince them...
or for the user to stand up and do it themselves. :)

> > I think there is a balance. Moving forward with minimal interference,
> > yet still trying to maintain quality too. You will never have
> > perfect. Perfect is the enemy of good.
> 
> I completely agree. I think in FOSS there is to much striving for
> perfection. When in closed source, at some point must ship to make
> money and recoup investment. I think FOSS has more hang ups to shipping
> less than perfect software. When the world is based on less than
> perfect software as is now.
> 
> Take GNU kernel vs Linux. Keep striving for perfect, was taking
> forever, and Linux screamed on by. Good example of such.
> 
> > > > I don't think we need STRUCTURE. I think we need communication. I
> > > > think people have become awfully bad at this. Here is what people
> > > > need to do IMHO.  
> > > 
> > > I agree on communication, but I also believe structure is important
> > > to organizing any group of people to work together on anything.  
> > 
> > structure is no good without communication to begin with.
> 
> I agree, communication is the core to it all. An organization cannot do
> a thing without good communication. You will have a hard time
> organizing at all without communication.

:)

> > > > f) I still think E should have the filemanager built in. It's far
> > > > too useful to not do this. It's pretty much necessary for icons on
> > > > the desktop and consistent FM UI. If its done in-process or
> > > > outside is another matter, but it has to be deeply integrated.   
> > > 
> > > In brief, I am not a big fan of such. Seems like a Windows concept
> > > where Explorer ( not Internet Explorer) is deeply integrated. Pretty
> > > much any issue I have with E that is non-recoverable comes from
> > > EFM.  
> > 
> > actually ... this pre-dates windows. amiga workbench had it all
> > integrated before windows 1.0 was around. and i'm an amiga fan. a lot
> > of e was inspired from those days. i firmly believe a filemanager has
> > to be deeply integrated.
> 
> Maybe best for another thread. I am curious what benefits you see in a
> deeply integrated file manager. I think that goes against the Unix
> philosophy of not deeply integrating anything.

e doesn't follow the "unix philosophy". quoting it doesn't work. i believe in
efficiency. if it's something that can be controlled by the same group and thus
can get attention and get fixed along with it and it needs to be integrated
(desktop icons require this as does efficiency) then it should be part of the
same process most likely.

e has never been a "unix philosophy thing" for as long as it has existed. this
is not a new thing. it's been the "have 1 process do as much of your day to day
desktop as can be done/is sensible" and fm is sensible. it's not fundamentally
that the shelf or e's menus or wallpaper handling etc. - if you want the unix
philosophy then all of those move out to processes too. if you like that then
kde is probably good for you. :) gnome used to be until gnome 3... :)

> I just do not like any one thing taking out other stuff. The more
> things can be limited and only effect themselves, the better IMHO.

that is why e has crash recovery... :) but everything being separate comes with
a cost. it's not cheap to have lots of processes. especially 

Re: [E-devel] Current State and Future Direction of E/EFL

[The Rasterman]

On Wed, 07 Mar 2018 15:57:56 + jaquilina  said:

it came through. i just replied. :)

> Not sure if my reply from earlier today made it to the list as I then 
> got an email shortly after saying my address had been suspended from the 
> list,
> God SF is a POS, but i digress there with that little rant.
> 
> I am more then eager and willing to put together an enlightenment spin 
> on fedora 27 with binary packages in a custom repository that anyone 
> could connect to as needed. I would base it off master branch given that 
> fedora is the more bleeding side of RHEL and centos are based off of it.
> 
> On 2018-03-07 15:52, William L. Thomson Jr. wrote:
> > On Wed, 7 Mar 2018 14:56:13 +0900
> > Carsten Haitzler (The Rasterman)  wrote:
> >> 
> >> last i checked bodhi wanted to fork e because they didn't want to
> >> update themes for compositing+wayland support (and e18 and on got
> >> more overhead as more objects were in the canvas - this should have
> >> been fixed by objects in buffers in evas but hasn't been to date) and
> >> voted to fork instead.
> >> 
> >> last i knew elive was on an ancient version of e.
> > 
> > Ideally at some point the communities find some way to re-unite and
> > combine efforts. That maybe more utopian than realistic.
> > 
> >> when i am thinking a distro i am thinking something that is up to
> >> date. probably 2 versions - last stable release one and a "bleeding
> >> edge" one from git to show off new things.
> > 
> > Not all distros are that up to date. Example I cannot find a deb for
> > Debian or Ubuntu for newer libcheck/check. They still use 0.10.0...
> > https://github.com/libcheck/check/releases
> > 
> > I may have missed something but could not find one in ppa etc. For EFL
> > I already have to use ppa stuff on Ubuntu in Travis.
> > 
> >> > If not using either of those, I could likely help with one based on
> >> > Gentoo. Either livecd or stage 4 base system, etc.
> >> 
> >> a distro where people have to wait for everything to compile... i'm
> >> not a fan of.
> > 
> > The other choice is to wait for others to package stuff in binary
> > format. Some distros are better than others. But who says it has to
> > remain that way? Ever checked out Sabayon? A binary distro built on
> > Gentoo.
> > https://www.sabayon.org/
> > https://en.wikipedia.org/wiki/Sabayon_Linux
> > 
> >> :( i think for gentoo having the gentoo emerge package
> >> builds up to date and clean and tidy and well done is probably the
> >> right thing. when i say "distro" i mean something that out of the box
> >> just works. boots right into e. working desktop etc. etc. ... and if
> >> they want to install more they don't have to wait for compiles. quick
> >> package download+install and presto.
> > 
> > That is Sabayon philosophy as well, "out of the box".
> > 
> >> > I have all sorts of E stuff in my overlay, updated eclass, sets,
> >> > etc. I already have a custom profile based on E, and could make
> >> > others.
> >> > https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/eclass/e.eclass
> >> > https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/sets/e-desktop
> >> > https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/sets/e-desktop-dev
> >> > https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/profiles/linux/amd64/workstation/packages
> >> >
> >> >
> >> > P.S.
> >> > One reason I feel Gentoo and E/EFL are good for each other. Gentoo
> >> > preffixes most everything with the letter e...
> >> 
> >> hahahah!
> >> 
> >> despite all of that. i don't think its a good experience for users if
> >> they just want to try something out. :) i think gentoo is fine for
> >> the kind of people who want precisely what it provides. that is not
> >> imho the average user wanting an out-of-the-box experience. if those
> >> were the users to address then a wiki page on how to compile and
> >> configure an os for e is enough... that;'s not really what i think we
> >> need though.
> > 
> > I think your thinking of Gentoo as it is now, rather than a foundation
> > to build what you want on top. Who says a E distro based on Gentoo
> > would required compiling? E could easily compile stuff and setup a
> > binhost etc. Lots of options if you think creatively.
> > 
> > Plus you will want to build stuff to offer options. Otherwise you
> > either ship with all the lights/bells and whistles turned on, or you
> > choose for people. There are various compile time options for both EFL
> > and E. Thus either need to provide different binaries for each combo or
> > choose for people, which may exclude others.
> > 
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net

Re: [E-devel] Current State and Future Direction of E/EFL

[William L. Thomson Jr.]

On Thu, 8 Mar 2018 17:14:21 +0900
Carsten Haitzler (The Rasterman)  wrote:
>
> But that is the reality. They can call the shots and listen to users.
> Users are not always right. But listening is good. In the end people
> doing work make the final decisions. And I guess to some extent I
> hold a veto power over those which I generally choose not to exercise
> except on rare occasions when I think it is warranted.

Not for all, I think those that balance user needs the most tend to
prosper the most. It is the same for companies that make products. They
choose what to make, and how. But the ultimate decider if they were
right or not is the market, the users.

Apple was never big on focus groups, but if a product hit market and
did not do well. That was a tell as to product failure or success.
Either method relies on the end user, before, during, or after. Users
tend to make or break things, determine if it was successful or not.

Gentoo has had an ever increasing focus on those doing the work vs
users and its not had a good effect. I try to always put users needs
above my own. Even when I am the one doing the work.

> I think there is a balance. Moving forward with minimal interference,
> yet still trying to maintain quality too. You will never have
> perfect. Perfect is the enemy of good.

I completely agree. I think in FOSS there is to much striving for
perfection. When in closed source, at some point must ship to make
money and recoup investment. I think FOSS has more hang ups to shipping
less than perfect software. When the world is based on less than
perfect software as is now.

Take GNU kernel vs Linux. Keep striving for perfect, was taking
forever, and Linux screamed on by. Good example of such.

> > > I don't think we need STRUCTURE. I think we need communication. I
> > > think people have become awfully bad at this. Here is what people
> > > need to do IMHO.  
> > 
> > I agree on communication, but I also believe structure is important
> > to organizing any group of people to work together on anything.  
> 
> structure is no good without communication to begin with.

I agree, communication is the core to it all. An organization cannot do
a thing without good communication. You will have a hard time
organizing at all without communication.
   
> > > f) I still think E should have the filemanager built in. It's far
> > > too useful to not do this. It's pretty much necessary for icons on
> > > the desktop and consistent FM UI. If its done in-process or
> > > outside is another matter, but it has to be deeply integrated.   
> > 
> > In brief, I am not a big fan of such. Seems like a Windows concept
> > where Explorer ( not Internet Explorer) is deeply integrated. Pretty
> > much any issue I have with E that is non-recoverable comes from
> > EFM.  
> 
> actually ... this pre-dates windows. amiga workbench had it all
> integrated before windows 1.0 was around. and i'm an amiga fan. a lot
> of e was inspired from those days. i firmly believe a filemanager has
> to be deeply integrated.

Maybe best for another thread. I am curious what benefits you see in a
deeply integrated file manager. I think that goes against the Unix
philosophy of not deeply integrating anything.

I just do not like any one thing taking out other stuff. The more
things can be limited and only effect themselves, the better IMHO.

> what are the non-recoverable issues you have? i don't see those. i do
> use efm... sometimes thumbnails are blank - scrol lup and down again
> and it fixes... recently dnd seems to be flaky and stop working but
> that's not an efm change. something in efl did this i think. efm
> doesn't have a transhcan. that should be added.

The main one, maybe theme issue, is some animation I cannot easily
replicate. Where there are arrows on all four corners of the box around
the selected file/folder. It does an animation and never ends and gets
stuck. Remains on screen after closing EFM. I have had other issues
where I could not close it.  Those are what I can recall offhand.
Pretty sure there are more. I really try to avoid it.

Aside from curiosity the main reason I have verne installed is issues
with EFM. I really try to avoid it due to past history with it.

Trashcan is some what moot to me, as I rarely delete files via a file
manager.

Along the same lines, I cannot select multiple files/folders/icons on
the desktop. Though maybe related to main menu being left click. You
can do that in the file manager itself.



-- 
William L. Thomson Jr.


pgpdzQ8Da225_.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[The Rasterman]

On Mon, 5 Mar 2018 10:48:02 -0500 "William L. Thomson Jr."
 said:

> On Mon, 5 Mar 2018 20:57:17 +0900
> Carsten Haitzler (The Rasterman)  wrote:
> >
> > People who do the work get to call the shots.
> 
> That is a fine balance. I am not really a fan of say ignoring users
> wishes or others because of who is doing the work and doing it their
> way vs whats best for all with others input beyond their own opinion.

But that is the reality. They can call the shots and listen to users. Users are
not always right. But listening is good. In the end people doing work make the
final decisions. And I guess to some extent I hold a veto power over those
which I generally choose not to exercise except on rare occasions when I think
it is warranted.

> > If we made everything code-reviewed ala phab, I think it'd be far
> > worse.
> 
> This is true, it happens all the time with Gentoo. One of your own 
> Bertrand Jacquin has been stuck in such endless review... 68 comments
> https://github.com/gentoo/gentoo/pull/5832
> 
> I have been there myself with 1 line change, and no longer bother
> https://github.com/gentoo/gentoo/pull/101
> 
> > development would dwindle and die.
> 
> Yes! Just look at Gentoo for proof. QA is killing it slowly
> 
> >  I absolutely know that I'd  personally just stop if I had to put
> > every commit I do through review. 
> 
> I stopped, as have others. Your sentiments are shared by many others.

I think there is a balance. Moving forward with minimal interference, yet still
trying to maintain quality too. You will never have perfect. Perfect is the
enemy of good.

> > I don't think we need STRUCTURE. I think we need communication. I
> > think people have become awfully bad at this. Here is what people
> > need to do IMHO.
> 
> I agree on communication, but I also believe structure is important to
> organizing any group of people to work together on anything.

structure is no good without communication to begin with.

> > 4. Writing down goals
> 
> Why I started these pages I can no longer edit.
> https://phab.enlightenment.org/w/efl_apps_todo/
> https://phab.enlightenment.org/w/elm_code/syntax_support/
> 
> > f) I still think E should have the filemanager built in. It's far
> > too useful to not do this. It's pretty much necessary for icons on
> > the desktop and consistent FM UI. If its done in-process or outside
> > is another matter, but it has to be deeply integrated. 
> 
> In brief, I am not a big fan of such. Seems like a Windows concept
> where Explorer ( not Internet Explorer) is deeply integrated. Pretty
> much any issue I have with E that is non-recoverable comes from EFM.

actually ... this pre-dates windows. amiga workbench had it all integrated
before windows 1.0 was around. and i'm an amiga fan. a lot of e was inspired
from those days. i firmly believe a filemanager has to be deeply integrated.

what are the non-recoverable issues you have? i don't see those. i do use
efm... sometimes thumbnails are blank - scrol lup and down again and it
fixes... recently dnd seems to be flaky and stop working but that's not an efm
change. something in efl did this i think. efm doesn't have a transhcan. that
should be added.

> Maybe a stand alone widget/app could render Icons on desktop and be
> creative there. 3d icons, animated, etc. Integrate say a screen saver
> and live desktop, so icons move to as screen saver and for aesthetics.
> Like having an animated or live background image.
> 
> > i'm sure many people have their own ideas and priorities on what they
> > think is important/right. i'm just dropping the above out there. if
> > you want direction and can't submit your own instead, then look at
> > the above and expand on it as logical.
> 
> Maybe a start is creating more like ToDo or Wish List type pages under
> Phab to identify various interests and goals of each. Or even a simple
> EFL goals or E goals page.
> 
> -- 
> William L. Thomson Jr.


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[Vinícius dos Santos Oliveira]

2018-03-04 4:37 GMT-03:00 Davide Andreoli :

> 2018-03-02 4:42 GMT+01:00 Vinícius dos Santos Oliveira <
> vini.ipsma...@gmail.com>:
> > I miss the penguins module a lot.
> >
>
> Why you miss it? the penguins module is perfectly working with current E
> and
> (I hope) with latest stable releases. Please report any issue you will
> found to me.
>

Thank you, sir.

It was not packaged by default on ArchLinux. I assumed it has just vanished
on Enlightenment API changes just like the grudge theme.

The penguins module is working and it rocks.


-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[jaquilina]

Not sure if my reply from earlier today made it to the list as I then 
got an email shortly after saying my address had been suspended from the 
list,

God SF is a POS, but i digress there with that little rant.

I am more then eager and willing to put together an enlightenment spin 
on fedora 27 with binary packages in a custom repository that anyone 
could connect to as needed. I would base it off master branch given that 
fedora is the more bleeding side of RHEL and centos are based off of it.


On 2018-03-07 15:52, William L. Thomson Jr. wrote:

On Wed, 7 Mar 2018 14:56:13 +0900
Carsten Haitzler (The Rasterman)  wrote:


last i checked bodhi wanted to fork e because they didn't want to
update themes for compositing+wayland support (and e18 and on got
more overhead as more objects were in the canvas - this should have
been fixed by objects in buffers in evas but hasn't been to date) and
voted to fork instead.

last i knew elive was on an ancient version of e.


Ideally at some point the communities find some way to re-unite and
combine efforts. That maybe more utopian than realistic.


when i am thinking a distro i am thinking something that is up to
date. probably 2 versions - last stable release one and a "bleeding
edge" one from git to show off new things.


Not all distros are that up to date. Example I cannot find a deb for
Debian or Ubuntu for newer libcheck/check. They still use 0.10.0...
https://github.com/libcheck/check/releases

I may have missed something but could not find one in ppa etc. For EFL
I already have to use ppa stuff on Ubuntu in Travis.


> If not using either of those, I could likely help with one based on
> Gentoo. Either livecd or stage 4 base system, etc.

a distro where people have to wait for everything to compile... i'm
not a fan of.


The other choice is to wait for others to package stuff in binary
format. Some distros are better than others. But who says it has to
remain that way? Ever checked out Sabayon? A binary distro built on
Gentoo.
https://www.sabayon.org/
https://en.wikipedia.org/wiki/Sabayon_Linux


:( i think for gentoo having the gentoo emerge package
builds up to date and clean and tidy and well done is probably the
right thing. when i say "distro" i mean something that out of the box
just works. boots right into e. working desktop etc. etc. ... and if
they want to install more they don't have to wait for compiles. quick
package download+install and presto.


That is Sabayon philosophy as well, "out of the box".


> I have all sorts of E stuff in my overlay, updated eclass, sets,
> etc. I already have a custom profile based on E, and could make
> others.
> https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/eclass/e.eclass
> https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/sets/e-desktop
> https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/sets/e-desktop-dev
> 
https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/profiles/linux/amd64/workstation/packages
>
>
> P.S.
> One reason I feel Gentoo and E/EFL are good for each other. Gentoo
> preffixes most everything with the letter e...

hahahah!

despite all of that. i don't think its a good experience for users if
they just want to try something out. :) i think gentoo is fine for
the kind of people who want precisely what it provides. that is not
imho the average user wanting an out-of-the-box experience. if those
were the users to address then a wiki page on how to compile and
configure an os for e is enough... that;'s not really what i think we
need though.


I think your thinking of Gentoo as it is now, rather than a foundation
to build what you want on top. Who says a E distro based on Gentoo
would required compiling? E could easily compile stuff and setup a
binhost etc. Lots of options if you think creatively.

Plus you will want to build stuff to offer options. Otherwise you
either ship with all the lights/bells and whistles turned on, or you
choose for people. There are various compile time options for both EFL
and E. Thus either need to provide different binaries for each combo or
choose for people, which may exclude others.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[William L. Thomson Jr.]

On Wed, 7 Mar 2018 14:56:13 +0900
Carsten Haitzler (The Rasterman)  wrote:
> 
> last i checked bodhi wanted to fork e because they didn't want to
> update themes for compositing+wayland support (and e18 and on got
> more overhead as more objects were in the canvas - this should have
> been fixed by objects in buffers in evas but hasn't been to date) and
> voted to fork instead.
> 
> last i knew elive was on an ancient version of e.

Ideally at some point the communities find some way to re-unite and
combine efforts. That maybe more utopian than realistic.

> when i am thinking a distro i am thinking something that is up to
> date. probably 2 versions - last stable release one and a "bleeding
> edge" one from git to show off new things.

Not all distros are that up to date. Example I cannot find a deb for
Debian or Ubuntu for newer libcheck/check. They still use 0.10.0...
https://github.com/libcheck/check/releases

I may have missed something but could not find one in ppa etc. For EFL
I already have to use ppa stuff on Ubuntu in Travis.

> > If not using either of those, I could likely help with one based on
> > Gentoo. Either livecd or stage 4 base system, etc.  
> 
> a distro where people have to wait for everything to compile... i'm
> not a fan of. 

The other choice is to wait for others to package stuff in binary
format. Some distros are better than others. But who says it has to
remain that way? Ever checked out Sabayon? A binary distro built on
Gentoo.
https://www.sabayon.org/
https://en.wikipedia.org/wiki/Sabayon_Linux

> :( i think for gentoo having the gentoo emerge package
> builds up to date and clean and tidy and well done is probably the
> right thing. when i say "distro" i mean something that out of the box
> just works. boots right into e. working desktop etc. etc. ... and if
> they want to install more they don't have to wait for compiles. quick
> package download+install and presto.

That is Sabayon philosophy as well, "out of the box".

> > I have all sorts of E stuff in my overlay, updated eclass, sets,
> > etc. I already have a custom profile based on E, and could make
> > others.
> > https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/eclass/e.eclass
> > https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/sets/e-desktop
> > https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/sets/e-desktop-dev
> > https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/profiles/linux/amd64/workstation/packages
> > 
> > 
> > P.S.
> > One reason I feel Gentoo and E/EFL are good for each other. Gentoo
> > preffixes most everything with the letter e...  
> 
> hahahah!
> 
> despite all of that. i don't think its a good experience for users if
> they just want to try something out. :) i think gentoo is fine for
> the kind of people who want precisely what it provides. that is not
> imho the average user wanting an out-of-the-box experience. if those
> were the users to address then a wiki page on how to compile and
> configure an os for e is enough... that;'s not really what i think we
> need though.

I think your thinking of Gentoo as it is now, rather than a foundation
to build what you want on top. Who says a E distro based on Gentoo
would required compiling? E could easily compile stuff and setup a
binhost etc. Lots of options if you think creatively.

Plus you will want to build stuff to offer options. Otherwise you
either ship with all the lights/bells and whistles turned on, or you
choose for people. There are various compile time options for both EFL
and E. Thus either need to provide different binaries for each combo or
choose for people, which may exclude others.

-- 
William L. Thomson Jr.


pgpZY7Q05CXcg.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[William L. Thomson Jr.]

On Wed, 7 Mar 2018 12:03:27 +1030
Simon Lees  wrote:

> On Wednesday, 7 March 2018 05:33:45 ACDT, William L. Thomson Jr.
> wrote:
> > On Mon, 5 Mar 2018 20:57:17 +0900
> > Carsten Haitzler (The Rasterman)  wrote:  
> >>
> >>  h) I think at some point we may have to do our own distro that
> >> integrates E well and shows it off out-of-the-box.  
> >
> > I would be interested in such. There are a couple existing.
> > http://www.elivecd.org/
> > http://www.bodhilinux.com/
> >
> > If not using either of those, I could likely help with one based on
> > Gentoo. Either livecd or stage 4 base system, etc.  
> 
> Neither of the 2 above ship the latest e, 

Maybe reaching out and working with them could change that. Just saying
there are 2 existing, with users, communities, a 3rd will just confuse
people. Its a some what confusing situation already.

-- 
William L. Thomson Jr.


pgpex5tXqapsO.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[Jonathan Aquilina]

I’m willing to do a fedora spin for the bleeding edge stuff if you want me to

Sent from my iPhone

> On 07 Mar 2018, at 06:56, Carsten Haitzler (The Rasterman) 
>  wrote:
> 
> On Tue, 6 Mar 2018 14:03:45 -0500 "William L. Thomson Jr."
>  said:
> 
>> On Mon, 5 Mar 2018 20:57:17 +0900
>> Carsten Haitzler (The Rasterman)  wrote:
>>> 
>>> h) I think at some point we may have to do our own distro that
>>> integrates E well and shows it off out-of-the-box. 
>> 
>> I would be interested in such. There are a couple existing.
>> http://www.elivecd.org/
>> http://www.bodhilinux.com/
> 
> last i checked bodhi wanted to fork e because they didn't want to update 
> themes
> for compositing+wayland support (and e18 and on got more overhead as more
> objects were in the canvas - this should have been fixed by objects in
> buffers in evas but hasn't been to date) and voted to fork instead.
> 
> last i knew elive was on an ancient version of e.
> 
> when i am thinking a distro i am thinking something that is up to date.
> probably 2 versions - last stable release one and a "bleeding edge" one from
> git to show off new things.
> 
>> If not using either of those, I could likely help with one based on
>> Gentoo. Either livecd or stage 4 base system, etc.
> 
> a distro where people have to wait for everything to compile... i'm not a fan
> of. :( i think for gentoo having the gentoo emerge package builds up to date
> and clean and tidy and well done is probably the right thing. when i say
> "distro" i mean something that out of the box just works. boots right into e.
> working desktop etc. etc. ... and if they want to install more they don't have
> to wait for compiles. quick package download+install and presto.
> 
>> I have all sorts of E stuff in my overlay, updated eclass, sets, etc. I
>> already have a custom profile based on E, and could make others.
>> https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/eclass/e.eclass
>> https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/sets/e-desktop
>> https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/sets/e-desktop-dev
>> https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/profiles/linux/amd64/workstation/packages
>> 
>> 
>> P.S.
>> One reason I feel Gentoo and E/EFL are good for each other. Gentoo
>> preffixes most everything with the letter e...
> 
> hahahah!
> 
> despite all of that. i don't think its a good experience for users if they 
> just
> want to try something out. :) i think gentoo is fine for the kind of people 
> who
> want precisely what it provides. that is not imho the average user wanting an
> out-of-the-box experience. if those were the users to address then a wiki page
> on how to compile and configure an os for e is enough... that;'s not really
> what i think we need though.
> 
>> emerge, equery, eselect, euse, etc 
>> 
>> Just seems like a natural paring. Though for many Gentoo is not an
>> ideal distro. I do not recommend it to anyone other than developers.
>> 
>> -- 
>> William L. Thomson Jr.
> 
> 
> -- 
> - Codito, ergo sum - "I code, therefore I am" --
> Carsten Haitzler - ras...@rasterman.com
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[Jonathan Aquilina]

Stupid suggestion probably if you are going to use opensuse as the base why not 
maintain the existing code base and fork it and clean that up in a way kind of 
start from scratch?

Sent from my iPhone

> On 07 Mar 2018, at 07:40, Carsten Haitzler (The Rasterman) 
>  wrote:
> 
> On Wed, 7 Mar 2018 12:03:27 +1030 Simon Lees  said:
> 
>> On Wednesday, 7 March 2018 05:33:45 ACDT, William L. Thomson Jr. wrote:
>>> On Mon, 5 Mar 2018 20:57:17 +0900
>>> Carsten Haitzler (The Rasterman)  wrote:
 
 h) I think at some point we may have to do our own distro that
 integrates E well and shows it off out-of-the-box.
>>> 
>>> I would be interested in such. There are a couple existing.
>>> http://www.elivecd.org/
>>> http://www.bodhilinux.com/
>>> 
>>> If not using either of those, I could likely help with one based on
>>> Gentoo. Either livecd or stage 4 base system, etc.
>> 
>> Neither of the 2 above ship the latest e, at some point I will start
>> creating e images again to use with openQA as part of testing, the only
>> thing I need before I can spin up an "Enlightenment OS" is probably
>> matching Grub2, Plymouth and lightdm branding. I suggest we tackle that
>> after we do e's theme though. But if someone wants to get to it sooner
>> why not.
> 
> we were discussing on irc with you.. i thought i'd bring some of that here.
> 
> i think we should look into opensuse as a base. it will allow for a more
> minimal os than something like arch or gentoo (though maybe on par with
> debian). mostly because simon has been around with us for years and years and 
> i
> trust him not to vanish. i think working with him to at least investigate 
> would
> be good.
> 
> so my take also is to strip out as much as we can get away with. that would
> mean no lightdm. no plymouth. have the system boot right into a fixed user 
> with
> no login (have e optionally ask for passwd on startup).
> 
> keep the thole thing as simple as needed then fill these things in as we have
> nice solutions.
> 
>> I have made some raspberry pi images, but they are using an older efl
>> from before I tried to switch to luajit on aarch64.
> 
> we can just stick to 32bit arm until this is resolved.
> 
>> -- 
>> 
>> Simon Lees (Simotek)http://simotek.net
>> 
>> Emergency Update Team   keybase.io/simotek
>> SUSE Linux   Adelaide Australia, UTC+10:30
>> GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
>> 
> 
> 
> -- 
> - Codito, ergo sum - "I code, therefore I am" --
> Carsten Haitzler - ras...@rasterman.com
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[The Rasterman]

On Wed, 7 Mar 2018 12:03:27 +1030 Simon Lees  said:

> On Wednesday, 7 March 2018 05:33:45 ACDT, William L. Thomson Jr. wrote:
> > On Mon, 5 Mar 2018 20:57:17 +0900
> > Carsten Haitzler (The Rasterman)  wrote:
> >>
> >>  h) I think at some point we may have to do our own distro that
> >> integrates E well and shows it off out-of-the-box.
> >
> > I would be interested in such. There are a couple existing.
> > http://www.elivecd.org/
> > http://www.bodhilinux.com/
> >
> > If not using either of those, I could likely help with one based on
> > Gentoo. Either livecd or stage 4 base system, etc.
> 
> Neither of the 2 above ship the latest e, at some point I will start
> creating e images again to use with openQA as part of testing, the only
> thing I need before I can spin up an "Enlightenment OS" is probably
> matching Grub2, Plymouth and lightdm branding. I suggest we tackle that
> after we do e's theme though. But if someone wants to get to it sooner
> why not.

we were discussing on irc with you.. i thought i'd bring some of that here.

i think we should look into opensuse as a base. it will allow for a more
minimal os than something like arch or gentoo (though maybe on par with
debian). mostly because simon has been around with us for years and years and i
trust him not to vanish. i think working with him to at least investigate would
be good.

so my take also is to strip out as much as we can get away with. that would
mean no lightdm. no plymouth. have the system boot right into a fixed user with
no login (have e optionally ask for passwd on startup).

keep the thole thing as simple as needed then fill these things in as we have
nice solutions.

> I have made some raspberry pi images, but they are using an older efl
> from before I tried to switch to luajit on aarch64.

we can just stick to 32bit arm until this is resolved.

> -- 
> 
> Simon Lees (Simotek)http://simotek.net
> 
> Emergency Update Team   keybase.io/simotek
> SUSE Linux   Adelaide Australia, UTC+10:30
> GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[The Rasterman]

On Tue, 6 Mar 2018 14:03:45 -0500 "William L. Thomson Jr."
 said:

> On Mon, 5 Mar 2018 20:57:17 +0900
> Carsten Haitzler (The Rasterman)  wrote:
> >
> >  h) I think at some point we may have to do our own distro that
> > integrates E well and shows it off out-of-the-box. 
> 
> I would be interested in such. There are a couple existing.
> http://www.elivecd.org/
> http://www.bodhilinux.com/

last i checked bodhi wanted to fork e because they didn't want to update themes
for compositing+wayland support (and e18 and on got more overhead as more
objects were in the canvas - this should have been fixed by objects in
buffers in evas but hasn't been to date) and voted to fork instead.

last i knew elive was on an ancient version of e.

when i am thinking a distro i am thinking something that is up to date.
probably 2 versions - last stable release one and a "bleeding edge" one from
git to show off new things.

> If not using either of those, I could likely help with one based on
> Gentoo. Either livecd or stage 4 base system, etc.

a distro where people have to wait for everything to compile... i'm not a fan
of. :( i think for gentoo having the gentoo emerge package builds up to date
and clean and tidy and well done is probably the right thing. when i say
"distro" i mean something that out of the box just works. boots right into e.
working desktop etc. etc. ... and if they want to install more they don't have
to wait for compiles. quick package download+install and presto.

> I have all sorts of E stuff in my overlay, updated eclass, sets, etc. I
> already have a custom profile based on E, and could make others.
> https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/eclass/e.eclass
> https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/sets/e-desktop
> https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/sets/e-desktop-dev
> https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/profiles/linux/amd64/workstation/packages
> 
> 
> P.S.
> One reason I feel Gentoo and E/EFL are good for each other. Gentoo
> preffixes most everything with the letter e...

hahahah!

despite all of that. i don't think its a good experience for users if they just
want to try something out. :) i think gentoo is fine for the kind of people who
want precisely what it provides. that is not imho the average user wanting an
out-of-the-box experience. if those were the users to address then a wiki page
on how to compile and configure an os for e is enough... that;'s not really
what i think we need though.

> emerge, equery, eselect, euse, etc 
> 
> Just seems like a natural paring. Though for many Gentoo is not an
> ideal distro. I do not recommend it to anyone other than developers.
> 
> -- 
> William L. Thomson Jr.


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[Simon Lees]

On Wednesday, 7 March 2018 05:33:45 ACDT, William L. Thomson Jr. wrote:
> On Mon, 5 Mar 2018 20:57:17 +0900
> Carsten Haitzler (The Rasterman)  wrote:
>>
>>  h) I think at some point we may have to do our own distro that
>> integrates E well and shows it off out-of-the-box.
>
> I would be interested in such. There are a couple existing.
> http://www.elivecd.org/
> http://www.bodhilinux.com/
>
> If not using either of those, I could likely help with one based on
> Gentoo. Either livecd or stage 4 base system, etc.

Neither of the 2 above ship the latest e, at some point I will start
creating e images again to use with openQA as part of testing, the only
thing I need before I can spin up an "Enlightenment OS" is probably
matching Grub2, Plymouth and lightdm branding. I suggest we tackle that
after we do e's theme though. But if someone wants to get to it sooner
why not.

I have made some raspberry pi images, but they are using an older efl
from before I tried to switch to luajit on aarch64.
-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[Christophe Sadoine]

On 7 March 2018 at 01:50, Carsten Haitzler  wrote:
> On Tue, 06 Mar 2018 16:21:48 + Stephen Houston  
> said:
>
>> Sigh. You are missing the point...
>
> i'm not... you're saying "hey look he wants cherries. check out this box of
> potatoes we have!".
>
> i'm not saying that one or the other is invalid or wrong, but you're linking
> things that are not the same thing. not like that ticket solves anything for
> stefan and CI. that's my point. so why link them?

Well this ticket is for finding solutions.
If there is an issue with qa and someone has ideas/solutions why not
write them there?
I think that the one person always doing this not be sane for him. So
for example we could have a rotation, divide the work, or a way to
automate it?

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[William L. Thomson Jr.]

On Mon, 5 Mar 2018 20:57:17 +0900
Carsten Haitzler (The Rasterman)  wrote:
>
>  h) I think at some point we may have to do our own distro that
> integrates E well and shows it off out-of-the-box. 

I would be interested in such. There are a couple existing.
http://www.elivecd.org/
http://www.bodhilinux.com/

If not using either of those, I could likely help with one based on
Gentoo. Either livecd or stage 4 base system, etc.

I have all sorts of E stuff in my overlay, updated eclass, sets, etc. I
already have a custom profile based on E, and could make others.
https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/eclass/e.eclass
https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/sets/e-desktop
https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/sets/e-desktop-dev
https://github.com/Obsidian-StudiosInc/os-xtoo/blob/master/profiles/linux/amd64/workstation/packages


P.S.
One reason I feel Gentoo and E/EFL are good for each other. Gentoo
preffixes most everything with the letter e...

emerge, equery, eselect, euse, etc 

Just seems like a natural paring. Though for many Gentoo is not an
ideal distro. I do not recommend it to anyone other than developers.

-- 
William L. Thomson Jr.


pgpep8iQH6tkS.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[Stephen Houston]

No I'm saying look, potatoes or cherries let's do something, anything,
other than nothing and here is a place to discuss with summarizations.

On Tue, Mar 6, 2018, 10:52 AM Carsten Haitzler  wrote:

> On Tue, 06 Mar 2018 16:21:48 + Stephen Houston 
> said:
>
> > Sigh. You are missing the point...
>
> i'm not... you're saying "hey look he wants cherries. check out this box of
> potatoes we have!".
>
> i'm not saying that one or the other is invalid or wrong, but you're
> linking
> things that are not the same thing. not like that ticket solves anything
> for
> stefan and CI. that's my point. so why link them?
>
> > On Tue, Mar 6, 2018, 10:16 AM Carsten Haitzler 
> wrote:
> >
> > > On Tue, 06 Mar 2018 15:27:06 + Stephen Houston <
> smhousto...@gmail.com>
> > > said:
> > >
> > > > We have developers leaving or severely cutting back their work, and
> this
> > > > includes developers who carry a large work load.  Now we see Stefan
> has
> > > > lost faith and interest in QA/CI and is going to step back from
> that... I
> > > > think at some point we need to agree to stop arguing the merits of
> > > getting
> > > > better structure and better organization and agree that SOMETHING
> needs
> > > to
> > > > be done and start putting together a plan.  So I think indefini put
> > > > together a phab ticket https://phab.enlightenment.org/T6740 we
> should
> > > > really work there to put together a plan to help.
> > >
> > > not sure why you said the above... that exact ticket is entirely
> unrelated
> > > to
> > > what stefan is talking about. in fact they disagree.
> > >
> > > > On Tue, Mar 6, 2018 at 8:46 AM Carsten Haitzler <
> ras...@rasterman.com>
> > > > wrote:
> > > >
> > > > > On Tue, 6 Mar 2018 13:43:09 +0100 Stefan Schmidt <
> > > ste...@osg.samsung.com>
> > > > > said:
> > > > >
> > > > > > Hello.
> > > > > >
> > > > > >
> > > > > > On 03/06/2018 12:34 PM, Carsten Haitzler (The Rasterman) wrote:
> > > > > > > On Tue, 6 Mar 2018 09:54:50 +0100 Stefan Schmidt <
> > > > > ste...@osg.samsung.com>
> > > > > > > said:
> > > > > > >
> > > > > > >> Hello.
> > > > > > >>
> > > > > > >>
> > > > > > >> On 03/06/2018 07:44 AM, Carsten Haitzler (The Rasterman)
> wrote:
> > > > > > >>> tbh platforms is an issue. windows is kind of big as setting
> up a
> > > > > > >>> cross-build environment is a fair bit of work. setting up a
> > > windows
> > > > > vm
> > > > > > >>> costs money to test (need licenses, or if you can scrounge
> one
> > > off
> > > > > another
> > > > > > >>> pc you have/had). osx is worse in that you have to go buy
> > > hardware
> > > > > to run
> > > > > > >>> osx to test.
> > > > > > >>>
> > > > > > >>> i think making it a requirement that every commit work on
> every
> > > > > platform
> > > > > > >>> is not viable UNLESS:
> > > > > > >>>
> > > > > > >>> 1. a windows cross-compile env is available to developers
> (e.g.
> > > ssh
> > > > > into a
> > > > > > >>> vm set up for this with clear documentation and
> scripts/tools to
> > > do
> > > > > the
> > > > > > >>> builds. i have one set up for me at home).
> > > > > > >>> 2. a vm with remote display that developers can use to
> run/test
> > > > > changes
> > > > > > >>> easily.
> > > > > > >>> 3. an actual osx box that developers can ssh into and
> compile and
> > > > > runa nd
> > > > > > >>> test and remotely view/interact with like the windows vm.
> > > > > > >>> 4. same for freebsd etc.
> > > > > > >> We do not have this and I am pretty sure we never will (I can
> only
> > > > > hope the
> > > > > > >> future proofs me wrong). Maybe we should be more honest and
> state
> > > > > that any
> > > > > > > then i can't see how we could make it a requirement for
> committing
> > > > > that they
> > > > > > > build/run there.
> > > > > >
> > > > > > Having them running a build is very different from having full
> remote
> > > > > shell
> > > > > > access. E.g. osx build slaves available on TravisCi do not have
> any
> > > > > option to
> > > > > > get shell access.
> > > > > >
> > > > > > Detecting a problem is the first step. A build test for these
> > > *before*
> > > > > > entering master would do this. It would still need fixing, but
> that
> > > is
> > > > > the
> > > > > > same we have right now. The difference really is where we detect
> the
> > > > > break
> > > > > > and if we have it sitting in master or not.
> > > > >
> > > > > ok - i wasn't thinking github's travis but more an actual osx
> machine
> > > > > plugged
> > > > > in somewhere we can remotely manage and use. :) i know travis will
> be
> > > very
> > > > > limited.
> > > > >
> > > > > > > when people report issues with specific builds/platforms then
> > > > > > > address them as needed.
> > > > > >
> > > > > > I can report the build being broken on osx, on aarch64, with the
> > > debug
> > > > > > profile enabled and also make check with cxx enabled right now.
> That
> > > are
> > > > > 4
> > > > > > 

Re: [E-devel] Current State and Future Direction of E/EFL

[Carsten Haitzler]

On Tue, 06 Mar 2018 16:21:48 + Stephen Houston  said:

> Sigh. You are missing the point...

i'm not... you're saying "hey look he wants cherries. check out this box of
potatoes we have!".

i'm not saying that one or the other is invalid or wrong, but you're linking
things that are not the same thing. not like that ticket solves anything for
stefan and CI. that's my point. so why link them?

> On Tue, Mar 6, 2018, 10:16 AM Carsten Haitzler  wrote:
> 
> > On Tue, 06 Mar 2018 15:27:06 + Stephen Houston 
> > said:
> >
> > > We have developers leaving or severely cutting back their work, and this
> > > includes developers who carry a large work load.  Now we see Stefan has
> > > lost faith and interest in QA/CI and is going to step back from that... I
> > > think at some point we need to agree to stop arguing the merits of
> > getting
> > > better structure and better organization and agree that SOMETHING needs
> > to
> > > be done and start putting together a plan.  So I think indefini put
> > > together a phab ticket https://phab.enlightenment.org/T6740 we should
> > > really work there to put together a plan to help.
> >
> > not sure why you said the above... that exact ticket is entirely unrelated
> > to
> > what stefan is talking about. in fact they disagree.
> >
> > > On Tue, Mar 6, 2018 at 8:46 AM Carsten Haitzler 
> > > wrote:
> > >
> > > > On Tue, 6 Mar 2018 13:43:09 +0100 Stefan Schmidt <
> > ste...@osg.samsung.com>
> > > > said:
> > > >
> > > > > Hello.
> > > > >
> > > > >
> > > > > On 03/06/2018 12:34 PM, Carsten Haitzler (The Rasterman) wrote:
> > > > > > On Tue, 6 Mar 2018 09:54:50 +0100 Stefan Schmidt <
> > > > ste...@osg.samsung.com>
> > > > > > said:
> > > > > >
> > > > > >> Hello.
> > > > > >>
> > > > > >>
> > > > > >> On 03/06/2018 07:44 AM, Carsten Haitzler (The Rasterman) wrote:
> > > > > >>> tbh platforms is an issue. windows is kind of big as setting up a
> > > > > >>> cross-build environment is a fair bit of work. setting up a
> > windows
> > > > vm
> > > > > >>> costs money to test (need licenses, or if you can scrounge one
> > off
> > > > another
> > > > > >>> pc you have/had). osx is worse in that you have to go buy
> > hardware
> > > > to run
> > > > > >>> osx to test.
> > > > > >>>
> > > > > >>> i think making it a requirement that every commit work on every
> > > > platform
> > > > > >>> is not viable UNLESS:
> > > > > >>>
> > > > > >>> 1. a windows cross-compile env is available to developers (e.g.
> > ssh
> > > > into a
> > > > > >>> vm set up for this with clear documentation and scripts/tools to
> > do
> > > > the
> > > > > >>> builds. i have one set up for me at home).
> > > > > >>> 2. a vm with remote display that developers can use to run/test
> > > > changes
> > > > > >>> easily.
> > > > > >>> 3. an actual osx box that developers can ssh into and compile and
> > > > runa nd
> > > > > >>> test and remotely view/interact with like the windows vm.
> > > > > >>> 4. same for freebsd etc.
> > > > > >> We do not have this and I am pretty sure we never will (I can only
> > > > hope the
> > > > > >> future proofs me wrong). Maybe we should be more honest and state
> > > > that any
> > > > > > then i can't see how we could make it a requirement for committing
> > > > that they
> > > > > > build/run there.
> > > > >
> > > > > Having them running a build is very different from having full remote
> > > > shell
> > > > > access. E.g. osx build slaves available on TravisCi do not have any
> > > > option to
> > > > > get shell access.
> > > > >
> > > > > Detecting a problem is the first step. A build test for these
> > *before*
> > > > > entering master would do this. It would still need fixing, but that
> > is
> > > > the
> > > > > same we have right now. The difference really is where we detect the
> > > > break
> > > > > and if we have it sitting in master or not.
> > > >
> > > > ok - i wasn't thinking github's travis but more an actual osx machine
> > > > plugged
> > > > in somewhere we can remotely manage and use. :) i know travis will be
> > very
> > > > limited.
> > > >
> > > > > > when people report issues with specific builds/platforms then
> > > > > > address them as needed.
> > > > >
> > > > > I can report the build being broken on osx, on aarch64, with the
> > debug
> > > > > profile enabled and also make check with cxx enabled right now. That
> > are
> > > > 4
> > > > > things broken in master just what i see today.
> > > >
> > > > arm64 - known. and this is a bit of a surprise from luajit. it's
> > > > technically
> > > > been broken like this forever. it wasn't some change we made. somehow
> > > > luajit
> > > > started breaking at some point. the "we only allow you to use 27 bits
> > out
> > > > of 64
> > > > of a pointer" thing.
> > > >
> > > > so this is not something CI would magically stop as changes to the
> > > > dependencies
> > > > started making things crash there. 

Re: [E-devel] Current State and Future Direction of E/EFL

[Stephen Houston]

Sigh. You are missing the point...

On Tue, Mar 6, 2018, 10:16 AM Carsten Haitzler  wrote:

> On Tue, 06 Mar 2018 15:27:06 + Stephen Houston 
> said:
>
> > We have developers leaving or severely cutting back their work, and this
> > includes developers who carry a large work load.  Now we see Stefan has
> > lost faith and interest in QA/CI and is going to step back from that... I
> > think at some point we need to agree to stop arguing the merits of
> getting
> > better structure and better organization and agree that SOMETHING needs
> to
> > be done and start putting together a plan.  So I think indefini put
> > together a phab ticket https://phab.enlightenment.org/T6740 we should
> > really work there to put together a plan to help.
>
> not sure why you said the above... that exact ticket is entirely unrelated
> to
> what stefan is talking about. in fact they disagree.
>
> > On Tue, Mar 6, 2018 at 8:46 AM Carsten Haitzler 
> > wrote:
> >
> > > On Tue, 6 Mar 2018 13:43:09 +0100 Stefan Schmidt <
> ste...@osg.samsung.com>
> > > said:
> > >
> > > > Hello.
> > > >
> > > >
> > > > On 03/06/2018 12:34 PM, Carsten Haitzler (The Rasterman) wrote:
> > > > > On Tue, 6 Mar 2018 09:54:50 +0100 Stefan Schmidt <
> > > ste...@osg.samsung.com>
> > > > > said:
> > > > >
> > > > >> Hello.
> > > > >>
> > > > >>
> > > > >> On 03/06/2018 07:44 AM, Carsten Haitzler (The Rasterman) wrote:
> > > > >>> tbh platforms is an issue. windows is kind of big as setting up a
> > > > >>> cross-build environment is a fair bit of work. setting up a
> windows
> > > vm
> > > > >>> costs money to test (need licenses, or if you can scrounge one
> off
> > > another
> > > > >>> pc you have/had). osx is worse in that you have to go buy
> hardware
> > > to run
> > > > >>> osx to test.
> > > > >>>
> > > > >>> i think making it a requirement that every commit work on every
> > > platform
> > > > >>> is not viable UNLESS:
> > > > >>>
> > > > >>> 1. a windows cross-compile env is available to developers (e.g.
> ssh
> > > into a
> > > > >>> vm set up for this with clear documentation and scripts/tools to
> do
> > > the
> > > > >>> builds. i have one set up for me at home).
> > > > >>> 2. a vm with remote display that developers can use to run/test
> > > changes
> > > > >>> easily.
> > > > >>> 3. an actual osx box that developers can ssh into and compile and
> > > runa nd
> > > > >>> test and remotely view/interact with like the windows vm.
> > > > >>> 4. same for freebsd etc.
> > > > >> We do not have this and I am pretty sure we never will (I can only
> > > hope the
> > > > >> future proofs me wrong). Maybe we should be more honest and state
> > > that any
> > > > > then i can't see how we could make it a requirement for committing
> > > that they
> > > > > build/run there.
> > > >
> > > > Having them running a build is very different from having full remote
> > > shell
> > > > access. E.g. osx build slaves available on TravisCi do not have any
> > > option to
> > > > get shell access.
> > > >
> > > > Detecting a problem is the first step. A build test for these
> *before*
> > > > entering master would do this. It would still need fixing, but that
> is
> > > the
> > > > same we have right now. The difference really is where we detect the
> > > break
> > > > and if we have it sitting in master or not.
> > >
> > > ok - i wasn't thinking github's travis but more an actual osx machine
> > > plugged
> > > in somewhere we can remotely manage and use. :) i know travis will be
> very
> > > limited.
> > >
> > > > > when people report issues with specific builds/platforms then
> > > > > address them as needed.
> > > >
> > > > I can report the build being broken on osx, on aarch64, with the
> debug
> > > > profile enabled and also make check with cxx enabled right now. That
> are
> > > 4
> > > > things broken in master just what i see today.
> > >
> > > arm64 - known. and this is a bit of a surprise from luajit. it's
> > > technically
> > > been broken like this forever. it wasn't some change we made. somehow
> > > luajit
> > > started breaking at some point. the "we only allow you to use 27 bits
> out
> > > of 64
> > > of a pointer" thing.
> > >
> > > so this is not something CI would magically stop as changes to the
> > > dependencies
> > > started making things crash there. at least i have personally compiled
> > > using a
> > > luajit compiled myself on arm64 and it worked. this was a while back.
> > >
> > > cxx bindings. indeed these are a problem to the point where i just
> disable
> > > them
> > > in my build. i am not sure if this is good or bad though. it's kind of
> > > tired
> > > with the eo and bindings work and as things change multiple languages
> need
> > > to
> > > adapt.
> > >
> > > as for osx - i have no info as to what is going on there or why. :( i
> don't
> > > know even where the build breaks/logs etc. are. i do know
> > > build.enlightenment.org and that basically 

Re: [E-devel] Current State and Future Direction of E/EFL

[The Rasterman]

On Tue, 06 Mar 2018 15:27:06 + Stephen Houston  said:

> We have developers leaving or severely cutting back their work, and this
> includes developers who carry a large work load.  Now we see Stefan has
> lost faith and interest in QA/CI and is going to step back from that... I
> think at some point we need to agree to stop arguing the merits of getting
> better structure and better organization and agree that SOMETHING needs to
> be done and start putting together a plan.  So I think indefini put
> together a phab ticket https://phab.enlightenment.org/T6740 we should
> really work there to put together a plan to help.

not sure why you said the above... that exact ticket is entirely unrelated to
what stefan is talking about. in fact they disagree.

> On Tue, Mar 6, 2018 at 8:46 AM Carsten Haitzler 
> wrote:
> 
> > On Tue, 6 Mar 2018 13:43:09 +0100 Stefan Schmidt 
> > said:
> >
> > > Hello.
> > >
> > >
> > > On 03/06/2018 12:34 PM, Carsten Haitzler (The Rasterman) wrote:
> > > > On Tue, 6 Mar 2018 09:54:50 +0100 Stefan Schmidt <
> > ste...@osg.samsung.com>
> > > > said:
> > > >
> > > >> Hello.
> > > >>
> > > >>
> > > >> On 03/06/2018 07:44 AM, Carsten Haitzler (The Rasterman) wrote:
> > > >>> tbh platforms is an issue. windows is kind of big as setting up a
> > > >>> cross-build environment is a fair bit of work. setting up a windows
> > vm
> > > >>> costs money to test (need licenses, or if you can scrounge one off
> > another
> > > >>> pc you have/had). osx is worse in that you have to go buy hardware
> > to run
> > > >>> osx to test.
> > > >>>
> > > >>> i think making it a requirement that every commit work on every
> > platform
> > > >>> is not viable UNLESS:
> > > >>>
> > > >>> 1. a windows cross-compile env is available to developers (e.g. ssh
> > into a
> > > >>> vm set up for this with clear documentation and scripts/tools to do
> > the
> > > >>> builds. i have one set up for me at home).
> > > >>> 2. a vm with remote display that developers can use to run/test
> > changes
> > > >>> easily.
> > > >>> 3. an actual osx box that developers can ssh into and compile and
> > runa nd
> > > >>> test and remotely view/interact with like the windows vm.
> > > >>> 4. same for freebsd etc.
> > > >> We do not have this and I am pretty sure we never will (I can only
> > hope the
> > > >> future proofs me wrong). Maybe we should be more honest and state
> > that any
> > > > then i can't see how we could make it a requirement for committing
> > that they
> > > > build/run there.
> > >
> > > Having them running a build is very different from having full remote
> > shell
> > > access. E.g. osx build slaves available on TravisCi do not have any
> > option to
> > > get shell access.
> > >
> > > Detecting a problem is the first step. A build test for these *before*
> > > entering master would do this. It would still need fixing, but that is
> > the
> > > same we have right now. The difference really is where we detect the
> > break
> > > and if we have it sitting in master or not.
> >
> > ok - i wasn't thinking github's travis but more an actual osx machine
> > plugged
> > in somewhere we can remotely manage and use. :) i know travis will be very
> > limited.
> >
> > > > when people report issues with specific builds/platforms then
> > > > address them as needed.
> > >
> > > I can report the build being broken on osx, on aarch64, with the debug
> > > profile enabled and also make check with cxx enabled right now. That are
> > 4
> > > things broken in master just what i see today.
> >
> > arm64 - known. and this is a bit of a surprise from luajit. it's
> > technically
> > been broken like this forever. it wasn't some change we made. somehow
> > luajit
> > started breaking at some point. the "we only allow you to use 27 bits out
> > of 64
> > of a pointer" thing.
> >
> > so this is not something CI would magically stop as changes to the
> > dependencies
> > started making things crash there. at least i have personally compiled
> > using a
> > luajit compiled myself on arm64 and it worked. this was a while back.
> >
> > cxx bindings. indeed these are a problem to the point where i just disable
> > them
> > in my build. i am not sure if this is good or bad though. it's kind of
> > tired
> > with the eo and bindings work and as things change multiple languages need
> > to
> > adapt.
> >
> > as for osx - i have no info as to what is going on there or why. :( i don't
> > know even where the build breaks/logs etc. are. i do know
> > build.enlightenment.org and that basically seems ok.
> >
> > > >> platform we support (besides Linux on x86_64) has only been tested at
> > some
> > > >> point in the past.
> > > > i actually cross-build for windows maybe every few weeks or so, and
> > freebsd
> > > > maybe similarly too. i build on rpi3 (32bit) too regularly enough.
> > > >
> > > > we haven't tested on every linux distro either... so should we only
> > 

Re: [E-devel] Current State and Future Direction of E/EFL

[William L. Thomson Jr.]

On Tue, 6 Mar 2018 08:59:02 +0100
Jérémy Zurcher  wrote:

> Rust uses github bot to post commits after testing thus ensure a good
> state master branch.
> 
> https://github.com/barosl/homu
> https://www.youtube.com/watch?v=dIageYT0Vgg

Ansible seems to have made their own. Its pretty cool since 3rd party
contributors/maintainers can commit directly after passing CI by typing
"shipit" in github PRs. Then the bot merges that PR.
https://github.com/ansible/ansibullbot

May have to make something specific for E/EFL needs.

-- 
William L. Thomson Jr.


pgpB3OmJ_5XIk.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[Stephen Houston]

We have developers leaving or severely cutting back their work, and this
includes developers who carry a large work load.  Now we see Stefan has
lost faith and interest in QA/CI and is going to step back from that... I
think at some point we need to agree to stop arguing the merits of getting
better structure and better organization and agree that SOMETHING needs to
be done and start putting together a plan.  So I think indefini put
together a phab ticket https://phab.enlightenment.org/T6740 we should
really work there to put together a plan to help.

On Tue, Mar 6, 2018 at 8:46 AM Carsten Haitzler 
wrote:

> On Tue, 6 Mar 2018 13:43:09 +0100 Stefan Schmidt 
> said:
>
> > Hello.
> >
> >
> > On 03/06/2018 12:34 PM, Carsten Haitzler (The Rasterman) wrote:
> > > On Tue, 6 Mar 2018 09:54:50 +0100 Stefan Schmidt <
> ste...@osg.samsung.com>
> > > said:
> > >
> > >> Hello.
> > >>
> > >>
> > >> On 03/06/2018 07:44 AM, Carsten Haitzler (The Rasterman) wrote:
> > >>> tbh platforms is an issue. windows is kind of big as setting up a
> > >>> cross-build environment is a fair bit of work. setting up a windows
> vm
> > >>> costs money to test (need licenses, or if you can scrounge one off
> another
> > >>> pc you have/had). osx is worse in that you have to go buy hardware
> to run
> > >>> osx to test.
> > >>>
> > >>> i think making it a requirement that every commit work on every
> platform
> > >>> is not viable UNLESS:
> > >>>
> > >>> 1. a windows cross-compile env is available to developers (e.g. ssh
> into a
> > >>> vm set up for this with clear documentation and scripts/tools to do
> the
> > >>> builds. i have one set up for me at home).
> > >>> 2. a vm with remote display that developers can use to run/test
> changes
> > >>> easily.
> > >>> 3. an actual osx box that developers can ssh into and compile and
> runa nd
> > >>> test and remotely view/interact with like the windows vm.
> > >>> 4. same for freebsd etc.
> > >> We do not have this and I am pretty sure we never will (I can only
> hope the
> > >> future proofs me wrong). Maybe we should be more honest and state
> that any
> > > then i can't see how we could make it a requirement for committing
> that they
> > > build/run there.
> >
> > Having them running a build is very different from having full remote
> shell
> > access. E.g. osx build slaves available on TravisCi do not have any
> option to
> > get shell access.
> >
> > Detecting a problem is the first step. A build test for these *before*
> > entering master would do this. It would still need fixing, but that is
> the
> > same we have right now. The difference really is where we detect the
> break
> > and if we have it sitting in master or not.
>
> ok - i wasn't thinking github's travis but more an actual osx machine
> plugged
> in somewhere we can remotely manage and use. :) i know travis will be very
> limited.
>
> > > when people report issues with specific builds/platforms then
> > > address them as needed.
> >
> > I can report the build being broken on osx, on aarch64, with the debug
> > profile enabled and also make check with cxx enabled right now. That are
> 4
> > things broken in master just what i see today.
>
> arm64 - known. and this is a bit of a surprise from luajit. it's
> technically
> been broken like this forever. it wasn't some change we made. somehow
> luajit
> started breaking at some point. the "we only allow you to use 27 bits out
> of 64
> of a pointer" thing.
>
> so this is not something CI would magically stop as changes to the
> dependencies
> started making things crash there. at least i have personally compiled
> using a
> luajit compiled myself on arm64 and it worked. this was a while back.
>
> cxx bindings. indeed these are a problem to the point where i just disable
> them
> in my build. i am not sure if this is good or bad though. it's kind of
> tired
> with the eo and bindings work and as things change multiple languages need
> to
> adapt.
>
> as for osx - i have no info as to what is going on there or why. :( i don't
> know even where the build breaks/logs etc. are. i do know
> build.enlightenment.org and that basically seems ok.
>
> > >> platform we support (besides Linux on x86_64) has only been tested at
> some
> > >> point in the past.
> > > i actually cross-build for windows maybe every few weeks or so, and
> freebsd
> > > maybe similarly too. i build on rpi3 (32bit) too regularly enough.
> > >
> > > we haven't tested on every linux distro either... so should we only
> claim a
> > > few distributions? i don't think we're being dishonest really.
> releases do
> > > get a lot more testing to see they work across os's. master may not
> get as
> > > much until a release cycle.
> >
> > Yeah, and as I had the pleasure of handling these releases I can tell you
> > that dealing with them so late in the cycle is a nightmare. Having a
> smoother
> > release cycle is actually one of my main motivations to have this early
> > 

Re: [E-devel] Current State and Future Direction of E/EFL

[Carsten Haitzler]

On Tue, 6 Mar 2018 13:43:09 +0100 Stefan Schmidt  said:

> Hello.
> 
> 
> On 03/06/2018 12:34 PM, Carsten Haitzler (The Rasterman) wrote:
> > On Tue, 6 Mar 2018 09:54:50 +0100 Stefan Schmidt 
> > said:
> >
> >> Hello.
> >>
> >>
> >> On 03/06/2018 07:44 AM, Carsten Haitzler (The Rasterman) wrote:
> >>> tbh platforms is an issue. windows is kind of big as setting up a
> >>> cross-build environment is a fair bit of work. setting up a windows vm
> >>> costs money to test (need licenses, or if you can scrounge one off another
> >>> pc you have/had). osx is worse in that you have to go buy hardware to run
> >>> osx to test.
> >>>
> >>> i think making it a requirement that every commit work on every platform
> >>> is not viable UNLESS:
> >>>
> >>> 1. a windows cross-compile env is available to developers (e.g. ssh into a
> >>> vm set up for this with clear documentation and scripts/tools to do the
> >>> builds. i have one set up for me at home).
> >>> 2. a vm with remote display that developers can use to run/test changes
> >>> easily.
> >>> 3. an actual osx box that developers can ssh into and compile and runa nd
> >>> test and remotely view/interact with like the windows vm.
> >>> 4. same for freebsd etc.
> >> We do not have this and I am pretty sure we never will (I can only hope the
> >> future proofs me wrong). Maybe we should be more honest and state that any
> > then i can't see how we could make it a requirement for committing that they
> > build/run there. 
> 
> Having them running a build is very different from having full remote shell
> access. E.g. osx build slaves available on TravisCi do not have any option to
> get shell access.
> 
> Detecting a problem is the first step. A build test for these *before*
> entering master would do this. It would still need fixing, but that is the
> same we have right now. The difference really is where we detect the break
> and if we have it sitting in master or not.

ok - i wasn't thinking github's travis but more an actual osx machine plugged
in somewhere we can remotely manage and use. :) i know travis will be very
limited.

> > when people report issues with specific builds/platforms then
> > address them as needed.
> 
> I can report the build being broken on osx, on aarch64, with the debug
> profile enabled and also make check with cxx enabled right now. That are 4
> things broken in master just what i see today.

arm64 - known. and this is a bit of a surprise from luajit. it's technically
been broken like this forever. it wasn't some change we made. somehow luajit
started breaking at some point. the "we only allow you to use 27 bits out of 64
of a pointer" thing.

so this is not something CI would magically stop as changes to the dependencies
started making things crash there. at least i have personally compiled using a
luajit compiled myself on arm64 and it worked. this was a while back.

cxx bindings. indeed these are a problem to the point where i just disable them
in my build. i am not sure if this is good or bad though. it's kind of tired
with the eo and bindings work and as things change multiple languages need to
adapt.

as for osx - i have no info as to what is going on there or why. :( i don't
know even where the build breaks/logs etc. are. i do know
build.enlightenment.org and that basically seems ok.

> >> platform we support (besides Linux on x86_64) has only been tested at some
> >> point in the past.
> > i actually cross-build for windows maybe every few weeks or so, and freebsd
> > maybe similarly too. i build on rpi3 (32bit) too regularly enough.
> >
> > we haven't tested on every linux distro either... so should we only claim a
> > few distributions? i don't think we're being dishonest really. releases do
> > get a lot more testing to see they work across os's. master may not get as
> > much until a release cycle.
> 
> Yeah, and as I had the pleasure of handling these releases I can tell you
> that dealing with them so late in the cycle is a nightmare. Having a smoother
> release cycle is actually one of my main motivations to have this early
> detection and avoidance of breaks.

indeed you are right - catching things early is far better. i really was more
about us being honest about the releases working on those platforms or not. :)
that's all. you are right there and i totally agree with that.

> >>> if a platform is on EASILY accessible and able to be EASILY worked with,
> >>> then making this a requirement to pass a build/test on that platform is
> >>> silly.
> >>>
> >>> developers have to be able to do incremental builds. not a "wait 10 mins
> >>> for the next build cycle to happen then wait another 10 for the log to
> >>> see if it worked this time". that's fine for reports. it's not fine for
> >>> actual development.
> >>>
> >>> if this infra existed and worked well, THEN i think it might be sane to
> >>> start adding "it has to pass a build test". then deciding on what
> >>> platforms 

Re: [E-devel] Current State and Future Direction of E/EFL

[The Rasterman]

On Tue, 6 Mar 2018 21:10:04 +0900 Christophe Sadoine  said:

> On 6 March 2018 at 20:34, Carsten Haitzler  wrote:
> > On Tue, 6 Mar 2018 09:54:50 +0100 Stefan Schmidt 
> > said:
> >
> > i really don't think we have a lot of break issues given size and
> > complexity. not build breaks anyway. right now if jenkins detects a build
> > break... how does a developer know? it can take hours before it detects
> > something. should they sit hitting reload on the browser for the next hour
> > hoping one of the builds going contains their commit? we have a broken
> > feedback cycle. jenkins should mail the mailing list with "commit X broke
> > build: log etc. link here". if a build breaks, jenkins should go back
> > commits until it finds a working one then report the commit that broke. at
> > least devs would get a notification. unless i they sit staring at
> > build.e.org with reloads or someone tells me, i just have no idea a build
> > would have broken.
> >
> > i think we've talked about this many times before... :)
> 
> I think in this case, you should probably open a task about it.
> The probability is low but someone might see this and decide to to
> help on it. (it is better than having no task)

that is true.

> We could also put in the wiki as wanted help or something.
> I think many people with admin knowledge have proposed to help on the ml.

right now that's really hard because our infra is very complex. still actually
waiting to hear about how thijngs are going between beber and john there.

> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[Stefan Schmidt]

Hello.


On 03/06/2018 12:34 PM, Carsten Haitzler (The Rasterman) wrote:
> On Tue, 6 Mar 2018 09:54:50 +0100 Stefan Schmidt  
> said:
>
>> Hello.
>>
>>
>> On 03/06/2018 07:44 AM, Carsten Haitzler (The Rasterman) wrote:
>>> tbh platforms is an issue. windows is kind of big as setting up a
>>> cross-build environment is a fair bit of work. setting up a windows vm
>>> costs money to test (need licenses, or if you can scrounge one off another
>>> pc you have/had). osx is worse in that you have to go buy hardware to run
>>> osx to test.
>>>
>>> i think making it a requirement that every commit work on every platform is
>>> not viable UNLESS:
>>>
>>> 1. a windows cross-compile env is available to developers (e.g. ssh into a
>>> vm set up for this with clear documentation and scripts/tools to do the
>>> builds. i have one set up for me at home).
>>> 2. a vm with remote display that developers can use to run/test changes
>>> easily.
>>> 3. an actual osx box that developers can ssh into and compile and runa nd
>>> test and remotely view/interact with like the windows vm.
>>> 4. same for freebsd etc.
>> We do not have this and I am pretty sure we never will (I can only hope the
>> future proofs me wrong). Maybe we should be more honest and state that any
> then i can't see how we could make it a requirement for committing that they
> build/run there. 

Having them running a build is very different from having full remote shell 
access. E.g. osx build slaves available on TravisCi do not have
any option to get shell access.

Detecting a problem is the first step. A build test for these *before* entering 
master would do this. It would still need fixing, but that
is the same we have right now. The difference really is where we detect the 
break and if we have it sitting in master or not.

> when people report issues with specific builds/platforms then
> address them as needed.

I can report the build being broken on osx, on aarch64, with the debug profile 
enabled and also make check with cxx enabled right now. That
are 4 things broken in master just what i see today.


>> platform we support (besides Linux on x86_64) has only been tested at some
>> point in the past.
> i actually cross-build for windows maybe every few weeks or so, and freebsd
> maybe similarly too. i build on rpi3 (32bit) too regularly enough.
>
> we haven't tested on every linux distro either... so should we only claim a 
> few
> distributions? i don't think we're being dishonest really. releases do  get a
> lot more testing to see they work across os's. master may not get as much
> until a release cycle.

Yeah, and as I had the pleasure of handling these releases I can tell you that 
dealing with them so late in the cycle is a nightmare.
Having a smoother release cycle is actually one of my main motivations to have 
this early detection and avoidance of breaks.

>>> if a platform is on EASILY accessible and able to be EASILY worked with,
>>> then making this a requirement to pass a build/test on that platform is
>>> silly.
>>>
>>> developers have to be able to do incremental builds. not a "wait 10 mins for
>>> the next build cycle to happen then wait another 10 for the log to see if it
>>> worked this time". that's fine for reports. it's not fine for actual
>>> development.
>>>
>>> if this infra existed and worked well, THEN i think it might be sane to
>>> start adding "it has to pass a build test". then deciding on what platforms
>>> have to be supported is another step. this has to be pain-free or as close
>>> as possible to that.
>> Good luck to finding somehow setting this all up and keep it working.
>> Definitely not me. :-) If I look back how badly the idea of having a windows
>> vm, a mac and a arm device hooked up to Jenkins turned out. I simply gave up
>> on that part.
> well then i just can't see us ever making it a requirement they build across
> these os's on every single commit if it can't be automated and made available
> to developers to actually look into and see what is working or not and why. :(
>
>>> not to mention... the test suites need to actually be reliable. i just found
>>> one of the ecore_file tests was grabbing a page from sf.net ... and now
>>> sf.net is refusing to servie it anymore thus test suites keep failing.
>>> tests that are fragile like this should not be some gatekeeper as to if
>>> code goes in or not.
>>>
>>> if a test suite is to be a gatekeeper it has to be done right. that means it
>>> has to work reliably on the build host. run very quickly. things like
>>> testing network fetches has to not rely on anything outside of that
>>> vm/box/chroot etc. etc. ... and we don't have that situation. this probably
>>> needs to be fixed first and foremost. not to mention just dealing with
>>> check and our tests to find what went wrong is a nightmare. finding the
>>> test that goes wrong in a sea of output ... is bad.
>>>
>>> so my take iis this: first work on the steps needed to get the 

Re: [E-devel] Current State and Future Direction of E/EFL

[Christophe Sadoine]

On 6 March 2018 at 20:34, Carsten Haitzler  wrote:
> On Tue, 6 Mar 2018 09:54:50 +0100 Stefan Schmidt  
> said:
>
> i really don't think we have a lot of break issues given size and complexity.
> not build breaks anyway. right now if jenkins detects a build break... how 
> does
> a developer know? it can take hours before it detects something. should they
> sit hitting reload on the browser for the next hour hoping one of the builds
> going contains their commit? we have a broken feedback cycle. jenkins should
> mail the mailing list with "commit X broke build: log etc. link here". if a
> build breaks, jenkins should go back commits until it finds a working one then
> report the commit that broke. at least devs would get a notification. unless i
> they sit staring at build.e.org with reloads or someone tells me, i just have
> no idea a build would have broken.
>
> i think we've talked about this many times before... :)

I think in this case, you should probably open a task about it.
The probability is low but someone might see this and decide to to
help on it. (it is better than having no task)
We could also put in the wiki as wanted help or something.
I think many people with admin knowledge have proposed to help on the ml.

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[The Rasterman]

On Tue, 6 Mar 2018 09:54:50 +0100 Stefan Schmidt  said:

> Hello.
> 
> 
> On 03/06/2018 07:44 AM, Carsten Haitzler (The Rasterman) wrote:
> > tbh platforms is an issue. windows is kind of big as setting up a
> > cross-build environment is a fair bit of work. setting up a windows vm
> > costs money to test (need licenses, or if you can scrounge one off another
> > pc you have/had). osx is worse in that you have to go buy hardware to run
> > osx to test.
> >
> > i think making it a requirement that every commit work on every platform is
> > not viable UNLESS:
> >
> > 1. a windows cross-compile env is available to developers (e.g. ssh into a
> > vm set up for this with clear documentation and scripts/tools to do the
> > builds. i have one set up for me at home).
> > 2. a vm with remote display that developers can use to run/test changes
> > easily.
> > 3. an actual osx box that developers can ssh into and compile and runa nd
> > test and remotely view/interact with like the windows vm.
> > 4. same for freebsd etc.
> 
> We do not have this and I am pretty sure we never will (I can only hope the
> future proofs me wrong). Maybe we should be more honest and state that any

then i can't see how we could make it a requirement for committing that they
build/run there. when people report issues with specific builds/platforms then
address them as needed.

> platform we support (besides Linux on x86_64) has only been tested at some
> point in the past.

i actually cross-build for windows maybe every few weeks or so, and freebsd
maybe similarly too. i build on rpi3 (32bit) too regularly enough.

we haven't tested on every linux distro either... so should we only claim a few
distributions? i don't think we're being dishonest really. releases do  get a
lot more testing to see they work across os's. master may not get as much
until a release cycle.

> > if a platform is on EASILY accessible and able to be EASILY worked with,
> > then making this a requirement to pass a build/test on that platform is
> > silly.
> >
> > developers have to be able to do incremental builds. not a "wait 10 mins for
> > the next build cycle to happen then wait another 10 for the log to see if it
> > worked this time". that's fine for reports. it's not fine for actual
> > development.
> >
> > if this infra existed and worked well, THEN i think it might be sane to
> > start adding "it has to pass a build test". then deciding on what platforms
> > have to be supported is another step. this has to be pain-free or as close
> > as possible to that.
> 
> Good luck to finding somehow setting this all up and keep it working.
> Definitely not me. :-) If I look back how badly the idea of having a windows
> vm, a mac and a arm device hooked up to Jenkins turned out. I simply gave up
> on that part.

well then i just can't see us ever making it a requirement they build across
these os's on every single commit if it can't be automated and made available
to developers to actually look into and see what is working or not and why. :(

> > not to mention... the test suites need to actually be reliable. i just found
> > one of the ecore_file tests was grabbing a page from sf.net ... and now
> > sf.net is refusing to servie it anymore thus test suites keep failing.
> > tests that are fragile like this should not be some gatekeeper as to if
> > code goes in or not.
> >
> > if a test suite is to be a gatekeeper it has to be done right. that means it
> > has to work reliably on the build host. run very quickly. things like
> > testing network fetches has to not rely on anything outside of that
> > vm/box/chroot etc. etc. ... and we don't have that situation. this probably
> > needs to be fixed first and foremost. not to mention just dealing with
> > check and our tests to find what went wrong is a nightmare. finding the
> > test that goes wrong in a sea of output ... is bad.
> >
> > so my take iis this: first work on the steps needed to get the final
> > outcome. better test infra. easier to write tests. easier to run and find
> > just the test that failed and run it by itself easily etc. it should be as
> > simple as:
> >
> > make check
> > ...
> > FAIL: src/tests/some_test_binary
> >
> > and to test it i just copy & paste that binary/line and nothing more and i
> > get exactly that one test that failed. i don't have to set env vars, read
> > src code to find the test name and so on. ... it currently is not this
> > simple by far. ;(
> 
> Yes, our tests are not as reliable as they should be.
> Yes, they would need to run in an controlled env.
> Yes, we might need so look at alternatives to libcheck.

i'm just saying these need to not randomly reject commits from devs when the
issue has nothing to do with what the dev is doing. it can't become an automated
requirement unless its reliably correct. :(

> But even with me agreeing to the three things above the core question stays
> still open.
> 
> Is this developer community willing to accept a 

Re: [E-devel] Current State and Future Direction of E/EFL

[Stefan Schmidt]

Hello.


On 03/06/2018 07:44 AM, Carsten Haitzler (The Rasterman) wrote:
> tbh platforms is an issue. windows is kind of big as setting up a cross-build
> environment is a fair bit of work. setting up a windows vm costs money to test
> (need licenses, or if you can scrounge one off another pc you have/had). osx 
> is
> worse in that you have to go buy hardware to run osx to test.
>
> i think making it a requirement that every commit work on every platform is 
> not
> viable UNLESS:
>
> 1. a windows cross-compile env is available to developers (e.g. ssh into a vm
> set up for this with clear documentation and scripts/tools to do the builds. i
> have one set up for me at home).
> 2. a vm with remote display that developers can use to run/test changes 
> easily.
> 3. an actual osx box that developers can ssh into and compile and runa nd test
> and remotely view/interact with like the windows vm.
> 4. same for freebsd etc.

We do not have this and I am pretty sure we never will (I can only hope the 
future proofs me wrong).
Maybe we should be more honest and state that any platform we support (besides 
Linux on x86_64) has only been tested at some point in the past.

>
> if a platform is on EASILY accessible and able to be EASILY worked with, then
> making this a requirement to pass a build/test on that platform is silly.
>
> developers have to be able to do incremental builds. not a "wait 10 mins for
> the next build cycle to happen then wait another 10 for the log to see if it
> worked this time". that's fine for reports. it's not fine for actual
> development.
>
> if this infra existed and worked well, THEN i think it might be sane to start
> adding "it has to pass a build test". then deciding on what platforms have to
> be supported is another step. this has to be pain-free or as close as possible
> to that.

Good luck to finding somehow setting this all up and keep it working. 
Definitely not me. :-)
If I look back how badly the idea of having a windows vm, a mac and a arm 
device hooked up to Jenkins turned out. I simply gave up on that part.

> not to mention... the test suites need to actually be reliable. i just found
> one of the ecore_file tests was grabbing a page from sf.net ... and now sf.net
> is refusing to servie it anymore thus test suites keep failing. tests that are
> fragile like this should not be some gatekeeper as to if code goes in or not.
>
> if a test suite is to be a gatekeeper it has to be done right. that means it
> has to work reliably on the build host. run very quickly. things like testing
> network fetches has to not rely on anything outside of that vm/box/chroot etc.
> etc. ... and we don't have that situation. this probably needs to be fixed
> first and foremost. not to mention just dealing with check and our tests to
> find what went wrong is a nightmare. finding the test that goes wrong in a sea
> of output ... is bad.
>
> so my take iis this: first work on the steps needed to get the final outcome.
> better test infra. easier to write tests. easier to run and find just the test
> that failed and run it by itself easily etc. it should be as simple as:
>
> make check
> ...
> FAIL: src/tests/some_test_binary
>
> and to test it i just copy & paste that binary/line and nothing more and i get
> exactly that one test that failed. i don't have to set env vars, read src code
> to find the test name and so on. ... it currently is not this simple by far. 
> ;(

Yes, our tests are not as reliable as they should be.
Yes, they would need to run in an controlled env.
Yes, we might need so look at alternatives to libcheck.

But even with me agreeing to the three things above the core question stays 
still open.

Is this developer community willing to accept a working test suite as a 
gatekeeper?
I don't think this is the case.

My personal motivation to work on QA and CI has gone down to zero over the 
years. It just feels like a Sisyphus task to look at master again
and again why it is broken now. Dig through the commits, bisect them, point 
fingers and constantly poke people top get it fixed. All long
after the problem have entered master.

I willing to admit that the approach I used to reach my goals might have been 
flawed and simply failed.
Someone else might want to pick up the slack on it.

regards
Stefan Schmidt




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[Knapp]

The very best open source project that I know of is Blender 3d. I changes
quickly, a great user community and dev community, grows like crazy, is
crushing the Pay versions of 3d software and is almost bug free. I would
take a look at how they do things.

On Tue, Mar 6, 2018 at 8:59 AM, Jérémy Zurcher  wrote:

> Rust uses github bot to post commits after testing thus ensure a good
> state master branch.
>
> https://github.com/barosl/homu
> https://www.youtube.com/watch?v=dIageYT0Vgg
>
>
> On Tuesday 06 March 2018  17:01, Simon Lees wrote :
> >
> >
> > On 06/03/18 15:50, jaquilina wrote:
> > > Hi simon,
> > >
> > > I think what you are talking about is gerrit code review. I know
> > > Libreoffice use it and for them I think you need to have 3 reviewers
> > > before the code is committed as well the code gets compiled and built
> as
> > > well to ensure it works.
> > >
> > > https://gerrit-review.googlesource.com/Documentation/intro-how-
> gerrit-works.html
> > >
> > >
> > > I am not sure if jenkins has a flow like what you are describing, but
> at
> > > least you have more control over the quality of whats committed.
> > >
> >
> > Yeah I'm suggesting that we don't need to go as far as needing 1-3 (or
> > any number of human reviewers) atleast for committers who have commit
> > access.
> >
> > I have contributed to projects via github that have an intergrated
> > jenkins (or something similar) bot that blocks the pull request being
> > accepted until atleast build tests have been done and other simple error
> > checking is done. So in a sense rather then jenkins running once a day
> > its running for every commit (or group) and giving direct feedback that
> > these commits will break the build so you should go and fix them, rather
> > then Stefan having to wait and check Jenkins then go bug people to fix
> > there work for breaking things.
> >
> > --
> >
> > Simon Lees (Simotek)http://simotek.net
> >
> > Emergency Update Team   keybase.io/simotek
> > SUSE Linux   Adelaide Australia, UTC+10:30
> > GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
> >
>
>
>
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
> --- Hell'O from Yverdoom
>
> Jérémy (jeyzu)
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>



-- 
Douglas E Knapp, MSAOM, LAc.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[Jérémy Zurcher]

Rust uses github bot to post commits after testing thus ensure a good state 
master branch.

https://github.com/barosl/homu
https://www.youtube.com/watch?v=dIageYT0Vgg


On Tuesday 06 March 2018  17:01, Simon Lees wrote :
> 
> 
> On 06/03/18 15:50, jaquilina wrote:
> > Hi simon,
> > 
> > I think what you are talking about is gerrit code review. I know
> > Libreoffice use it and for them I think you need to have 3 reviewers
> > before the code is committed as well the code gets compiled and built as
> > well to ensure it works.
> > 
> > https://gerrit-review.googlesource.com/Documentation/intro-how-gerrit-works.html
> > 
> > 
> > I am not sure if jenkins has a flow like what you are describing, but at
> > least you have more control over the quality of whats committed.
> > 
> 
> Yeah I'm suggesting that we don't need to go as far as needing 1-3 (or
> any number of human reviewers) atleast for committers who have commit
> access.
> 
> I have contributed to projects via github that have an intergrated
> jenkins (or something similar) bot that blocks the pull request being
> accepted until atleast build tests have been done and other simple error
> checking is done. So in a sense rather then jenkins running once a day
> its running for every commit (or group) and giving direct feedback that
> these commits will break the build so you should go and fix them, rather
> then Stefan having to wait and check Jenkins then go bug people to fix
> there work for breaking things.
> 
> -- 
> 
> Simon Lees (Simotek)http://simotek.net
> 
> Emergency Update Team   keybase.io/simotek
> SUSE Linux   Adelaide Australia, UTC+10:30
> GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
> 



> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot

> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--- Hell'O from Yverdoom

Jérémy (jeyzu)

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[The Rasterman]

On Tue, 6 Mar 2018 15:01:23 +1030 Simon Lees  said:

> 
> 
> On 06/03/18 12:51, Christophe Sadoine wrote:
> > Then, it would be great if there was a tool to detect an api/theme
> > break... and additions of api?
> > I think a theme break tool is possible and should be done, not sure
> > about the api.
> > 
> There are API break tools available, currently they struggle with
> differentiating between beta and release api automatically, currently
> you will get a number of interface related breaks.
> 
> > It would also be nice if at least one human reviewed what you want to
> > merge. You shouldn't trust anyone even yourself. Humans always make
> > mistakes.
> 
> Humans can make mistakes, but the problem here is its a bunch of extra
> work and delays, you may have to wait a few days for a human review,
> that and some people already have a backlog of stuff to review from
> people who haven't got commit rights yet. I don't think there is the
> manpower for this atm.

tbh platforms is an issue. windows is kind of big as setting up a cross-build
environment is a fair bit of work. setting up a windows vm costs money to test
(need licenses, or if you can scrounge one off another pc you have/had). osx is
worse in that you have to go buy hardware to run osx to test.

i think making it a requirement that every commit work on every platform is not
viable UNLESS:

1. a windows cross-compile env is available to developers (e.g. ssh into a vm
set up for this with clear documentation and scripts/tools to do the builds. i
have one set up for me at home).
2. a vm with remote display that developers can use to run/test changes easily.
3. an actual osx box that developers can ssh into and compile and runa nd test
and remotely view/interact with like the windows vm.
4. same for freebsd etc.

if a platform is on EASILY accessible and able to be EASILY worked with, then
making this a requirement to pass a build/test on that platform is silly.

developers have to be able to do incremental builds. not a "wait 10 mins for
the next build cycle to happen then wait another 10 for the log to see if it
worked this time". that's fine for reports. it's not fine for actual
development.

if this infra existed and worked well, THEN i think it might be sane to start
adding "it has to pass a build test". then deciding on what platforms have to
be supported is another step. this has to be pain-free or as close as possible
to that.

not to mention... the test suites need to actually be reliable. i just found
one of the ecore_file tests was grabbing a page from sf.net ... and now sf.net
is refusing to servie it anymore thus test suites keep failing. tests that are
fragile like this should not be some gatekeeper as to if code goes in or not.

if a test suite is to be a gatekeeper it has to be done right. that means it
has to work reliably on the build host. run very quickly. things like testing
network fetches has to not rely on anything outside of that vm/box/chroot etc.
etc. ... and we don't have that situation. this probably needs to be fixed
first and foremost. not to mention just dealing with check and our tests to
find what went wrong is a nightmare. finding the test that goes wrong in a sea
of output ... is bad.

so my take iis this: first work on the steps needed to get the final outcome.
better test infra. easier to write tests. easier to run and find just the test
that failed and run it by itself easily etc. it should be as simple as:

make check
...
FAIL: src/tests/some_test_binary

and to test it i just copy & paste that binary/line and nothing more and i get
exactly that one test that failed. i don't have to set env vars, read src code
to find the test name and so on. ... it currently is not this simple by far. ;(

> > Communication:
> > Discussion can happen on irc/mailing list, but decisions should not.
> > There should be only one place where decisions are made. And it should
> > be phab.
> > The mailing list is good for questions/discussions but it is very easy
> > to forget a mail. A ticket has a status and it stays there until you
> > resolve it.
> > Decisions should have a clear status and should not be dangling like a
> > mail thread could be.
> > And you would also have proof there was a discussion and how a
> > decision was made.
> > Someone joining the project would have a hard time searching though
> > the mailing list/irc logs to find information about a specific issue.
> > So I think all important decisions should be in one easy
> > searchable/referable place. (it doesn't have to be phab but it is what
> > we have now)
> 
> As I said on IRC I don't think phab will work efficiently it will be
> more effort getting the right group of people subscribed to the ticket
> then the amount of benefit we gain, there will always be someone who
> didn't get subscribed for some reason, and maybe the scope will broaden
> slightly and people who didn't think they would care might end up caring
> and miss the 

Re: [E-devel] Current State and Future Direction of E/EFL

[Simon Lees]

On 06/03/18 15:50, jaquilina wrote:
> Hi simon,
> 
> I think what you are talking about is gerrit code review. I know
> Libreoffice use it and for them I think you need to have 3 reviewers
> before the code is committed as well the code gets compiled and built as
> well to ensure it works.
> 
> https://gerrit-review.googlesource.com/Documentation/intro-how-gerrit-works.html
> 
> 
> I am not sure if jenkins has a flow like what you are describing, but at
> least you have more control over the quality of whats committed.
> 

Yeah I'm suggesting that we don't need to go as far as needing 1-3 (or
any number of human reviewers) atleast for committers who have commit
access.

I have contributed to projects via github that have an intergrated
jenkins (or something similar) bot that blocks the pull request being
accepted until atleast build tests have been done and other simple error
checking is done. So in a sense rather then jenkins running once a day
its running for every commit (or group) and giving direct feedback that
these commits will break the build so you should go and fix them, rather
then Stefan having to wait and check Jenkins then go bug people to fix
there work for breaking things.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[jaquilina]

Hi simon,

I think what you are talking about is gerrit code review. I know 
Libreoffice use it and for them I think you need to have 3 reviewers 
before the code is committed as well the code gets compiled and built as 
well to ensure it works.


https://gerrit-review.googlesource.com/Documentation/intro-how-gerrit-works.html

I am not sure if jenkins has a flow like what you are describing, but at 
least you have more control over the quality of whats committed.


On 2018-03-06 00:25, Simon Lees wrote:

On 06/03/18 03:56, Stefan Schmidt wrote:

Hello.

I snipped away a lot of text here to make it easier to follow. If you 
feel I quoted out of context let me know.


On 03/05/2018 12:57 PM, Carsten Haitzler (The Rasterman) wrote:

1. Code reverting.

I take API breaks seriously. An API break shouldn't happen. It should 
get
caught as soon as possible if it does before anything is built on top 
and that
may mean reverting work that created a break ASAP if that is the most 
efficient
path. More generically here is the order of bad things for git 
master:


#1. Builds break.
#2. Building against X breaks (e.g. building terminology or e against 
efl).
#3. The app or lib just crashes or doesn't work in regular usage 
leaving people

with an unusable environment
#4. API/ABI breaks (code, data files, theme etc. - we only do these 
with a lot

of careful thought, discussion and weighing up of the pros and cons).
#5. A new design or idea/direction that then will be built on top of 
and if

#this design/idea has big issues.

git master should be "usable day to day" for developers and "advanced 
users".
It will get bugs and issues but they should be resolved ASAP and 
avoided as

much as possible.


But at least in my reality this is just not happening. A lot of things 
stay broken until I poke people to fix them, bisect them or push to

get a release out.

Right now there is at least the osx build broken for a while and 
edje_cc does run when build on a aarch64 system.
These are simply not the development systems we use. One could say 
that everything not x86_64 and Linux will stay undetected.
Once detected such things are often to hard to revert by the pure 
amount of commits that hit master in between.


People who do the work get to call the shots. It is of course 
affected by
history of contribution, knowledge of the project and what it 
interacts with
etc. etc. ... I do not think having some committee of project 
managers is going
to make anything better. I think if anything it just makes things 
worse by
adding overhead. If we made everything code-reviewed ala phab, I 
think it'd be
far worse. development would dwindle and die. I absolutely know that 
I'd
personally just stop if I had to put every commit I do through 
review. Review
is a tool for developers who are not trusted yet or who need to learn 
or who
are not involved deeply enough to be held responsible for their work. 
Then I

believe the cost is justified.


If you see that the majority of breaks actual comes from developers 
with commit access this is partly amusing and partly sad.


I my opinion we should actually be happy if we could slow down the 
amount of commits. Way to often I see rushed in commits which get
followed up by n more commits to fix things that could have been 
spotted during QA and review before letting it in master.


I realize this is something fundamentally disagree on. You want all 
commits in master as soon as possible so other can actually use it.
I only want a stable and tested subset of changes being put in master 
after the code maybe has gone through some iterations.


The world is not going to stop spinning just because a commit gets 
into master a day later.


The way we use CI is a toothless tiger. Whatever it detects (and it 
does not detect as much as it should, actually) nobody cares if I not
personally come after the person. Given the little impact it can have 
this way my interest does dwindle and die to push it forward. I am
fighting this area alone and no interest has been shown from others 
(which is fair enough), which basically means it will drop dead if I
stop looking after it. Maybe someone would pick it up again, but 
future telling is not my string side.



Which does summarize my stand point as:
1) ALL commits should go through review and automated QA
2) New things can easily be tested by using branches, no need to have 
it in master for this.
3) Slow down of commits  by taking your time and addressing found 
issues in new iterations instead of fix up later on in master.

4) QA, test cases, etc should be the objective of all devs.

So yeah, very far a way from what you think as the best workflow. 
Well, we agree that QA, test cases and review is needed but not at 
what

point in the workflow. :-)

regards
Stefan Schmidt



Morning all,

Maybe a half way point here is if every commit (or maybe group of
commits) had to go through a simple review where jenkins or some other
bot checks that the commits 

Re: [E-devel] Current State and Future Direction of E/EFL

[Simon Lees]

On 06/03/18 12:51, Christophe Sadoine wrote:
> Then, it would be great if there was a tool to detect an api/theme
> break... and additions of api?
> I think a theme break tool is possible and should be done, not sure
> about the api.
> 
There are API break tools available, currently they struggle with
differentiating between beta and release api automatically, currently
you will get a number of interface related breaks.

> It would also be nice if at least one human reviewed what you want to
> merge. You shouldn't trust anyone even yourself. Humans always make
> mistakes.

Humans can make mistakes, but the problem here is its a bunch of extra
work and delays, you may have to wait a few days for a human review,
that and some people already have a backlog of stuff to review from
people who haven't got commit rights yet. I don't think there is the
manpower for this atm.

> 
> Communication:
> Discussion can happen on irc/mailing list, but decisions should not.
> There should be only one place where decisions are made. And it should
> be phab.
> The mailing list is good for questions/discussions but it is very easy
> to forget a mail. A ticket has a status and it stays there until you
> resolve it.
> Decisions should have a clear status and should not be dangling like a
> mail thread could be.
> And you would also have proof there was a discussion and how a
> decision was made.
> Someone joining the project would have a hard time searching though
> the mailing list/irc logs to find information about a specific issue.
> So I think all important decisions should be in one easy
> searchable/referable place. (it doesn't have to be phab but it is what
> we have now)

As I said on IRC I don't think phab will work efficiently it will be
more effort getting the right group of people subscribed to the ticket
then the amount of benefit we gain, there will always be someone who
didn't get subscribed for some reason, and maybe the scope will broaden
slightly and people who didn't think they would care might end up caring
and miss the discussion.

Really all we need is the original Author to summarize the discussion in
one email and add it to a wiki / roadmap thingo. If the main person
working on the feature isn't willing to do that then maybe a project
manager can.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[Christophe Sadoine]

On 6 March 2018 at 10:07, William L. Thomson Jr.
 wrote:
> On Tue, 6 Mar 2018 10:55:36 +1030
> Simon Lees  wrote:
>
>> On 06/03/18 03:56, Stefan Schmidt wrote:
>> > Hello.
>> >
>> > I snipped away a lot of text here to make it easier to follow. If
>> > you feel I quoted out of context let me know.
>> >
>> > On 03/05/2018 12:57 PM, Carsten Haitzler (The Rasterman) wrote:
>> >> 1. Code reverting.
>> >>
>> >> I take API breaks seriously. An API break shouldn't happen. It
>> >> should get caught as soon as possible if it does before anything
>> >> is built on top and that may mean reverting work that created a
>> >> break ASAP if that is the most efficient path. More generically
>> >> here is the order of bad things for git master:
>> >>
>> >> #1. Builds break.
>> >> #2. Building against X breaks (e.g. building terminology or e
>> >> against efl). #3. The app or lib just crashes or doesn't work in
>> >> regular usage leaving people with an unusable environment
>> >> #4. API/ABI breaks (code, data files, theme etc. - we only do
>> >> these with a lot of careful thought, discussion and weighing up of
>> >> the pros and cons). #5. A new design or idea/direction that then
>> >> will be built on top of and if #this design/idea has big issues.
>> >>
>> >> git master should be "usable day to day" for developers and
>> >> "advanced users". It will get bugs and issues but they should be
>> >> resolved ASAP and avoided as much as possible.
>> >
>> > But at least in my reality this is just not happening. A lot of
>> > things stay broken until I poke people to fix them, bisect them or
>> > push to get a release out.
>> >
>> > Right now there is at least the osx build broken for a while and
>> > edje_cc does run when build on a aarch64 system. These are simply
>> > not the development systems we use. One could say that everything
>> > not x86_64 and Linux will stay undetected. Once detected such
>> > things are often to hard to revert by the pure amount of commits
>> > that hit master in between.
>> >> People who do the work get to call the shots. It is of course
>> >> affected by history of contribution, knowledge of the project and
>> >> what it interacts with etc. etc. ... I do not think having some
>> >> committee of project managers is going to make anything better. I
>> >> think if anything it just makes things worse by adding overhead.
>> >> If we made everything code-reviewed ala phab, I think it'd be far
>> >> worse. development would dwindle and die. I absolutely know that
>> >> I'd personally just stop if I had to put every commit I do through
>> >> review. Review is a tool for developers who are not trusted yet or
>> >> who need to learn or who are not involved deeply enough to be held
>> >> responsible for their work. Then I believe the cost is justified.
>> >
>> > If you see that the majority of breaks actual comes from developers
>> > with commit access this is partly amusing and partly sad.
>> >
>> > I my opinion we should actually be happy if we could slow down the
>> > amount of commits. Way to often I see rushed in commits which get
>> > followed up by n more commits to fix things that could have been
>> > spotted during QA and review before letting it in master.
>> >
>> > I realize this is something fundamentally disagree on. You want all
>> > commits in master as soon as possible so other can actually use it.
>> > I only want a stable and tested subset of changes being put in
>> > master after the code maybe has gone through some iterations.
>> >
>> > The world is not going to stop spinning just because a commit gets
>> > into master a day later.
>> >
>> > The way we use CI is a toothless tiger. Whatever it detects (and it
>> > does not detect as much as it should, actually) nobody cares if I
>> > not personally come after the person. Given the little impact it
>> > can have this way my interest does dwindle and die to push it
>> > forward. I am fighting this area alone and no interest has been
>> > shown from others (which is fair enough), which basically means it
>> > will drop dead if I stop looking after it. Maybe someone would pick
>> > it up again, but future telling is not my string side.
>> >
>> >
>> > Which does summarize my stand point as:
>> > 1) ALL commits should go through review and automated QA
>> > 2) New things can easily be tested by using branches, no need to
>> > have it in master for this. 3) Slow down of commits  by taking your
>> > time and addressing found issues in new iterations instead of fix
>> > up later on in master. 4) QA, test cases, etc should be the
>> > objective of all devs.
>> >
>> > So yeah, very far a way from what you think as the best workflow.
>> > Well, we agree that QA, test cases and review is needed but not at
>> > what point in the workflow. :-)
>> >
>> > regards
>> > Stefan Schmidt
>> >
>>
>> Morning all,
>>
>> Maybe a half way point here is if every commit (or maybe group of
>> commits) had to go through a 

Re: [E-devel] Current State and Future Direction of E/EFL

[William L. Thomson Jr.]

On Tue, 6 Mar 2018 10:55:36 +1030
Simon Lees  wrote:

> On 06/03/18 03:56, Stefan Schmidt wrote:
> > Hello.
> > 
> > I snipped away a lot of text here to make it easier to follow. If
> > you feel I quoted out of context let me know.
> > 
> > On 03/05/2018 12:57 PM, Carsten Haitzler (The Rasterman) wrote:  
> >> 1. Code reverting.
> >>
> >> I take API breaks seriously. An API break shouldn't happen. It
> >> should get caught as soon as possible if it does before anything
> >> is built on top and that may mean reverting work that created a
> >> break ASAP if that is the most efficient path. More generically
> >> here is the order of bad things for git master:
> >>
> >> #1. Builds break.
> >> #2. Building against X breaks (e.g. building terminology or e
> >> against efl). #3. The app or lib just crashes or doesn't work in
> >> regular usage leaving people with an unusable environment
> >> #4. API/ABI breaks (code, data files, theme etc. - we only do
> >> these with a lot of careful thought, discussion and weighing up of
> >> the pros and cons). #5. A new design or idea/direction that then
> >> will be built on top of and if #this design/idea has big issues.
> >>
> >> git master should be "usable day to day" for developers and
> >> "advanced users". It will get bugs and issues but they should be
> >> resolved ASAP and avoided as much as possible.   
> > 
> > But at least in my reality this is just not happening. A lot of
> > things stay broken until I poke people to fix them, bisect them or
> > push to get a release out.
> > 
> > Right now there is at least the osx build broken for a while and
> > edje_cc does run when build on a aarch64 system. These are simply
> > not the development systems we use. One could say that everything
> > not x86_64 and Linux will stay undetected. Once detected such
> > things are often to hard to revert by the pure amount of commits
> > that hit master in between. 
> >> People who do the work get to call the shots. It is of course
> >> affected by history of contribution, knowledge of the project and
> >> what it interacts with etc. etc. ... I do not think having some
> >> committee of project managers is going to make anything better. I
> >> think if anything it just makes things worse by adding overhead.
> >> If we made everything code-reviewed ala phab, I think it'd be far
> >> worse. development would dwindle and die. I absolutely know that
> >> I'd personally just stop if I had to put every commit I do through
> >> review. Review is a tool for developers who are not trusted yet or
> >> who need to learn or who are not involved deeply enough to be held
> >> responsible for their work. Then I believe the cost is justified.  
> > 
> > If you see that the majority of breaks actual comes from developers
> > with commit access this is partly amusing and partly sad.
> > 
> > I my opinion we should actually be happy if we could slow down the
> > amount of commits. Way to often I see rushed in commits which get
> > followed up by n more commits to fix things that could have been
> > spotted during QA and review before letting it in master.
> > 
> > I realize this is something fundamentally disagree on. You want all
> > commits in master as soon as possible so other can actually use it.
> > I only want a stable and tested subset of changes being put in
> > master after the code maybe has gone through some iterations.
> > 
> > The world is not going to stop spinning just because a commit gets
> > into master a day later.
> > 
> > The way we use CI is a toothless tiger. Whatever it detects (and it
> > does not detect as much as it should, actually) nobody cares if I
> > not personally come after the person. Given the little impact it
> > can have this way my interest does dwindle and die to push it
> > forward. I am fighting this area alone and no interest has been
> > shown from others (which is fair enough), which basically means it
> > will drop dead if I stop looking after it. Maybe someone would pick
> > it up again, but future telling is not my string side.
> > 
> > 
> > Which does summarize my stand point as:
> > 1) ALL commits should go through review and automated QA
> > 2) New things can easily be tested by using branches, no need to
> > have it in master for this. 3) Slow down of commits  by taking your
> > time and addressing found issues in new iterations instead of fix
> > up later on in master. 4) QA, test cases, etc should be the
> > objective of all devs.
> > 
> > So yeah, very far a way from what you think as the best workflow.
> > Well, we agree that QA, test cases and review is needed but not at
> > what point in the workflow. :-)
> > 
> > regards
> > Stefan Schmidt
> >   
> 
> Morning all,
> 
> Maybe a half way point here is if every commit (or maybe group of
> commits) had to go through a simple review where jenkins or some other
> bot checks that the commits still compile etc. Once the automated
> review has finished anyone with commit access 

Re: [E-devel] Current State and Future Direction of E/EFL

[Simon Lees]

On 06/03/18 03:56, Stefan Schmidt wrote:
> Hello.
> 
> I snipped away a lot of text here to make it easier to follow. If you feel I 
> quoted out of context let me know.
> 
> On 03/05/2018 12:57 PM, Carsten Haitzler (The Rasterman) wrote:
>> 1. Code reverting.
>>
>> I take API breaks seriously. An API break shouldn't happen. It should get
>> caught as soon as possible if it does before anything is built on top and 
>> that
>> may mean reverting work that created a break ASAP if that is the most 
>> efficient
>> path. More generically here is the order of bad things for git master:
>>
>> #1. Builds break.
>> #2. Building against X breaks (e.g. building terminology or e against efl).
>> #3. The app or lib just crashes or doesn't work in regular usage leaving 
>> people
>> with an unusable environment
>> #4. API/ABI breaks (code, data files, theme etc. - we only do these with a 
>> lot
>> of careful thought, discussion and weighing up of the pros and cons).
>> #5. A new design or idea/direction that then will be built on top of and if
>> #this design/idea has big issues.
>>
>> git master should be "usable day to day" for developers and "advanced users".
>> It will get bugs and issues but they should be resolved ASAP and avoided as
>> much as possible. 
> 
> But at least in my reality this is just not happening. A lot of things stay 
> broken until I poke people to fix them, bisect them or push to
> get a release out.
> 
> Right now there is at least the osx build broken for a while and edje_cc does 
> run when build on a aarch64 system.
> These are simply not the development systems we use. One could say that 
> everything not x86_64 and Linux will stay undetected.
> Once detected such things are often to hard to revert by the pure amount of 
> commits that hit master in between.
> 
>> People who do the work get to call the shots. It is of course affected by
>> history of contribution, knowledge of the project and what it interacts with
>> etc. etc. ... I do not think having some committee of project managers is 
>> going
>> to make anything better. I think if anything it just makes things worse by
>> adding overhead. If we made everything code-reviewed ala phab, I think it'd 
>> be
>> far worse. development would dwindle and die. I absolutely know that I'd
>> personally just stop if I had to put every commit I do through review. Review
>> is a tool for developers who are not trusted yet or who need to learn or who
>> are not involved deeply enough to be held responsible for their work. Then I
>> believe the cost is justified.
> 
> If you see that the majority of breaks actual comes from developers with 
> commit access this is partly amusing and partly sad.
> 
> I my opinion we should actually be happy if we could slow down the amount of 
> commits. Way to often I see rushed in commits which get
> followed up by n more commits to fix things that could have been spotted 
> during QA and review before letting it in master.
> 
> I realize this is something fundamentally disagree on. You want all commits 
> in master as soon as possible so other can actually use it.
> I only want a stable and tested subset of changes being put in master after 
> the code maybe has gone through some iterations.
> 
> The world is not going to stop spinning just because a commit gets into 
> master a day later.
> 
> The way we use CI is a toothless tiger. Whatever it detects (and it does not 
> detect as much as it should, actually) nobody cares if I not
> personally come after the person. Given the little impact it can have this 
> way my interest does dwindle and die to push it forward. I am
> fighting this area alone and no interest has been shown from others (which is 
> fair enough), which basically means it will drop dead if I
> stop looking after it. Maybe someone would pick it up again, but future 
> telling is not my string side.
> 
> 
> Which does summarize my stand point as:
> 1) ALL commits should go through review and automated QA
> 2) New things can easily be tested by using branches, no need to have it in 
> master for this.
> 3) Slow down of commits  by taking your time and addressing found issues in 
> new iterations instead of fix up later on in master.
> 4) QA, test cases, etc should be the objective of all devs.
> 
> So yeah, very far a way from what you think as the best workflow. Well, we 
> agree that QA, test cases and review is needed but not at what
> point in the workflow. :-)
> 
> regards
> Stefan Schmidt
> 

Morning all,

Maybe a half way point here is if every commit (or maybe group of
commits) had to go through a simple review where jenkins or some other
bot checks that the commits still compile etc. Once the automated review
has finished anyone with commit access (including the author) could
accept the review and commit the code. This way people will be notified
about really dumb mistakes but if Jenkins is broken for other reasons
people will still be able to commit etc. Down the track maybe there 

Re: [E-devel] Current State and Future Direction of E/EFL

[Simon Lees]

On Tuesday, 6 March 2018 02:18:02 ACDT, William L. Thomson Jr. wrote:
> On Mon, 5 Mar 2018 20:57:17 +0900
> Carsten Haitzler (The Rasterman)  wrote:
>>
>> People who do the work get to call the shots.
>> If we made everything code-reviewed ala phab, I think it'd be far
>> worse.
>> development would dwindle and die.
>
> Yes! Just look at Gentoo for proof. QA is killing it slowly
>

Conversely look at openSUSE Tumbleweed where really good automated QA is
making it flourish.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE Linux   Adelaide Australia, UTC+10:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B




signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Current State and Future Direction of E/EFL

[Stephen Houston]

I've been pondering writing this email for some time now.  As others have
mentioned - our community has been trending downwards.  Work from Samsung
aside, and those that use E/EFL through Samsung's work -- The developer and
user base has been getting smaller and smaller.  That is regular members of
the community contributing work and regular members of the community using
E/EFL as an option for their linux desktops/laptops.  The number of
arguments that are now occurring among those of us still left has been
rising.  The current state of the project is such that dissenting
opinions/code are not allowed and get reverted or overruled in discussions,
this likely directly related to our structure and our lack of documented
road maps, goals, and plans.

This project has been around for decades.  Many of our developers have
spent blood sweat and tears adding code to this project and working on it.
Many of our developers have poured just as much code into this project as
the next has.  The project has become so much more than just one person's
vision or one person's opinion.  As it is the project is really not set up
to handle this.  There is no clear decision tree. No clear path for what is
and is not accepted.  No clear direction of what the goal is to
accomplish.  This has been leading to so much animosity, and frankly a
stagnant project that is dwindling instead of growing.  Sure plenty of code
gets written, rewritten, or worked on, but the majority of it is not seen
in the product.  It is working on rewrites for performance, bug fixes for
corner cases, implementing new apis that are not used anywhere, etc...,
etc..., and all of that is fine and necessary, but other very important
work gets left out.  Take Enlightenment from late 2000s - now.  A lot of
work has been done.  Compositing, Wayland, e_widgets -> Elm, etc..., etc...
But in the last say 10 years... You could pull up versions of Enlightenment
and without a technical sense or from someone following the project, you
would think it is the same... Same menus, same settings, same gadgets, same
shelves, same themes, same look, same interface, etc..., etc...  EFL
consistently is worked on and sure is doing really cool new stuff like
Interfaces... but does it matter if no one is even using it? (Samsung
aside).  We have 3 or 4 applications that we have always had and there
seems to be very little growth.  We have people who have decided to fork
off work or go their own route... see Moksha, Fyne, etc... due to problems
within our community or our vision.  This is difficult for a community like
ours to overcome when and if we lose users when we already have few to
begin with.

I believe it is time that we as a community revisit ourselves and consider
restructuring.  Projects can't just be YOLO with no clear laid out
direction or plan.  Community based projects can't succeed in an
environment where there is seemingly no project management and discussions
only happen when a feature or change is pushed and one person overrides
it.  This project needs to have more project management.  Goals need to be
laid out.  Road maps need to be developed.  Release plans need to be
created and adhered to.  This project needs structure, and frankly this
structure needs to come from more than just one person.  There needs to be
a team of project managers who determine whether changes, features, or
proposal are accepted, not only one person.  There needs to be a team of
project managers determining the direction of the project and developing
road maps for it.  This team needs to be represented of our developers, our
corporate interests, and our community user base.  Having a team will keep
from personal bias, desires, or egos getting in the way.  Once we have some
structure in place, it will become much easier for us to band together to
work towards meeting our goals.

As it is - It really feels like if we continue on the path we are on, the
future is not bright at all.  If we treat this project's goals as whatever
meets the desires or ideas of one or two, that is what it will eventually
become - a project used by one or two.  I'm pleading with everyone to put
egos aside, put personal ambitions, personal goals, and related aside and
begin working as a team.  The current climate will improve dramatically if
that happens.

Before you get upset and respond angrily at this email, remember I love
this project and have worked on it for over 15 years and developed
relationships with most of you along the way, and so I am in no way sending
this email with ill intent or to anger or hurt anyone.  I'm sending this
email in hopes that we can only improve as we move forward.

Thanks,
Stephen
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list

Re: [E-devel] Current State and Future Direction of E/EFL

[Stefan Schmidt]

Hello.

I snipped away a lot of text here to make it easier to follow. If you feel I 
quoted out of context let me know.

On 03/05/2018 12:57 PM, Carsten Haitzler (The Rasterman) wrote:
> 1. Code reverting.
>
> I take API breaks seriously. An API break shouldn't happen. It should get
> caught as soon as possible if it does before anything is built on top and that
> may mean reverting work that created a break ASAP if that is the most 
> efficient
> path. More generically here is the order of bad things for git master:
>
> #1. Builds break.
> #2. Building against X breaks (e.g. building terminology or e against efl).
> #3. The app or lib just crashes or doesn't work in regular usage leaving 
> people
> with an unusable environment
> #4. API/ABI breaks (code, data files, theme etc. - we only do these with a lot
> of careful thought, discussion and weighing up of the pros and cons).
> #5. A new design or idea/direction that then will be built on top of and if
> #this design/idea has big issues.
>
> git master should be "usable day to day" for developers and "advanced users".
> It will get bugs and issues but they should be resolved ASAP and avoided as
> much as possible. 

But at least in my reality this is just not happening. A lot of things stay 
broken until I poke people to fix them, bisect them or push to
get a release out.

Right now there is at least the osx build broken for a while and edje_cc does 
run when build on a aarch64 system.
These are simply not the development systems we use. One could say that 
everything not x86_64 and Linux will stay undetected.
Once detected such things are often to hard to revert by the pure amount of 
commits that hit master in between.

> People who do the work get to call the shots. It is of course affected by
> history of contribution, knowledge of the project and what it interacts with
> etc. etc. ... I do not think having some committee of project managers is 
> going
> to make anything better. I think if anything it just makes things worse by
> adding overhead. If we made everything code-reviewed ala phab, I think it'd be
> far worse. development would dwindle and die. I absolutely know that I'd
> personally just stop if I had to put every commit I do through review. Review
> is a tool for developers who are not trusted yet or who need to learn or who
> are not involved deeply enough to be held responsible for their work. Then I
> believe the cost is justified.

If you see that the majority of breaks actual comes from developers with commit 
access this is partly amusing and partly sad.

I my opinion we should actually be happy if we could slow down the amount of 
commits. Way to often I see rushed in commits which get
followed up by n more commits to fix things that could have been spotted during 
QA and review before letting it in master.

I realize this is something fundamentally disagree on. You want all commits in 
master as soon as possible so other can actually use it.
I only want a stable and tested subset of changes being put in master after the 
code maybe has gone through some iterations.

The world is not going to stop spinning just because a commit gets into master 
a day later.

The way we use CI is a toothless tiger. Whatever it detects (and it does not 
detect as much as it should, actually) nobody cares if I not
personally come after the person. Given the little impact it can have this way 
my interest does dwindle and die to push it forward. I am
fighting this area alone and no interest has been shown from others (which is 
fair enough), which basically means it will drop dead if I
stop looking after it. Maybe someone would pick it up again, but future telling 
is not my string side.


Which does summarize my stand point as:
1) ALL commits should go through review and automated QA
2) New things can easily be tested by using branches, no need to have it in 
master for this.
3) Slow down of commits  by taking your time and addressing found issues in new 
iterations instead of fix up later on in master.
4) QA, test cases, etc should be the objective of all devs.

So yeah, very far a way from what you think as the best workflow. Well, we 
agree that QA, test cases and review is needed but not at what
point in the workflow. :-)

regards
Stefan Schmidt

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[William L. Thomson Jr.]

On Mon, 5 Mar 2018 20:57:17 +0900
Carsten Haitzler (The Rasterman)  wrote:
>
> People who do the work get to call the shots.

That is a fine balance. I am not really a fan of say ignoring users
wishes or others because of who is doing the work and doing it their
way vs whats best for all with others input beyond their own opinion.

> If we made everything code-reviewed ala phab, I think it'd be far
> worse.

This is true, it happens all the time with Gentoo. One of your own 
Bertrand Jacquin has been stuck in such endless review... 68 comments
https://github.com/gentoo/gentoo/pull/5832

I have been there myself with 1 line change, and no longer bother
https://github.com/gentoo/gentoo/pull/101

> development would dwindle and die.

Yes! Just look at Gentoo for proof. QA is killing it slowly

>  I absolutely know that I'd  personally just stop if I had to put
> every commit I do through review. 

I stopped, as have others. Your sentiments are shared by many others.

> I don't think we need STRUCTURE. I think we need communication. I
> think people have become awfully bad at this. Here is what people
> need to do IMHO.

I agree on communication, but I also believe structure is important to
organizing any group of people to work together on anything.

> 4. Writing down goals

Why I started these pages I can no longer edit.
https://phab.enlightenment.org/w/efl_apps_todo/
https://phab.enlightenment.org/w/elm_code/syntax_support/

> f) I still think E should have the filemanager built in. It's far
> too useful to not do this. It's pretty much necessary for icons on
> the desktop and consistent FM UI. If its done in-process or outside
> is another matter, but it has to be deeply integrated. 

In brief, I am not a big fan of such. Seems like a Windows concept
where Explorer ( not Internet Explorer) is deeply integrated. Pretty
much any issue I have with E that is non-recoverable comes from EFM.

Maybe a stand alone widget/app could render Icons on desktop and be
creative there. 3d icons, animated, etc. Integrate say a screen saver
and live desktop, so icons move to as screen saver and for aesthetics.
Like having an animated or live background image.

> i'm sure many people have their own ideas and priorities on what they
> think is important/right. i'm just dropping the above out there. if
> you want direction and can't submit your own instead, then look at
> the above and expand on it as logical.

Maybe a start is creating more like ToDo or Wish List type pages under
Phab to identify various interests and goals of each. Or even a simple
EFL goals or E goals page.

-- 
William L. Thomson Jr.


pgpFakgD9N0m4.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[The Rasterman]

On Thu, 01 Mar 2018 19:28:15 + Stephen Houston  said:

Hi!

So I was busy with some work and didn't want jump into this in the middle.

I also allowed for some feedback from others too. I've read over some of these,
and I actually have little to say about the feedback other than "Yup. I pretty
much am with you there", so I won't reply to those mails, but I did read and
digest them.

So, response time:

I'm not going to go into history and past, point fingers etc. etc. . I'm going
to address how things should be and what my opinions are.

1. Code reverting.

I take API breaks seriously. An API break shouldn't happen. It should get
caught as soon as possible if it does before anything is built on top and that
may mean reverting work that created a break ASAP if that is the most efficient
path. More generically here is the order of bad things for git master:

#1. Builds break.
#2. Building against X breaks (e.g. building terminology or e against efl).
#3. The app or lib just crashes or doesn't work in regular usage leaving people
with an unusable environment
#4. API/ABI breaks (code, data files, theme etc. - we only do these with a lot
of careful thought, discussion and weighing up of the pros and cons).
#5. A new design or idea/direction that then will be built on top of and if
#this design/idea has big issues.

git master should be "usable day to day" for developers and "advanced users".
It will get bugs and issues but they should be resolved ASAP and avoided as
much as possible. The longer bad code stays in, the harder it is to revert or
fix as more and more changes are built on top. Time is of the essence.

If someone wants to make major changes that change direction, design, etc. etc.
then discussing first is a good idea, and realising that it may not be right or
perfect and may need to be fixed one way or the other, but the worse it is on
the above scale, the more likely it needs to be addressed ASAP.

Consider these the rules of engagement. Don't break stuff. If you do then
expect swift action to counter it. Don't like that? Then don't break things.

2. Decisions/Management

I have to agree with what has been said. I don't think some kind of committee
and formal "management" can happen on an OSS project without basically ripping
out the heart of that project. Comments have been made about the politics of
voting for leaders and how this just creates new issues. My take is this:

People who do the work get to call the shots. It is of course affected by
history of contribution, knowledge of the project and what it interacts with
etc. etc. ... I do not think having some committee of project managers is going
to make anything better. I think if anything it just makes things worse by
adding overhead. If we made everything code-reviewed ala phab, I think it'd be
far worse. development would dwindle and die. I absolutely know that I'd
personally just stop if I had to put every commit I do through review. Review
is a tool for developers who are not trusted yet or who need to learn or who
are not involved deeply enough to be held responsible for their work. Then I
believe the cost is justified.

What I have seen is commits that were objectively bad (e.g. break API) or were
arguably going the wrong way, and those get addressed based on severity etc.
but what seems to be the issue is that such work was made without discussion
then people get very upset when there is disagreement or their work is pointed
out to have had core issues. I don't see how any project management etc. will
change this. People need to objectively look at what they do and why others
might reject it (via review or revert). I never revert without my log
containing good reasons. I revert when the issue is bad enough to require it. I
have noticed that often there are commits with major changes with no
information in the commit log as to the reasoning behind such changes.

So I'm going to add another rule of engagement that people see to be ignoring:

* Your commit log must contain information as to WHY you did this. Someone
reading the git commit log needs to understand what was going on and WHY. If
the patch/diff is trivial then often the log only needs 1 line. Sometimes it's
a major change and it needs explanation as to WHY. The less information you
provide in your commit, the more likely it is going to be looked on poorly.
That also goes for patch submissions+review.

It's about communication. Communicate appropriately before you make changes.
Communicate with the changes. And be around to communicate after the changes.
Without communication things will fall apart. This requires people actively
make use of e-mail, IRC, phab tasks, etc. etc. ... as long as there is
reasonable amounts of it so people know WHY something is going on.

Keep in mind. This has nothing to do with personal goals but to do with the
health of a project and it's code base and changes. My priorities are to try
protect those.

3. Communication

I 

Re: [E-devel] Current State and Future Direction of E/EFL

[Simon Lees]

On 02/03/18 05:58, Stephen Houston wrote:
> I've been pondering writing this email for some time now.  As others have
> mentioned - our community has been trending downwards.  Work from Samsung
> aside, and those that use E/EFL through Samsung's work -- The developer and
> user base has been getting smaller and smaller.  That is regular members of
> the community contributing work and regular members of the community using
> E/EFL as an option for their linux desktops/laptops.  The number of
> arguments that are now occurring among those of us still left has been
> rising.  The current state of the project is such that dissenting
> opinions/code are not allowed and get reverted or overruled in discussions,
> this likely directly related to our structure and our lack of documented
> road maps, goals, and plans.
> 
> This project has been around for decades.  Many of our developers have
> spent blood sweat and tears adding code to this project and working on it.
> Many of our developers have poured just as much code into this project as
> the next has.  The project has become so much more than just one person's
> vision or one person's opinion.  As it is the project is really not set up
> to handle this.  There is no clear decision tree. No clear path for what is
> and is not accepted.  No clear direction of what the goal is to
> accomplish.  This has been leading to so much animosity, and frankly a
> stagnant project that is dwindling instead of growing.  Sure plenty of code
> gets written, rewritten, or worked on, but the majority of it is not seen
> in the product.  It is working on rewrites for performance, bug fixes for
> corner cases, implementing new apis that are not used anywhere, etc...,
> etc..., and all of that is fine and necessary, but other very important
> work gets left out.  Take Enlightenment from late 2000s - now.  A lot of
> work has been done.  Compositing, Wayland, e_widgets -> Elm, etc..., etc...
> But in the last say 10 years... You could pull up versions of Enlightenment
> and without a technical sense or from someone following the project, you
> would think it is the same... Same menus, same settings, same gadgets, same
> shelves, same themes, same look, same interface, etc..., etc...  EFL
> consistently is worked on and sure is doing really cool new stuff like
> Interfaces... but does it matter if no one is even using it? (Samsung
> aside).  We have 3 or 4 applications that we have always had and there
> seems to be very little growth.  We have people who have decided to fork
> off work or go their own route... see Moksha, Fyne, etc... due to problems
> within our community or our vision.  This is difficult for a community like
> ours to overcome when and if we lose users when we already have few to
> begin with.
> 
> I believe it is time that we as a community revisit ourselves and consider
> restructuring.  Projects can't just be YOLO with no clear laid out
> direction or plan.  Community based projects can't succeed in an
> environment where there is seemingly no project management and discussions
> only happen when a feature or change is pushed and one person overrides
> it.  This project needs to have more project management.  Goals need to be
> laid out.  Road maps need to be developed.  Release plans need to be
> created and adhered to.  This project needs structure, and frankly this
> structure needs to come from more than just one person.  There needs to be
> a team of project managers who determine whether changes, features, or
> proposal are accepted, not only one person.  There needs to be a team of
> project managers determining the direction of the project and developing
> road maps for it.  This team needs to be represented of our developers, our
> corporate interests, and our community user base.  Having a team will keep
> from personal bias, desires, or egos getting in the way.  Once we have some
> structure in place, it will become much easier for us to band together to
> work towards meeting our goals.
> 
> As it is - It really feels like if we continue on the path we are on, the
> future is not bright at all.  If we treat this project's goals as whatever
> meets the desires or ideas of one or two, that is what it will eventually
> become - a project used by one or two.  I'm pleading with everyone to put
> egos aside, put personal ambitions, personal goals, and related aside and
> begin working as a team.  The current climate will improve dramatically if
> that happens.
> 
> Before you get upset and respond angrily at this email, remember I love
> this project and have worked on it for over 15 years and developed
> relationships with most of you along the way, and so I am in no way sending
> this email with ill intent or to anger or hurt anyone.  I'm sending this
> email in hopes that we can only improve as we move forward.
> 
> Thanks,
> Stephen

I'm going to agree and disagree with a bunch of stuff here, as a
starting point, we are an open source project, 

Re: [E-devel] Current State and Future Direction of E/EFL

[Davide Andreoli]

2018-03-02 4:42 GMT+01:00 Vinícius dos Santos Oliveira <
vini.ipsma...@gmail.com>:

> 2018-03-01 21:17 GMT-03:00 William L. Thomson Jr. <
> wlt...@obsidian-studios.com>:
>
> > I also like Debians approach of an annually elected leader.
> > https://www.debian.org/devel/leader
> > https://en.wikipedia.org/wiki/List_of_Debian_project_leaders
> >
>
> I like “raster is top” way to go.
>
> Also:
>
> 2018-03-01 16:28 GMT-03:00 Stephen Houston :
>
> > Same menus, same settings, same gadgets, same
> > shelves, same themes, same look, same interface, etc..., etc...
> >
>
> I miss the penguins module a lot.
>

Why you miss it? the penguins module is perfectly working with current E
and
(I hope) with latest stable releases. Please report any issue you will
found to me.


>
> --
> Vinícius dos Santos Oliveira
> https://vinipsmaker.github.io/
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[Vinícius dos Santos Oliveira]

2018-03-01 21:17 GMT-03:00 William L. Thomson Jr. <
wlt...@obsidian-studios.com>:

> I also like Debians approach of an annually elected leader.
> https://www.debian.org/devel/leader
> https://en.wikipedia.org/wiki/List_of_Debian_project_leaders
>

I like “raster is top” way to go.

Also:

2018-03-01 16:28 GMT-03:00 Stephen Houston :

> Same menus, same settings, same gadgets, same
> shelves, same themes, same look, same interface, etc..., etc...
>

I miss the penguins module a lot.

-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Current State and Future Direction of E/EFL

[William L. Thomson Jr.]

Many projects face hardships. I am optimistic still. Though I maybe seen
as troublesome, unwanted, bad apple, etc by some. It is good to bring
such issues up and discuss them. Problems do not solve themselves.

On Thu, 01 Mar 2018 19:28:15 +
Stephen Houston  wrote:
>
> Community based projects can't succeed
> in an environment where there is seemingly no project management and
> discussions only happen when a feature or change is pushed and one
> person overrides it.  This project needs to have more project
> management.  Goals need to be laid out.  Road maps need to be
> developed.  Release plans need to be created and adhered to.  This
> project needs structure,

I fully agree on organization and structure! To many think volunteer
and FOSS projects do not need organization and leadership. Those that
can organize can thrive. Those who cannot, do not.

> and frankly this structure needs to come
> from more than just one person.  There needs to be a team of project
> managers who determine whether changes, features, or proposal are
> accepted, not only one person.  There needs to be a team of project
> managers determining the direction of the project and developing road
> maps for it.  This team needs to be represented of our developers,
> our corporate interests, and our community user base.  Having a team
> will keep from personal bias, desires, or egos getting in the way.
> Once we have some structure in place, it will become much easier for
> us to band together to work towards meeting our goals.

I would caution a move to decision by committee. It was the almost
death of Apple. It has not really been a good thing for other
organizations. Best example is Gentoo. Since its move to a Gentoo
Council. Gentoo has had more issues with leadership, direction, etc.
IMHO it had a better initial approach to management.

Something like this may work for E.
https://www.gentoo.org/glep/glep-0004.html

Say Raster is top. Then a managers team below. Then each project has
its own. Now E/EFL does not really have projects in the same sense. I
would say someone would be like Elementary Manager, EINA, etc. Parts of
EFL a person would be the manager for, working with other managers, and
any team beneath them. Someone for E, maybe a modules/bryce manager,
etc. A Wayland manager, X11, etc. Various parts, Windows OS, OS X, etc.

IMHO this has been total crap and why Gentoo has had so many issues
since its early years. GLEP-39 replaces GLEP-4, management structure
 https://www.gentoo.org/glep/glep-0039.html

I also like Debians approach of an annually elected leader.
https://www.debian.org/devel/leader
https://en.wikipedia.org/wiki/List_of_Debian_project_leaders

I highly recommend using existing forms of structure and leadership or
some combination there of that works. Gentoo has always experimented
with unique structure and organization that is really a failed
experiment. Many have yet to get past denial and make effort to
correct. Just doubling down on status quo and trying to make something
that will never work, work...

Read Daniel Robbins comments here. It tells the tail of how the Gentoo
Council came to be... It very much is a failed experiment.
https://archives.gentoo.org/gentoo-project/message/3ac5418dd061fc53f4b8d55a99773f4c


Extra comments

IMHO there is always going to be various social issues around anything
technical. Many technical people are not great a social stuff in person
or in general. Not insulting anyone, we all have strengths and
weaknesses. Even non technical, the world has a hard time getting along
in general. FOSS projects cross many boarders, cultures, etc. Its
natural there be issues a a result of such. But seems the era of thick
skin etc is dead, its now Code of Conduct, ban, punish, drive away etc.
Those things do not help grow communities.

-- 
William L. Thomson Jr.


pgpcqIJBuTQ4q.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Current State and Future Direction of E/EFL

[Stephen Houston]

I've been pondering writing this email for some time now.  As others have
mentioned - our community has been trending downwards.  Work from Samsung
aside, and those that use E/EFL through Samsung's work -- The developer and
user base has been getting smaller and smaller.  That is regular members of
the community contributing work and regular members of the community using
E/EFL as an option for their linux desktops/laptops.  The number of
arguments that are now occurring among those of us still left has been
rising.  The current state of the project is such that dissenting
opinions/code are not allowed and get reverted or overruled in discussions,
this likely directly related to our structure and our lack of documented
road maps, goals, and plans.

This project has been around for decades.  Many of our developers have
spent blood sweat and tears adding code to this project and working on it.
Many of our developers have poured just as much code into this project as
the next has.  The project has become so much more than just one person's
vision or one person's opinion.  As it is the project is really not set up
to handle this.  There is no clear decision tree. No clear path for what is
and is not accepted.  No clear direction of what the goal is to
accomplish.  This has been leading to so much animosity, and frankly a
stagnant project that is dwindling instead of growing.  Sure plenty of code
gets written, rewritten, or worked on, but the majority of it is not seen
in the product.  It is working on rewrites for performance, bug fixes for
corner cases, implementing new apis that are not used anywhere, etc...,
etc..., and all of that is fine and necessary, but other very important
work gets left out.  Take Enlightenment from late 2000s - now.  A lot of
work has been done.  Compositing, Wayland, e_widgets -> Elm, etc..., etc...
But in the last say 10 years... You could pull up versions of Enlightenment
and without a technical sense or from someone following the project, you
would think it is the same... Same menus, same settings, same gadgets, same
shelves, same themes, same look, same interface, etc..., etc...  EFL
consistently is worked on and sure is doing really cool new stuff like
Interfaces... but does it matter if no one is even using it? (Samsung
aside).  We have 3 or 4 applications that we have always had and there
seems to be very little growth.  We have people who have decided to fork
off work or go their own route... see Moksha, Fyne, etc... due to problems
within our community or our vision.  This is difficult for a community like
ours to overcome when and if we lose users when we already have few to
begin with.

I believe it is time that we as a community revisit ourselves and consider
restructuring.  Projects can't just be YOLO with no clear laid out
direction or plan.  Community based projects can't succeed in an
environment where there is seemingly no project management and discussions
only happen when a feature or change is pushed and one person overrides
it.  This project needs to have more project management.  Goals need to be
laid out.  Road maps need to be developed.  Release plans need to be
created and adhered to.  This project needs structure, and frankly this
structure needs to come from more than just one person.  There needs to be
a team of project managers who determine whether changes, features, or
proposal are accepted, not only one person.  There needs to be a team of
project managers determining the direction of the project and developing
road maps for it.  This team needs to be represented of our developers, our
corporate interests, and our community user base.  Having a team will keep
from personal bias, desires, or egos getting in the way.  Once we have some
structure in place, it will become much easier for us to band together to
work towards meeting our goals.

As it is - It really feels like if we continue on the path we are on, the
future is not bright at all.  If we treat this project's goals as whatever
meets the desires or ideas of one or two, that is what it will eventually
become - a project used by one or two.  I'm pleading with everyone to put
egos aside, put personal ambitions, personal goals, and related aside and
begin working as a team.  The current climate will improve dramatically if
that happens.

Before you get upset and respond angrily at this email, remember I love
this project and have worked on it for over 15 years and developed
relationships with most of you along the way, and so I am in no way sending
this email with ill intent or to anger or hurt anyone.  I'm sending this
email in hopes that we can only improve as we move forward.

Thanks,
Stephen
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list