Re: [E-devel] Self Hosted Gitlab Instead of Phabricator

[Jonathan Aquilina via enlightenment-devel]

Hi Raster,

I am assuming I would need to get you an SSH key as the next step?

Regards,
Jonathan



-Original Message-
From: Carsten Haitzler  
Sent: 11 November 2021 16:27
To: Enlightenment developer list 
Cc: Jonathan Aquilina 
Subject: Re: [E-devel] Self Hosted Gitlab Instead of Phabricator

On Thu, 11 Nov 2021 15:19:44 + Jonathan Aquilina via enlightenment-devel 
 said:

> Hey Raster,
> 
> What infrastructure is in place maybe this is something we can start 
> working on slowly and im willing to work on this slowly slowly.

e5.enlightenment.org - there is a whole machine with lots of disk and ram to do 
this ... it doesn't need vm's or containers - that is necessary  to run 
services (and actually makes it so much harder to maintain). these only matter 
if you are scaling up to huge services and you have to divide.

it'd be fantastic if you want to do this. i can easily set up a dns entry like 
gitlab.e.org to point to e.org like phab, www, git.e.org etc. do and apache can 
split it out to its own www tree like everything else. - there already is a 
mysql db running (for phab) and other things... so everything needed is there. 
all the disks are raid1/10 mirrored fully so it's pretty redundant.

> Regards,
> Jonathan
> 
> -Original Message-
> From: Carsten Haitzler 
> Sent: 11 November 2021 16:16
> To: Enlightenment developer list 
> 
> Subject: Re: [E-devel] Self Hosted Gitlab Instead of Phabricator
> 
> On Thu, 11 Nov 2021 15:45:29 +0400 Abdur-Rahmaan Janhangeer 
>  said:
> 
> > Worse case scenario is:
> > Me in some 6 years.
> 
> Hahahahah! glad you at least you put your hand up for "when i am able 
> to do that in a few years".
> 
> My point here is more - it will end up being me right now and I only 
> have X time to do things with and i have to prioritize. Phab works and does 
> the job.
> It may not be perfect or the nicest things but it works and still does now.
> It's not that hard to use it and adapt to it. There isn't a big need 
> to fix this right now. There are much more important things to work on 
> (at least for me), so I'm going to focus on those for now. :)
> 
> 
> --
> - Codito, ergo sum - "I code, therefore I am" 
> -- Carsten Haitzler - ras...@rasterman.com
> 
> 
> 
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://link.edgepilot.com/s/08a7b46d/HQuQl_QXSU2KEwCDcbJBMg?u=https:/
> /lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 
> 
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://link.edgepilot.com/s/8d835e7c/ckykYrGtn0WhRVdQXQIF6g?u=https:/
> /lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


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



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

Re: [E-devel] Self Hosted Gitlab Instead of Phabricator

[Jonathan Aquilina via enlightenment-devel]

Hey Raster,

What infrastructure is in place maybe this is something we can start working on 
slowly and im willing to work on this slowly slowly.

Regards,
Jonathan

-Original Message-
From: Carsten Haitzler  
Sent: 11 November 2021 16:16
To: Enlightenment developer list 
Subject: Re: [E-devel] Self Hosted Gitlab Instead of Phabricator

On Thu, 11 Nov 2021 15:45:29 +0400 Abdur-Rahmaan Janhangeer 
 said:

> Worse case scenario is:
> Me in some 6 years.

Hahahahah! glad you at least you put your hand up for "when i am able to do 
that in a few years".

My point here is more - it will end up being me right now and I only have X 
time to do things with and i have to prioritize. Phab works and does the job.
It may not be perfect or the nicest things but it works and still does now.
It's not that hard to use it and adapt to it. There isn't a big need to fix 
this right now. There are much more important things to work on (at least for 
me), so I'm going to focus on those for now. :)


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



___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://link.edgepilot.com/s/08a7b46d/HQuQl_QXSU2KEwCDcbJBMg?u=https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


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

Re: [E-devel] e16 mentioned in this talk

[Jonathan Aquilina]

Welcome to the way back machine :D




-Original Message-
From: Stefan Schmidt  
Sent: Monday, 20 April 2020 17:54
To: enlightenment-devel@lists.sourceforge.net
Subject: Re: [E-devel] e16 mentioned in this talk

Hello.

On 19.04.20 09:14, Jonathan Aquilina wrote:
> https://www.youtube.com/watch?v=8QlZbg5B1vk=youtu.be

A talk from 2000 :-)

regards
Stefan Schmidt


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


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

[E-devel] e16 mentioned in this talk

[Jonathan Aquilina]

https://www.youtube.com/watch?v=8QlZbg5B1vk=youtu.be

Regards,
Jonathan Aquilina

EagleEyeT
Phone +356 20330099
Sales - sa...@eagleeyet.net<mailto:sa...@eagleeyet.net>
Support - supp...@eagleeyet.net


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

Re: [E-devel] Committer access proposal: ali.alzyod (Ali Alzyod)

[Jonathan Aquilina]

Hi Carsten,

Not to hijack this thread but I still need to test out the vpn access you had 
requested for me. Infra wise where do we stand are we still on gentoo? Feel 
free to email me directly to discuss.




-Original Message-
From: Carsten Haitzler  
Sent: Tuesday, 31 March 2020 13:32
To: Enlightenment developer list 
Subject: Re: [E-devel] Committer access proposal: ali.alzyod (Ali Alzyod)

On Tue, 31 Mar 2020 20:02:05 +0900 woohyun said:

> @raster
> Woops !!  What happen  ?!?! 

bear wrestling! the bear came off second best of course! :)

> Are you ok now ? I  really hope you will be recovered soon.

well it'll take time. i'm told 6-12 months to be kind-of back to normal and in 
a few years i should be totally back, but i just went from "severely limited"
last friday to "i have my arm back - but now with metal, screws and a scar and 
very limited movement in my wrist". i need to exercise movement to get it back 
but it can be a bit of a strain, so i can't do it as much as i used to. 

> Plus, I really appreciate for sharing the information in your worst 
> situation for typing.

I'm back to typing again as of last friday - but am keeping myself to at most 
maybe ~8-9 keyboard hours a day (still need to work).

e.org moved from e6 back to e5 a few months ago as an emergency measure when 
e.org broke again and i had to quickly move everything to e5 and set it all up.
i spent a few days doing that but i didn't re-set up automatic developer 
account management (it's a bit complicated :)). it's something still to do, so 
this will have to wait for some spare time for me to dig into that. it'
actually hasn't been necessary for quite a while which is why it was not high 
priority :)

> -Original Message-
> From: "Carsten Haitzler"
> To: "Enlightenment developer 
> list";
> Cc: "woohyun";
> Sent: 2020-03-31 (화) 18:54:20 (GMT+09:00)
> Subject: Re: [E-devel] Committer access proposal: ali.alzyod (Ali 
> Alzyod)
>  
> On Tue, 31 Mar 2020 13:25:42 +0900 woohyun said:
> 
> not so fast... :) no dev access changes happen unless i do them 
> manually currently. i've been essentially off unable to do much in the 
> past 6 weeks or so due to broken arm and wrist and surgery on my right 
> hand/arm. i just got out of the bandages and cast with my new 
> adamantine wolverine claws embedded in my right arm. :)
> 
> > Since there has been no objection, I registered him as a EFL 
> > developer :)
> >  
> > @ali.alzyod Welcome and Congrats :)
> >  
> > -Original Message-
> > From: "cnook"
> > To: "Enlightenment developer
> > list"; Cc:
> > Sent: 2020-03-19 (목) 09:58:29 (GMT+09:00)
> > Subject: Re: [E-devel] Committer access proposal: ali.alzyod (Ali 
> > Alzyod)
> >  
> > +1
> >
> > Yes he is. I actually got valuable opinions regarding color related thing.
> > Thank you.
> >
> > 2020년 3월 17일 (화) 오후 3:12, Hermet Park 님이 작성:
> >
> > > +1
> > >
> > > On Tue, Mar 17, 2020 at 2:11 PM woohyun  wrote:
> > >
> > > > Hello. Everyone here :)
> > > >
> > > > I would like to promote Ali to become a committer.
> > > >
> > > > He has been contributing a lot in Text field, and I think he can 
> > > > do more for other fields, too.
> > > > (Especially, he has contributed many of new Text interface 
> > > > features by
> > > his
> > > > own)
> > > >
> > > > Plus, he has been given valuable feedback on many patches.
> > > > So, I think he is ready to be a committer.
> > > >
> > > > If nobody object, I will give access next week :)
> > > >
> > > > Thanks for reading !! ~
> > > >
> > > > WooHyun Jung
> > > >
> > > > ___
> > > > enlightenment-devel mailing list 
> > > > enlightenment-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > >
> > >
> > >
> > > --
> > > Regards, Hermet
> > >
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >
> >
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> > ___
> > 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
> 
> 
> ___
> 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



___
enlightenment-devel 

[E-devel] (no subject)

[Jonathan Aquilina]

Hi guys,

I’m noticing a bit of tensions through some diffs I’m seeing come through the 
pipeline.

I think two points to make here are the following:

Firstly English might not be the native language spoken by some so one needs to 
keep this in mind that when reading their English some wording they use might 
come out as harsh and abrasive when that would not have been the intention.

Secondly from text Alone one cannot fully understand what their emotion they 
want to put forth really is. Through text that is easily lost.

If anyone takes anything out of what I’m sending I hope that these two points 
will come to mind.

Regards,
Jonathan Aquilina
Owner managing director

Phone (356) 20330099
Mobile (356) 79957942

Email sa...@eagleeyet.net

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

Re: [E-devel] Hacking all aspects of enlightenment

[Jonathan Aquilina]

Is it hard to get an environment setup with wayland?



On 02/01/2020, 05:49, "Simon Lees"  wrote:

Hi,

On 1/2/20 7:06 AM, Jonathan Aquilina wrote:
> Evening All,
> 
> I have a question is there anyone working on ethically hacking all 
aspects of enlightenment. Reason I am asking is it might be a good idea to 
ensure enlightenment does not pose any issues from a security aspect for end 
users.
> 
> Let me know your opinions on this as this is an area that really does 
interest me for sure 
> 
> Hope everyone had a great Christmas and wanting to wish everyone a very 
happy and prosperous new year!

Under X11 there is little point in doing much, it was never designed
with security in mind so things like key logging and screen grabbing can
be done just using the native X11 API. If you think about what apps like
synergy and gimp's color picker can do using native API's with no
privileges you'll get a good idea. As such many things that would
generally be a security issue in other software don't get heaps of time
because you can probably do it using the API without an exploit anyway.

Having said that there are certainly areas worth looking at, especially
the binaries using suid bits to see if you can do any privilege
escalation. Wayland also sandboxes apps much better so its probably
worth looking there because anything you find would be worth while.


-- 

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




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

[E-devel] Hacking all aspects of enlightenment

[Jonathan Aquilina]

Evening All,

I have a question is there anyone working on ethically hacking all aspects of 
enlightenment. Reason I am asking is it might be a good idea to ensure 
enlightenment does not pose any issues from a security aspect for end users.

Let me know your opinions on this as this is an area that really does interest 
me for sure 

Hope everyone had a great Christmas and wanting to wish everyone a very happy 
and prosperous new year!

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

Re: [E-devel] EDD 2019 wrap up: news post, meeting minutes, recordings

[Jonathan Aquilina]

Hey Stefan can help with rendering of the videos if need be least I can do to 
contribute back to the community

Regards,
Jonathan Aquilina
Owner managing director

Phone (356) 20330099
Mobile (356) 79957942

Email sa...@eagleeyet.net

From: Stefan Schmidt 
Sent: Thursday, November 28, 2019 2:07:51 PM
To: e ; enlightenment-users 

Subject: [E-devel] EDD 2019 wrap up: news post, meeting minutes, recordings

Hello.

We had some good and useful time last weekend at EDD. Xavi did a litle
write up with pretty pictures for our website. Go and have a read:

https://www.enlightenment.org/news/2019-11-26-e-dev-days-2019.txt

Many, many things have been talked about. We tried to capture at least a
little of this in our meetings notes we worked on together. In addition
the first slides have been added to the EDD wiki page schedule (the rest
will follow over the next days).

https://phab.enlightenment.org/w/events/enlightenment_developer_days_2019/minutes/

https://phab.enlightenment.org/w/events/enlightenment_developer_days_2019/

This surely does not cover everything but at least it gives some ideas.
Recordings have been taken but we have not yet checked on the audio
quality and we will see how it is and how long it will take to get the
videos out. Don't hold your breath (or offer help if you are willing to
do some cutting, etc).

regards
Stefan Schmidt


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

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

Re: [E-devel] e-commits ML no longer working

[Jonathan Aquilina]

Hi Bertrand,

Also I  am not sure if you are aware there are some nasty bugs in older exim 
versions that I have read articles that attackers are exploiting are we on the 
latest version to ensure the server does not end up compromised?

Regards,
Jonathan

-Original Message-
From: Bertrand Jacquin  
Sent: Monday, 16 September 2019 22:39
To: Michael Blumenkrantz 
Cc: Enlightenment developer list 
Subject: Re: [E-devel] e-commits ML no longer working

Hi,

On Mon, Sep 16, 2019 at 03:44:45PM -0400, Michael Blumenkrantz wrote:
> Great, thanks. Is there some way to prevent this from happening again in the 
> future? It seems to be a recurring issue.

This is not really recurring issue, this is a bug in exim when a domain has srv 
record associated with. I disabled srv lookup for now and I filled 
https://bugs.exim.org/show_bug.cgi?id=2443. Once this is fixed, we can roll 
back the change.

> On Sun, 15 Sep 2019 22:56:23 +0100
> Bertrand Jacquin  wrote:
> 
> > Issue is now fixed. Queue is being flushed atm.
> > 
> > On Thu, Sep 12, 2019 at 09:58:40AM -0400, Mike Blumenkrantz wrote:
> > > This has been an issue for a long time now.
> > > 
> > > On Wed, Sep 11, 2019 at 3:12 AM Simon Lees  wrote:
> > >   
> > > > I still don't either so it seems like an ongoing problem
> > > >
> > > > On 9/11/19 12:12 PM, Hermet Park wrote:  
> > > > > Hi, still i can't receive mails.
> > > > > Is this still invalid? or only my problem?
> > > > >
> > > > >
> > > > > On Wed, Aug 7, 2019 at 6:04 AM Boris Faure  wrote:
> > > > >  
> > > > >> Hi :)
> > > > >>
> > > > >>   It seems that the e-commits mailing list is no longer working.
> > > > >>   Could someone please look into it?
> > > > >>
> > > > >> Thanks
> > > > >>
> > > > >> --
> > > > >> Boris Faure
> > > > >> Pointer Arithmetician
> > > > >> ___
> > > > >> enlightenment-devel mailing list 
> > > > >> enlightenment-devel@lists.sourceforge.net
> > > > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-de
> > > > >> vel
> > > > >>  
> > > > >
> > > > >  
> > > >
> > > > --
> > > >
> > > > 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
> > > >
> > > >
> > > > ___
> > > > enlightenment-devel mailing list 
> > > > enlightenment-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > >  
> > 



--
Bertrand


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

Re: [E-devel] EDD 2019 location and dates vote online FINAL VOTE

[Jonathan Aquilina]

Hi Stefan,

I also want to add if accommodation is required I can help with that plus I 
know a relaxed place where we can have a big table if need be and can eat drink 
and be merry as we code. Are there plans for talks like the last time it was 
held here in malta?

Regards,
Jonathan


-Original Message-
From: Stefan Schmidt  
Sent: Thursday, 1 August 2019 15:26
To: e ; enlightenment-users 

Subject: Re: [E-devel] EDD 2019 location and dates vote online FINAL VOTE

Hello.

Sorry that an update took so long on this. Summer vacation time kicked in and 
delayed planning.

On 21.06.19 15:26, Stefan Schmidt wrote:
> Hello.
> 
> On 13.06.19 13:09, Stefan Schmidt wrote:
>> Hello.
>>
>> On 12.06.19 16:06, Stefan Schmidt wrote:
>>> Hello.
>>>
>>> I got feedback that my original mail pointing to the EDD vote has 
>>> been buried to deep in a mail thread to be noticed.
>>>
>>> Here we go again. I started a vote to get input for this years EDD 2019.
>>>
>>> https://phab.enlightenment.org/V44
>>>
>>> I am still open to have other dates or locations (if hosting could 
>>> be
>>> provided) if that fits people better.
>>
>> Thanks to Xavi we can add Barcelona to the offered locations.
>>
>> Sadly I can't edit the choices in the phab vote afterwards, only the 
>> text. Please use the vot comment section to express your interest in 
>> Barcelona. An example is already there.
> 
> Great to see that this got some more traction over the last few days. 
> We have 14 votes so far and I look forward to see some more!
> 
> A quick summary as where we stand it terms of location and date so far 
> sorted by votes:
> 
> Location:
> Cambridge: 11
> Malta: 10
> London: 9
> Staines: 5
> Barcelona: 5
> 
> Dates:
> 02. + 03.11: 9
> 07. + 08.09: 5
> 21. + 22.09: 4
> 26. + 27.10: 4
> 
> While Cambridge is still listed as no hosting confirmed (the choices 
> can not be edited afterwards) we now have two hosting offers available for it.
> 
> As for dates we seem to have a clear first place so far with the 
> weekend in November. If November is more favorable I can also add some 
> more weekends to the next vote.

Finally came around to check the vote, make a summary and setup the final vote 
which should give us the location and date we can work with.

Since the last update we got two more votes (making in 16 in total).
Here is how they spread out:

Location:
Cambridge: 13
Malta: 11
London: 10
Barcelona: 8
Staines: 6

Dates:
02. + 03.11: 10
07. + 08.09: 6
26. + 27.10: 5
21. + 22.09: 4


This brings us to the final vote I just set up. I reduced the location options 
to three. Malta, Cambridge and Barcelona. The first two have the highest votes 
and Barcelona also has hosting offered. I dropped London as there was no 
offered hosting which makes it complicated for me to handle and its only an 
hour train ride to Cambridge anyway.

As for dates I skipped the ones in September as it would be impossible for me 
to organize things by then. I also added a few more in November as that seemed 
a popular month.

https://phab.enlightenment.org/V45

Again, I can not guarantee that the location and date with the most votes will 
really be what I pick, as there are sometimes other problems which make it 
unsuitable, but I will try very hard to go with the highest votes.

Recordings:
There have been requests for recording and maybe live streaming. We tried this 
before two times and it failed both times. If we have someone wanting to handle 
this and give it another try I would be happy to have it, but I am not putting 
this on my plate :-)

User sessions:
Another topic of questions have been about users of Enlightenment or 
applications which are no developers. We are happy to have them. This just 
started out as a meeting for developers to coordinate, but that does not mean 
it only for them. If we have enough people interested we could go and have a 
half a day of sessions on user topics like Enlightenment and other EFL apps.

Lengthy mail, time to cut it off. Please go and vote until August 23rd.

regards
Stefan Schmidt


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


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

Re: [E-devel] server down

[Jonathan Aquilina]

Hi Guys,

I would open a ticket with OUOSL to have them give the server a kick in the rump

Regards,
Jonathan

On 02/07/2019, 10:49, "Carsten Haitzler"  wrote:

On Mon, 01 Jul 2019 21:52:37 +0300 Bertrand Jacquin  
said:


I can't do anything. Same situation it has always been with e6:

 9:46AM ~ > ssh e6.enlightenment.org
Permission denied (publickey).
 9:46AM ~ > ssh e6v1.enlightenment.org
packet_write_wait: Connection to 163.172.114.208 port 22: Broken pipe
SSH: Server;LType: Throughput;Remote: 163.172.114.208-22;IN: 0;OUT: 
0;Duration:
1562057252.65;tPut_in: 0;tPut_out: 0
 9:47AM ~ > ssh www.enlightenment.org
packet_write_wait: Connection to 163.172.114.208 port 22: Broken pipe
SSH: Server;LType: Throughput;Remote: 163.172.114.208-22;IN: 0;OUT: 
0;Duration:
1562057264.42;tPut_in: 0;tPut_out: 0


> Hey,
> 
> Je suis en vacances cette semaine, je vais pas pouvoir m'en occuper avant
> mardi prochain. Est ce que raster peut regarder ?
> 
> -- 
> BertrandOn 30 Jun 2019 17:27, Boris Faure  wrote:
> >
> > Hi :) 
> >
> > Server looks down again. 
> > I can't push to terminology's git, phab and the website all look down. 
> >
> > I hope you'll be able to fix it soon. 
> > -- 
> > Boris Faure 
> > Pointer Arithmetician 
> 
> ___
> 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



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



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

Re: [E-devel] Seeking inout for Enlightenment Developer Days 2019

[Jonathan Aquilina]

Got it. Thanks Stefan

On 27/05/2019, 12:21, "Stefan Schmidt"  wrote:

Hello Jonathon.

On 27.05.19 12:09, Jonathan Aquilina wrote:
> Hi Stefan,
> 
> Anything I can do to help? Is it possible to do a poll on phab?

Not really, I needed to get some initial dates sorted out.

I created a poll on phab now. This is to gauge interest for the
different dates and locations. If nothing fits please vote the answers I
added for these cases.

If there are other preferred dates or someone else can offer hosting I
am happy to add it. We would need a final vote in the end anyway.

https://phab.enlightenment.org/V44

regards
Stefan Schmidt



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

Re: [E-devel] Seeking inout for Enlightenment Developer Days 2019

[Jonathan Aquilina]

Hi Stefan,

Anything I can do to help? Is it possible to do a poll on phab?

Regards,
Jonathan

On 27/05/2019, 09:48, "Stefan Schmidt"  wrote:

Hello Jonathon.

On 25.05.19 07:14, Jonathan Aquilina wrote:
> Hi Stefan,
> 
> EDD discussions have seem to have gone silent. Has anything been decided?

As raster wrote, just busy. I will try to come back to it soon.

regards
Stefan Schmidt



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

Re: [E-devel] Seeking inout for Enlightenment Developer Days 2019

[Jonathan Aquilina]

@Carsten Haitzler would love to host you guys again. Now that I am self 
employed I have a bit more time to be a tour guide so to speak lol. But it 
really is up to the community.

-Original Message-
From: Carsten Haitzler  
Sent: 25 May 2019 10:09
To: Enlightenment developer list 
Cc: Jonathan Aquilina ; Stefan Schmidt 

Subject: Re: [E-devel] Seeking inout for Enlightenment Developer Days 2019

On Sat, 25 May 2019 05:14:39 + Jonathan Aquilina 
said:

> Hi Stefan,
> 
> EDD discussions have seem to have gone silent. Has anything been decided?

just busy ... :) depending on when and some dates i'd love to make it, but 
things may come up. malta would be nice IMHO. :)

> Regards,
> Jonathan
> 
> -Original Message-
> From: Stefan Schmidt 
> Sent: 29 April 2019 12:35
> To: Enlightenment developer list 
> ;
> Jonathan Aquilina  Subject: Re: [E-devel] 
> Seeking inout for Enlightenment Developer Days 2019
> 
> Hello.
> 
> On 28.04.19 07:39, Jonathan Aquilina wrote:
> > Hi Stefan, yes it would be the same location as last time. But then 
> > again it doesn’t have to be we can meet at a restaurant with WIFI if 
> > you guys want we can enjoy drinks and food easily and have no issues 
> > with a locked down university network.
> 
> The original location would be fine. Restaurant or bar is for the 
> evening but not for the sessions where we have talks and discussions.
> 
> I will add Malta to the list of hosting offers again.
> 
> regards
> Stefan Schmidt
> 
> ___
> 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


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

Re: [E-devel] Seeking inout for Enlightenment Developer Days 2019

[Jonathan Aquilina]

Hi Stefan,

EDD discussions have seem to have gone silent. Has anything been decided?

Regards,
Jonathan

-Original Message-
From: Stefan Schmidt  
Sent: 29 April 2019 12:35
To: Enlightenment developer list ; 
Jonathan Aquilina 
Subject: Re: [E-devel] Seeking inout for Enlightenment Developer Days 2019

Hello.

On 28.04.19 07:39, Jonathan Aquilina wrote:
> Hi Stefan, yes it would be the same location as last time. But then again it 
> doesn’t have to be we can meet at a restaurant with WIFI if you guys want we 
> can enjoy drinks and food easily and have no issues with a locked down 
> university network.

The original location would be fine. Restaurant or bar is for the evening but 
not for the sessions where we have talks and discussions.

I will add Malta to the list of hosting offers again.

regards
Stefan Schmidt

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

Re: [E-devel] Seeking inout for Enlightenment Developer Days 2019

[Jonathan Aquilina]

Hi Guys,

Any updates in regards to this as this has gone silent.

Regards,
Jonathan

-Original Message-
From: Stefan Schmidt  
Sent: 30 April 2019 12:33
To: Marcel Hollerbach 
Cc: e 
Subject: Re: [E-devel] Seeking inout for Enlightenment Developer Days 2019

Hello.

[added e-devel back, guess you just missed in during reply]

On 30.04.19 12:24, Marcel Hollerbach wrote:
> 
> 
> On 4/25/19 11:48 AM, Stefan Schmidt wrote:
>> Hello.
>>
>> We did not come around to have EDDs last year and we shoul do better 
>> this year again. :-)
>>
>> Right now I would like to seek some inout on where and when.
>>
>> Right now we seem to have the following location offers:
>> o Jonathan offered Malta again (Would that be the same location as 
>> last
>> time?)
>> o Stefan could offer the SRUK office in Staines, UK o Marcel might be 
>> able to offer hosting at the University in Karlsruhe, Germany
> 
> Sadly there is no option to get a room on a weekend at the university.
> So this option is out.

Thanks for trying!

Which means for now we would have Staines, UK and Malta as available hostings.

Any more offers?

I am also open to suggestions on the best location even we we have no hosting 
available for it. If the other reasons are appealing enough I would try to get 
some small sponsorship of a hotel conference room for two days.

regards
Stefan Schmidt


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


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

Re: [E-devel] EFL Autotools freeze proposal

[Jonathan Aquilina]

For EFL cant we do like other projects do such as libreoffice set a minimum 
base line version or newer for meason?

Regards,
Jonathan

Regards,
Jonathan Aquilina
Owner EagleEyeT


From: Simon Lees 
Sent: Thursday, May 2, 2019 10:46 AM
To: enlightenment-devel@lists.sourceforge.net
Subject: Re: [E-devel] EFL Autotools freeze proposal

Generally stable releases will get version updates for point releases,
and if there are any other major bugs that are fixed after i'll normally
backport them, if thats too hard I may consider a major version update.

We tend to encourage people who want the latest everything to use the
rolling release instead, or wait for the next leap point release which
will be within a year. There are repo's that get used for development
where people could get a newer version but we generally don't encourage
it, and they would still require a new enough meson to be in the core
system in order to build. Because enabling a newer version of E
shouldn't force you onto a non system build of Meson thats not being as
well maintained.

For the crazy adventurous there are repo's that even have git builds,
but generally normal openSUSE users shouldn't need to add any additional
repos to there system bar 1 or 2 where legal issues get in the way,
unlike ubuntu where not everything makes it into the core distro in
openSUSE we encourage everything possible to be in the main distro at an
appropriate version depending on whether users are expecting a "stable
system that changes less" or a "rolling release". So the problem we hit
and are discussing is that the appropriate version of meson in the next
point release of openSUSE is too old to build the ideal version of efl,
which will likely end up blocking a new version of e (which does work
with that version of meson). Extra repo's are not a solution for 99% of
users who will just use the version that ships in the distro, which in
fairness may not be that big an issue because it is rather stable and
works really well on X11, but there is the potential that they will
still be using that version in 2-3 years unless we lower the version of
meson required by efl slightly.

On 02/05/2019 14:08, Jonathan Aquilina wrote:
> Hi Simon,
>
> What happens in terms of OpenSuse in the sense of giving those on stable 
> versions of Suse the latest versions of e? Won’t a 3rd party repo still be 
> needed until the next release is released with a newer version of e?
>
> Regards,
> Jonathan
>
> Regards,
> Jonathan Aquilina
> Owner EagleEyeT
>
> 
> From: Simon Lees 
> Sent: Thursday, May 2, 2019 1:12 AM
> To: enlightenment-devel@lists.sourceforge.net
> Subject: Re: [E-devel] EFL Autotools freeze proposal
>
> I have ways of creating 3rd party repo's easily, but currently you can
> install enlightenment from the openSUSE installer, and I'd like to keep
> that at the latest version for each new version of leap, so i'd like e23
> or later in Leap 15.2 (about a year away), which will probably need a
> reasonably new efl, but will likely only have meson 0.46.0 which is fine
> for e but atm not for efl.
>
> There are alot of people using e from the installer, I keep bumping into
> them at conferences etc, GNU Health have been using openSUSE +
> enlightenment on all there raspberry pi's etc, so there is a significant
> number of people using e in this way, and i'd like them to stay
> reasonably up to date.
>
> On 01/05/2019 16:12, Jonathan Aquilina wrote:
>> Hi Simon,
>>
>> Open suse is an rpm based distro correct?
>>
>> If yes why not creat a copr repo that will contain the newer stuff?
>>
>> Get Outlook for iOS<https://aka.ms/o0ukef>
>>
>> 
>> From: Simon Lees 
>> Sent: Wednesday, May 1, 2019 02:13
>> To: Carsten Haitzler (The Rasterman); Enlightenment developer list
>> Subject: Re: [E-devel] EFL Autotools freeze proposal
>>
>>
>>
>> On 30/04/2019 21:39, Carsten Haitzler (The Rasterman) wrote:
>>> On Tue, 30 Apr 2019 18:30:20 +0930 Simon Lees  said:
>>>
>>>>
>>>>
>>>> On 30/04/2019 17:40, Carsten Haitzler (The Rasterman) wrote:
>>>>> On Mon, 29 Apr 2019 15:20:19 -0700 Ross Vandegrift  
>>>>> said:
>>>>>
>>>>>> On Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote:
>>>>>>> I think everyone is missing the point. What you are saying is true but
>>>>>>> that is why then they say if you want newer stuff to use a PPA for it
>>>>>>> even though its not in the main repo's
>>>>>>
>>>>>> Yes, anyone can make a PPA. But you're talking to the maintaine

Re: [E-devel] EFL Autotools freeze proposal

[Jonathan Aquilina]

Hi Simon,

What happens in terms of OpenSuse in the sense of giving those on stable 
versions of Suse the latest versions of e? Won’t a 3rd party repo still be 
needed until the next release is released with a newer version of e?

Regards,
Jonathan

Regards,
Jonathan Aquilina
Owner EagleEyeT


From: Simon Lees 
Sent: Thursday, May 2, 2019 1:12 AM
To: enlightenment-devel@lists.sourceforge.net
Subject: Re: [E-devel] EFL Autotools freeze proposal

I have ways of creating 3rd party repo's easily, but currently you can
install enlightenment from the openSUSE installer, and I'd like to keep
that at the latest version for each new version of leap, so i'd like e23
or later in Leap 15.2 (about a year away), which will probably need a
reasonably new efl, but will likely only have meson 0.46.0 which is fine
for e but atm not for efl.

There are alot of people using e from the installer, I keep bumping into
them at conferences etc, GNU Health have been using openSUSE +
enlightenment on all there raspberry pi's etc, so there is a significant
number of people using e in this way, and i'd like them to stay
reasonably up to date.

On 01/05/2019 16:12, Jonathan Aquilina wrote:
> Hi Simon,
>
> Open suse is an rpm based distro correct?
>
> If yes why not creat a copr repo that will contain the newer stuff?
>
> Get Outlook for iOS<https://aka.ms/o0ukef>
>
> 
> From: Simon Lees 
> Sent: Wednesday, May 1, 2019 02:13
> To: Carsten Haitzler (The Rasterman); Enlightenment developer list
> Subject: Re: [E-devel] EFL Autotools freeze proposal
>
>
>
> On 30/04/2019 21:39, Carsten Haitzler (The Rasterman) wrote:
>> On Tue, 30 Apr 2019 18:30:20 +0930 Simon Lees  said:
>>
>>>
>>>
>>> On 30/04/2019 17:40, Carsten Haitzler (The Rasterman) wrote:
>>>> On Mon, 29 Apr 2019 15:20:19 -0700 Ross Vandegrift  said:
>>>>
>>>>> On Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote:
>>>>>> I think everyone is missing the point. What you are saying is true but
>>>>>> that is why then they say if you want newer stuff to use a PPA for it
>>>>>> even though its not in the main repo's
>>>>>
>>>>> Yes, anyone can make a PPA. But you're talking to the maintainers of
>>>>> distro packaging - we try to put packages into distros for real :)
>>>>
>>>> and i think this was covered - a stable distro release that will not 
>>>> upgrade
>>>> meson out of principle (that's the definition of stable) isn't going to
>>>> upgrade efl either for the same reasons... so i think the topic is kind of
>>>> moot. if someone wants to make pkgs for such distros they can create
>>>> upgraded meson packages too etc. if they want to go the "all done by pkgs"
>>>> path :)
>>>>
>>>
>>> This is kind of right, in an openSUSE context for a new service pack we
>>> probably won't update Meson because it effects alot but we can update
>>> efl / e because it doesn't affect as much, we could also add it if it
>>> didn't exist. Further if a new version of efl fixed a serious bug that
>>> was hard to backport we would also take the version update.
>>
>> tho meson doesn't affect THAT much... it's a build tool not a "runtime 
>> tool". it
>> isn't int he realms of libc, Xserver, bash etc.
>>
>
> Yeah there's a lot of stuff thats using meson to build now, and a meson
> update effects any updates we do for anything thats built with it due to
> needing full QA cycles to verify that the package was built correctly
> which is why enterprise distro's prefer not to update build tools mid cycle.
>
>
>>> In ubuntu's case from memory the service packs tend to only be a new
>>> installer containing all the updates so its probably less likely, but I
>>> don't remember how ubuntu works 100% so I could be wrong.
>>
>> in our case if a new efl needs a new meson, then... that's what it needs and 
>> an
>> efl upgrade is not likely to happen then from the core distro. ppa's and
>> equivalents can manage to fill that gap. this problem will go away over time 
>> as
>> meson matures etc. etc. so this is a short-term problem as such. :)
>>
>
> Yep but in openSUSE's case that may mean keeping e22 through all the
> leap 15.X releases which I really don't want to do because I cant
> support it, so welcome back to the world of having bugs reported that
> are already fixed.
>
> --
>
> Simon Lees (Simotek) http://simotek.net
>
> Emergency Update Team keybase.io/simotek
>

Re: [E-devel] EFL Autotools freeze proposal

[Jonathan Aquilina]

Hi Simon,

Open suse is an rpm based distro correct?

If yes why not creat a copr repo that will contain the newer stuff?

Get Outlook for iOS<https://aka.ms/o0ukef>


From: Simon Lees 
Sent: Wednesday, May 1, 2019 02:13
To: Carsten Haitzler (The Rasterman); Enlightenment developer list
Subject: Re: [E-devel] EFL Autotools freeze proposal



On 30/04/2019 21:39, Carsten Haitzler (The Rasterman) wrote:
> On Tue, 30 Apr 2019 18:30:20 +0930 Simon Lees  said:
>
>>
>>
>> On 30/04/2019 17:40, Carsten Haitzler (The Rasterman) wrote:
>>> On Mon, 29 Apr 2019 15:20:19 -0700 Ross Vandegrift  said:
>>>
>>>> On Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote:
>>>>> I think everyone is missing the point. What you are saying is true but
>>>>> that is why then they say if you want newer stuff to use a PPA for it
>>>>> even though its not in the main repo's
>>>>
>>>> Yes, anyone can make a PPA. But you're talking to the maintainers of
>>>> distro packaging - we try to put packages into distros for real :)
>>>
>>> and i think this was covered - a stable distro release that will not upgrade
>>> meson out of principle (that's the definition of stable) isn't going to
>>> upgrade efl either for the same reasons... so i think the topic is kind of
>>> moot. if someone wants to make pkgs for such distros they can create
>>> upgraded meson packages too etc. if they want to go the "all done by pkgs"
>>> path :)
>>>
>>
>> This is kind of right, in an openSUSE context for a new service pack we
>> probably won't update Meson because it effects alot but we can update
>> efl / e because it doesn't affect as much, we could also add it if it
>> didn't exist. Further if a new version of efl fixed a serious bug that
>> was hard to backport we would also take the version update.
>
> tho meson doesn't affect THAT much... it's a build tool not a "runtime tool". 
> it
> isn't int he realms of libc, Xserver, bash etc.
>

Yeah there's a lot of stuff thats using meson to build now, and a meson
update effects any updates we do for anything thats built with it due to
needing full QA cycles to verify that the package was built correctly
which is why enterprise distro's prefer not to update build tools mid cycle.


>> In ubuntu's case from memory the service packs tend to only be a new
>> installer containing all the updates so its probably less likely, but I
>> don't remember how ubuntu works 100% so I could be wrong.
>
> in our case if a new efl needs a new meson, then... that's what it needs and 
> an
> efl upgrade is not likely to happen then from the core distro. ppa's and
> equivalents can manage to fill that gap. this problem will go away over time 
> as
> meson matures etc. etc. so this is a short-term problem as such. :)
>

Yep but in openSUSE's case that may mean keeping e22 through all the
leap 15.X releases which I really don't want to do because I cant
support it, so welcome back to the world of having bugs reported that
are already fixed.

--

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


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

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

Re: [E-devel] EFL Autotools freeze proposal

[Jonathan Aquilina]

The key with ubuntu to ensure if you need newer versions of meson is to ensure 
that Debian has the latest package and as long as Debian is kept up to date new 
ubuntu release will end up with them until package freeze that they have 
scheduled.

Regards,
Jonathan

-Original Message-
From: Carsten Haitzler  
Sent: 30 April 2019 14:09
To: Enlightenment developer list 
Subject: Re: [E-devel] EFL Autotools freeze proposal

On Tue, 30 Apr 2019 18:30:20 +0930 Simon Lees  said:

> 
> 
> On 30/04/2019 17:40, Carsten Haitzler (The Rasterman) wrote:
> > On Mon, 29 Apr 2019 15:20:19 -0700 Ross Vandegrift  said:
> > 
> >> On Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote:
> >>> I think everyone is missing the point. What you are saying is true 
> >>> but that is why then they say if you want newer stuff to use a PPA 
> >>> for it even though its not in the main repo's
> >>
> >> Yes, anyone can make a PPA.  But you're talking to the maintainers 
> >> of distro packaging - we try to put packages into distros for real 
> >> :)
> > 
> > and i think this was covered - a stable distro release that will not 
> > upgrade meson out of principle (that's the definition of stable) 
> > isn't going to upgrade efl either for the same reasons... so i think 
> > the topic is kind of moot. if someone wants to make pkgs for such 
> > distros they can create upgraded meson packages too etc. if they want to go 
> > the "all done by pkgs"
> > path :)
> >
> 
> This is kind of right, in an openSUSE context for a new service pack 
> we probably won't update Meson because it effects alot but we can 
> update efl / e because it doesn't affect as much, we could also add it 
> if it didn't exist. Further if a new version of efl fixed a serious 
> bug that was hard to backport we would also take the version update.

tho meson doesn't affect THAT much... it's a build tool not a "runtime tool". 
it isn't int he realms of libc, Xserver, bash etc.

> In ubuntu's case from memory the service packs tend to only be a new 
> installer containing all the updates so its probably less likely, but 
> I don't remember how ubuntu works 100% so I could be wrong.

in our case if a new efl needs a new meson, then... that's what it needs and an 
efl upgrade is not likely to happen then from the core distro. ppa's and 
equivalents can manage to fill that gap. this problem will go away over time as 
meson matures etc. etc. so this is a short-term problem as such. :)

> --
> 
> 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
> 
> 
> ___
> 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



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


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

Re: [E-devel] EFL Autotools freeze proposal

[Jonathan Aquilina]

Hi Simon,

What I have been mentioning was targeting Ubuntu distro’s and it is more or 
less along the same lines as you mentioned with OpenSuse

Regards,
Jonathan Aquilina
Owner EagleEyeT


From: Simon Lees 
Sent: Tuesday, April 30, 2019 11:00 AM
To: enlightenment-devel@lists.sourceforge.net
Subject: Re: [E-devel] EFL Autotools freeze proposal



On 30/04/2019 17:40, Carsten Haitzler (The Rasterman) wrote:
> On Mon, 29 Apr 2019 15:20:19 -0700 Ross Vandegrift  said:
>
>> On Mon, Apr 29, 2019 at 05:30:33AM +0000, Jonathan Aquilina wrote:
>>> I think everyone is missing the point. What you are saying is true but
>>> that is why then they say if you want newer stuff to use a PPA for it
>>> even though its not in the main repo's
>>
>> Yes, anyone can make a PPA. But you're talking to the maintainers of
>> distro packaging - we try to put packages into distros for real :)
>
> and i think this was covered - a stable distro release that will not upgrade
> meson out of principle (that's the definition of stable) isn't going to 
> upgrade
> efl either for the same reasons... so i think the topic is kind of moot. if
> someone wants to make pkgs for such distros they can create upgraded meson
> packages too etc. if they want to go the "all done by pkgs" path :)
>

This is kind of right, in an openSUSE context for a new service pack we
probably won't update Meson because it effects alot but we can update
efl / e because it doesn't affect as much, we could also add it if it
didn't exist. Further if a new version of efl fixed a serious bug that
was hard to backport we would also take the version update.

In ubuntu's case from memory the service packs tend to only be a new
installer containing all the updates so its probably less likely, but I
don't remember how ubuntu works 100% so I could be wrong.

--

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


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

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

Re: [E-devel] EFL Autotools freeze proposal

[Jonathan Aquilina]

Hi Ross,

I understand that, the issue becomes already released versions of Ubuntu and 
family. They do not just allow anything into backports unless it fixes a 
particular bug that is being encountered and it is absolutely necessary to 
update the version that was released.

In other words for Ubuntu they will tell you put it in a ppa if users want the 
bleeding edge stuff. Other than that for Ubuntu package maintainers are asked 
to get newer versions into Debian which will trickle down then into subsequent 
Ubuntu releases.

Regards,
Jonathan

Get Outlook for iOS<https://aka.ms/o0ukef>


From: Ross Vandegrift 
Sent: Tuesday, April 30, 2019 12:20 AM
To: Enlightenment developer list
Subject: Re: [E-devel] EFL Autotools freeze proposal

On Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote:
> I think everyone is missing the point. What you are saying is true but
> that is why then they say if you want newer stuff to use a PPA for it
> even though its not in the main repo's

Yes, anyone can make a PPA. But you're talking to the maintainers of
distro packaging - we try to put packages into distros for real :)

Ross


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

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

Re: [E-devel] EFL Autotools freeze proposal

[Jonathan Aquilina]

I think everyone is missing the point. What you are saying is true but that is 
why then they say if you want newer stuff to use a PPA for it even though its 
not in the main repo's

-Original Message-
From: Simon Lees  
Sent: 29 April 2019 05:59
To: enlightenment-devel@lists.sourceforge.net
Subject: Re: [E-devel] EFL Autotools freeze proposal

We are talking about LTS Ubuntu here, which i'm guessing will get a new meson 
for the next LTS version which will be released in April 2020, I would not be 
surprised if like openSUSE they do not take newer versions of most software 
into there LTS versions because this is generally what people running LTS 
versions want.

On 29/04/2019 12:51, Jonathan Aquilina wrote:
> I think what we would really need to check is if Debian has a meason 
> maintainer if yes we need to work with them to keep meason up to date in 
> Debian unstable and then the newer version will trickle its way down to each 
> new release of ubuntu.
> 
> -Original Message-
> From: Simon Lees 
> Sent: 29 April 2019 05:16
> To: enlightenment-devel@lists.sourceforge.net
> Subject: Re: [E-devel] EFL Autotools freeze proposal
> 
> 
> 
> On 26/04/2019 17:10, Jonathan Aquilina wrote:
>> Hi Ross,
>>
>> Why go through the headache of getting something backported when you can 
>> just create a ppa for all supported releases and one just add's a ppa?
>>
>> Regards,
>> Jonathan
>>
> 
> Generally because if the package is in a PPA it can't be used to build an 
> official package, so you wouldn't be able to use it to update the current efl 
> version. I'm not sure if debian allows you to use a backports package to 
> build a package in stable, but i'm guessing you could use it to build a 
> package in backports.
> 
> 
>> On 25/04/2019, 22:56, "Ross Vandegrift"  wrote:
>>
>>   On Thu, Apr 25, 2019 at 04:40:40PM +, Jonathan Aquilina wrote:
>>   > Hi Ross thanks for the tips, I don't think it is that easy to get
>>   > something in to backports unless it fixes a bug or security
>>   > vulnerability hence the use of PPA's they allow for bleeding edge
>>   > stuff.
>>   
>>   I think you're mixing up backports & stable.  Stable releases only
>>   accept security fixes & small changes.  Backports provides a path for
>>   selectively providing newer versions of software to stable.  It's an
>>   opt-in repo.  See: https://help.ubuntu.com/community/UbuntuBackports
>>   (The same is true for Debian.)
>>   
>>   It shouldn't be too hard to get new backports accepted - the hardest
>>   piece is probably finding someone to do the testing.
>>   
>>   Ross
>>   
>>   
>>   ___
>>   enlightenment-devel mailing list
>>   enlightenment-devel@lists.sourceforge.net
>>   
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>   
>>
>>
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
> 

-- 

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


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

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

Re: [E-devel] EFL Autotools freeze proposal

[Jonathan Aquilina]

I think what we would really need to check is if Debian has a meason maintainer 
if yes we need to work with them to keep meason up to date in Debian unstable 
and then the newer version will trickle its way down to each new release of 
ubuntu.

-Original Message-
From: Simon Lees  
Sent: 29 April 2019 05:16
To: enlightenment-devel@lists.sourceforge.net
Subject: Re: [E-devel] EFL Autotools freeze proposal



On 26/04/2019 17:10, Jonathan Aquilina wrote:
> Hi Ross,
> 
> Why go through the headache of getting something backported when you can just 
> create a ppa for all supported releases and one just add's a ppa?
> 
> Regards,
> Jonathan
> 

Generally because if the package is in a PPA it can't be used to build an 
official package, so you wouldn't be able to use it to update the current efl 
version. I'm not sure if debian allows you to use a backports package to build 
a package in stable, but i'm guessing you could use it to build a package in 
backports.


> On 25/04/2019, 22:56, "Ross Vandegrift"  wrote:
> 
>  On Thu, Apr 25, 2019 at 04:40:40PM +, Jonathan Aquilina wrote:
>  > Hi Ross thanks for the tips, I don't think it is that easy to get
>  > something in to backports unless it fixes a bug or security
>  > vulnerability hence the use of PPA's they allow for bleeding edge
>  > stuff.
>  
>  I think you're mixing up backports & stable.  Stable releases only
>  accept security fixes & small changes.  Backports provides a path for
>  selectively providing newer versions of software to stable.  It's an
>  opt-in repo.  See: https://help.ubuntu.com/community/UbuntuBackports
>  (The same is true for Debian.)
>  
>  It shouldn't be too hard to get new backports accepted - the hardest
>  piece is probably finding someone to do the testing.
>  
>  Ross
>  
>  
>  ___
>  enlightenment-devel mailing list
>  enlightenment-devel@lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>  
> 
> 
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 

-- 

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


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

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

Re: [E-devel] Seeking inout for Enlightenment Developer Days 2019

[Jonathan Aquilina]

Hi Stefan, yes it would be the same location as last time. But then again it 
doesn’t have to be we can meet at a restaurant with WIFI if you guys want we 
can enjoy drinks and food easily and have no issues with a locked down 
university network.

Regards,
Jonathan

-Original Message-
From: Marcel Hollerbach  
Sent: 25 April 2019 11:53
To: Enlightenment developer list 
Subject: Re: [E-devel] Seeking inout for Enlightenment Developer Days 2019



On 4/25/19 11:48 AM, Stefan Schmidt wrote:
> Hello.
> 
> We did not come around to have EDDs last year and we shoul do better 
> this year again. :-)
> 
> Right now I would like to seek some inout on where and when.
> 
> Right now we seem to have the following location offers:
> o Jonathan offered Malta again (Would that be the same location as 
> last
> time?)
> o Stefan could offer the SRUK office in Staines, UK o Marcel might be 
> able to offer hosting at the University in Karlsruhe, Germany
> 
> I remember Paris was nice due to the french community parts. Anyone 
> could offer hosting there?
> 
> 
> The other input vector would be dates. We normally aim for
> Saturday+Sunday. That should work best for the community. Is that 
> Saturday+still
> accurate?
> 
> July and August have already been announced as problematic due to 
> summer vacations. May would be to early to make this happen. That 
> leaves June or September onwards. Preferences?

Just as a sidenote: I needed to give informations *when* i wanted to have rooms 
in the university.
So if there is room in the university, its the 22. / 23.06 or 29./30.06

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

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

Re: [E-devel] EFL Autotools freeze proposal

[Jonathan Aquilina]

Hi Ross,

Why go through the headache of getting something backported when you can just 
create a ppa for all supported releases and one just add's a ppa?

Regards,
Jonathan

On 25/04/2019, 22:56, "Ross Vandegrift"  wrote:

On Thu, Apr 25, 2019 at 04:40:40PM +, Jonathan Aquilina wrote:
> Hi Ross thanks for the tips, I don't think it is that easy to get
> something in to backports unless it fixes a bug or security
> vulnerability hence the use of PPA's they allow for bleeding edge
> stuff.

I think you're mixing up backports & stable.  Stable releases only
accept security fixes & small changes.  Backports provides a path for
selectively providing newer versions of software to stable.  It's an
opt-in repo.  See: https://help.ubuntu.com/community/UbuntuBackports
(The same is true for Debian.)

It shouldn't be too hard to get new backports accepted - the hardest
piece is probably finding someone to do the testing.

Ross


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



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

Re: [E-devel] EFL Autotools freeze proposal

[Jonathan Aquilina]

Hi Ross thanks for the tips, I don't think it is that easy to get something in 
to backports unless it fixes a bug or security vulnerability hence the use of 
PPA's they allow for bleeding edge stuff.

Jonathan

-Original Message-
From: Ross Vandegrift  
Sent: 25 April 2019 18:31
To: Enlightenment developer list 
Subject: Re: [E-devel] EFL Autotools freeze proposal

On Thu, Apr 25, 2019 at 07:45:41AM +, Jonathan Aquilina wrote:
> @Stefan Schmidt I did a bit of digging one would need to package and 
> setup a PPA to be able to support any and all versions of meason in 
> this case in terms of supported releases. If you like I can try and 
> learn how to package and get something going in terms of a PPA for 
> meason and hell maybe even a PPA for enlightenment.

Hi Jonathan, if you're interested, start here:
https://wiki.ubuntu.com/UbuntuBackports
meson 0.49 from disco cleanly builds in bionic, though I didn't do any testing 
of the result. (the meson tests do pass during build)

The Debian packages for efl 1.21 & e22 are in disco as well.  efl could 
probably be backported now, e might need newer meson in bionic-backports first.

Ross


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


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

Re: [E-devel] EFL Autotools freeze proposal

[Jonathan Aquilina]

@Stefan Schmidt I did a bit of digging one would need to package and setup a 
PPA to be able to support any and all versions of meason in this case in terms 
of supported releases. If you like I can try and learn how to package and get 
something going in terms of a PPA for meason and hell maybe even a PPA for 
enlightenment.

-Original Message-
From: Stefan Schmidt  
Sent: 25 April 2019 09:43
To: Carsten Haitzler (The Rasterman) ; Enlightenment 
developer list 
Subject: Re: [E-devel] EFL Autotools freeze proposal

Hello.

On 24.04.19 23:23, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 24 Apr 2019 10:27:26 +0200 Stefan Schmidt 
> 
> said:
> 
>> Hello.
>>
>> On 17.04.19 15:15, Carsten Haitzler (The Rasterman) wrote:
>>> On Wed, 17 Apr 2019 08:19:35 -0400 Mike Blumenkrantz 
>>>  said:
>>>
 Hi,

 We are currently in the 1.23 release cycle, and it seems agreed 
 upon that we are planning to remove autotools prior to the 1.23 
 release. Overall, the meson build is in reasonable shape--there are 
 some small issues on our main platforms (and larger ones for 
 Windows)--and it should not be an issue to meet this goal.
>>>
>>> i thought meson was in better shape...
>>>
 With this in mind, I would like to propose a freeze on the 
 autotools build starting Friday. This means that we no longer 
 modify the autotools build in any way in the master branch 
 (excepting outstanding patches in phab), and instead focus entirely on 
 ensuring the quality of the meson build system.
>>>
>>> i think we should push this off a few more weeks/month or 2.
>>
>> I would like to get reports on what is actually missing or problematic.
>> We can push back the freeze a bit, but its only a freeze, not the 
>> autotools removal. And we need people to switch over to see if all 
>> the crazy use cases we do not have are covered.
> 
> the issue i saw got fixed by bu5hm4n since, but we really need to go 
> over everything in detail before removing autofoo - ensure it matches 
> up correctly and installs the same things in the same places before removal.

One test that should shed some light one things is to build and install efl 
with autotools as well as meson and compare the two destirs to find differences 
in the install.

windows support
> is another big one. do we know the state on osx?

OSX is building with meson for a long time on CI for every push.

>>>
 There is not much action which would need to be taken for this:
 * stop patching build files
 * disable CI jobs for autotools


 I think this would help to streamline build system development and 
 reduce overhead for this release.
>>>
>>> i agree on this - but the autofoo needs to still work and be up to 
>>> date until the point where meson is equivalent - the windows work is 
>>> one ware it needs to catch up on for sure as well as some other 
>>> niggles. get all of these up to snuff and... yup. drop autotools.
>>
>> ok, so a concrete list of things that blocks autotools freeze and removal:
>>
>> 1) Windows port: ecore_win32 (gdi and ddraw engines) need to work, 
>> maybe more to come, feedback from Vincent needed.
> 
> yup.
> 
>> 2) Meson minumim version requirement: Need to check if there is a 
>> backport for Ubuntu LTS, maybe a list with meson versions on 
>> different distros?
> 
> there has to be a line we draw. thing of this: RH support their distro 
> for 10 years. does that means we need to also rely on 10 year old 
> build tools too because that is what distro does? just because distros 
> are conservative doesn't necessarily mean we have to also be.

This is very similar to how we work with new dependencies or new version of 
deps. Aiming to support the *latest* LTS release from distros should be a goal, 
if possible.

When the meson version was brought up as problem the last tiem I remember 
talking to Marcel to find out if that version is needed for performance 
improvements or if it has fixes that are needed to actually build efl with 
meson at all. IIRC it was the last one.

Still waiting on Simotek about which version of Suse he wants to support. Also 
Ubuntu LTS needs digging if there is a backport.

Right now I do not see this as a dramatic setback. We still have at least 4 
months to go before the next release (new distros will ship or get updated). 
What we should avoid though is to update the meson version requirement.

> now, that being said, it does present a problem. this problem will 
> eventually go away in time, so perhaps it means no efl upgrade on 
> those distros unless they also get a backported newer meson too. the 
> pip solution also works in many cases but not so much for official 
> packagers as they have to stick to tools provided on the distro, but 
> packages can be built in a users environment where they used pip to 
> get a newer meson, so it can be done. it just requires being a bit dirty.

For developers and users building from git its most likely 

Re: [E-devel] EFL Autotools freeze proposal

[Jonathan Aquilina]

Isn’t it better to get the documentation sorted so we can start encouraging 
people to test meson and report any issues they find with it?

-Original Message-
From: Marcel Hollerbach  
Sent: 25 April 2019 08:31
To: Enlightenment developer list 
Subject: Re: [E-devel] EFL Autotools freeze proposal

There are no official docuemtnations on the website yet. And i think there will 
be none by the time autotools is still the prefered way of building.

On 4/25/19 8:23 AM, Jonathan Aquilina wrote:
> Hi Marcel,
> 
> What about documentation on website on how to build with meason on osx is 
> there anything of that sort in place?
> 
> Regards,
> Jonathan
> 
> -Original Message-
> From: Marcel Hollerbach 
> Sent: 25 April 2019 08:19
> To: Enlightenment developer list 
> 
> Subject: Re: [E-devel] EFL Autotools freeze proposal
> 
> Hi,
> 
> you can find our build definitions for osx in
> https://git.enlightenment.org/core/efl.git/tree/.ci/ci-configure.sh#n4
> 9
> 
> Things do work on macos, you can rendering with cocoa, beside the normal 
> rendering bugs, things are normal there.
> 
> Greetings,
>bu5hm4n
> 
> On 4/25/19 7:20 AM, Jonathan Aquilina wrote:
>> Hi Guys,
>>
>> Regarding the state of things on OSX is the documentation updated to reflect 
>> the changes for meason as I am willing to test and report back to you guys 
>> with feed back.
>>
>> Regards,
>> Jonathan
>>
>> -Original Message-
>> From: Carsten Haitzler 
>> Sent: 24 April 2019 23:24
>> To: Enlightenment developer list
>> 
>> Subject: Re: [E-devel] EFL Autotools freeze proposal
>>
>> On Wed, 24 Apr 2019 10:27:26 +0200 Stefan Schmidt 
>> 
>> said:
>>
>>> Hello.
>>>
>>> On 17.04.19 15:15, Carsten Haitzler (The Rasterman) wrote:
>>>> On Wed, 17 Apr 2019 08:19:35 -0400 Mike Blumenkrantz 
>>>>  said:
>>>>
>>>>> Hi,
>>>>>
>>>>> We are currently in the 1.23 release cycle, and it seems agreed 
>>>>> upon that we are planning to remove autotools prior to the 1.23 
>>>>> release. Overall, the meson build is in reasonable shape--there 
>>>>> are some small issues on our main platforms (and larger ones for 
>>>>> Windows)--and it should not be an issue to meet this goal.
>>>>
>>>> i thought meson was in better shape...
>>>>
>>>>> With this in mind, I would like to propose a freeze on the 
>>>>> autotools build starting Friday. This means that we no longer 
>>>>> modify the autotools build in any way in the master branch 
>>>>> (excepting outstanding patches in phab), and instead focus entirely on 
>>>>> ensuring the quality of the meson build system.
>>>>
>>>> i think we should push this off a few more weeks/month or 2.
>>>
>>> I would like to get reports on what is actually missing or problematic.
>>> We can push back the freeze a bit, but its only a freeze, not the 
>>> autotools removal. And we need people to switch over to see if all 
>>> the crazy use cases we do not have are covered.
>>
>> the issue i saw got fixed by bu5hm4n since, but we really need to go over 
>> everything in detail before removing autofoo - ensure it matches up 
>> correctly and installs the same things in the same places before removal. 
>> windows support is another big one. do we know the state on osx?
>>
>>>>
>>>>> There is not much action which would need to be taken for this:
>>>>> * stop patching build files
>>>>> * disable CI jobs for autotools
>>>>>
>>>>>
>>>>> I think this would help to streamline build system development and 
>>>>> reduce overhead for this release.
>>>>
>>>> i agree on this - but the autofoo needs to still work and be up to 
>>>> date until the point where meson is equivalent - the windows work 
>>>> is one ware it needs to catch up on for sure as well as some other 
>>>> niggles. get all of these up to snuff and... yup. drop autotools.
>>>
>>> ok, so a concrete list of things that blocks autotools freeze and removal:
>>>
>>> 1) Windows port: ecore_win32 (gdi and ddraw engines) need to work, 
>>> maybe more to come, feedback from Vincent needed.
>>
>> yup.
>>
>>> 2) Meson minumim version requirement: Need to check if there is a 
>>> backport for Ubuntu LTS, maybe a list with meson versio

Re: [E-devel] EFL Autotools freeze proposal

[Jonathan Aquilina]

Hi Marcel,

What about documentation on website on how to build with meason on osx is there 
anything of that sort in place?

Regards,
Jonathan

-Original Message-
From: Marcel Hollerbach  
Sent: 25 April 2019 08:19
To: Enlightenment developer list 
Subject: Re: [E-devel] EFL Autotools freeze proposal

Hi,

you can find our build definitions for osx in
https://git.enlightenment.org/core/efl.git/tree/.ci/ci-configure.sh#n49

Things do work on macos, you can rendering with cocoa, beside the normal 
rendering bugs, things are normal there.

Greetings,
   bu5hm4n

On 4/25/19 7:20 AM, Jonathan Aquilina wrote:
> Hi Guys,
> 
> Regarding the state of things on OSX is the documentation updated to reflect 
> the changes for meason as I am willing to test and report back to you guys 
> with feed back.
> 
> Regards,
> Jonathan
> 
> -Original Message-
> From: Carsten Haitzler 
> Sent: 24 April 2019 23:24
> To: Enlightenment developer list 
> 
> Subject: Re: [E-devel] EFL Autotools freeze proposal
> 
> On Wed, 24 Apr 2019 10:27:26 +0200 Stefan Schmidt 
> 
> said:
> 
>> Hello.
>>
>> On 17.04.19 15:15, Carsten Haitzler (The Rasterman) wrote:
>>> On Wed, 17 Apr 2019 08:19:35 -0400 Mike Blumenkrantz 
>>>  said:
>>>
>>>> Hi,
>>>>
>>>> We are currently in the 1.23 release cycle, and it seems agreed 
>>>> upon that we are planning to remove autotools prior to the 1.23 
>>>> release. Overall, the meson build is in reasonable shape--there are 
>>>> some small issues on our main platforms (and larger ones for 
>>>> Windows)--and it should not be an issue to meet this goal.
>>>
>>> i thought meson was in better shape...
>>>
>>>> With this in mind, I would like to propose a freeze on the 
>>>> autotools build starting Friday. This means that we no longer 
>>>> modify the autotools build in any way in the master branch 
>>>> (excepting outstanding patches in phab), and instead focus entirely on 
>>>> ensuring the quality of the meson build system.
>>>
>>> i think we should push this off a few more weeks/month or 2.
>>
>> I would like to get reports on what is actually missing or problematic.
>> We can push back the freeze a bit, but its only a freeze, not the 
>> autotools removal. And we need people to switch over to see if all 
>> the crazy use cases we do not have are covered.
> 
> the issue i saw got fixed by bu5hm4n since, but we really need to go over 
> everything in detail before removing autofoo - ensure it matches up correctly 
> and installs the same things in the same places before removal. windows 
> support is another big one. do we know the state on osx?
> 
>>>
>>>> There is not much action which would need to be taken for this:
>>>> * stop patching build files
>>>> * disable CI jobs for autotools
>>>>
>>>>
>>>> I think this would help to streamline build system development and 
>>>> reduce overhead for this release.
>>>
>>> i agree on this - but the autofoo needs to still work and be up to 
>>> date until the point where meson is equivalent - the windows work is 
>>> one ware it needs to catch up on for sure as well as some other 
>>> niggles. get all of these up to snuff and... yup. drop autotools.
>>
>> ok, so a concrete list of things that blocks autotools freeze and removal:
>>
>> 1) Windows port: ecore_win32 (gdi and ddraw engines) need to work, 
>> maybe more to come, feedback from Vincent needed.
> 
> yup.
> 
>> 2) Meson minumim version requirement: Need to check if there is a 
>> backport for Ubuntu LTS, maybe a list with meson versions on 
>> different distros?
> 
> there has to be a line we draw. thing of this: RH support their distro for 10 
> years. does that means we need to also rely on 10 year old build tools too 
> because that is what distro does? just because distros are conservative 
> doesn't necessarily mean we have to also be.
> 
> now, that being said, it does present a problem. this problem will eventually 
> go away in time, so perhaps it means no efl upgrade on those distros unless 
> they also get a backported newer meson too. the pip solution also works in 
> many cases but not so much for official packagers as they have to stick to 
> tools provided on the distro, but packages can be built in a users 
> environment where they used pip to get a newer meson, so it can be done. it 
> just requires being a bit dirty.
> 
>> Pretty sure there will be more, but the question is if we find out 
>&

Re: [E-devel] EFL Autotools freeze proposal

[Jonathan Aquilina]

Hi Guys,

Regarding the state of things on OSX is the documentation updated to reflect 
the changes for meason as I am willing to test and report back to you guys with 
feed back.

Regards,
Jonathan

-Original Message-
From: Carsten Haitzler  
Sent: 24 April 2019 23:24
To: Enlightenment developer list 
Subject: Re: [E-devel] EFL Autotools freeze proposal

On Wed, 24 Apr 2019 10:27:26 +0200 Stefan Schmidt 
said:

> Hello.
> 
> On 17.04.19 15:15, Carsten Haitzler (The Rasterman) wrote:
> > On Wed, 17 Apr 2019 08:19:35 -0400 Mike Blumenkrantz 
> >  said:
> > 
> >> Hi,
> >>
> >> We are currently in the 1.23 release cycle, and it seems agreed 
> >> upon that we are planning to remove autotools prior to the 1.23 
> >> release. Overall, the meson build is in reasonable shape--there are 
> >> some small issues on our main platforms (and larger ones for 
> >> Windows)--and it should not be an issue to meet this goal.
> > 
> > i thought meson was in better shape...
> > 
> >> With this in mind, I would like to propose a freeze on the 
> >> autotools build starting Friday. This means that we no longer 
> >> modify the autotools build in any way in the master branch 
> >> (excepting outstanding patches in phab), and instead focus entirely on 
> >> ensuring the quality of the meson build system.
> > 
> > i think we should push this off a few more weeks/month or 2.
> 
> I would like to get reports on what is actually missing or problematic.
> We can push back the freeze a bit, but its only a freeze, not the 
> autotools removal. And we need people to switch over to see if all the 
> crazy use cases we do not have are covered.

the issue i saw got fixed by bu5hm4n since, but we really need to go over 
everything in detail before removing autofoo - ensure it matches up correctly 
and installs the same things in the same places before removal. windows support 
is another big one. do we know the state on osx?

> > 
> >> There is not much action which would need to be taken for this:
> >> * stop patching build files
> >> * disable CI jobs for autotools
> >>
> >>
> >> I think this would help to streamline build system development and 
> >> reduce overhead for this release.
> > 
> > i agree on this - but the autofoo needs to still work and be up to 
> > date until the point where meson is equivalent - the windows work is 
> > one ware it needs to catch up on for sure as well as some other 
> > niggles. get all of these up to snuff and... yup. drop autotools.
> 
> ok, so a concrete list of things that blocks autotools freeze and removal:
> 
> 1) Windows port: ecore_win32 (gdi and ddraw engines) need to work, 
> maybe more to come, feedback from Vincent needed.

yup.

> 2) Meson minumim version requirement: Need to check if there is a 
> backport for Ubuntu LTS, maybe a list with meson versions on different 
> distros?

there has to be a line we draw. thing of this: RH support their distro for 10 
years. does that means we need to also rely on 10 year old build tools too 
because that is what distro does? just because distros are conservative doesn't 
necessarily mean we have to also be.

now, that being said, it does present a problem. this problem will eventually 
go away in time, so perhaps it means no efl upgrade on those distros unless 
they also get a backported newer meson too. the pip solution also works in many 
cases but not so much for official packagers as they have to stick to tools 
provided on the distro, but packages can be built in a users environment where 
they used pip to get a newer meson, so it can be done. it just requires being a 
bit dirty.

> Pretty sure there will be more, but the question is if we find out 
> before we drop autotools or not.
> 
> regards
> Stefan Schmidt
> 
> 
> ___
> 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



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


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

Re: [E-devel] EFL Autotools freeze proposal

[Jonathan Aquilina]

Morning Stefan,

Take a look at 

https://launchpad.net/ubuntu/+source/meson

That might be able to point you in the right direction as to what versions are 
available for what release. What I couldn't find though is if a PPA is 
available for newer versions on already released distro's such as 18.04

Regards,
Jonathan

-Original Message-
From: Stefan Schmidt  
Sent: 24 April 2019 10:27
To: enlightenment-devel@lists.sourceforge.net
Subject: Re: [E-devel] EFL Autotools freeze proposal

Hello.

On 17.04.19 15:15, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 17 Apr 2019 08:19:35 -0400 Mike Blumenkrantz 
>  said:
> 
>> Hi,
>>
>> We are currently in the 1.23 release cycle, and it seems agreed upon 
>> that we are planning to remove autotools prior to the 1.23 release. 
>> Overall, the meson build is in reasonable shape--there are some small 
>> issues on our main platforms (and larger ones for Windows)--and it 
>> should not be an issue to meet this goal.
> 
> i thought meson was in better shape...
> 
>> With this in mind, I would like to propose a freeze on the autotools 
>> build starting Friday. This means that we no longer modify the 
>> autotools build in any way in the master branch (excepting 
>> outstanding patches in phab), and instead focus entirely on ensuring the 
>> quality of the meson build system.
> 
> i think we should push this off a few more weeks/month or 2.

I would like to get reports on what is actually missing or problematic.
We can push back the freeze a bit, but its only a freeze, not the autotools 
removal. And we need people to switch over to see if all the crazy use cases we 
do not have are covered.

> 
>> There is not much action which would need to be taken for this:
>> * stop patching build files
>> * disable CI jobs for autotools
>>
>>
>> I think this would help to streamline build system development and 
>> reduce overhead for this release.
> 
> i agree on this - but the autofoo needs to still work and be up to 
> date until the point where meson is equivalent - the windows work is 
> one ware it needs to catch up on for sure as well as some other 
> niggles. get all of these up to snuff and... yup. drop autotools.

ok, so a concrete list of things that blocks autotools freeze and removal:

1) Windows port: ecore_win32 (gdi and ddraw engines) need to work, maybe more 
to come, feedback from Vincent needed.

2) Meson minumim version requirement: Need to check if there is a backport for 
Ubuntu LTS, maybe a list with meson versions on different distros?

Pretty sure there will be more, but the question is if we find out before we 
drop autotools or not.

regards
Stefan Schmidt


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


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

Re: [E-devel] 1.22 schedule proposal - updated

[Jonathan Aquilina]

Hi Stefan,

Sorry about the changes to the plan that wasn’t my intention. I am in complete 
agreement with you on the below points. When ever you are ready with the script 
let me know and we can get things going with the infrastructure with a linode I 
have and at least get the release out and running.

Regards,
Jonathan

On 19/02/2019, 09:23, "Stefan Schmidt"  wrote:

Hello.

On 18.02.19 07:07, Jonathan Aquilina wrote:
> Morning Simon,
> 
> What I am thinking is the master branch would have the weekly releases 
for developers and stable releases would be  once a month.

No, sorry. I don't think that makes sense. We don't need a tarball
packaged from git without any extra work. People who want bleeding edge
stay on git. If we would provide snapshots people would expect some
extra testing on them which would simply not happen.

> What do you think about this?

I think we should stick with what we talked about and not mix in other
things every day.

1) Try a 5 months release schedule to see if that works better and lifts
some pressure form the 3 months cycle.

2) For stable updates we will have a cron job running that checks every
Monday if there are new patches in the stable branches compared to the
last stable update. If there are we trigger the process to do a new release.

In practice that would mean we do it really "on-demand", as in, some fix
was seen worthwhile backporting. I would imagine that will give us
weekly updates for the first few weeks after a major release and after
that only occasionally an update.

regards
Stefan Schmidt


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



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

Re: [E-devel] 1.22 schedule proposal - updated

[Jonathan Aquilina]

Hi Raster,

What about those end users that might want more bleeding edge stuff to test 
etc? Currently how often are new tarballs generated prior to a stable release?

Regards,
Jonathan

On 18/02/2019, 09:34, "Carsten Haitzler"  wrote:

On Mon, 18 Feb 2019 06:07:18 +0000 Jonathan Aquilina 

said:

> Morning Simon,
> 
> What I am thinking is the master branch would have the weekly releases for
> developers and stable releases would be  once a month.

why weekly releases? that's not going to have any release PROCESS done other
than "make distcheck" or "ninja dist" - i don't see any stabilization work 
or
QA being done beyond that (it won't be sustainable at that rate without
basically no QA). at that point we have git master itself - so anyone
interested in such things can just use git master.

> What do you think about this?
> 
> Regards,
> Jonathan
> 
> -Original Message-
> From: Simon Lees  
> Sent: 17 February 2019 23:16
> To: enlightenment-devel@lists.sourceforge.net
> Subject: Re: [E-devel] 1.22 schedule proposal - updated
> 
> 
> 
> On 16/02/2019 20:24, Jonathan Aquilina wrote:
> > Hi Simon,
> > 
> > My idea for that is more for developers to have more frequent snapshots
> > granted there is the repository that one can pull from but that will 
always
> > be the latest commits you will be pulling from the repo.
> > 
> But these snapshots would be different, most developers are following the
> master branch rather then the 1.22 branch that we use for doing point 
releases
> 
> -- 
> 
> 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
> 
> 
> ___
> 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




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

Re: [E-devel] 1.22 schedule proposal - updated

[Jonathan Aquilina]

Morning Simon,

What I am thinking is the master branch would have the weekly releases for 
developers and stable releases would be  once a month.

What do you think about this?

Regards,
Jonathan

-Original Message-
From: Simon Lees  
Sent: 17 February 2019 23:16
To: enlightenment-devel@lists.sourceforge.net
Subject: Re: [E-devel] 1.22 schedule proposal - updated



On 16/02/2019 20:24, Jonathan Aquilina wrote:
> Hi Simon,
> 
> My idea for that is more for developers to have more frequent snapshots 
> granted there is the repository that one can pull from but that will always 
> be the latest commits you will be pulling from the repo.
> 
But these snapshots would be different, most developers are following the 
master branch rather then the 1.22 branch that we use for doing point releases

-- 

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


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

Re: [E-devel] 1.22 schedule proposal - updated

[Jonathan Aquilina]

Hi Simon,

My idea for that is more for developers to have more frequent snapshots granted 
there is the repository that one can pull from but that will always be the 
latest commits you will be pulling from the repo.

-Original Message-
From: Simon Lees  
Sent: 16 February 2019 10:52
To: enlightenment-devel@lists.sourceforge.net
Subject: Re: [E-devel] 1.22 schedule proposal - updated



On 16/02/2019 14:33, Jonathan Aquilina wrote:
> Hi Stefan,
> 
> I thought you were making a few changes to it given we are doing 5 month 
> major releases and then weekly point releases.
> 
> Regards,
> Jonathan.
> 

Personally I think Monthly point releases are probably more then enough unless 
we find a major issue. Distro's who are the major users of them probably won't 
update once a week, I'd also expect that once a release settles we probably 
wouldn't even see new commits once a week.

-- 

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


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

Re: [E-devel] 1.22 schedule proposal - updated

[Jonathan Aquilina]

Hi Stefan,

I thought you were making a few changes to it given we are doing 5 month major 
releases and then weekly point releases.

Regards,
Jonathan.

-Original Message-
From: Stefan Schmidt  
Sent: 15 February 2019 19:56
To: enlightenment-devel@lists.sourceforge.net
Subject: Re: [E-devel] 1.22 schedule proposal - updated

Hello Jonathan.

On 15.02.19 16:41, Jonathan Aquilina wrote:
> Hi Stefan,
> 
> Not to derail the below in terms of the scripts that will be used to generate 
> the release do you have an ETA for these scripts or will it be sometime next 
> week?

Not sure what you are talking about here. It will be the same release script I 
used all the time. I pointed you several times to it. Last time when we had or 
IRC chat.

regards
Stefan Schmidt

> -Original Message-
> From: Stefan Schmidt 
> Sent: 15 February 2019 16:37
> To: enlightenment-devel@lists.sourceforge.net
> Subject: Re: [E-devel] 1.22 schedule proposal - updated
> 
> Hello.
> 
> We pushed back on the initial schedule to not get everyone caught by surprise 
> of a freeze.
> 
> We had some extra weeks now and I wonder if the following updated schedule 
> would work?
> 
> === Schedule ===
> 2018-08-17 Merge window for 1.22 opens
> 2019-02-20 Notice about soon ending merge window
> 2019-02-28 Merge window is over. Freeze in place.
> * Only bug fixes from this point
> * Alpha release tarball
> * One month stabilization phase starts
> 2019-03-07 Beta1 release tarball
> * Only critical fixes from this point
> 2019-03-14 Beta2 release tarball
> 2019-03-21 EFL 1.22 is out
> 
> As a sidenote I would consider this the last release with autotools. We will 
> also have a meson based tarball ready at that point which we would appreciate 
> testing from packagers. After the release is out we should remove autotools 
> support from master to focus on one build system only.
> Autotools will only be kept use in the 1.22.x releases for maintenance.
> 
> If this schedule does not work for you for a good reason speak up now.
> 
> regards
> Stefan Schmidt
> 
> 
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 
> 
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


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


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

Re: [E-devel] 1.22 schedule proposal - updated

[Jonathan Aquilina]

Hi Stefan,

Not to derail the below in terms of the scripts that will be used to generate 
the release do you have an ETA for these scripts or will it be sometime next 
week?

-Original Message-
From: Stefan Schmidt  
Sent: 15 February 2019 16:37
To: enlightenment-devel@lists.sourceforge.net
Subject: Re: [E-devel] 1.22 schedule proposal - updated

Hello.

We pushed back on the initial schedule to not get everyone caught by surprise 
of a freeze.

We had some extra weeks now and I wonder if the following updated schedule 
would work?

=== Schedule ===
2018-08-17 Merge window for 1.22 opens
2019-02-20 Notice about soon ending merge window
2019-02-28 Merge window is over. Freeze in place.
* Only bug fixes from this point
* Alpha release tarball
* One month stabilization phase starts
2019-03-07 Beta1 release tarball
* Only critical fixes from this point
2019-03-14 Beta2 release tarball
2019-03-21 EFL 1.22 is out

As a sidenote I would consider this the last release with autotools. We will 
also have a meson based tarball ready at that point which we would appreciate 
testing from packagers. After the release is out we should remove autotools 
support from master to focus on one build system only.
Autotools will only be kept use in the 1.22.x releases for maintenance.

If this schedule does not work for you for a good reason speak up now.

regards
Stefan Schmidt


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


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

Re: [E-devel] Release plans

[Jonathan Aquilina]

Ok will try and put Debian on the system not a problem.

On 12/02/2019, 11:00, "Simon Lees"  wrote:



On 12/02/2019 18:55, Jonathan Aquilina wrote:
> I tend to use centos these days but my concern is given the fact things 
are older versions for example maybe for compilers doe we for instance have a 
compiler base line requirement?
> 

With a openSUSE hat on, currently we have meson 0.46.0 and gcc7, Debian
has Meson 0.37.0 (but newer in backports) and gcc6. At one point we were
using as long as most distro's had it, its ok which mostly meant if it
was in debian (I think we cared less about centos as there wasn't many e
users there). At some point we went to Meson 0.40.0 though because the
wayland stack had also gone to there.

-- 

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




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

Re: [E-devel] Release plans

[Jonathan Aquilina]

I tend to use centos these days but my concern is given the fact things are 
older versions for example maybe for compilers doe we for instance have a 
compiler base line requirement?

Get Outlook for iOS<https://aka.ms/o0ukef>


From: Simon Lees 
Sent: Tuesday, February 12, 2019 09:23
To: enlightenment-devel@lists.sourceforge.net
Subject: Re: [E-devel] Release plans



On 12/02/2019 18:35, Jonathan Aquilina wrote:
> Good morning everyone,
>
> Yesterday both Stefan and myself discussed CI and releases.
>
> In terms of CI I will be setting up a team on azure so we can do some bench 
> marking on performance compared to Travis as well as how many simultaneous 
> builds can be run at any one time to see if there are any limitations.
>
> In regards to releasing of major releases we agreed that 3 months seems to be 
> a bit short and are looking at changing that to 5 months for major release 
> and then more frequent point release in between those five months if there 
> are lots of fixes we can look at doing point releases on a weekly basis.
>
> At this stage given my scripting skills are virtually non existent and this 
> would take me a while to script Stefan is going to try this week to get me 
> the script for the releases as well as weekly point releases. After that my 
> plan is to use a linode that I have to start churning out the releases.
>
> Stefan in regards to base os for the release system would I be fine with 
> centos or would something like Debian or Ubuntu be better?

As the release is just a compressed folder with source code the release
should be the same regardless of which base os you use unless we have
bugs in the build scripts. I build the enlightenment ones on my local
openSUSE Tumbleweed machine.

--

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


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

[E-devel] Release plans

[Jonathan Aquilina]

Good morning everyone,

Yesterday both Stefan and myself discussed CI and releases.

In terms of CI I will be setting up a team on azure so we can do some bench 
marking on performance compared to Travis as well as how many simultaneous 
builds can be run at any one time to see if there are any limitations.

In regards to releasing of major releases we agreed that 3 months seems to be a 
bit short and are looking at changing that to 5 months for major release and 
then more frequent point release in between those five months if there are lots 
of fixes we can look at doing point releases on a weekly basis.

At this stage given my scripting skills are virtually non existent and this 
would take me a while to script Stefan is going to try this week to get me the 
script for the releases as well as weekly point releases. After that my plan is 
to use a linode that I have to start churning out the releases.

Stefan in regards to base os for the release system would I be fine with centos 
or would something like Debian or Ubuntu be better?

Wishing you all a pleasant day.

Regards,
Jonathan

Get Outlook for iOS

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

Re: [E-devel] 1.22 schedule proposal

[Jonathan Aquilina]

Hi Stefan,

Are you available Sunday evening by any chance?

Regards,
Jonathan

On 08/02/2019, 09:34, "Stefan Schmidt"  wrote:

Hello.

On 06.02.19 15:33, Jonathan Aquilina wrote:
> I just landed a new job which I start on Monday but I am willing to help 
and take over this. I am sure a lot more can be automated for sure.

Have you looked at the wiki page and scripts used for release handling?
Much of the mechanical work of building the tarball and pushing it out
is already scripted. Sure it could get cleaned up and maybe made more
robust, but its there.

What could be further automated is the news generation and addtition to
the wiki, sending out release mails, etc. Could all be done but it never
urged me enough to spend time on it.

> 
> I think best place to get this rolling would be to do a conference call 
or a chat on slack.

Slack or IRC. What day and time would you prefer?

regards
Stefan Schmidt

> -Original Message-
> From: Stefan Schmidt  
> Sent: 06 February 2019 13:56
> To: enlightenment-devel@lists.sourceforge.net; Jonathan Aquilina 

> Subject: Re: [E-devel] 1.22 schedule proposal
> 
> Hello Jonathan.
    > 
> On 09.01.19 16:26, Jonathan Aquilina wrote:
>> I'm ready to step and take charge of this but I think we need a bit more 
frequent minor release updates both for those in the community that want to Be 
on the bleeding edge and those that want to help bug fix more incremental 
stable releases.
> 
> So, a 1.21.2. We currently have 4 patches pending in the 1.21.x branch 
which are not in the 1.21.1 release. When announced that there will be a stable 
update we might see more backports coming.
> 
>> Stefan do you have any documentation on how release plan works?
> 
> I posted this very link to you a couple of times, but I had no feedback 
from you if that covers what you asked for.
> 
> https://phab.enlightenment.org/w/release_procedure/
> 
> Jonathan, are you willing top work on a 1.21.2 stable release?
> I can give you a hand but I would need to know if you are willing, have 
the time and the bandwidth to do this.
> 
> regards
> Stefan Schmidt
> 



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

Re: [E-devel] 1.22 schedule proposal

[Jonathan Aquilina]

Hi Stefan,

22:00 is perfect for me we can have a chat on slack regarding this and Azure CI 
side of things. Thank god for being in the same time zone makes things like 
this much easier to coordinate.

Regards,
Jonathan

On 08/02/2019, 09:47, "Stefan Schmidt"  wrote:

Hello.

On 08.02.19 09:35, Jonathan Aquilina wrote:
> Hi Stefan,
> 
> Are you available Sunday evening by any chance?

Sunday is family day. I can offer you something before I go to bed:

https://www.timeanddate.com/worldclock/meetingdetails.html?year=2019=2=10=21=0=0=37

22:00 CET timezone.

regards
Stefan Schmidt

> Regards,
> Jonathan
> 
> On 08/02/2019, 09:34, "Stefan Schmidt"  wrote:
> 
> Hello.
    >     
> On 06.02.19 15:33, Jonathan Aquilina wrote:
> > I just landed a new job which I start on Monday but I am willing to 
help and take over this. I am sure a lot more can be automated for sure.
> 
> Have you looked at the wiki page and scripts used for release 
handling?
> Much of the mechanical work of building the tarball and pushing it out
> is already scripted. Sure it could get cleaned up and maybe made more
> robust, but its there.
> 
> What could be further automated is the news generation and addtition 
to
> the wiki, sending out release mails, etc. Could all be done but it 
never
> urged me enough to spend time on it.
> 
> > 
> > I think best place to get this rolling would be to do a conference 
call or a chat on slack.
> 
> Slack or IRC. What day and time would you prefer?
> 
> regards
> Stefan Schmidt
> 
> > -Original Message-
>     > From: Stefan Schmidt  
> > Sent: 06 February 2019 13:56
> > To: enlightenment-devel@lists.sourceforge.net; Jonathan Aquilina 

> > Subject: Re: [E-devel] 1.22 schedule proposal
> > 
> > Hello Jonathan.
> > 
> > On 09.01.19 16:26, Jonathan Aquilina wrote:
> >> I'm ready to step and take charge of this but I think we need a 
bit more frequent minor release updates both for those in the community that 
want to Be on the bleeding edge and those that want to help bug fix more 
incremental stable releases.
> > 
> > So, a 1.21.2. We currently have 4 patches pending in the 1.21.x 
branch which are not in the 1.21.1 release. When announced that there will be a 
stable update we might see more backports coming.
> > 
> >> Stefan do you have any documentation on how release plan works?
> > 
> > I posted this very link to you a couple of times, but I had no 
feedback from you if that covers what you asked for.
> > 
> > https://phab.enlightenment.org/w/release_procedure/
> > 
> > Jonathan, are you willing top work on a 1.21.2 stable release?
> > I can give you a hand but I would need to know if you are willing, 
have the time and the bandwidth to do this.
> > 
> > regards
> > Stefan Schmidt
> > 
> 
> 



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

Re: [E-devel] Azure Devop's CI

[Jonathan Aquilina]

Hi Stefan,

This is something I was planning on working on given I am working on azure for 
some personal projects and potentially a massive project which atm is very 
small but can be gigantic for the aerospace sector.

I think we can add this to our discussion list for Sunday when we meet to speak 
regarding release builds.

On 08/02/2019, 09:40, "Stefan Schmidt"  wrote:

Hello.

On 06.02.19 15:32, Jonathan Aquilina wrote:
> Correct me if I am wrong but isn’t travis a bit limited to an extent.

Well, everything is limited to an extend. Only Google and Amazon have
infinite computer power ;-)

More concrete Travis is limited to 5 parallel build jobs for a OSS
project. We are over this limit which means the 6th job and further will
only start when one of the first five finished.

IIRC Azure has a higher limit here (10 parallel jobs?) that would help.
But someone would need to investigate how to use it and work on actually
doing it.

> I can actually give you guys control over this team so to speak so those 
that need to make changes can.

Sure, you can give me access, but I am looking for someone who would do
the actual work to get the efl CI builds we have running on Azure as
well. On my personal todo list its quite near the bottom. If you or
someone else thinks we should have it running on Azure I would welcome
anyone to start working at it.

> I think we need to have a chat somewhere maybe a conference call on this 
Stefan or a chat on slack.

As I wrote in the releases thread I would prefer IRC/Slack. What date
and time would ou want to have the discussion?

regards
Stefan Schmidt

> -Original Message-
> From: Stefan Schmidt  
> Sent: 06 February 2019 14:04
> To: Enlightenment developer list 
; Jonathan Aquilina 

> Subject: Re: [E-devel] Azure Devop's CI
> 
> Hello Jonathan.
    > 
> On 16.01.19 07:31, Jonathan Aquilina wrote:
>> Hi Guys,
>>
>> I am looking to propose that I setup for the project CI on azure. There 
is no charge as far as I can gather for this. It seems like I would just need 
to tie it in to git to pull in the changes and schedule runs. From what I can 
see this is ubuntu based as a platform. What do you guys think do you think 
it's a good idea to have it do CI testing on each build?
> 
> I assume you know that we already have an actively used Travis CI setup?
> https://travis-ci.org/Enlightenment/efl/branches
> 
> We have an instant github mirror by now and if azures ties into Github to 
get the new pushes that would work for us.
> 
> If you want to add an Azure CI for testing to crunch on our efl commits I 
would be interested in see how it goes. But as many other things this needs 
time and bandwidth to work at. For me personally trying out another CI system 
is interesting but way down my todo list.
> 
> If you are willing to work on this let me know. I certainly should be 
able to configure things on github top get commits notified to Azure.
> As a good starting point I would suggest to look at the .travis.yml file 
and everything below .ci/ to see what we have so far and how it is setup with 
Travis. Most of the actual build testing as well as unit tests are executed in 
docker containers and not bound to any Travis specifics. If you set things up 
to execute jobs in docker containers on Azure most of it should be possible to 
bring over.
> 
> regards
> Stefan Schmidt
> 



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

Re: [E-devel] Azure Devop's CI

[Jonathan Aquilina]

Correct me if I am wrong but isn’t travis a bit limited to an extent. I can 
actually give you guys control over this team so to speak so those that need to 
make changes can.

I think we need to have a chat somewhere maybe a conference call on this Stefan 
or a chat on slack.

-Original Message-
From: Stefan Schmidt  
Sent: 06 February 2019 14:04
To: Enlightenment developer list ; 
Jonathan Aquilina 
Subject: Re: [E-devel] Azure Devop's CI

Hello Jonathan.

On 16.01.19 07:31, Jonathan Aquilina wrote:
> Hi Guys,
> 
> I am looking to propose that I setup for the project CI on azure. There is no 
> charge as far as I can gather for this. It seems like I would just need to 
> tie it in to git to pull in the changes and schedule runs. From what I can 
> see this is ubuntu based as a platform. What do you guys think do you think 
> it's a good idea to have it do CI testing on each build?

I assume you know that we already have an actively used Travis CI setup?
https://travis-ci.org/Enlightenment/efl/branches

We have an instant github mirror by now and if azures ties into Github to get 
the new pushes that would work for us.

If you want to add an Azure CI for testing to crunch on our efl commits I would 
be interested in see how it goes. But as many other things this needs time and 
bandwidth to work at. For me personally trying out another CI system is 
interesting but way down my todo list.

If you are willing to work on this let me know. I certainly should be able to 
configure things on github top get commits notified to Azure.
As a good starting point I would suggest to look at the .travis.yml file and 
everything below .ci/ to see what we have so far and how it is setup with 
Travis. Most of the actual build testing as well as unit tests are executed in 
docker containers and not bound to any Travis specifics. If you set things up 
to execute jobs in docker containers on Azure most of it should be possible to 
bring over.

regards
Stefan Schmidt

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

Re: [E-devel] 1.22 schedule proposal

[Jonathan Aquilina]

I just landed a new job which I start on Monday but I am willing to help and 
take over this. I am sure a lot more can be automated for sure.

I think best place to get this rolling would be to do a conference call or a 
chat on slack.

-Original Message-
From: Stefan Schmidt  
Sent: 06 February 2019 13:56
To: enlightenment-devel@lists.sourceforge.net; Jonathan Aquilina 

Subject: Re: [E-devel] 1.22 schedule proposal

Hello Jonathan.

On 09.01.19 16:26, Jonathan Aquilina wrote:
> I'm ready to step and take charge of this but I think we need a bit more 
> frequent minor release updates both for those in the community that want to 
> Be on the bleeding edge and those that want to help bug fix more incremental 
> stable releases.

So, a 1.21.2. We currently have 4 patches pending in the 1.21.x branch which 
are not in the 1.21.1 release. When announced that there will be a stable 
update we might see more backports coming.

> Stefan do you have any documentation on how release plan works?

I posted this very link to you a couple of times, but I had no feedback from 
you if that covers what you asked for.

https://phab.enlightenment.org/w/release_procedure/

Jonathan, are you willing top work on a 1.21.2 stable release?
I can give you a hand but I would need to know if you are willing, have the 
time and the bandwidth to do this.

regards
Stefan Schmidt


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

Re: [E-devel] Linux subsystem on windows

[Jonathan Aquilina]

That’s another way things could go but how would you interact and restyle the 
windows windows lol

Get Outlook for iOS<https://aka.ms/o0ukef>


From: Vincent Torri 
Sent: Tuesday, January 22, 2019 10:48
To: Enlightenment developer list
Subject: Re: [E-devel] Linux subsystem on windows

On Tue, Jan 22, 2019 at 10:43 AM Felipe Magno de Almeida
 wrote:
>
> On Tue, Jan 22, 2019 at 6:39 PM Vincent Torri  wrote:
> >
> > On Tue, Jan 22, 2019 at 10:33 AM Felipe Magno de Almeida
> >  wrote:
> > >
> > > On Tue, Jan 22, 2019 at 6:12 PM Vincent Torri  
> > > wrote:
> > > >
> > > > On Tue, Jan 22, 2019 at 10:06 AM Felipe Magno de Almeida
> > > >  wrote:
> > > > >
> > > > > On Tue, Jan 22, 2019 at 5:40 PM Jonathan Aquilina
> > > > >  wrote:
> > > > > >
> > > > > > I say why not. I am willing to work on it slowly slowly.
> > > > > >
> > > > > > My question becomes do we have any stats of enlightenement usage by 
> > > > > > windows users?
> > > > >
> > > > > Considering it is completely impossible to use enlightenment on
> > > > > Windows
> > > >
> > > > not impossible, but really difficult
> > > >
> > > > I would like to mention that in the late 90's, a Windows NT port of E
> > > > 0.14 or 0.15 has been done, called e-sense (I have the sources
> > > > somewhere on my HD). It was using Litestep for the windows management.
> > >
> > > I meant impossible now. I mentioned the possibility of porting 
> > > Enlightenment
> > > wayland. I think it is probably easier than trying to use X11. However, 
> > > you
> > > would end up with Enlightenment as an application with all applications
> > > inside.
> >
> > the current desktop shell of Windows is a fullscreen application with
> > all the applications inside
>
> Yes. But then Windows applications do not work the same way as
> Linux ones would. It would be fine for people only using Linux
> applications. Maybe we could have a wayland that actually creates
> normal CreateWindowsEx for their clients, but that is a lot of work.

i was having another idea, which would make all the Windows
sapplications behave like the ones in a Unix WM : content is managed
by the application, decoration (title bar, etc ..) managed by E

Vincent


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

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

Re: [E-devel] Linux subsystem on windows

[Jonathan Aquilina]

My idea is this we start with enlightenment inside windows non native then we 
do like VMware fusion does work on native integration l. That is how I’m seeing 
it

Get Outlook for iOS<https://aka.ms/o0ukef>


From: Vincent Torri 
Sent: Tuesday, January 22, 2019 10:39
To: Enlightenment developer list
Subject: Re: [E-devel] Linux subsystem on windows

On Tue, Jan 22, 2019 at 10:33 AM Felipe Magno de Almeida
 wrote:
>
> On Tue, Jan 22, 2019 at 6:12 PM Vincent Torri  wrote:
> >
> > On Tue, Jan 22, 2019 at 10:06 AM Felipe Magno de Almeida
> >  wrote:
> > >
> > > On Tue, Jan 22, 2019 at 5:40 PM Jonathan Aquilina
> > >  wrote:
> > > >
> > > > I say why not. I am willing to work on it slowly slowly.
> > > >
> > > > My question becomes do we have any stats of enlightenement usage by 
> > > > windows users?
> > >
> > > Considering it is completely impossible to use enlightenment on
> > > Windows
> >
> > not impossible, but really difficult
> >
> > I would like to mention that in the late 90's, a Windows NT port of E
> > 0.14 or 0.15 has been done, called e-sense (I have the sources
> > somewhere on my HD). It was using Litestep for the windows management.
>
> I meant impossible now. I mentioned the possibility of porting Enlightenment
> wayland. I think it is probably easier than trying to use X11. However, you
> would end up with Enlightenment as an application with all applications
> inside.

the current desktop shell of Windows is a fullscreen application with
all the applications inside

Vincent


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

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

Re: [E-devel] Linux subsystem on windows

[Jonathan Aquilina]

Isn’t that the best way to start and then work on integrating things natively?

Get Outlook for iOS<https://aka.ms/o0ukef>


From: Felipe Magno de Almeida 
Sent: Tuesday, January 22, 2019 10:33
To: Enlightenment developer list
Subject: Re: [E-devel] Linux subsystem on windows

On Tue, Jan 22, 2019 at 6:12 PM Vincent Torri  wrote:
>
> On Tue, Jan 22, 2019 at 10:06 AM Felipe Magno de Almeida
>  wrote:
> >
> > On Tue, Jan 22, 2019 at 5:40 PM Jonathan Aquilina
> >  wrote:
> > >
> > > I say why not. I am willing to work on it slowly slowly.
> > >
> > > My question becomes do we have any stats of enlightenement usage by 
> > > windows users?
> >
> > Considering it is completely impossible to use enlightenment on
> > Windows
>
> not impossible, but really difficult
>
> I would like to mention that in the late 90's, a Windows NT port of E
> 0.14 or 0.15 has been done, called e-sense (I have the sources
> somewhere on my HD). It was using Litestep for the windows management.

I meant impossible now. I mentioned the possibility of porting Enlightenment
wayland. I think it is probably easier than trying to use X11. However, you
would end up with Enlightenment as an application with all applications
inside.

> Vincent

Regards,
--
Felipe Magno de Almeida


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

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

Re: [E-devel] Linux subsystem on windows

[Jonathan Aquilina]

If you are saying that al is it worth the time and effort?

Get Outlook for iOS<https://aka.ms/o0ukef>


From: Al Poole 
Sent: Tuesday, January 22, 2019 09:46
To: Enlightenment developer list
Subject: Re: [E-devel] Linux subsystem on windows

Yes, stats are as follows:

Total users: 0.

;-)

On Tue, Jan 22, 2019 at 8:40 AM Jonathan Aquilina 
wrote:

> I say why not. I am willing to work on it slowly slowly.
>
> My question becomes do we have any stats of enlightenement usage by
> windows users?
>
> -Original Message-
> From: Felipe Magno de Almeida 
> Sent: 22 January 2019 06:53
> To: Enlightenment developer list <
> enlightenment-devel@lists.sourceforge.net>
> Subject: Re: [E-devel] Linux subsystem on windows
>
> On Tue, Jan 22, 2019 at 3:04 PM Jonathan Aquilina 
> wrote:
> >
> > As far as I know no, but cant we use what ever windows uses to display
> their UI?
>
> Yes, but then it is not a window manager is it? I think you could port
> Enlightenment Wayland to Windows, running in Fullscreen.
> You will probably find a lot of difficults, but I guess it can be possible.
>
> > -Original Message-
> > From: Felipe Magno de Almeida 
> > Sent: 22 January 2019 06:49
> > To: Enlightenment developer list
> > 
> > Subject: Re: [E-devel] Linux subsystem on windows
> >
> > On Tue, Jan 22, 2019 at 2:16 PM Jonathan Aquilina <
> jaquil...@eagleeyet.net> wrote:
> > >
> > > I was just wondering given the fact that it's a part of windows now
> how it would simplify the building of enlightenment on windows in the sense
> before you probably would have needed mingw or Cygwin. I might give it a
> try this coming weekend and start documenting on the wiki if I can or on
> phab.
> >
> > The Linux Subsystem doesn't work with X11, you need a a Windows X11
> server. And I don't know any X11 server which runs window managers on
> Windows. Is there?
> >
> > > Regards,
> > > Jonathan.
> > >
> > > -Original Message-
> > > From: Felipe Magno de Almeida 
> > > Sent: 22 January 2019 04:09
> > > To: Enlightenment developer list
> > > 
> > > Subject: Re: [E-devel] Linux subsystem on windows
> > >
> > > On Sun, Jan 13, 2019 at 2:18 AM Jonathan Aquilina <
> jaquil...@eagleeyet.net> wrote:
> > > >
> > > > Hi Guys,
> > > >
> > > > I have an interesting thing I would like to work on.
> > > >
> > > > Has anyone tried to build enlightenement through the linux subsystem
> on windows?
> > >
> > > Not yet, but I'll probably try soon.
> > >
> > > > Regards,
> > > > Jonathan
> > > >
> > > > ___
> > > > enlightenment-devel mailing list
> > > > enlightenment-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >
> > >
> > >
> > > --
> > > Felipe Magno de Almeida
> > >
> > >
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >
> > >
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
> >
> > --
> > Felipe Magno de Almeida
> >
> >
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
>
> --
> Felipe Magno de Almeida
>
>
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

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

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

Re: [E-devel] Linux subsystem on windows

[Jonathan Aquilina]

I say why not. I am willing to work on it slowly slowly.

My question becomes do we have any stats of enlightenement usage by windows 
users?

-Original Message-
From: Felipe Magno de Almeida  
Sent: 22 January 2019 06:53
To: Enlightenment developer list 
Subject: Re: [E-devel] Linux subsystem on windows

On Tue, Jan 22, 2019 at 3:04 PM Jonathan Aquilina  
wrote:
>
> As far as I know no, but cant we use what ever windows uses to display their 
> UI?

Yes, but then it is not a window manager is it? I think you could port 
Enlightenment Wayland to Windows, running in Fullscreen.
You will probably find a lot of difficults, but I guess it can be possible.

> -Original Message-
> From: Felipe Magno de Almeida 
> Sent: 22 January 2019 06:49
> To: Enlightenment developer list 
> 
> Subject: Re: [E-devel] Linux subsystem on windows
>
> On Tue, Jan 22, 2019 at 2:16 PM Jonathan Aquilina  
> wrote:
> >
> > I was just wondering given the fact that it's a part of windows now how it 
> > would simplify the building of enlightenment on windows in the sense before 
> > you probably would have needed mingw or Cygwin. I might give it a try this 
> > coming weekend and start documenting on the wiki if I can or on phab.
>
> The Linux Subsystem doesn't work with X11, you need a a Windows X11 server. 
> And I don't know any X11 server which runs window managers on Windows. Is 
> there?
>
> > Regards,
> > Jonathan.
> >
> > -Original Message-
> > From: Felipe Magno de Almeida 
> > Sent: 22 January 2019 04:09
> > To: Enlightenment developer list
> > 
> > Subject: Re: [E-devel] Linux subsystem on windows
> >
> > On Sun, Jan 13, 2019 at 2:18 AM Jonathan Aquilina  
> > wrote:
> > >
> > > Hi Guys,
> > >
> > > I have an interesting thing I would like to work on.
> > >
> > > Has anyone tried to build enlightenement through the linux subsystem on 
> > > windows?
> >
> > Not yet, but I'll probably try soon.
> >
> > > Regards,
> > > Jonathan
> > >
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
> >
> > --
> > Felipe Magno de Almeida
> >
> >
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
>
> --
> Felipe Magno de Almeida
>
>
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



--
Felipe Magno de Almeida


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


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

Re: [E-devel] Linux subsystem on windows

[Jonathan Aquilina]

As far as I know no, but cant we use what ever windows uses to display their 
UI? 

-Original Message-
From: Felipe Magno de Almeida  
Sent: 22 January 2019 06:49
To: Enlightenment developer list 
Subject: Re: [E-devel] Linux subsystem on windows

On Tue, Jan 22, 2019 at 2:16 PM Jonathan Aquilina  
wrote:
>
> I was just wondering given the fact that it's a part of windows now how it 
> would simplify the building of enlightenment on windows in the sense before 
> you probably would have needed mingw or Cygwin. I might give it a try this 
> coming weekend and start documenting on the wiki if I can or on phab.

The Linux Subsystem doesn't work with X11, you need a a Windows X11 server. And 
I don't know any X11 server which runs window managers on Windows. Is there?

> Regards,
> Jonathan.
>
> -Original Message-
> From: Felipe Magno de Almeida 
> Sent: 22 January 2019 04:09
> To: Enlightenment developer list 
> 
> Subject: Re: [E-devel] Linux subsystem on windows
>
> On Sun, Jan 13, 2019 at 2:18 AM Jonathan Aquilina  
> wrote:
> >
> > Hi Guys,
> >
> > I have an interesting thing I would like to work on.
> >
> > Has anyone tried to build enlightenement through the linux subsystem on 
> > windows?
>
> Not yet, but I'll probably try soon.
>
> > Regards,
> > Jonathan
> >
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
>
> --
> Felipe Magno de Almeida
>
>
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



--
Felipe Magno de Almeida


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


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

Re: [E-devel] Linux subsystem on windows

[Jonathan Aquilina]

Exactly for enlightenment on windows.

Regards,
Jonathan

-Original Message-
From: Hermet Park  
Sent: 22 January 2019 06:22
To: Enlightenment developer list 
Subject: Re: [E-devel] Linux subsystem on windows

Can't imagine building enlightenment on window subsystem, for what?
enlightenment on windows?

On Tue, Jan 22, 2019 at 12:23 PM Felipe Magno de Almeida < 
felipe.m.alme...@gmail.com> wrote:

> On Sun, Jan 13, 2019 at 2:18 AM Jonathan Aquilina 
>  wrote:
> >
> > Hi Guys,
> >
> > I have an interesting thing I would like to work on.
> >
> > Has anyone tried to build enlightenement through the linux subsystem 
> > on
> windows?
>
> Not yet, but I'll probably try soon.
>
> > Regards,
> > Jonathan
> >
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
>
> --
> Felipe Magno de Almeida
>
>
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>


--
Regards, Hermet

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


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

Re: [E-devel] Linux subsystem on windows

[Jonathan Aquilina]

I was just wondering given the fact that it's a part of windows now how it 
would simplify the building of enlightenment on windows in the sense before you 
probably would have needed mingw or Cygwin. I might give it a try this coming 
weekend and start documenting on the wiki if I can or on phab.

Regards,
Jonathan.

-Original Message-
From: Felipe Magno de Almeida  
Sent: 22 January 2019 04:09
To: Enlightenment developer list 
Subject: Re: [E-devel] Linux subsystem on windows

On Sun, Jan 13, 2019 at 2:18 AM Jonathan Aquilina  
wrote:
>
> Hi Guys,
>
> I have an interesting thing I would like to work on.
>
> Has anyone tried to build enlightenement through the linux subsystem on 
> windows?

Not yet, but I'll probably try soon.

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



--
Felipe Magno de Almeida


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


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

[E-devel] Azure Devop's CI

[Jonathan Aquilina]

Hi Guys,

I am looking to propose that I setup for the project CI on azure. There is no 
charge as far as I can gather for this. It seems like I would just need to tie 
it in to git to pull in the changes and schedule runs. From what I can see this 
is ubuntu based as a platform. What do you guys think do you think it's a good 
idea to have it do CI testing on each build?

If I am not mistaken I can setup a team and add members to that team if you 
guys would be interested.

Regards,
Jonathan

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

[E-devel] Linux subsystem on windows

[Jonathan Aquilina]

Hi Guys,

I have an interesting thing I would like to work on.

Has anyone tried to build enlightenement through the linux subsystem on windows?

Regards,
Jonathan

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

Re: [E-devel] 1.22 schedule proposal

[Jonathan Aquilina]

I’m ready to step and take charge of this but I think we need a bit more 
frequent minor release updates both for those in the community that want to Be 
on the bleeding edge and those that want to help bug fix more incremental 
stable releases.

Stefan do you have any documentation on how release plan works?

Get Outlook for iOS


From: Stefan Schmidt 
Sent: Wednesday, January 9, 2019 16:22
To: e
Subject: [E-devel] 1.22 schedule proposal

Hello.

Its almost 5 months since we released 1.21 and I stepped down.

When talking with people I got help offers on the release handling but
no-one stepped up to fully take a lead on this. I start to get the
feeling that this might need to be handled with a smoother transition of
knowledge and work.

Jonathan and Mike both offered help and others also expressed that they
would be willing to do their share towards a release. I count on you to
make this work :-)

To get back to time based releases we should get working on 1.22 soon
(and not block ourselves with $FEATURE not being ready right now)

The 3 months based schedule has been putting to much load onto the
project with release stuff. At least that is my opinion. After 1.22 is
out we should think about increasing this. Maybe 4, 5 or even 6 months?
Up to discussion.

After 5 full months of development I think we should allow two weeks
before we freeze to allow everybody to get their work in order. Fixes
will follow over the next weeks to get it ready.

Here is my release schedule proposal to get us started. Comments?

=== Schedule ===
2018-08-17 Merge window for 1.22 opens
2019-01-18 Notice about soon ending merge window
2019-01-23 Merge window is over. Freeze in place.
* Only bug fixes from this point
* Alpha release tarball
* One month stabilization phase starts
2019-01-30 Beta1 release tarball
* Only critical fixes from this point
2019-02-06 Beta2 release tarball
2019-02-13 EFL 1.22 is out

regards
Stefan Schmidt


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

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

[E-devel] Next Release

[Jonathan Aquilina]

Hi All,

I have a quick question who is taking care of the next release since Stefan has 
stepped down? I am willing to setup if necessary. Do we have a time line for 
the next release?

Regards,
Jonathan

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

Re: [E-devel] Server/Gitlab/Etc... and our servers/sysadmins routinely letting us down.

[Jonathan Aquilina]

Can you kindly keep me in the loop with the ticket please so I can follow up 
once I get my access sorted out please.

On 16/12/2018, 18:24, "Carsten Haitzler"  wrote:

On Sun, 16 Dec 2018 18:01:43 +0100 Jonathan Aquilina 

said:

> Hi Carsten,
> 
> In terms of the HDD's and fan issues have those all been resolved?

see my mails recently. fan isn't an issue right now but sata
controller/connectors are. osuosl have needed root access and ipmi access to
sanely help with this. i'm working on it. waiting now on osuosl to try some
things after i fixed ipmi on friday.

> On 16/12/2018, 14:32, "Carsten Haitzler"  wrote:
> 
>     On Sat, 15 Dec 2018 14:07:55 +0100 Jonathan Aquilina
>  said:
> 
> > I have no problem with that at all if it helps to keep the project
> > moving forward. What is being done about simplifying the complexity 
of
> > all the infrastructure currently setup and in use?
> > 
> > If we are going to be rebuilding why don’t we go with a centos
> > infrastructure? Something secure and reliable and stable with 10 
year
> > support
> 
> not useful for us as we regularly want to run things that need newer
> things and these needs then updates to 10 years is not useful to us IMHO.
> 
> what is probably better is really ubuntu. 6 monthly upgrades, big 
userbase
> tested and thus can stay relatively up to date with fairly minimal 
effort.
> 
> see my other email - getting e5 back to full strength is first. i've
> gotten an ipmi console - the java app though doesn't allow any kbd input -
> just displays. pretty useless but ipmi serial console does work. so i was
> hoping that will work for a re-install. but first get the sata stuff 
sorted
> one way or another. 
> > On 15/12/2018, 13:58, "Carsten Haitzler   (The Rasterman)"
> >  wrote:
> > 
> > On Thu, 13 Dec 2018 18:40:14 +0100 Jonathan Aquilina
> >  said:
> > 
> > i can arrange you get vpn access to osuosl then the rest is ipmi
> > (there is a web ui and cmdline too). that's all that's needed (other
> > than needing to know admin passwd :)).
> > 
> > > Hi Stephen,
> > > 
> > > What can I do to start getting things going in a new 
direction.
> > > The advantage with Linode is that then I can give access to
> > > multiple individuals to access the linode manager and other
> > > aspects of the server.
> > > 
> > > Are we going to go forward with this change? I am very 
willing to
> > > sponsor all this.
> > > 
> > > On 13/12/2018, 18:38, "Stephen Houston" 

> > > wrote:
> > > 
> > > A few months ago Mike set up  a test instance of gitlab 
on a
> > > server for us... After testing and the like, I set up a 
slowvote
> > > on Phab that covered 4 options:
> > > 
> > > Gitlab with new infra
> > > Gitlab with current infra
> > > Phab with new infra
> > > Phab with current infra
> > > 
> > > The overwhelming support was for new infra.  As in every
> > > single vote except for one wanted new infra.  The majority 
also
> > > wanted gitlab, but for the sake of this email, that is 
irrelevant.
> > > 
> > > The arguments against new infra, having it sponsored, 
cloud,
> > > etc... keep being that if someone leaves the project, or the
> > > owners of the servers changes, or policies change, or etc... 
that
> > > we might lose access.  To me this seems like an incredibly 
poor
> > > argument right now especially considering that we have been
> > > experiencing this very thing and even worse with our own 
current
> > > infra.  The problems I have seen are that we: 
> > > A. Failed at maintaining the physical aspects of our 
server.
> > > B. Keep having continued downtime over and over and over
> > > again. C. Can never get in touch with or get a response from 
our
> >

Re: [E-devel] Server/Gitlab/Etc... and our servers/sysadmins routinely letting us down.

[Jonathan Aquilina]

Hi Carsten,

In terms of the HDD's and fan issues have those all been resolved?

On 16/12/2018, 14:32, "Carsten Haitzler"  wrote:

On Sat, 15 Dec 2018 14:07:55 +0100 Jonathan Aquilina 

said:

> I have no problem with that at all if it helps to keep the project moving
> forward. What is being done about simplifying the complexity of all the
> infrastructure currently setup and in use?
> 
> If we are going to be rebuilding why don’t we go with a centos
> infrastructure? Something secure and reliable and stable with 10 year 
support

not useful for us as we regularly want to run things that need newer things 
and
these needs then updates to 10 years is not useful to us IMHO.

what is probably better is really ubuntu. 6 monthly upgrades, big userbase
tested and thus can stay relatively up to date with fairly minimal effort.

see my other email - getting e5 back to full strength is first. i've gotten 
an
ipmi console - the java app though doesn't allow any kbd input - just 
displays.
pretty useless but ipmi serial console does work. so i was hoping that will
work for a re-install. but first get the sata stuff sorted one way or 
another.

> On 15/12/2018, 13:58, "Carsten Haitzler   (The Rasterman)"
>  wrote:
> 
> On Thu, 13 Dec 2018 18:40:14 +0100 Jonathan Aquilina
>  said:
> 
> i can arrange you get vpn access to osuosl then the rest is ipmi 
(there
> is a web ui and cmdline too). that's all that's needed (other than 
needing to
> know admin passwd :)).
> 
> > Hi Stephen,
> > 
> > What can I do to start getting things going in a new direction. The
> > advantage with Linode is that then I can give access to multiple
> > individuals to access the linode manager and other aspects of the
> > server.
> > 
> > Are we going to go forward with this change? I am very willing to
> > sponsor all this.
> > 
> > On 13/12/2018, 18:38, "Stephen Houston"  
wrote:
> > 
> > A few months ago Mike set up  a test instance of gitlab on a 
server
> > for us... After testing and the like, I set up a slowvote on Phab 
that
> > covered 4 options:
> > 
> > Gitlab with new infra
> > Gitlab with current infra
> > Phab with new infra
> > Phab with current infra
> > 
> > The overwhelming support was for new infra.  As in every single 
vote
> > except for one wanted new infra.  The majority also wanted gitlab, 
but
> > for the sake of this email, that is irrelevant.
> > 
> > The arguments against new infra, having it sponsored, cloud, 
etc...
> > keep being that if someone leaves the project, or the owners of the
> > servers changes, or policies change, or etc... that we might lose
> > access.  To me this seems like an incredibly poor argument right now
> > especially considering that we have been experiencing this very 
thing
> > and even worse with our own current infra.  The problems I have seen
> > are that we: 
> > A. Failed at maintaining the physical aspects of our server.
> > B. Keep having continued downtime over and over and over again.
> > C. Can never get in touch with or get a response from our server
> > admin in any kind of remotely adequate timeframe.
> > 
> > Insanity is often said to be defined as doing the same thing 
over
> > and over again expecting a different result.  It is time to have an
> > open mind to the needs/wants of this community and make a change.
> > 
> > Stephen
> > 
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > 
> > 
> > 
> > 
> > 
> > ___
> > 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" 
--

Re: [E-devel] Server/Gitlab/Etc... and our servers/sysadmins routinely letting us down.

[Jonathan Aquilina]

Again to all mentioned below. What Can I do to help?

On 15/12/2018, 13:58, "Carsten Haitzler   (The Rasterman)" 
 wrote:

On Thu, 13 Dec 2018 11:36:55 -0600 Stephen Houston  
said:

> A few months ago Mike set up  a test instance of gitlab on a server for
> us... After testing and the like, I set up a slowvote on Phab that covered
> 4 options:
> 
> Gitlab with new infra
> Gitlab with current infra
> Phab with new infra
> Phab with current infra
> 
> The overwhelming support was for new infra.  As in every single vote 
except
> for one wanted new infra.  The majority also wanted gitlab, but for the
> sake of this email, that is irrelevant.
> 
> The arguments against new infra, having it sponsored, cloud, etc... keep
> being that if someone leaves the project, or the owners of the servers
> changes, or policies change, or etc... that we might lose access.  To me
> this seems like an incredibly poor argument right now especially
> considering that we have been experiencing this very thing and even worse
> with our own current infra.  The problems I have seen are that we:

there was an offer for new corporate sponsored infra. you have no idea how
close things were to that infra just vanishing a few weeks ago if it had 
been
used. we'd be back to begging for someone else to provide it or everyone 
having
to pony up and pay for some hosting and have given up osuosl who have 
served us
well (when you know the details).

> A. Failed at maintaining the physical aspects of our server.

i personally ordered 2 replacement drives for our server recently(ish) and i
care. i had hoped people physically closer would handle things first, but 
that
didn't happen, so i did. there are other issues which i'm sorting through 
and
have been blocked by other configuration issues.

> B. Keep having continued downtime over and over and over again.

actually we don't. we had downtime because of a software configuration issue
for years regarding qemu and logging. this would have happened anywhere with
any infra if we used vm's and had the same setup.

> C. Can never get in touch with or get a response from our server admin in
> any kind of remotely adequate timeframe.

admin, server+hosting and what runs on them are different matters. 
conflating
them all is a bad idea.

this is why our infra needs multiple hands from multiple people involved so
there is always a backup. that is what i want to happen with e5 once its 
back
up. it has to be easier to manage remotely for people who are not full-time
looking at the system and know it backwards. so system has to be pretty 
boring
and "standard" as possible. it may be less secure as a result but that's 
better
than not having multiple hands making light work.

> Insanity is often said to be defined as doing the same thing over and over
> again expecting a different result.  It is time to have an open mind to 
the
> needs/wants of this community and make a change.

we just had a near fatal miss above AND osuosl have done a great job over 
the
years. they have more recently been locked out of helping out much (the ipmi
thing as well as server access to OS has not been given to them like a 
working
account with root access).

the current e.org is not even running inside osuosl. it's a temporary server
meant for "getting containers set up on our original server inside osuosl".
that has not happened after 1.5 years. i'm, not interested i going into 
blame
or what should have been done when or by who. i do want to say that i 
consider
beber a friend and he has done a lot of work over the years and invested his
time and effort and more and i totally respect that.

now that temporary server runs somewhere only beber knows about right now 
and
since it seems the host had physical problems, only he can do anything about
that. i couldn't ssh in and do anything - no access was possible for me. 
this
temporary machine is e6.

the osuosl machine (e5). is up and working but 1 drive isn't responding. 
fixing
this has been delayed because ipmi access has not worked for me since the 
day
this machine was set up, nor has it worked for osuosl - they have been 
unable
to access console and do the basic power up/down etc. without physically
walking into the server room.

i have actually figured out why it doesn't work just today... it was a very
simple thing and never should/would have happened if there had been a little
less paranoia :), i spent a lot of time today getting impicfg installed and
working so i could update the user config. suffice to say that gentoo made 
this
an absolute chore. i learned a lot more about how gentoo works and my 
opinions
of it have 

Re: [E-devel] Server/Gitlab/Etc... and our servers/sysadmins routinely letting us down.

[Jonathan Aquilina]

I have no problem with that at all if it helps to keep the project moving 
forward. What is being done about simplifying the complexity of all the 
infrastructure currently setup and in use?

If we are going to be rebuilding why don’t we go with a centos infrastructure? 
Something secure and reliable and stable with 10 year support

On 15/12/2018, 13:58, "Carsten Haitzler   (The Rasterman)" 
 wrote:

On Thu, 13 Dec 2018 18:40:14 +0100 Jonathan Aquilina 

said:

i can arrange you get vpn access to osuosl then the rest is ipmi (there is a
web ui and cmdline too). that's all that's needed (other than needing to
know admin passwd :)).

> Hi Stephen,
> 
> What can I do to start getting things going in a new direction. The 
advantage
> with Linode is that then I can give access to multiple individuals to 
access
> the linode manager and other aspects of the server.
> 
> Are we going to go forward with this change? I am very willing to sponsor 
all
> this.
> 
> On 13/12/2018, 18:38, "Stephen Houston"  wrote:
> 
> A few months ago Mike set up  a test instance of gitlab on a server 
for
> us... After testing and the like, I set up a slowvote on Phab that 
covered
> 4 options:
> 
> Gitlab with new infra
> Gitlab with current infra
> Phab with new infra
> Phab with current infra
> 
> The overwhelming support was for new infra.  As in every single vote
> except for one wanted new infra.  The majority also wanted gitlab, but 
for the
> sake of this email, that is irrelevant.
> 
> The arguments against new infra, having it sponsored, cloud, etc... 
keep
> being that if someone leaves the project, or the owners of the servers
> changes, or policies change, or etc... that we might lose access.  To 
me
> this seems like an incredibly poor argument right now especially
> considering that we have been experiencing this very thing and even 
worse
> with our own current infra.  The problems I have seen are that we:
> 
> A. Failed at maintaining the physical aspects of our server.
> B. Keep having continued downtime over and over and over again.
> C. Can never get in touch with or get a response from our server 
admin in
> any kind of remotely adequate timeframe.
> 
> Insanity is often said to be defined as doing the same thing over and 
over
> again expecting a different result.  It is time to have an open mind 
to
> the needs/wants of this community and make a change.
> 
> Stephen
> 
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 
> 
> 
> 
> 
> ___
> 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






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

Re: [E-devel] Server/Gitlab/Etc... and our servers/sysadmins routinely letting us down.

[Jonathan Aquilina]

Hi Stephen,

What can I do to start getting things going in a new direction. The advantage 
with Linode is that then I can give access to multiple individuals to access 
the linode manager and other aspects of the server.

Are we going to go forward with this change? I am very willing to sponsor all 
this.

On 13/12/2018, 18:38, "Stephen Houston"  wrote:

A few months ago Mike set up  a test instance of gitlab on a server for
us... After testing and the like, I set up a slowvote on Phab that covered
4 options:

Gitlab with new infra
Gitlab with current infra
Phab with new infra
Phab with current infra

The overwhelming support was for new infra.  As in every single vote except
for one wanted new infra.  The majority also wanted gitlab, but for the
sake of this email, that is irrelevant.

The arguments against new infra, having it sponsored, cloud, etc... keep
being that if someone leaves the project, or the owners of the servers
changes, or policies change, or etc... that we might lose access.  To me
this seems like an incredibly poor argument right now especially
considering that we have been experiencing this very thing and even worse
with our own current infra.  The problems I have seen are that we:

A. Failed at maintaining the physical aspects of our server.
B. Keep having continued downtime over and over and over again.
C. Can never get in touch with or get a response from our server admin in
any kind of remotely adequate timeframe.

Insanity is often said to be defined as doing the same thing over and over
again expecting a different result.  It is time to have an open mind to the
needs/wants of this community and make a change.

Stephen

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





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

Re: [E-devel] enlightenment.org down

[Jonathan Aquilina]

Is it possible for someone to open a ticket with OSUSL maybe they had some form 
of power outage or they are doing maintenance in the DC

On 11/12/2018, 15:59, "Vincent Torri"  wrote:

hello

www, phab and git are down.

I've asked Bertrand, no answer yet

Vincent

On Tue, Dec 11, 2018 at 2:21 PM Boris Faure  wrote:
>
> Hi :)
>   It seems https://enlightenment.org/ is down. It shows a message
> "SORRY! I'm having trouble waking up...". My small CI script also fails
> on https://git.enlightenment.org/apps/terminology.git/ : The requested
> URL returned error: 503.
>
> Could someone look into it?
> Thanks
> --
> Boris Faure
> Pointer Arithmetician
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


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





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

Re: [E-devel] Gitlab/Infrastructure Slowvote

[Jonathan Aquilina]

I will gladly sponsor a server to host on until we get e5 reinstalled and going 
again. 

I think here before a new server is mentioned, we need to see about decide 
about distribution as that will open up a whole new can of worms

Sent from my iPhone

> On 26 Sep 2018, at 17:56, Stefan Schmidt  wrote:
> 
> Hello.
> 
>> On 9/26/18 5:30 PM, Stephen Houston wrote:
>> A. We were assured the server could be provided free of charge.  I.E.
>> "Sponsored" not bought or paid for as you and raster seem to think
>> sponsored means.
> 
> The server you mentioned here is the cloud hosting Mike offered? I read
> nothing besides that. No details on who is sponsoring, how long, on a
> monthly basis (could be canceled any time) or one big chunk to be
> managed by the EFL foundation, etc.
> 
> Relying on sponsorship for critical infrastructure is difficult for an
> open source project. Not impossible, but difficult. You basically base
> your trust on business decisions not changing in a company.
> 
> Without a clear pledge on the sponsorship level in terms of length and
> amount this option sounds really problematic to me.
> 
>> 
>> B. If you would have spent the last month or so since that Gitlab thread
>> started actually testing or using the prototype set up, you would see that
>> gitlab provides a web interface for git, so no need for cgit.  Obviously
>> phab provides a wiki and gitlab provides a wiki so the move from phab to
>> gitlab would move phab's wiki to gitlab's wiki. 
> 
> I spent time on the thread, looked at the prototype and raised
> questions. Not all have been answered nor have they all been fully
> dissected. Wiki is per project in Gitlab and not overall like Phab, we
> use cgit while phab also offers a git web interface, etc.
> 
> Blaming Marcel for not spending time on the thread is pretty harsh if
> many of these things have not been answered and are still in "to be
> found out" state.
> 
> Again these are trivial
>> things that could have/should have been discussed for the many weeks that
>> has thread has been there.  CI was also mentioned.  It's a huge problem
>> with e5 and Stefan explained this.  Gitlab has some really good CI tools,
>> but obviously that is one of the biggest considerations in moving as Stefan
>> clearly laid out.  CI with E5 is crap.
> 
> How would Gitlab help with the CI situation? I see no good integration
> with things like Travis for it (if I missed it I am happy to get pointed
> to it). It basically means we would move our CI over to Gitlab and all
> builds run on our infra (cloud/or hardware). That could easily bring
> back the overloading problems we had on e5. I am very hesitant in buying
> into using Gitlab for CI without enough knowledge about it.
> 
> regards
> Stefan Schmidt
> 
> 
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



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

Re: [E-devel] Gitlab/Infrastructure Slowvote

[Jonathan Aquilina]

My suggestion would be to move to a temporary server and use the full power of 
the physical server and chroots and or docker containers. I think using the 
bare metal setup right on something like centos would provide us with better 
stability. If more bleeding edge stuffnis needed go for fedora.

Sent from my iPhone

> On 26 Sep 2018, at 17:30, Stephen Houston  wrote:
> 
> A. We were assured the server could be provided free of charge.  I.E.
> "Sponsored" not bought or paid for as you and raster seem to think
> sponsored means.
> 
> B. If you would have spent the last month or so since that Gitlab thread
> started actually testing or using the prototype set up, you would see that
> gitlab provides a web interface for git, so no need for cgit.  Obviously
> phab provides a wiki and gitlab provides a wiki so the move from phab to
> gitlab would move phab's wiki to gitlab's wiki.  Again these are trivial
> things that could have/should have been discussed for the many weeks that
> has thread has been there.  CI was also mentioned.  It's a huge problem
> with e5 and Stefan explained this.  Gitlab has some really good CI tools,
> but obviously that is one of the biggest considerations in moving as Stefan
> clearly laid out.  CI with E5 is crap.
> 
> I will add a temporary move option to the vote.
> 
> I didn't jump the gun here.  The Gitlab thread has been around for a long
> time now with over 50 responses and is at the point where some kind of
> decisions have to be made as it is going to go stale.  There is nothing
> more frustrating than people who sit around and have AMPLE AMPLE time to
> respond and put opinions out there and concerns and discuss things more,
> and choose not to until the time comes to take the next step and they then
> want to speak their mind.  Communication really is key.
> 
> Finally - This vote isn't going to set anything in stone or set anything in
> motion.  After weeks and weeks of responses to the thread, the vote is
> simply there to guage what everybody's end goal/desire is so that we can
> have more focused discussions about A. Is it possible? B. How do we
> accomplish it? C. Pros/Cons D. Community buy-in
> 
> Relax a little - Vote on the slowvote as to what your ideal situation would
> be and then when the vote is over we will have a good feel of what the
> community's ideal situation is and we will see if its possible to get close
> to that/accomplish that.
> 
> 
>> On Wed, Sep 26, 2018 at 9:49 AM Marcel Hollerbach  wrote:
>> 
>> There is a difference between a precise plan on what kind of changes are
>> done and what the overall plan looks like.
>> 
>> - What is happening to the CI, cgit, wiki etc.
>> - Is the sponsoring a permanent choice, or just something for a year or
>> so, and the overall plan is to migrate back, (this was also proposed in
>> the "Gitlab" thread).
>> 
>> Those questions are rather fundamental (at least to me) in order to vote
>> for anything. Also, how useful is it to know that the community wants to
>> have a sponsored service if there is no funding at all.
>> 
>>> On 9/26/18 4:22 PM, Stephen Houston wrote:
>>> There is no point in developing a plan if we dont know what the plan is
>> or
>>> what the desire is of the community.
>>> 
 On Wed, Sep 26, 2018, 9:21 AM Marcel Hollerbach  wrote:
 
 I don't really see where this vote does make any sense.
 There is currently no one stepping up, saying he does the migration,
 there is no plan how the move should be done, there is no plan on where
 the funding would come from.
 
 How should i decide if a move would make sense or not in this stage? I
 don't even can see what kind of features would be included in case of a
 switch to gitlab.
 
 Greetings,
 bu5hm4n
 
> On 9/26/18 3:52 PM, Stephen Houston wrote:
> Hello developers,
> 
> Please take the time to consider options and vote on a migration to
 Gitlab
> and infrastructure possibilities here:
 https://phab.enlightenment.org/V39
> 
> Thanks,
> Stephen
> 
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 
 
 
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
>>> 
>>> ___
>>> enlightenment-devel mailing list
>>> enlightenment-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>> 
>> 
>> 
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>> 
> 
> 

Re: [E-devel] Gitlab

[Jonathan Aquilina]

I’m going to check the costs of a server with 100g but Linode now supports 
block storage so I can spin up the vps with that and we can run everything off 
of that in terms of data storage

Sent from my iPhone

> On 14 Sep 2018, at 09:56, Carsten Haitzler (The Rasterman) 
>  wrote:
> 
> On Thu, 13 Sep 2018 04:20:47 + jaquil...@eagleeyet.net said:
> 
>> How much space are we looking at as I am thinking a VPS running centos 
>> or even debian would be enough and then docker on it
> 
> well how much runs there? all of e.org ha sa lot of data - e.g. the screenshot
> collection is 3g right now and it grows. last time i cleared out the old stuff
> it was maybe 100g+ on its own. so expect total space with some safety to be
> 500g+ of space. i am pretty sure we'd eat about 50-100g of that right now 
> alone.
> 
>>> On 2018-09-13 00:43, Simon Lees wrote:
>>> One positive of migrating to gitlab if its done right ie containerized
>>> is the fact that it should be simple to move, so if someone can provide
>>> a machine and hosting somewhere it can sit there until the point until
>>> it no longer works for whatever reason or someone comes along with a
>>> better solution, at which point recreating the infra then migrating the
>>> data to a new server is a simple process. If it reaches a point where 
>>> no
>>> one is willing to provide infra we can equally move onto a public cloud
>>> for as long as necessary.
>>> 
>>> As long as the gitlab instance is created right this is probably a 
>>> major
>>> reason I think its worth migrating. I also don't have the time to do it
>>> so if it doesn't happen I wont complain but I think that if we do
>>> something it should be done properly otherwise we may as well stay with
>>> what we have.
>>> 
 On 13/09/2018 02:49, jaquil...@eagleeyet.net wrote:
 To be fair I am more than willing ot sponsor a server at OVH and give
 ssh access to those that need it.
 
> On 2018-09-12 11:45, Stephen Houston wrote:
> OSUOSL is great. But it's pointless when none of us can get the 
> access we
> need to the server and when the person that has/controls that access
> takes
> forever and a day to communicate and/or wont budge. Help has been 
> offered
> in sysadmin for years from multiple devs who are sysadmins by trade
> and who
> could handle the complexity, and there is absolutely no change and it 
> is
> not allowed. Further, Stefan is being generous... it has been more
> like 10
> months, nearly a year since OSUOSL asked us to replace the fan. This 
> is
> frankly embarrassing. We cant even get a model number so that one of 
> us
> could personally drop ship it to them. That really looks bad on us...
> Again
> that is basically humiliating.  With all of these issues I think it 
> would
> be a great improvement to moved to sponsored cloud hosting. We would
> actually have access and not have to worry about the hardware
> maintenance.
> 
> On Wed, Sep 12, 2018, 3:33 AM Carsten Haitzler 
> wrote:
> 
>> On Thu, 30 Aug 2018 19:49:29 +0930 Simon Lees  said:
>> 
>>> 
>>> 
 On 30/08/2018 18:57, Stefan Schmidt wrote:
 Hello.
 
> On 08/10/2018 08:09 PM, Mike Blumenkrantz wrote:
> 
> Q: Where would this be hosted?
> A: The provided link here is a cloud service which will be
>> funded for
>> the
> foreseeable future.
 
 This is a crucial point here. Business decisions change and the
 community has no influence on this. With my community hat on I
 appreciate that there would be a sponsoring of a cloud service,
>> but I
 truly think we should not depend on this mid or long term (having it
>> run
 there for a few month of migration would not worry me).
 Even if it would be more paperwork having the sponsorship going
>> to the
 foundation and the service being paid out from there would be the
>> right
 way. We can acknowledge the sponsorship on our sponsors page.
 
>>> 
>>> I tend to agree here, unless we knew we had a simple easy way to
>> migrate
>>> it to other hosting at anytime we needed.
>> 
>> My experience leads me to be pretty adamant on not relying on cloud
>> services we
>> have to pay for eve if someone sponsors and pays for it. We lose 
>> control
>> and
>> reality is that these helping hands come and go. OSUOSL is a
>> university and
>> they have been supporting OSS projects for a veery long time. We
>> need
>> to
>> get our server into better shape though. Probably simpler shape.
>> 
>> --
>> - Codito, ergo sum - "I code, therefore I am" 
>> --
>> Carsten Haitzler - ras...@rasterman.com
>> 
>> 
>> 
>> ___
>> 

Re: [E-devel] Gitlab

[Jonathan Aquilina]

I can sponsor a Linode vps for this until we get the server back in shape

Sent from my iPhone

> On 14 Sep 2018, at 09:48, Carsten Haitzler (The Rasterman) 
>  wrote:
> 
> On Wed, 12 Sep 2018 12:44:52 +0200 Stefan Schmidt 
> said:
> 
>> Hello.
>> 
>>> On 09/12/2018 10:24 AM, Carsten Haitzler (The Rasterman) wrote:
>>> On Thu, 30 Aug 2018 19:49:29 +0930 Simon Lees  said:
>>> 
 
 
> On 30/08/2018 18:57, Stefan Schmidt wrote:
> Hello.
> 
>> On 08/10/2018 08:09 PM, Mike Blumenkrantz wrote:
>> 
>> Q: Where would this be hosted?
>> A: The provided link here is a cloud service which will be funded for the
>> foreseeable future.
> 
> This is a crucial point here. Business decisions change and the
> community has no influence on this. With my community hat on I
> appreciate that there would be a sponsoring of a cloud service, but I
> truly think we should not depend on this mid or long term (having it run
> there for a few month of migration would not worry me).
> Even if it would be more paperwork having the sponsorship going to the
> foundation and the service being paid out from there would be the right
> way. We can acknowledge the sponsorship on our sponsors page.
> 
 
 I tend to agree here, unless we knew we had a simple easy way to migrate
 it to other hosting at anytime we needed.
>> 
>> If we would have, say a docker hosting it could start there and be
>> migrated over to our own hosting whenever we get that into shape.
>> Not saying its the best solution but it could be an option.
> 
> containers are nicer but they do then create more of a limit of where we can
> run.
> 
>>> My experience leads me to be pretty adamant on not relying on cloud
>>> services we have to pay for eve if someone sponsors and pays for it. We
>>> lose control and reality is that these helping hands come and go.
>> 
>> Using them for a given timeframe until we have our infra in better shape
>> would make the risk manageable for them in terms of how much they
>> sponsor and for us in terms of getting full control in the end.
>> 
>> OSUOSL is a university and
>>> they have been supporting OSS projects for a veery long time. We need to
>>> get our server into better shape though. Probably simpler shape.
>> 
>> This is the core problem. OSUOL has indeed doing a great job for us over
>> the years for hosting and connectivity. But they can only be as good as
>> we allow them to be. Waiting for us for a fan to be shipped to be
>> replaced for over 6 months is nothing we are helping them with.
>> 
>> To be blunt here our infra is a nightmare. To complex to manage for
>> anyone besides Beber. Beber not being available means _nothing_ changes.
> 
> precisely. I would like to go back to something very simple. not a bunch of
> vm's or containers etc. ... my thoughts right now are a simple single sub vm 
> on
> our current gentoo parent box. no fancy network layering/routing etc. ... then
> it's manageable for multiple people as it's simple and obvious and easy to
> figure out. yes. it's probably not as secure... but that's what the vm is for.
> extract the data out, and rebuild if the worst happens.
> 
> or at least something like the above. something very simple to manage/set
> up/run etc.
> 
>> Is that was all discussed during EDD in Malta in 2017 and promised to be
>> worked on. This was 15 months ago and I see zero impact so far.
>> 
>> This is not about to point fingers to Beber. He has been helping us many
>> many years as a volunteer. He has all rights to take time off or even
>> disappear completely and we still should be thankful for the work he did.
>> 
>> It is however a big problem in the project if we want to self host
>> everything, but our infra is simply not ready for it.
> 
> well one big big big issue is the ipmi console. i have tried to get access to
> it. i have asked cedric and beber. without that there is no way i can do a
> kernel upgrade on a gentoo host because you have to compile by hand and
> something is bound to go wrong... and without that console there is no rescue.
> 
>> To summarize: I share your concerns on cloud hosting with sponsoring,
>> but our infra is not ready for anything new. _If_ we move to gitlab
>> having it hosted for a few months on a cloud service with a migration
>> plan to our own infra is something I consider a fair deal.
> 
> my gut and experience tells em few months then becomes a few years and then
> something goes wrong and we're in a dark place. :(
> 
> my take is that if there is to be any move in addition to it "being worth it"
> we have to get our infra into shape FIRST. let this be the kick in the pants 
> to
> do that. if we just put that off then it will just never happen as above.
> 
>> regards
>> Stefan Schmidt
>> 
>> 
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> 

Re: [E-devel] Gitlab

[Jonathan Aquilina]

The way I see it if there is lack of activity it gets closed and if need be 
reopened when the issue resurfaced

Sent from my iPhone

> On 16 Aug 2018, at 16:29, Mike Blumenkrantz  
> wrote:
> 
> I am a bit curious where you think we need this much work with triaging?
> 
> The biggest issue that we will have here is actually from our
> passive-aggressive method of rejecting things we don't like. For example,
> there are many, many patches that have been rejected and are idle for a
> long time but not abandoned. These will not be closed using the current
> migration method. There are also unlimited tickets set to 'pending on user
> input' which are dead; these also will not be closed. Most likely both of
> these types of open items should just be closed during migration.
> 
> On Sat, Aug 11, 2018 at 2:56 AM Jonathan Aquilina 
> wrote:
> 
>> Guess then would be to migrate everything and I’ll work on triaging the
>> bigs after
>> 
>> Sent from my iPhone
>> 
>>>> On 11 Aug 2018, at 08:23, Pierre Couderc  wrote:
>>>> 
>>>> On 08/11/2018 07:30 AM, jaquil...@eagleeyet.net wrote:
>>>> If we are going to migrate I think we should migrate tickets slowly to
>> see which ones are still valid and not pollute the new tracker with issues
>> that are either moot or no longer valid.
>>>> 
>>> Mmm, it is not logical. Migrate is a thing. Process tickets is another
>> thing. Trying to do 2 independant things simulteaneoulsy?
>>> 
>>> 
>> --
>>> 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
>> 
> --
> 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] Gitlab

[Jonathan Aquilina]

Guess then would be to migrate everything and I’ll work on triaging the bigs 
after

Sent from my iPhone

> On 11 Aug 2018, at 08:23, Pierre Couderc  wrote:
> 
>> On 08/11/2018 07:30 AM, jaquil...@eagleeyet.net wrote:
>> If we are going to migrate I think we should migrate tickets slowly to see 
>> which ones are still valid and not pollute the new tracker with issues that 
>> are either moot or no longer valid.
>> 
> Mmm, it is not logical. Migrate is a thing. Process tickets is another thing. 
> Trying to do 2 independant things simulteaneoulsy?
> 
> --
> 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] Quality of bugs on phab

[Jonathan Aquilina]

Thanks for the clarification I started in on some bugs that have not had any 
activity since 2017 and some from 2016 if I don’t hear back I’ll close them and 
advise if this is still a valid issue to reopen.

I did have one dev actually close their own bug after I pointed out to them 
there hasn’t been any activity in a while on it.

My aim is to keep the tracker as clean as possible to allow you guys to focus 
on the tickets that matter.

Sent from my iPhone

> On 29 Jul 2018, at 07:18, Carsten Haitzler (The Rasterman) 
>  wrote:
> 
> On Sat, 28 Jul 2018 09:03:11 + jaquil...@eagleeyet.net said:
> 
>> Hi Guys,
>> 
>> I think a good place for me to start as I fight with getting things 
>> built on fedora from git is that of traging of bugs that have had no 
>> activity for an extended period of time. I am posting a comment on them 
>> to see if I get any feedback and if there is no feed back I will mark a 
>> note on it for those subscribed to reopen the ticket if its still valid.
>> 
>> Also I am seeing alot of bug reports of very low quality. In the sense 
>> there isnt any detail as to what the issue is. Is there a work flow that 
>> we can setup to ensure a standard of bug reports is met in the sense 
>> what steps we can take to try and reproduce as well as maybe hardware 
>> specs.
>> 
>> I am sending this more to open up a discussion on this as i feel like 
>> phab should be used to help us report issues that developers can then 
>> try to reproduce and if replicated fixed.
> 
> well TBH there isn't much you can do about what reporters will report. you ask
> questions. often it's hard to get the information (people are unable to 
> provide
> it - too complicated to get a backtrace for example - packages with no debug
> symbols etc.). sometimes the backtrace is useless. (dies inside libc malloc
> sanity checks - bug happened elsewhere and would need valgrind to know more).
> sp it's often a conversation digging out more information. if that 
> conversation
> stops (without a resolution or a "this needs to be handled later" from
> developers), the bug basically becomes useless. : (
> 
>> Regards,
>> Jonathan.
>> 
>> --
>> 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] Mac server sponsorship

[Jonathan Aquilina]

The provider I mentioned is getting more machines so space isn’t an issue as it 
will have 530gb on board. 

Sent from my iPhone

> On 29 Jul 2018, at 07:14, Carsten Haitzler  wrote:
> 
> On Sat, 28 Jul 2018 05:43:58 + jaquil...@eagleeyet.net said:
> 
>> Hi Carsten,
>> 
>> Thanks for the update. I am in search of another mac host provider. I 
>> know back in 2009 that osx was around 12gb installed then at some point 
>> they managed to get that down to 6gb for the os installed. My suspicion 
>> is that they moved alot of big apps like xcode out of the os and onto 
>> the app store.
> 
> wow... that's fat. even at 6gb... :) so 16g might be the ticket in either 
> case.
> not sure it's even an option...
> 
>>> On 2018-07-28 05:40, Carsten Haitzler wrote:
>>> On Sat, 28 Jul 2018 04:56:44 + jaquil...@eagleeyet.net said:
>>> 
>>>> Hi All,
>>>> 
>>>> I am looking at this to see what I can get and the initial provider I
>>>> found sadly his page is saying sold out on all models granted 2 say 
>>>> sign
>>>> up.
>>>> 
>>>> My question though is how much storage space for code as well as the
>>>> built product is needed?
>>> 
>>> spare space beyond dependencies and OS that is NEEDED is about 1gb, but 
>>> that's
>>> a bare minimum (well ok 700m for an efl git tree plus build files, with 
>>> some
>>> extra space for the install). once you start using ccache and need 
>>> space for
>>> comfort, maybe 8gb? that's beyond the base os + dependencies. i don't 
>>> know how
>>> much osx uses and i might hazard a guess that dependencies beyond basic 
>>> osx
>>> might add up to 200-500m. so maybe 16gb and call it a day if osx isn't 
>>> too
>>> bloated...
>>> 
>>>>> On 2018-07-25 06:54, Stefan Schmidt wrote:
>>>>> Hello.
>>>>> 
>>>>>> On 25.07.2018 08:41, Jonathan Aquilina wrote:
>>>>>> Seeing as there is quite a bit of interest in this tonight, which is
>>>>>> going to probably be the first evening relaxed at home with my wife
>>>>>> since we got back from the honeymoon, I will purchase the server. Can
>>>>>> someone open up some tickets on Phabricator with what you guys want me
>>>>>> to do and what the end goal is that way progress can be tracked by
>>>>>> those following the ticket.  If not I will open a ticket on my
>>>>>> helpdesk.
>>>>>> 
>>>>>> I’m also a bit concerned about accuracy of documentation. Is
>>>>>> everything up to date?
>>>>> 
>>>>> https://www.enlightenment.org/docs/distros/osx-start.md
>>>>> https://git.enlightenment.org/core/efl.git/tree/.ci/ci-osx-deps.sh
>>>>> https://git.enlightenment.org/core/efl.git/tree/.ci/ci-osx-build.sh
>>>>> 
>>>>> This is what I used when setting up the osx builds on Travis. Likely
>>>>> there are more details to figure out.
>>>>> 
>>>>> 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
>>>> 
>>>> --
>>>> 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] Mac server sponsorship

[Jonathan Aquilina]

Seeing as there is quite a bit of interest in this tonight, which is going to 
probably be the first evening relaxed at home with my wife since we got back 
from the honeymoon, I will purchase the server. Can someone open up some 
tickets on Phabricator with what you guys want me to do and what the end goal 
is that way progress can be tracked by those following the ticket.  If not I 
will open a ticket on my helpdesk.

I’m also a bit concerned about accuracy of documentation. Is everything up to 
date?

Sent from my iPhone

> On 25 Jul 2018, at 08:26, Stefan Schmidt  wrote:
> 
> Hello.
> 
>> On 24.07.2018 16:01, Mike Blumenkrantz wrote:
>> 
>> Any series of builds which requires a macos on Travis is subject to delay
>> until a macos builder can be provided, meaning we may end up having to wait
>> an undetermined amount of time for each new build if a lot of macos
>> builders are in use. If we could eliminate that builder from our build
>> matrix, it would help us from this angle.
> 
> Yes, the osx builds are a bottleneck. With both factors, delay until the
> job starts and build time itself.
> 
> We have not made real use of harbourmaster and drydock yet, which means
> we will have to learn if that really is a good option for all this. We
> will also see if the hosted mac server really gives the speed increase
> in CI you hope for. Something to try out but with various unknowns and
> risks attached.
> 
> Jonathan wanted to set this up. I would say we wait until he has
> somethign that can build efl over ssh and we can see how it would
> integrate with phab once that is done.
> 
> 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


--
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] Mac server sponsorship

[Jonathan Aquilina]

Ssh is All that’s needed as far as I know. 

Sent from my iPhone

> On 24 Jul 2018, at 16:14, Carsten Haitzler  wrote:
> 
> On Tue, 24 Jul 2018 11:41:29 +0200 Stefan Schmidt 
> said:
> 
>> 
>> 
>>> On 24.07.2018 11:19, Carsten Haitzler wrote:
>>> On Tue, 24 Jul 2018 09:28:05 +0200 Stefan Schmidt
>>>  said:
>>> 
 Hello.
 
> On 23.07.2018 11:11, Carsten Haitzler (The Rasterman) wrote:
> On Mon, 23 Jul 2018 09:42:43 +0200 Stefan Schmidt
>  said:
> 
>> Hello.
>> 
>>> On 23.07.2018 06:59, jaquil...@eagleeyet.net wrote:
>>> Hi Guys,
>>> 
>>> I am willing to work on getting a CI setup on a mac machine going.
>>> 
>>> I am willing to sponsor a server. I happened to find the following
>>> 
>>> https://www.hostmyapple.com/macdedicated.html
>>> 
>>> What do you guys think?
>> 
>> You know that we already have CI testing on OSX via TravisCI?
>> 
>> What would this do better than the current CI setup we have?
>> 
>> https://travis-ci.org/Enlightenment/efl (look at the build job with an
>> apple as logo)
> 
> run apps and debug them interactively? you'd need vnc or some remote
> display/access setup ...but that. :) it'd require people to not fight over
> the same display... i.e. one person at a time... :)
 
 If we have one osx system for CI builds and another one for debugging
 problems on OSX I easily see how they could be very different in terms
 of OSX versions, libraries, homebrew installs, etc.
>>> 
>>> that's massively better than only a CI system and no way to interactively
>>> debug things like copy & paste (ask netstar - he has a mac box to do that
>>> now). this isn't perfection, but it never will be. :) it's better than
>>> nothing as right now the CI systems do not allow dbeugging like i
>>> described. just builds. right?
>> 
>> Just builds. I don't expect a CI system to be a debugging system. To me
>> these are two very different things to do. The TravisCI setup for OSX
>> already proved itself very useful by finding build breaks on code
>> committed into master.
>> 
>> You fancy a full blown OSX system with remote VNC access for manually
>> compiling and debugging. That is fair and could be nice to have. Just
>> nothing on my list to work on. If you and Jonathan want to work on
>> setting this all up, just go ahead.
> 
> Indeed when eagleye mailed this, this was my first thought as it would need
> nothing more than:
> 
> 1. some kind of vnc setup
> 2. some kind of ssh access with accounts
> 3. some kind of sudo-like access
> 
> then at least when things really need some work, people can  ssh in, use vnc
> and develop/test without having to buy a mac themselves. it sure as hell isn't
> as nice as a local machine, but ... it is a big step up from just CI/test
> suites. :)
> 
> -- 
> - 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] Community Scheduling

[Jonathan Aquilina]

It would have to be after he 22nd as I am currently on honeymoon is that ok for 
you

Sent from my iPhone

> On 14 Jul 2018, at 19:20, Mike Blumenkrantz  
> wrote:
> 
> If you have interest in writing tests it's actually very simple, and I
> would not expect a new unit test to take more than 1-2 minutes to write and
> run. The biggest issue with it at present is that there are no docs for it.
> I can try to work with you a bit on this (mentoring test writing and adding
> some docs for it) next week if you can be around on IRC, just let me know.
> 
> On Sat, Jul 14, 2018 at 5:02 AM Jonathan Aquilina 
> wrote:
> 
>> Where can I begin?
>> 
>> Sent from my iPhone
>> 
>>> On 14 Jul 2018, at 10:25, Carsten Haitzler  wrote:
>>> 
>>> On Sat, 14 Jul 2018 10:00:41 +0300 Jonathan Aquilina <
>> jaquil...@eagleeyet.net>
>>> said:
>>> 
>>>> Hi Raster with what you said below and other threads I’ve seen with
>> people
>>>> complaining about lack of unit tests etc wouldn’t it be better to get
>> nightly
>>>> builds to those that like to be on bleeding edge and help us test and
>> report
>>>> bugs. Not to mention I think nightly builds are possible as I see a lot
>> of
>>>> things that get committed to the repos on a daily basis at times.
>>> 
>>> we already have that - jenkins and now travis builds every commit. there
>> is no
>>> point building daily if you are building every commit already.
>>> 
>>> the issue isn't the builds, it's the tests themselves. having them cover
>>> everything in an efficient and sensible way. in fact lowering the
>> barrier of
>>> entry to making a test... that's the work needed. :)
>>> 
>>>> My take like this is engaging the community and user base more.
>>>> 
>>>> Let me ask you this and it’s more to ponder on. How much of the current
>> user
>>>> base is on the latest and greatest?
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On 14 Jul 2018, at 08:57, Carsten Haitzler (The Rasterman)
>>>>>  wrote:
>>>>> 
>>>>> On Fri, 13 Jul 2018 18:51:30 +0300 Jonathan Aquilina
>>>>>  said:
>>>>> 
>>>>>> I think it was me not being clear I think what I’m thinking is
>> nightly tar
>>>>>> balls and if need be I’m willing to work on pre packaged binaries for
>>>>>> nightly builds
>>>>> 
>>>>> TBH fixes don't move into a stable branch fast enough to justify
>> nightlies.
>>>>> they go in over time maybe every few days or weeks then every now and
>> again
>>>>> a point release goes out with them after a "does it compile and pass
>> tests"
>>>>> check. these releases are incredibly easy and simple and can be
>> automated,
>>>>> but no point having them nightly - just a "we have enough fixes now -
>> push
>>>>> one out" time point.
>>>>> 
>>>>>> Sent from my iPhone
>>>>>> 
>>>>>>> On 13 Jul 2018, at 18:46, Stefan Schmidt 
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Hello.
>>>>>>> 
>>>>>>>> On 13.07.2018 11:27, Jonathan Aquilina wrote:
>>>>>>>> I was even thinking weekly point releases to get any new code or bug
>>>>>>>> fixes out for early testing.
>>>>>>> 
>>>>>>> Hmm, not sure I get you here. What I talk about are stable updates
>> which
>>>>>>> would only contain fixes. No new code and definitely not used for
>>>>>>> testing at the users systems. These should only ship with verified
>> fixes.
>>>>>>> 
>>>>>>> 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.

Re: [E-devel] End of Week: Phab Report

[Jonathan Aquilina]

Hi mike I can code in python and take it as a chance to brush up on my python 
scripting skills.

Any chance you can open a ticket and assign it to me please

Sent from my iPhone

> On 14 Jul 2018, at 19:25, Mike Blumenkrantz  
> wrote:
> 
> I suppose it's possible? Phabricator itself doesn't have any facilities for
> such a thing, but I think it should be doable to write a script to:
> 
> * scrape the ticket and patch review infrastructure and total the number of
> tickets in each query.
> * put the numbers into a mail template
> * send a mail to this list
> 
> Most likely the script would need to be python like git-phab or a shell
> script that uses 'arc call-conduit' to manually trigger phabricator methods.
> 
> On Sat, Jul 14, 2018 at 3:07 AM Jonathan Aquilina 
> wrote:
> 
>> Not to hijack this email but mike is this something which can be automated
>> and sent out weekly basis without any need for human intervention and just
>> use an email template that looks at the Phab tags for information?
>> 
>> Sent from my iPhone
>> 
>>> On 13 Jul 2018, at 21:18, Mike Blumenkrantz <
>> michael.blumenkra...@gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> I forgot to send this last week and people were feeling demotivated, so
>>> it's back again.
>>> 
>>> TICKETS:
>>> *https://phab.enlightenment.org/maniphest/query/YZYWvpQGfcgM/
>>> <https://phab.enlightenment.org/maniphest/query/YZYWvpQGfcgM/>*
>>> * 10 regular tasks open with the 1.21 milestone
>>> Some work has already been done on these, and the number has once again
>>> been cut in half since the last report.
>>> * 4 regression tickets open which must be resolved before the final 1.21
>>> release
>>> All of these already have patches in review, no further work beyond
>>> review/testing is required.
>>> * This search query is now available in the sidebar of the maniphest view
>>> for easier access.
>>> 
>>> PATCHES
>>> *https://phab.enlightenment.org/differential/query/38N2dAUrUZ7J/
>>> <https://phab.enlightenment.org/differential/query/38N2dAUrUZ7J/>*
>>> * 13 patches awaiting review
>>> * This search query is now available in the sidebar of the differential
>>> view for easier access.
>>> 
>>> If you aren't submitting your patches for review yet, please consider
>> doing
>>> so using the documentation here:
>> https://phab.enlightenment.org/w/arcanist/
>>> 
>>> Build status is green at present, tests are all passing as well. Next
>> week
>>> is a big Samsung internal event, so some slowdown may occur.
>>> 
>>> Regards,
>>> Mike
>>> 
>> --
>>> 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
>> 
> --
> 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] Community Scheduling

[Jonathan Aquilina]

Where can I begin?

Sent from my iPhone

> On 14 Jul 2018, at 10:25, Carsten Haitzler  wrote:
> 
> On Sat, 14 Jul 2018 10:00:41 +0300 Jonathan Aquilina 
> said:
> 
>> Hi Raster with what you said below and other threads I’ve seen with people
>> complaining about lack of unit tests etc wouldn’t it be better to get nightly
>> builds to those that like to be on bleeding edge and help us test and report
>> bugs. Not to mention I think nightly builds are possible as I see a lot of
>> things that get committed to the repos on a daily basis at times.
> 
> we already have that - jenkins and now travis builds every commit. there is no
> point building daily if you are building every commit already.
> 
> the issue isn't the builds, it's the tests themselves. having them cover
> everything in an efficient and sensible way. in fact lowering the barrier of
> entry to making a test... that's the work needed. :)
> 
>> My take like this is engaging the community and user base more.
>> 
>> Let me ask you this and it’s more to ponder on. How much of the current user
>> base is on the latest and greatest?
>> 
>> Sent from my iPhone
>> 
>>> On 14 Jul 2018, at 08:57, Carsten Haitzler (The Rasterman)
>>>  wrote:
>>> 
>>> On Fri, 13 Jul 2018 18:51:30 +0300 Jonathan Aquilina
>>>  said:
>>> 
>>>> I think it was me not being clear I think what I’m thinking is nightly tar
>>>> balls and if need be I’m willing to work on pre packaged binaries for
>>>> nightly builds
>>> 
>>> TBH fixes don't move into a stable branch fast enough to justify nightlies.
>>> they go in over time maybe every few days or weeks then every now and again
>>> a point release goes out with them after a "does it compile and pass tests"
>>> check. these releases are incredibly easy and simple and can be automated,
>>> but no point having them nightly - just a "we have enough fixes now - push
>>> one out" time point.
>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On 13 Jul 2018, at 18:46, Stefan Schmidt 
>>>>> wrote:
>>>>> 
>>>>> Hello.
>>>>> 
>>>>>> On 13.07.2018 11:27, Jonathan Aquilina wrote:
>>>>>> I was even thinking weekly point releases to get any new code or bug
>>>>>> fixes out for early testing.
>>>>> 
>>>>> Hmm, not sure I get you here. What I talk about are stable updates which
>>>>> would only contain fixes. No new code and definitely not used for
>>>>> testing at the users systems. These should only ship with verified fixes.
>>>>> 
>>>>> 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
>>>> 
>>>> 
>>>> --
>>>> 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
>>> 
>> 
> 
> 
> -- 
> - 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] Community Scheduling

[Jonathan Aquilina]

I can get a vps from Linode and sponsor it myself I can work on setting up 
docker containers for build systems if need be.

Also what is interesting is with Linode you can setup and use a GUI through 
what they call glish

https://www.linode.com/docs/platform/using-the-linode-graphical-shell-glish/

These vms might make for good little testing environments if anyone is 
interested.

Honestly though the two types of packages one needs to build binaries for are 
deb and rpm right?

Another question do we have any snaps for Ubuntu?

Sent from my iPhone

> On 14 Jul 2018, at 09:03, Carsten Haitzler (The Rasterman) 
>  wrote:
> 
> On Fri, 13 Jul 2018 14:35:10 -0400 Stefan Schmidt 
> said:
> 
>> Hello.
>> 
>>> On 13.07.2018 13:09, Jonathan Aquilina wrote:
>>> I think my take is more from the end user base. Isn’t it worth the time and
>>> effort to have binaries available for those non developers?
>> 
>> Every night? I would say no. For releases? Maybe.
> 
> setting up the infra (chroots etc.) for every distro and multiple versions is
> going to be a LOT of work... the packaging needs to be properly done with
> proper split between dev/devel and core, etc. ... I think the best bang for
> buck would be to focus on 1 or 2 distros and do it right (make a proper distro
> image/install that has everything set up right).
> 
>> 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
> 
> 
> -- 
> - 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] End of Week: Phab Report

[Jonathan Aquilina]

Not to hijack this email but mike is this something which can be automated and 
sent out weekly basis without any need for human intervention and just use an 
email template that looks at the Phab tags for information?

Sent from my iPhone

> On 13 Jul 2018, at 21:18, Mike Blumenkrantz  
> wrote:
> 
> Hi,
> 
> I forgot to send this last week and people were feeling demotivated, so
> it's back again.
> 
> TICKETS:
> *https://phab.enlightenment.org/maniphest/query/YZYWvpQGfcgM/
> *
> * 10 regular tasks open with the 1.21 milestone
> Some work has already been done on these, and the number has once again
> been cut in half since the last report.
> * 4 regression tickets open which must be resolved before the final 1.21
> release
> All of these already have patches in review, no further work beyond
> review/testing is required.
> * This search query is now available in the sidebar of the maniphest view
> for easier access.
> 
> PATCHES
> *https://phab.enlightenment.org/differential/query/38N2dAUrUZ7J/
> *
> * 13 patches awaiting review
> * This search query is now available in the sidebar of the differential
> view for easier access.
> 
> If you aren't submitting your patches for review yet, please consider doing
> so using the documentation here: https://phab.enlightenment.org/w/arcanist/
> 
> Build status is green at present, tests are all passing as well. Next week
> is a big Samsung internal event, so some slowdown may occur.
> 
> Regards,
> Mike
> --
> 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] Community Scheduling

[Jonathan Aquilina]

Hi Raster with what you said below and other threads I’ve seen with people 
complaining about lack of unit tests etc wouldn’t it be better to get nightly 
builds to those that like to be on bleeding edge and help us test and report 
bugs. Not to mention I think nightly builds are possible as I see a lot of 
things that get committed to the repos on a daily basis at times.

My take like this is engaging the community and user base more.

Let me ask you this and it’s more to ponder on. How much of the current user 
base is on the latest and greatest?

Sent from my iPhone

> On 14 Jul 2018, at 08:57, Carsten Haitzler (The Rasterman) 
>  wrote:
> 
> On Fri, 13 Jul 2018 18:51:30 +0300 Jonathan Aquilina 
> said:
> 
>> I think it was me not being clear I think what I’m thinking is nightly tar
>> balls and if need be I’m willing to work on pre packaged binaries for nightly
>> builds
> 
> TBH fixes don't move into a stable branch fast enough to justify nightlies.
> they go in over time maybe every few days or weeks then every now and again a
> point release goes out with them after a "does it compile and pass tests"
> check. these releases are incredibly easy and simple and can be automated, but
> no point having them nightly - just a "we have enough fixes now - push one 
> out"
> time point.
> 
>> Sent from my iPhone
>> 
>>> On 13 Jul 2018, at 18:46, Stefan Schmidt  wrote:
>>> 
>>> Hello.
>>> 
>>>> On 13.07.2018 11:27, Jonathan Aquilina wrote:
>>>> I was even thinking weekly point releases to get any new code or bug fixes
>>>> out for early testing.
>>> 
>>> Hmm, not sure I get you here. What I talk about are stable updates which
>>> would only contain fixes. No new code and definitely not used for
>>> testing at the users systems. These should only ship with verified fixes.
>>> 
>>> 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
>> 
>> 
>> --
>> 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] Community Scheduling

[Jonathan Aquilina]

Can Travis build rpm and deb binaries?

Sent from my iPhone

> On 13 Jul 2018, at 19:41, Mike Blumenkrantz  
> wrote:
> 
> I think it should be possible to just upload a travis build somewhere
> periodically if we want to do this?
> 
> On Fri, Jul 13, 2018 at 11:56 AM Stefan Schmidt 
> wrote:
> 
>> Hello.
>> 
>>> On 13.07.2018 11:51, Jonathan Aquilina wrote:
>>> I think it was me not being clear I think what I’m thinking is nightly
>> tar balls and if need be I’m willing to work on pre packaged binaries for
>> nightly builds
>> 
>> OK, very different from what I understood under a point release. Nightly
>> builds make it clear.
>> 
>> I really see no need for this. People that update often will use git
>> imho and not use nighlies for this. I am pretty much biased here as I am
>> a developer using git anyway and not a user, though.
>> 
>> 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
>> 
> --
> 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] Community Scheduling

[Jonathan Aquilina]

I think my take is more from the end user base. Isn’t it worth the time and 
effort to have binaries available for those non developers?

Sent from my iPhone

> On 13 Jul 2018, at 18:55, Stefan Schmidt  wrote:
> 
> Hello.
> 
>> On 13.07.2018 11:51, Jonathan Aquilina wrote:
>> I think it was me not being clear I think what I’m thinking is nightly tar 
>> balls and if need be I’m willing to work on pre packaged binaries for 
>> nightly builds
> 
> OK, very different from what I understood under a point release. Nightly
> builds make it clear.
> 
> I really see no need for this. People that update often will use git
> imho and not use nighlies for this. I am pretty much biased here as I am
> a developer using git anyway and not a user, though.
> 
> 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


--
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] Community Scheduling

[Jonathan Aquilina]

I think it was me not being clear I think what I’m thinking is nightly tar 
balls and if need be I’m willing to work on pre packaged binaries for nightly 
builds

Sent from my iPhone

> On 13 Jul 2018, at 18:46, Stefan Schmidt  wrote:
> 
> Hello.
> 
>> On 13.07.2018 11:27, Jonathan Aquilina wrote:
>> I was even thinking weekly point releases to get any new code or bug fixes 
>> out for early testing.
> 
> Hmm, not sure I get you here. What I talk about are stable updates which
> would only contain fixes. No new code and definitely not used for
> testing at the users systems. These should only ship with verified fixes.
> 
> 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


--
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] Community Scheduling

[Jonathan Aquilina]

Could we enhance the scripts to make things easier to do this?

If that is a yes then I’m more than willing to work on enhancing the scripts

Sent from my iPhone

> On 13 Jul 2018, at 16:36, Mike Blumenkrantz  
> wrote:
> 
> Yes, I think bugfix releases should be done much more frequently. The issue
> here is that doing releases in EFL is still very cumbersome; we need to
> greatly reduce the amount of active work that it takes to execute and ship
> a release.
> 
> On Fri, Jul 13, 2018 at 3:21 AM Jonathan Aquilina 
> wrote:
> 
>> Some food for thought wouldn’t it be better to do more frequent point
>> releases?
>> 
>> Sent from my iPhone
>> 
>>> On 12 Jul 2018, at 20:12, Mike Blumenkrantz <
>> michael.blumenkra...@gmail.com> wrote:
>>> 
>>> Now that we're interacting more as a community, I think there is the
>>> general expectation that if you're a core developer then you should try
>> to
>>> notify the project if you'll be gone for an extended period of time.
>>> 
>>> I agree that there is a "deal with it" aspect to a community project,
>> but I
>>> think that if a core developer will be gone for longer than maybe a week,
>>> then there should be some responsibility to at least alert everyone of
>> that
>>> unavailability. I don't think that's an unreasonable thing to ask?
>>> 
>>> To be clear, while this mail was not directed at you, certainly your
>>> absence was a factor in my sending it--I didn't even know that you would
>> be
>>> gone until 1-2 weeks after you'd left. While I am not in any way blaming
>>> you for taking a vacation, it would have been nice to be able to check
>> the
>>> calendar on the first week that you were out and seen that you were gone.
>>> 
>>> I would disagree with your assessment that you are the single point of
>>> failure in releases. The 1.21 release has had a lot of issues, more than
>>> any release since the 1.8 cycle in 2013. When a release fails to happen
>> on
>>> schedule as a result of community/project issues, I don't think the
>> release
>>> manager can be blamed in any way.
>>> 
>>> I can appreciate your concerns with community involvement in the release
>>> process, but I don't think that "stepping down" from the position of
>>> release manager will solve anything. Releases in EFL have historically
>> been
>>> handicapped by many issues, but most notably--as you mentioned--by lack
>> of
>>> community collaboration. This is not specific to releases however; it's
>>> only recently that we've begun to come together and make a concerted
>> effort
>>> to act and behave as a real community instead of simply bickering
>> endlessly
>>> about every trivial item.
>>> 
>>> Going forward, I would really appreciate it if you could give managing
>>> releases one more try for the 1.22 cycle, and send some mails to the list
>>> (or create tickets) regarding things that the community can do to help
>> with
>>> releases. Everyone knows in some sense that you need help, but I think
>>> maybe we're all a bit unsure what we can do to contribute.
>>> It would also be great if we could also do a bit more automation with
>>> releases, to reduce the active work burden on whoever is executing the
>>> release. I'm certainly willing to pitch in and help see if we can further
>>> streamline the release process, as well as discussing any changes which
>>> could simplify the process and avoid future cases where the release gets
>>> blocked for a long period of time.
>>> 
>>> Regardless of whether you follow through with your plan to step down from
>>> managing releases, I just want to say thanks for all the time and effort
>>> you've put into managing releases over the years. I know it wasn't easy,
>>> but you kept everyone (mostly) on schedule for many years, and I can't
>>> think of anyone who could have done it better.
>>> 
>>> On Thu, Jul 12, 2018 at 10:33 AM Stefan Schmidt <
>> ste...@datenfreihafen.org>
>>> wrote:
>>> 
>>>> Hello.
>>>> 
>>>>> On 10.07.2018 07:42, Mike Blumenkrantz wrote:
>>>>> Hello,
>>>>> 
>>>>> It seems that we have some issues lately regarding scheduling,
>>>> specifically
>>>>> personal schedules. We (as a project) have expectations of developer
>>>>> availability, and when these expectation

Re: [E-devel] Community Scheduling

[Jonathan Aquilina]

I was even thinking weekly point releases to get any new code or bug fixes out 
for early testing.

Sent from my iPhone

> On 13 Jul 2018, at 16:46, Stefan Schmidt  wrote:
> 
> Hello.
> 
>> On 13.07.2018 03:20, Jonathan Aquilina wrote:
>> Some food for thought wouldn’t it be better to do more frequent point 
>> releases?
> 
> If you look at the releases before 1.20 you will see that we did quite a
> few. I aimed for a one stable update per months schedule. Sometimes
> being faster or slower depending on how critical the backports have been.
> 
> With 1.20 and now 1.21 the schedules are all messed up. I would agree
> that coming back to more frequent stable updates make sense.
> 
> 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


--
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] Community Scheduling

[Jonathan Aquilina]

Count me in to start a team for this

Sent from my iPhone

> On 13 Jul 2018, at 17:02, Stefan Schmidt  wrote:
> 
> Hello.
> 
>> On 13.07.2018 03:10, Jonathan Aquilina wrote:
>> Hi Stefan,
>> 
>> What know how does one need for this role?
> 
> Well, there are many different parts to it.
> 
> The mechanical part of doing the tarballs is not that hard (parts are
> even scripted).
> 
> The other part is to keep an eye on the bug reports, monitoring critical
> ones, pitching in with comments, testing etc.
> 
> Running things like abi-checker and reviewing the reports to see how we
> do regarding API breaks.
> 
> The more complicated part is that you would need to understand enough of
> the code base to follow up with the latest issues that block a release.
> It does not mean you have to fix them yourself but you would need to
> understand the severity and impact the issue would have.
> 
> In general I would recommend to have developer with longer efl
> experience to handle the release. There are tasks that can be split of
> and helped with by all kind of folks though. If one takes the releases
> notes as an example. This have been taking a lot of my extra time on the
> release. If someone would got around look through the git log, pick
> bigger features, ask the authors to write up a short piece on it and
> massages it all into release notes this could be split of to people
> without a core developer background easily.
> 
> 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


--
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] Community Scheduling

[Jonathan Aquilina]

Some food for thought wouldn’t it be better to do more frequent point releases?

Sent from my iPhone

> On 12 Jul 2018, at 20:12, Mike Blumenkrantz  
> wrote:
> 
> Now that we're interacting more as a community, I think there is the
> general expectation that if you're a core developer then you should try to
> notify the project if you'll be gone for an extended period of time.
> 
> I agree that there is a "deal with it" aspect to a community project, but I
> think that if a core developer will be gone for longer than maybe a week,
> then there should be some responsibility to at least alert everyone of that
> unavailability. I don't think that's an unreasonable thing to ask?
> 
> To be clear, while this mail was not directed at you, certainly your
> absence was a factor in my sending it--I didn't even know that you would be
> gone until 1-2 weeks after you'd left. While I am not in any way blaming
> you for taking a vacation, it would have been nice to be able to check the
> calendar on the first week that you were out and seen that you were gone.
> 
> I would disagree with your assessment that you are the single point of
> failure in releases. The 1.21 release has had a lot of issues, more than
> any release since the 1.8 cycle in 2013. When a release fails to happen on
> schedule as a result of community/project issues, I don't think the release
> manager can be blamed in any way.
> 
> I can appreciate your concerns with community involvement in the release
> process, but I don't think that "stepping down" from the position of
> release manager will solve anything. Releases in EFL have historically been
> handicapped by many issues, but most notably--as you mentioned--by lack of
> community collaboration. This is not specific to releases however; it's
> only recently that we've begun to come together and make a concerted effort
> to act and behave as a real community instead of simply bickering endlessly
> about every trivial item.
> 
> Going forward, I would really appreciate it if you could give managing
> releases one more try for the 1.22 cycle, and send some mails to the list
> (or create tickets) regarding things that the community can do to help with
> releases. Everyone knows in some sense that you need help, but I think
> maybe we're all a bit unsure what we can do to contribute.
> It would also be great if we could also do a bit more automation with
> releases, to reduce the active work burden on whoever is executing the
> release. I'm certainly willing to pitch in and help see if we can further
> streamline the release process, as well as discussing any changes which
> could simplify the process and avoid future cases where the release gets
> blocked for a long period of time.
> 
> Regardless of whether you follow through with your plan to step down from
> managing releases, I just want to say thanks for all the time and effort
> you've put into managing releases over the years. I know it wasn't easy,
> but you kept everyone (mostly) on schedule for many years, and I can't
> think of anyone who could have done it better.
> 
> On Thu, Jul 12, 2018 at 10:33 AM Stefan Schmidt 
> wrote:
> 
>> Hello.
>> 
>>> On 10.07.2018 07:42, Mike Blumenkrantz wrote:
>>> Hello,
>>> 
>>> It seems that we have some issues lately regarding scheduling,
>> specifically
>>> personal schedules. We (as a project) have expectations of developer
>>> availability, and when these expectations are changed or not met then
>>> things can get a bit messy.
>> 
>> Do we (as a project) really have this expectations? For me a community
>> project has to deal with the coming and going of developer resources.
>> 
>> I tried many times to get a 1.21 release schedule set that would have
>> avoided my unavailability in June. All of these attempts failed and we
>> ended in this situation.
>> 
>>> Fortunately, we have tools to avoid issues with this.
>>> 
>>> https://phab.enlightenment.org/calendar/
>>> 
>>> If anyone is planning to be unavailable for a length of time which could
>>> impact the project (e.g., going on vacation/holiday for a week, going on
>> a
>>> business trip for several days when a release is pending, ...), please
>>> create an event on the calendar for it. The visibility for events can be
>>> set to "committers" if anyone is concerned about privacy, and I would not
>>> recommend providing excessive detail in the event description; a simple
>>> "unavailable" is enough.
>> 
>> I already have a private and a business calendar I need to keep updated.
>> I am not keen to have another one I need to update. My work scope
>> changed, my travels have increased and my private time I put into this
>> project has also reduced due to personal changes. Even if I would say
>> yes here to update such a schedule this with lag behind in just a few
>> weeks time from now due to me not updating it.
>> 
>> On the bright side though I should no longer be the single point failure
>> for release stuff after 1.21 is out as I will step down 

Re: [E-devel] Community Scheduling

[Jonathan Aquilina]

Hi Stefan,

What know how does one need for this role?

Sent from my iPhone

> On 12 Jul 2018, at 17:32, Stefan Schmidt  wrote:
> 
> Hello.
> 
>> On 10.07.2018 07:42, Mike Blumenkrantz wrote:
>> Hello,
>> 
>> It seems that we have some issues lately regarding scheduling, specifically
>> personal schedules. We (as a project) have expectations of developer
>> availability, and when these expectations are changed or not met then
>> things can get a bit messy.
> 
> Do we (as a project) really have this expectations? For me a community
> project has to deal with the coming and going of developer resources.
> 
> I tried many times to get a 1.21 release schedule set that would have
> avoided my unavailability in June. All of these attempts failed and we
> ended in this situation.
> 
>> Fortunately, we have tools to avoid issues with this.
>> 
>> https://phab.enlightenment.org/calendar/
>> 
>> If anyone is planning to be unavailable for a length of time which could
>> impact the project (e.g., going on vacation/holiday for a week, going on a
>> business trip for several days when a release is pending, ...), please
>> create an event on the calendar for it. The visibility for events can be
>> set to "committers" if anyone is concerned about privacy, and I would not
>> recommend providing excessive detail in the event description; a simple
>> "unavailable" is enough.
> 
> I already have a private and a business calendar I need to keep updated.
> I am not keen to have another one I need to update. My work scope
> changed, my travels have increased and my private time I put into this
> project has also reduced due to personal changes. Even if I would say
> yes here to update such a schedule this with lag behind in just a few
> weeks time from now due to me not updating it.
> 
> On the bright side though I should no longer be the single point failure
> for release stuff after 1.21 is out as I will step down from the release
> manager role. I tried to form a release team for many years so far but
> failed in getting anyone interested. By stepping down I kind of forcing
> this change, hopefully for the better.
> 
> 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


--
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] git-phab update

[Jonathan Aquilina]

Hi mike,

I have a bit of experience with python just rusty with it.

What are you trying to achieve in a non hackish way?

Sent from my iPhone

> On 13 Jul 2018, at 02:17, Mike Blumenkrantz  
> wrote:
> 
> Hello,
> 
> I've done more gross hacks to the git-phab script since no real python
> developers have shown up:
> 
> https://phab.enlightenment.org/P227
> 
> This fixes adding project tags (-p option) as well as adding
> reviewers/subscribers when updating patches.
> 
> Still hoping someone better at python than me steps in to help out!
> 
> Regards,
> Mike
> --
> 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] Release Handling

[Jonathan Aquilina]

Marcel this is what I have been wanting to see for some time. I want to 
contribute but given not knowing the code base this made it a rather daunting 
task for me. I hope this system is something that will stick and see new 
contributors joining.

Sent from my iPhone

> On 08 Jun 2018, at 17:31, Marcel Hollerbach  wrote:
> 
> Hello,
> 
> as Mike said, here my proposal for handling bugs for the upcoming release:
> 
> i) Every bug will get a difficulty assigned either Easy, Difficult, or 
> Impossible, this is to ensure that new people, and people that don't know the 
> subsystem or context very well can also help bugfixing.
> 
> ii) I am going to create 4 new workboards:
> - primitives: Stuff that has its root problems in eina, eo, (low in our 
> software stack)
> - interfaces: A Bug is caused due to the movement to a different namespace, 
> refactoring into new classes, or changes related to new efl_* code / classes.
> - rendering: A Bug is located in the engine code for some protocol/platform
> - widgets: Your usage of elm widgets broke somewhere between efl-1.20 and the 
> current state.
> 
> iii) If you work on a bug, claim it for you. If a other bug sneaks in 
> between, or there is no time in the next week or so: Document your findings, 
> and remove your name from the assignee field on phabricator, so someone else 
> might work on the bug.
> 
> Any objections ? For Monday I am planning to go through the bugtracker trying 
> to assign difficulities, and workboards.
> 
> Greetings,
>   bu5hm4n
> 
> --
> 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] latest efl lifecycle commits (from cedric)

[Jonathan Aquilina]

Not totally sure how Jenkins works but from what I have seen on the liver 
office project they use terror. You need three reviews before a patch gets 
pushed to the repository that way testing of each patch is kind of forced prior 
to pushing to the repo.

Sent from my iPhone

> On 29 May 2018, at 14:55, William L. Thomson Jr. 
>  wrote:
> 
> On Tue, 29 May 2018 06:36:47 +0200
> Jonathan Aquilina  wrote:
> 
>> Question do you guys have some tinder boxes that will auto build each
>> commit and if they fail a report is emailed notifying that there are
>> failures. I am very willing to sponsor a server
> 
> They have CI, Jenkins locally on E servers, and Travis
> https://travis-ci.org/Enlightenment/efl/builds
> 
> -- 
> William L. Thomson Jr.
> --
> 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] latest efl lifecycle commits (from cedric)

[Jonathan Aquilina]

Question do you guys have some tinder boxes that will auto build each commit 
and if they fail a report is emailed notifying that there are failures. I am 
very willing to sponsor a server

Sent from my iPhone

> On 29 May 2018, at 05:40, Carsten Haitzler (The Rasterman) 
>  wrote:
> 
> On Mon, 28 May 2018 16:05:11 -0400 "William L. Thomson Jr."
>  said:
> 
>> On Mon, 28 May 2018 19:55:55 +0200
>> Marcel Hollerbach  wrote:
>> 
>>> Hello,
>>> 
>>> D6224, D6223, D6222 are fixing the issue. (Or at least the cases i
>>> have seen).
>>> 
>>> However, could you stop acting up like this & writing mails like
>>> this? 
>> 
>> Maybe there needs to be more so others do not do such things?
> 
> will - i know we have our differences... but you hit the nail on the head
> here. :)
> 
>>> The lifetime of eo objects have been quite a mess, this branch
>>> brought a bit light into the dark, it was not perfect how it came,
>>> sure, 
>> 
>> I think all should focus more on the breakage than the reaction.
> 
> absolutely. i tried to make it clear it wasn't personal and i was focusing on
> the breakage and a solution (either solve without revert or a revert needed). 
> i
> also anted to point out that commits of this nature in large batches when it
> becomes "unibsectable" have horrible knock-on effects to other people trying 
> to
> fix it and as daniel points out too - in future digging through history to 
> find
> the commit that changed something now has to skip this entire batch. this is
> not good to have in our history.
> 
>> Breaking things is bad m'kay... A few have reported breakage already.
>> That never reflects well on a project much less any TEAM.
> 
> correct. someone did a bad play... it's being pointed out and i'm airing 2
> solutions with a deadline (for now). one of the solutions is mine (revert) and
> is not pretty.
> 
>>> however here it is. Further more, you claim that this is not
>>> personal, why was it then not enough to create a ticket, or simply a
>>> revert revision to discuss things? 
>> 
>> It seemed like considerable time was spent trying to find a commit to
>> revert or a a series. How much time should another spend? Should things
>> be broken like this in the first place? With several reporting
>> breakage already, and more likely to experience such.
>> 
>>> Doing patches in EFL had always a  team flavor for me, mails like
>>> this are destroying that feeling. So in the end: Could we stop this
>>> stupid blame team and start to act as a team again?
>> 
>> Dropping a series of some 121 commits at once does not seem to team
>> friendly to me. Unless the work is perfect or well tested and
>> reviewed. There was already a discussion on reviews. If you say 1 minute
>> per commit, that is 2 hours of review... If there is a discussion on
>> any or needs testing modification etc. You are talking many hours...
> 
> 1 minute is not a review. a proper review of a patch takes at least on average
> i'd say 30-60min. some can be 5-10min (i include apply, compile and run here 
> on
> a fast machine) others need deep reading of a large diff. that can take hours
> depending on diff size of course.
> 
>> Not to mention with a upcoming release. Unless a bunch of stuff was
>> broken and this fixes all that. Then really should be less than more.
>> Every fix could potentially break something else. This seems like it
>> caused way more issues than it fixed. Hard to defend.
> 
> indeed. nail. head.
> 
>> I think the reaction of waiting a few days and giving the author and
>> TEAM a chance to fix is more than adequate and being overly nice. Not
>> to mention effort put forth to fix, revert, etc already. I would not
>> have been surprised if the commits were reverted right away. But a more
>> diplomatic approach was taken. That is nice enough IMHO.
> 
> i tried. :) a combo of work needed to revert + possible value+gains within the
> patch series vs "badness of results post patch" made me take this path.
> 
>> People really need to get thick skin again. Its ok for a team member or
>> project lead to be harsh on others for things. Surely for large patch
>> sets and breaking stuff I have seen others lose it in public venues
>> over much less... This being overly nice is why stuff like this can
>> happen and others think its ok. I think the reaction would change
>> things so such does not happen again. Then no reaction, no problem.
> 
> i did try and be nice... as i value the work put in and cedric's time and
> effort etc. etc. and i'm trying to offer a reasonable reaction and solutions 
> to
> this. if any kind of identification of patches in future is seen as bad and
> cannot be done, then i suspect this will be dysfunctional as it can get as you
> have to tiptoe around everything you say or do. you can never point at any
> code lest it perhaps identify a person and make them feel bad. 
> 
> 
> -- 
> - Codito, ergo sum - "I code, therefore I am" --
> Carsten Haitzler - ras...@rasterman.com
> 

Re: [E-devel] Get an IRC meeting togther? (IRC Channel Merge)

[Jonathan Aquilina]

When is the date for this meeting. Also can we add something to the agenda?

On 19/04/2018 03:13, Simon Lees wrote:
> 
> 
> On 18/04/18 18:42, Stefan Schmidt wrote:
>> This ticket has items on:
>>
>> o How to handle EFL proposals
>> o Project and or release roadmap
>> o Build breakages from commits
>> o IRC channel merge
> 
> No idea if i'll make the meeting but this one should be a simple no.
> There are plenty of times when we have too much chat volume to squeeze
> everything into one channel especially when people are talking detailed
> design / implementation in #edevelop, occasionally it feels like we need
> a 3rd channel. We should encourage everyone in #edevelop to be in #e and
> all non technical discussions to happen in #e though.
> 
> A better question is what are we going to migrate away from slack too
> when they close there irc bridge, it was the one competitive advantage
> they had over any of the other providers.
> 



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] Mailing list headaches

[Jonathan Aquilina]

Hi Raster,

My server was grey listing the emails I have so far allowed in the
trusted hosts lists the ip address that i saw logged and have fixed the
greylisting issue on my end I am still though having issues with other
mailing lists but tits rather hard to constantly monitor they
greylisting logs.

Granted I will be putting clients on this server I am not to keen on
removing grey listing.

On 29/03/2018 13:23, Carsten Haitzler wrote:
> On Thu, 29 Mar 2018 06:38:53 +0200 Jonathan Aquilina <jaquil...@eagleeyet.net>
> said:
> 
>> I have a more annoying problem that my emails are bouncing for some
>> reason or were but I think i fixed that with my grey list filter.
> 
> well i'm seeing your mails. you fixed your mailserver to deal with greylisting
> properly you mean? sf.net was greylisting you?
> 
>> On 29/03/2018 05:07, Carsten Haitzler (The Rasterman) wrote:
>>> On Wed, 28 Mar 2018 16:30:22 + jaquilina <jaquil...@eagleeyet.net> said:
>>>
>>>> Can anyone confirm if my email regarding fedora packaging of bleeding 
>>>> edge enlightenment. are my emails getting through.
>>>
>>> i replied to one of them... this mail went through. though a few weeks back
>>> sf.net had mail hiccups. they did some migration and this seemed to have
>>> been the root cause. that seems to have settled now.
>>>
>>>> On my cpanel email server in the delivery report logging I am seeing the 
>>>> following
>>>>
>>>> SMTP error from remote mail server after RCPT 
>>>> TO:<enlightenment-devel@lists.sourceforge.net>: 451-IPADDRESS is not yet 
>>>> authorized to deliver mail from\n451-<jaquil...@eagleeyet.net> to 
>>>> <enlightenment-devel@lists.sourceforge.net>.\n451 Please try later.
>>>>
>>>> Regards,
>>>> Jonathan
>>>>
>>>> --
>>>> 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
>>>>
>>>
>>>
>>
> 
> 



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] Mailing list headaches

[Jonathan Aquilina]

I have a more annoying problem that my emails are bouncing for some
reason or were but I think i fixed that with my grey list filter.

On 29/03/2018 05:07, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 28 Mar 2018 16:30:22 + jaquilina  said:
> 
>> Can anyone confirm if my email regarding fedora packaging of bleeding 
>> edge enlightenment. are my emails getting through.
> 
> i replied to one of them... this mail went through. though a few weeks back
> sf.net had mail hiccups. they did some migration and this seemed to have been
> the root cause. that seems to have settled now.
> 
>> On my cpanel email server in the delivery report logging I am seeing the 
>> following
>>
>> SMTP error from remote mail server after RCPT 
>> TO:: 451-IPADDRESS is not yet 
>> authorized to deliver mail from\n451- to 
>> .\n451 Please try later.
>>
>> Regards,
>> Jonathan
>>
>> --
>> 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
>>
> 
> 



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] Packages for fedora

[Jonathan Aquilina]

Hi Carsten,

Now that I have changed jobs and a bit more relaxed I have more time and
I am more than willing to put together a fedora spin. I think the more
distros we can have with e out of the box the better in the sense more
testing platforms and more get goign with just a simple install so to
speak and you are good to go. I know it will be alot of work but am very
interested in learning how to make my own spin. Who knows we could even
offer it through the fedora website as a download option.

Regards,
Jonathan

On 29/03/2018 05:11, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 28 Mar 2018 15:44:56 + jaquilina  said:
> 
>> Hi All,
>>
>> I am very interested in working with you guys on providing packages for 
>> fedora of the bleeding edge enlightenment stuff to help the dev's as 
>> well s end users test the platform for us. I know Raster had told me we 
>> should discuss, so I am sending this email to open up a discussion.
> 
> packages - absolutely. how can we help in that regard? do you want to have a
> fedora package repository hosted off e.org that you can push packages to?
> 
> i think though the conversation was more about doing an actual distro spin
> (e.g. a live ISO or such). and that is a good deal more work than just
> packages. i generally think splitting resources between multiple such distros
> would be a bad move just for "but i prefer my distro" preferences. not 
> everyone
> will be happy. my general take is to pick one and then focus on that. unless 
> we
> have resources coming out of our ears... but the talk was for some official e
> based distro spin to show off e/efl as it should be out of the box. think
> ubuntu being a spin of debian or elementary os showing off their work in an
> integrated "just works out of the box" setup.
> 



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

[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) 
> <ras...@rasterman.com> wrote:
> 
> On Wed, 7 Mar 2018 08:21:22 +0100 Jonathan Aquilina <jaquil...@eagleeyet.net>
> 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)
>>> <ras...@rasterman.com> wrote:
>>> 
>>> On Wed, 7 Mar 2018 12:03:27 +1030 Simon Lees <sfl...@suse.de> 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) <ras...@rasterman.com> 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] A step to improving communication - Meetings

[Jonathan Aquilina]

There is another option which Allows text and voice communications and that is 
discord. Thoughts on that?

Sent from my iPhone

> On 09 Mar 2018, at 10:53, Simon Lees <sfl...@suse.de> wrote:
> 
> Slack is now in the process of killing there irc bridge so this won't
> work for much longer, goodbye slack. (The bots are terrible you have no
> idea who's actually active in the other chat room).
> 
>> On 09/03/18 20:07, Jérémy Zurcher wrote:
>> smack slack !!
>> 
>> https://get.slack.help/hc/en-us/articles/201727913-Connect-to-Slack-over-IRC-and-XMPP
>> 
>> long life to irc clients !!!!
>> 
>>> On Friday 09 March 2018  10:08, Jonathan Aquilina wrote :
>>> Hi Stefan you forgot there is slack and can speak in the channel on Irc 
>>> that way if we have the bot there as well they can join us through slack
>>> 
>>> Sent from my iPhone
>>> 
>>>> On 09 Mar 2018, at 10:03, Stefan Schmidt <ste...@osg.samsung.com> wrote:
>>>> 
>>>> Hello.
>>>> 
>>>> 
>>>>> On 03/08/2018 06:40 PM, William L. Thomson Jr. wrote:
>>>>> One thing I have seen be of benefit in other communities is having
>>>>> regular meetings.
>>>>> 
>>>>> It was definitely beneficial to Gentoo Java Team, long ago. This some
>>>>> what helped create a team, and definitely helped keep people on the same
>>>>> page, helped with communication, etc. When meetings ended, so did the
>>>>> team over time. They helped make the team and broke it...
>>>>> 
>>>>> Does the E developer community ever meet beyond like EDD? Like regular
>>>>> monthly meetings in IRC or other?
>>>> 
>>>> No we don't and I think it is a good idea you brought up here.
>>>> 
>>>> I think we should try it out and see how it flies for us.
>>>> 
>>>> I would propose IRC as medium (already heavily in use, suitable for many 
>>>> attendees even if just lurking around, video calls might be awkward
>>>> and problematic with many attendees)
>>>> 
>>>> I would also propose it to be bi-weekly. That misses the nice regularity 
>>>> of weekly meetings, but I think that might be a bit to often. Maybe
>>>> I am wrong and weeklies would be better. Hard to say.
>>>> 
>>>> Finding the right time slot is problematic though. As far as I see it we 
>>>> might have attendance from US west and east coast, Europe as well
>>>> as Asia. What should we do about 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
>>> 
>>> 
>>> --
>>> 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
>> 
> 
> -- 
> 
> 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


--
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] A step to improving communication - Meetings

[Jonathan Aquilina]

Hi Stefan you forgot there is slack and can speak in the channel on Irc that 
way if we have the bot there as well they can join us through slack

Sent from my iPhone

> On 09 Mar 2018, at 10:03, Stefan Schmidt  wrote:
> 
> Hello.
> 
> 
>> On 03/08/2018 06:40 PM, William L. Thomson Jr. wrote:
>> One thing I have seen be of benefit in other communities is having
>> regular meetings.
>> 
>> It was definitely beneficial to Gentoo Java Team, long ago. This some
>> what helped create a team, and definitely helped keep people on the same
>> page, helped with communication, etc. When meetings ended, so did the
>> team over time. They helped make the team and broke it...
>> 
>> Does the E developer community ever meet beyond like EDD? Like regular
>> monthly meetings in IRC or other?
> 
> No we don't and I think it is a good idea you brought up here.
> 
> I think we should try it out and see how it flies for us.
> 
> I would propose IRC as medium (already heavily in use, suitable for many 
> attendees even if just lurking around, video calls might be awkward
> and problematic with many attendees)
> 
> I would also propose it to be bi-weekly. That misses the nice regularity of 
> weekly meetings, but I think that might be a bit to often. Maybe
> I am wrong and weeklies would be better. Hard to say.
> 
> Finding the right time slot is problematic though. As far as I see it we 
> might have attendance from US west and east coast, Europe as well
> as Asia. What should we do about 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


--
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