Re: [E-devel] Gitlab
> OH amount of CPU is indeed not "infinite". We have plenty of disk and RAM to > go > around. The way I see it is "keep build jobs in the background and they take > however long they take". Developers should be able to run builds on their own > boxes far faster than the shared infra and all this kind of QA/CI should be > easily reproducible in a more minimal form on developer workstations. This > scales out the load. I have a feeling we're just trying to do too much in a > central service that SHOULD be being done by developers already as they > build/develop etc. Agreed > > > compared to a raspberry pi .. e5 runs rings around it so many times it's > > > not > > > funny and an rpi can do this easily enough. yes - jenkins adds infra cost > > > itself, but a single vm for linux builds (with multiple chroots) would > > > consume very little resources > > > > That is true, the VM overhead is not negligible. VM were the initial > > design and we stuck on this. I am far from being against that as I'm far > > from being against containers, finding the right time to work on this is > > a different matter. > > Indeed VM's are not free. they cost a whole new OS instance in RAM etc. - thus > why I mention chroots for example. Containers add some more isolation but a > single "builder VM" with just chroots should do the trick for any Linux > builds. > > I'm trying to just point out that when you try and do "too much" you create > work and trouble for yourselves. If you try and behave like you have infinite > access to infrastructure then you will get into trouble. Behave like your > infra > has limits and you use it sensibly and everything can work just fine. > > I'm OK having infra that is not on e5/our hw that we can "live without". For > example - if someone wants to have build slaves scale out across > hosted/sponsored machines to get more builds done per day... that's fine. If > they go away we turn them off and just do fewer builds per day (like above). > THAT I'm OK with. IT allows a fairly painless degrade in service when that > happens. :) > > > > as it would only need a single build controller and just > > > spawn off scripts per build that do the chroot fun. > > > > > > sure - need a vm for bsd, and windows and other OS's that can't do the > > > chroot trick. > > > > > > > the hosting instances. Even still, current ressources are too limited. > > > > You will not be able to have more than 10 instances running at the same > > > > time. > > > > > > 10 build instances? if they are properly ionice'd and niced to be > > > background > > > tasks vs www etc... i think we can,. they might take longer as the xeons > > > are > > > old on the server, but they can do the task still. i regularly build efl/e > > > on hardware a tiny fraction of the power of e5. > > > > We don't just instances for build, we have instances for web, mail, git, > > phab etc .. Which by the way were moved to e6 last year after the > > website was pretty much unsable and the disk issue we had, server that I'm > > still paying myself. This was meant to be a temporary solution, but I > > did not find the appropriate time to allocate on putting stuff back. > > Yeah. I know things moved to e6. I'd like to move stuff back too. I don't want > you paying for this... We have infra. I just ordered a replacement disk BTW > for > e5... :) Appreciated > Maybe it'd make sense to set up that single "VM" on e5 and then move stuff > into > it. so it's just e5 -> VM and this VM just tuns shared hosting and/or chroots > and containers? That would be the right thing to do from what we have available today. Let's fix the fan and disk issue before touching anything to avoid mixing different problems at the same time. Cheers -- Bertrand signature.asc Description: Digital signature ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] meson for efl
On 27/09/2018 02:21, Carsten Haitzler (The Rasterman) wrote: > On Tue, 28 Aug 2018 20:32:00 +0900 Hermet Park said: > >> then do we expect users need to toggle features on/off manually? > > I would say so - yes. automagic has downsides for reproducible builds. > I agree here, when some things were automatic I saw alot of users and some distro packages with a less then optional configuration due to having things not detected. There was also cases where people were wondering why something worked on one machine and not another which came down to them having installed a devel package on one machine at one point then forgetting about it. For a while we had a really fun bug where if the machine you were building the release tarballs had systemd headers installed the release would build fine with or without systemd, but if the machine generating the tars didn't have the systemd devel packages the release wouldn't build with systemd. The things we think that most users should have for the best experience should be enabled by default and others disabled, so users should have to pass no flags unless they explicitly don't want something like systemd or they have some use case like embedded where they want some features most people don't use. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab/Infrastructure Slowvote
Hi all, Regardless of gitlab vs phab while Bertrand has done a great job for a long time I think that rebuilding our infra on a more mainstream distro makes a lot of sense, because it will be much easier to document and for more people to understand. Whether it ends up being Centos, openSUSE Leap or Debian doesn't really matter to me but I think those three are the ones that make the most sense atleast for the bare metal machine. If we decide that we would like to migrate to gitlab, then as Jonathan has said setting up a temporary machine that will look and feel like whatever we eventually want for our infra migrating to gitlab on that machine, then giving us the time to get our core infra back into shape and migrating back when its ready makes alot of sense. On 27/09/2018 03:29, Jonathan Aquilina wrote: > 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 > -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab/Infrastructure Slowvote
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
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] Fwd: [support.osuosl.org #29680] enlightenment5.osuosl.oob fan failure
On Tue, 25 Sep 2018 14:05:25 -0700 "Bertrand Jacquin via RT" said: i already checked on the parts. i can buy a fan, but we had a spare parts box bought and shipped WITH the server and it has a spare fan in it. that fan should be the correct one according to my checks. if that box of spares can be found then there is a spare fan sitting on site already. i want to know if that spare parts box and fan can be/have been found? if not then i can order a fan. > Hi, > > Here are the last info I received from SuperMicro, more people were Cced > on that thread. > > Hi Bertrand, > > Your question: > could you tell me how we can purchase such parts ? > If you don't have a specific reseller/distributor please check on our website > "where to buy" ,see below link: > https://www.supermicro.com/wheretobuy/europe.cfm > > > Nota: Supermicro doesn't sell directly no end user . > > Met vriendelijke groet / Best Regards / Cordialement > > Alexandre Tavares > Application Engineer > > P: +31-736400390 > E: support_eur...@supermicro.com > A: Het Sterrenbeeld 12-16 > 5215 ML 'S-Hertogenbosch > Netherlands > W: www.Supermicro.com > > Cheers, > Bertrand > > On Fri, Aug 31, 2018 at 08:11:05AM -0700, Jonathan Frederick via RT wrote: > > -- Forwarded message - > > From: Stephen Houston > > Date: Fri, Aug 31, 2018 at 6:45 AM > > Subject: Re: [E-devel] [support.osuosl.org #29680] > > enlightenment5.osuosl.oob fan failure > > To: Enlightenment developer list > > Cc: , , > > , , > > > > > > This still hasn't been resolved? Nearly a year later? Can you tell us > > what fan it is so we can order one and have it shipped to you if need be? > > > > On Fri, Aug 31, 2018 at 6:24 AM Jonathan Frederick via RT < > > supp...@osuosl.org> wrote: > > > > > On Mon Apr 02 12:08:51 2018, doublej472 wrote: > > > > On Tue Feb 27 17:20:57 2018, bertr...@jacquin.bzh wrote: > > > > > Hi Jonathan, > > > > > > > > > > We had a response from supermicro which got trapped in my spam box, > > > > I > > > > > am now waiting for info about the > > > > > purchase. > > > > > > > > > > Cheers > > > > > > > > > > > > > Hello Bertrand! > > > > > > > > I can still hear the server beeping and the LED going off whenever I'm > > > > in the > > > > datacenter, so what's the status on this? > > > > > > > > -- > > > > Jonathan Frederick > > > > Student Systems Engineer > > > > Oregon State University | Open Source Lab > > > > > > Ping! > > > > > > -- > > > Jonathan Frederick > > > Student Systems Engineer > > > Oregon State University | Open Source Lab > > > > > > > > > > > > -- > > > 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 > > > > > > > -- > Bertrand > -- - 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] Fwd: [support.osuosl.org #29680] enlightenment5.osuosl.oob fan failure
On Tue, 25 Sep 2018 14:05:25 -0700 "Bertrand Jacquin via RT" said: i already checked on the parts. i can buy a fan, but we had a spare parts box bought and shipped WITH the server and it has a spare fan in it. that fan should be the correct one according to my checks. if that box of spares can be found then there is a spare fan sitting on site already. i want to know if that spare parts box and fan can be/have been found? if not then i can order a fan. > Hi, > > Here are the last info I received from SuperMicro, more people were Cced > on that thread. > > Hi Bertrand, > > Your question: > could you tell me how we can purchase such parts ? > If you don't have a specific reseller/distributor please check on our website > "where to buy" ,see below link: > https://www.supermicro.com/wheretobuy/europe.cfm > > > Nota: Supermicro doesn't sell directly no end user . > > Met vriendelijke groet / Best Regards / Cordialement > > Alexandre Tavares > Application Engineer > > P: +31-736400390 > E: support_eur...@supermicro.com > A: Het Sterrenbeeld 12-16 > 5215 ML 'S-Hertogenbosch > Netherlands > W: www.Supermicro.com > > Cheers, > Bertrand > > On Fri, Aug 31, 2018 at 08:11:05AM -0700, Jonathan Frederick via RT wrote: > > -- Forwarded message - > > From: Stephen Houston > > Date: Fri, Aug 31, 2018 at 6:45 AM > > Subject: Re: [E-devel] [support.osuosl.org #29680] > > enlightenment5.osuosl.oob fan failure > > To: Enlightenment developer list > > Cc: , , > > , , > > > > > > This still hasn't been resolved? Nearly a year later? Can you tell us > > what fan it is so we can order one and have it shipped to you if need be? > > > > On Fri, Aug 31, 2018 at 6:24 AM Jonathan Frederick via RT < > > supp...@osuosl.org> wrote: > > > > > On Mon Apr 02 12:08:51 2018, doublej472 wrote: > > > > On Tue Feb 27 17:20:57 2018, bertr...@jacquin.bzh wrote: > > > > > Hi Jonathan, > > > > > > > > > > We had a response from supermicro which got trapped in my spam box, > > > > I > > > > > am now waiting for info about the > > > > > purchase. > > > > > > > > > > Cheers > > > > > > > > > > > > > Hello Bertrand! > > > > > > > > I can still hear the server beeping and the LED going off whenever I'm > > > > in the > > > > datacenter, so what's the status on this? > > > > > > > > -- > > > > Jonathan Frederick > > > > Student Systems Engineer > > > > Oregon State University | Open Source Lab > > > > > > Ping! > > > > > > -- > > > Jonathan Frederick > > > Student Systems Engineer > > > Oregon State University | Open Source Lab > > > > > > > > > > > > -- > > > 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 > > > > > > > -- > Bertrand > -- - 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] Gitlab
On Tue, 25 Sep 2018 22:09:22 +0100 Bertrand Jacquin said: > On Mon, Sep 24, 2018 at 12:26:03PM +0100, Carsten Haitzler wrote: > > On Sat, 22 Sep 2018 15:51:44 +0100 Bertrand Jacquin > > said: > > > > > On Fri, Sep 14, 2018 at 09:16:23AM +0100, Carsten Haitzler wrote: > > > > On Wed, 12 Sep 2018 06:45:20 -0500 Stephen Houston > > > > said: > > > > > > > > > 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. > > > > > > > > i thought cedric was going to order one from califronia and beber was > > > > getting the model from supermicro ... i saw/heard nothing so thought > > > > they exchanged the info... seems not. > > > > > > > > I'll chase this up. we bought from silicon mechanics. I'll hunt down the > > > > original order and ask them if they know what fan model it would be. > > > > > > > > But that doesn't change the overall state of the sevrer. IPMI console > > > > access is an issue. I tried to gbet it to work for a day or 2 via my > > > > osuosl vpn ... i got to a web page for it and password didn't work. i > > > > can try again. with an ipmi console the device is maintainable. it can > > > > be re=installed if needed, kernel upgraded etc. ... > > > > > > IPMI is accessible over OSUOSL OpenVPN. Admin password is stored in in > > > our shared passwordstore. Tested 10 minutes ago, credentials are still > > > valid > > > > You used the IPMI console web page? Last time I tried this it didn't work. > > Yes, that was using the web interface. hmmm. so either i ended up at someone elses machine or didn't use that password or... i don't know. > > (that same password I think). My home desktop was configured for the VPN > > and is currently not usable for a few more weeks, so I'm waiting for that. > > Do you mean you don't have access to OSUOSL VPN ? If that's the case > that's a different issue indeed. i do have it on my desktop that i can't use due to moving ATM. thus this needs to wait until i stop living out of a suitcase. :) -- - 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] Gitlab
On Tue, 25 Sep 2018 22:08:14 +0100 Bertrand Jacquin said: > On Mon, Sep 24, 2018 at 11:54:16AM +0100, Carsten Haitzler wrote: > > On Sat, 22 Sep 2018 15:57:27 +0100 Bertrand Jacquin > > said: > > > > > > > This is something I do not agree with. I have been kicking into pants > > > > > for problems with the infra for _years_ when doing Jenkins. It has > > > > > changed nothing and I moved over to cloud services to get the control > > > > > and flexibility I needed. > > > > > > > > This is a result of policy from Beber of giving pretty minimal VM's with > > > > limited ram/disk with gentoo. We have the resources - they are just not > > > > being assigned and being able to provision your own is far too complex > > > > with what we have. If all you had to do was run some libvirt cmds to > > > > spin up a new VM of whatever size/config you wanted , I think you'd be > > > > fine. > > > > > > Well, e5 clearly has not enough memory and CPU to support all the build > > > ran by Jenkins, this is why we had to split the building instances from > > > > That I just don't buy. I compile all of e, efl, terminology, rage on a > > raspberry pi with 768m ram (256 partitioned off to gpu) and do parallel > > builds... and can run a gui at the same time. e5 has 48gb of ram. last i > > heard from stefan the vm's for building had maybe 2 or 4gb ram allocated to > > them and limited disk space. correct me if i'm wrong - this may have been a > > while ago. > > Memory is not the issue here, CPU is. Each VM has 4GB or RAM, each build > use -j6 and we can have up to 4 jenkins build at the same time, this on > 3 different VM. > > Read this a different way: having build and servers (web, git etc) is not > achievable. OH amount of CPU is indeed not "infinite". We have plenty of disk and RAM to go around. The way I see it is "keep build jobs in the background and they take however long they take". Developers should be able to run builds on their own boxes far faster than the shared infra and all this kind of QA/CI should be easily reproducible in a more minimal form on developer workstations. This scales out the load. I have a feeling we're just trying to do too much in a central service that SHOULD be being done by developers already as they build/develop etc. > > compared to a raspberry pi .. e5 runs rings around it so many times it's not > > funny and an rpi can do this easily enough. yes - jenkins adds infra cost > > itself, but a single vm for linux builds (with multiple chroots) would > > consume very little resources > > That is true, the VM overhead is not negligible. VM were the initial > design and we stuck on this. I am far from being against that as I'm far > from being against containers, finding the right time to work on this is > a different matter. Indeed VM's are not free. they cost a whole new OS instance in RAM etc. - thus why I mention chroots for example. Containers add some more isolation but a single "builder VM" with just chroots should do the trick for any Linux builds. I'm trying to just point out that when you try and do "too much" you create work and trouble for yourselves. If you try and behave like you have infinite access to infrastructure then you will get into trouble. Behave like your infra has limits and you use it sensibly and everything can work just fine. I'm OK having infra that is not on e5/our hw that we can "live without". For example - if someone wants to have build slaves scale out across hosted/sponsored machines to get more builds done per day... that's fine. If they go away we turn them off and just do fewer builds per day (like above). THAT I'm OK with. IT allows a fairly painless degrade in service when that happens. :) > > as it would only need a single build controller and just > > spawn off scripts per build that do the chroot fun. > > > > sure - need a vm for bsd, and windows and other OS's that can't do the > > chroot trick. > > > > > the hosting instances. Even still, current ressources are too limited. > > > You will not be able to have more than 10 instances running at the same > > > time. > > > > 10 build instances? if they are properly ionice'd and niced to be background > > tasks vs www etc... i think we can,. they might take longer as the xeons are > > old on the server, but they can do the task still. i regularly build efl/e > > on hardware a tiny fraction of the power of e5. > > We don't just instances for build, we have instances for web, mail, git, > phab etc .. Which by the way were moved to e6 last year after the > website was pretty much unsable and the disk issue we had, server that I'm > still paying myself. This was meant to be a temporary solution, but I > did not find the appropriate time to allocate on putting stuff back. Yeah. I know things moved to e6. I'd like to move stuff back too. I don't want you paying for this... We have infra. I just ordered a replacement disk BTW for e5... :) Maybe it'd make sense to set up that single "VM" on e5 an
Re: [E-devel] meson for efl
On Tue, 28 Aug 2018 20:32:00 +0900 Hermet Park said: > then do we expect users need to toggle features on/off manually? I would say so - yes. automagic has downsides for reproducible builds. > On Tue, Aug 28, 2018 at 4:34 AM Marcel Hollerbach wrote: > > > Hello, > > > > with this morning a few more fixes landed, the current state can be > > found here: > > > > https://git.enlightenment.org/core/efl.git/log/?h=devs/bu5hm4n/meson > > > > Currently building the whole tree works. However, cxx, mono, ecore_drm, > > ecore_wl and elocation is missing. And will be added. > > > > Right now there is a bit of disussion going on, in autotools > > ecore_avahi, ecore_imf- scim ibus & xim have been enabled by default. > > But were only build if avahi or ibus or xim are found on the system. > > > > We concluded at some point that it is not a good idea to enable / > > disable features based on the availability of libraries, thus i would > > like to enable / disable them strictly by default. Currently they are > > on, as this is the behaviour from autotools. Onions voices ? > > > > Other than that, feel free to test / report issues :) > > > > Another explanation mail will follow before it lands on master. > > > > 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 > > > > > -- > Regards, Hermet > -- > 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] meson for efl
On Tue, 25 Sep 2018 19:44:54 +0200 Vincent Torri said: > On Tue, Sep 25, 2018 at 6:24 PM Marcel Hollerbach wrote: > > > > Hello, > > > > new update! > > Everything beside the bindings is added, there is a README that sums up > > everything. All known bugs are fixed. > > > > I plan to merge meson within the next few days. Bindings support will be > > added after that. Any questions / opinions ? > > what about Evil ? is it compiling ? i suspect that might be a little way down the track... but it needs to work before this can be "prime time". -- - 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] Gitlab
On Tue, 25 Sep 2018 22:17:29 +0100 Bertrand Jacquin said: > On Mon, Sep 24, 2018 at 12:32:01PM +0100, Carsten Haitzler wrote: > > On Sat, 22 Sep 2018 15:50:00 +0100 Bertrand Jacquin > > said: > > > > > On Wed, Sep 12, 2018 at 06:45:20AM -0500, 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, > > > > > > You have the right to complain, that's probably fair but you have to > > > remember I'm only a volunteer here, nothing else can be expected from > > > me. Stop the fud. > > > > > > Not to blame or anything, the only actual help was provided by Raster > > > from time to time to hotfix some crap going on. Raster, jaquilina and > > > myself are root on the whole infra, any changes can be made. If the > > > infra is seen as too complex, questions can be raised but there are not. > > > > TBH... I'm partly to blame as I just don't know how most of it works. I > > figure it out as I go. :) But it would be good to have more people able to > > do hot fixes or address issues when others can't. I try and remember to let > > you know of any changes that you need to know about. > > This is correct, hotfix are fine, nothing wrong about that. What looks > not fair is people blaming me for not being available in my spare time > to volunteer for a project when others have access. It's a lost cause, > I'm not going to whine about it. indeed you are busy and can't devote such time and that is the reason i think we need to simplify so regular devs who don't keep up with every little detail could figure things out and make things work. it will come at a price of cleanliness and security probably, but at a bonus of far less of your time ever being needed! :) > > I think having as many VMs as we have doesn't help. Containers won't make > > that element simpler in terms of "too fragmented". Knowing which VM (or > > which container) something is in is hard enough to follow. :) You really > > need to know the infra well. > > Or just being used to do that. That's the thing as code, you know well > code so you can pretty much decipher code quickly, whatever language or > architecture being used. For infra it's pretty much the same thing. > When you are used to it, you can figure out pretty much all the > components very quickly. correct. so not blaming you for "sucking" etc. - you just are busy and this is a reality of what we have and we need some setup that addresses the reality of things. :) > > I know it's not "secure" and "right" but having fewer VMs with "shared > > hosting" within a single instance for many things might help a lot. > > This is a design choice we made 5+ years ago when we set e5 up. The idea indeed it was and a look back make me think this imho is wrong. :) > being to be able to put each VM to a different place in case of disaster > recovery. This does not mean we have to stick on that. I'm in favor in > making this change. It does not mean it has to be me doing this. You're > all bunch of smart people that can come with alternative. What I'm NOT > going to do is to explain every single step to people as it would > consume me more time than doing it myself. This is exactly the speech I > have to Jacquinola multiple time, I see a will to do stuff but not seen > much proposal or action from that. all i'd like is that you can answer questions on "how does X work?" - so we know where to look. i even have mentioned that i might set up a single big vm and look into migrating things in. to migrate or get it to work right i'll need help (i.e. information). :) > > At least I have > > found it easier in the past to find things that way. Don't know how > > something is set up? "sudo grep -r /". :) > > That's a very good starting point. :) just easy to do if we have a single FS to grep from the root of instead of FS images :) -- - 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] Gitlab/Infrastructure Slowvote
1. Yes I'm referring to the sponsored hosting Mike referenced. As to whether or not that is ideal - that is one of the reasons I wanted to see people's opinions on the slowvote. 2. I'm well aware you spent time on the thread and played with the prototype. I'm also aware that not all questions are answered :) What I blamed Marcel for was not expressing his concerns more in the thread - but perhaps this was too harsh. The thread got pretty much hijacked with arguments about our current infra. So here is what we know. Mike is willing teach and help with migration - Johnathan Aquilna is willing to put forth a large effort with it and is a sysadmin. I am willing to help and do it. There are others as well. Yes there are no guarantees and it will take work. What I'm interested in with the vote, is whether or not the community even wants to go this direction and what kind of infrastructure they want for it. 3. Gitlab CI would not be intended to be integrated with Travis, but replace it. This doesn't have to be on our own infra - but it can be either way. There are many options here. But again these are decisions that would have to be made. Right now I'm trying to gauge from the community whether or not it is worth putting in the time to develop plans and debate a focused end goal and how to get there. Gitlab CI vs Travis CI https://about.gitlab.com/comparison/gitlab-vs-travis-ci.html On Wed, Sep 26, 2018 at 10:57 AM 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
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
Re: [E-devel] Gitlab/Infrastructure Slowvote
On 9/26/18 5:27 PM, Stefan Schmidt wrote: Hello. On 9/26/18 4:48 PM, 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. A fair question. - 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). Stephen clarified this now in the vote. The vote would be on the end goal. Gitlab on own infra in this case. 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. I think using the term sponsorship is a bit misleading. The current server and network access is also sponsored. What I understand from the thread is that some wanted a cloud service (which would be sponsored as it costs monthly). From okra: 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. It seems we both have been mistaken :) Nothing about that is clear yet. No price tag on monthly costs, who would sponsor, for how long, etc. Everyone wanting this should think how it could happen. None the less I think its fair to start having a vote on community desires. That should show a bit better what the people here want. If there will be a sustainable plan to get to that goal has to be seen. One have to start somewhere though and this thread has gone in many direction without a clear directive showing up. 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
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 > ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab/Infrastructure Slowvote
Hello. On 9/26/18 4:48 PM, 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. A fair question. > - 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). Stephen clarified this now in the vote. The vote would be on the end goal. Gitlab on own infra in this case. > 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. I think using the term sponsorship is a bit misleading. The current server and network access is also sponsored. What I understand from the thread is that some wanted a cloud service (which would be sponsored as it costs monthly). Nothing about that is clear yet. No price tag on monthly costs, who would sponsor, for how long, etc. Everyone wanting this should think how it could happen. None the less I think its fair to start having a vote on community desires. That should show a bit better what the people here want. If there will be a sustainable plan to get to that goal has to be seen. One have to start somewhere though and this thread has gone in many direction without a clear directive showing up. regards Stefan Schmidt ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab/Infrastructure Slowvote
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/Infrastructure Slowvote
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
Re: [E-devel] Gitlab/Infrastructure Slowvote
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
[E-devel] Gitlab/Infrastructure Slowvote
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
Re: [E-devel] Gitlab
I get the impression that almost everyone is on board with gitlab and the debate is whether or not we should implement it on our own infra or sponsored infra. Then the follow up becomes who will do the migration. I'll start a slow vote and mail it out. On Wed, Sep 26, 2018, 12:37 AM wrote: > I am getting many different vibes here. Are we looking at redoing the e5 > setup and another server is needed in terms of sponsor ship in order to > rebuild e5? > > On 2018-09-25 21:08, Bertrand Jacquin wrote: > > On Mon, Sep 24, 2018 at 11:54:16AM +0100, Carsten Haitzler wrote: > >> On Sat, 22 Sep 2018 15:57:27 +0100 Bertrand Jacquin > >> said: > >> > >> > > > This is something I do not agree with. I have been kicking into > pants > >> > > > for problems with the infra for _years_ when doing Jenkins. It has > >> > > > changed nothing and I moved over to cloud services to get the > control > >> > > > and flexibility I needed. > >> > > > >> > > This is a result of policy from Beber of giving pretty minimal VM's > with > >> > > limited ram/disk with gentoo. We have the resources - they are just > not > >> > > being assigned and being able to provision your own is far too > complex with > >> > > what we have. If all you had to do was run some libvirt cmds to > spin up a > >> > > new VM of whatever size/config you wanted , I think you'd be fine. > >> > > >> > Well, e5 clearly has not enough memory and CPU to support all the > build > >> > ran by Jenkins, this is why we had to split the building instances > from > >> > >> That I just don't buy. I compile all of e, efl, terminology, rage on a > >> raspberry pi with 768m ram (256 partitioned off to gpu) and do > >> parallel > >> builds... and can run a gui at the same time. e5 has 48gb of ram. last > >> i heard > >> from stefan the vm's for building had maybe 2 or 4gb ram allocated to > >> them and > >> limited disk space. correct me if i'm wrong - this may have been a > >> while ago. > > > > Memory is not the issue here, CPU is. Each VM has 4GB or RAM, each > > build > > use -j6 and we can have up to 4 jenkins build at the same time, this on > > 3 different VM. > > > > Read this a different way: having build and servers (web, git etc) is > > not > > achievable. > > > >> compared to a raspberry pi .. e5 runs rings around it so many times > >> it's not > >> funny and an rpi can do this easily enough. yes - jenkins adds infra > >> cost > >> itself, but a single vm for linux builds (with multiple chroots) would > >> consume > >> very little resources > > > > That is true, the VM overhead is not negligible. VM were the initial > > design and we stuck on this. I am far from being against that as I'm > > far > > from being against containers, finding the right time to work on this > > is > > a different matter. > > > >> as it would only need a single build controller and just > >> spawn off scripts per build that do the chroot fun. > >> > >> sure - need a vm for bsd, and windows and other OS's that can't do the > >> chroot > >> trick. > >> > >> > the hosting instances. Even still, current ressources are too limited. > >> > You will not be able to have more than 10 instances running at the > same > >> > time. > >> > >> 10 build instances? if they are properly ionice'd and niced to be > >> background > >> tasks vs www etc... i think we can,. they might take longer as the > >> xeons are > >> old on the server, but they can do the task still. i regularly build > >> efl/e on > >> hardware a tiny fraction of the power of e5. > > > > We don't just instances for build, we have instances for web, mail, > > git, > > phab etc .. Which by the way were moved to e6 last year after the > > website was pretty much unsable and the disk issue we had, server that > > I'm > > still paying myself. This was meant to be a temporary solution, but I > > did not find the appropriate time to allocate on putting stuff back. > > > > Cheers > > > > ___ > > 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
[E-devel] base_pyefl_build on Jenkins
Hello Dave. I have recently disabled all builds on Jenkins. The only job I left enabled is your base_pyefl_build job. Disabling the jobs was only the first step towards shutting down Jenkins on our server completely. That leaves the question open what do do with the pyefl job. Is this something you are still actively using? Something that produces tarballs or artifacts you need? If it is something actively used and needed we need to find a new home for it. If it is just a left over we can simply drop it. regards Stefan Schmidt ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
Hello. On 9/25/18 11:08 PM, Bertrand Jacquin wrote: > Memory is not the issue here, CPU is. Each VM has 4GB or RAM, each build > use -j6 and we can have up to 4 jenkins build at the same time, this on > 3 different VM. > > Read this a different way: having build and servers (web, git etc) is not > achievable. I disabled all remaining Jenkins jobs (besides one base_pyefl job I need to talk to Dave about) last week. There should be basically no load coming from Jenkins on our server. You can shutdown the Jenkins slaves e3, e5-build-gentoo-cross1 and e5-build-gentoo-x86-1 right now. Master and e5-build-gentoo-x86_64-1 VM's are still needed for base_pyefl (please keep the files on disk if I need a reference at some point). With all the Jenkins VM's out of the way I hope a the work on the infra is easier to get done. regards Stefan Schmidt ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
