[E-devel] Gitlab test instance
Hi guys, I know alot of you havent had a chance to play around with gitlab. I am setting up a linode instance with gitlab for playing around with I have included backups as they are dirt cheap, and once everything is setup I will take a snapshot so if you guys break it all you need to do is let me know and I can restore from the snapshot. Also I know you guys mentioned using cloud services. Linode what I like the most about them they arent expensive is the first thing, the second thing is that I can give those that want and need access to manage the infrastructure (VPS) access to individual accounts so if I am not around you guys can administer the VPS. I would highly advocate linode as a temporary solution until we get our main machine in working order. You can also keep the vps if you opt to do so and turn the main server's that e have into CI servers. I thought i would let you guys know about this. Git lab from what I found on the documentation is rather easy to setup from the looks of things. ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Edi 0.7.0 reelease
Hello, This morning we released the latest version of Edi (0.7.0) which is available to download[1]. Finally with the release of the efl 1.21.x series we have support for themes within Edi. We also added translucency and other visual tweaks to improve continuity. Some refactoring and implementation of existing code has been introduced also. The release is dependent on the efl-1.21.1 release which has included some additional fixes and improvements to the elm_code widget. Hopefully you'll find this version a little more polished as we move towards 1.0. Feedback is always appreciated. Thanks! Alastair [1]: https://github.com/Enlightenment/edi/releases/download/v0.7.0/edi-0.7.0.tar.xz ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
Hello. On 09/14/2018 09:48 AM, Carsten Haitzler (The Rasterman) wrote: > On Wed, 12 Sep 2018 12:44:52 +0200 Stefan Schmidt > said: >> 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. As I am not going to handle anything of this my opinion on it is not worth much. I find containers easy to use for such things. What I really want to see in the end so is a system where we have a _group_ of people having access and understanding the system. >> 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. I guess you should ask Beber how to get access to IPMI (password, etc) and if he fails to reply you would need to go back to OSUOL. They should still have you listed as a person with rights to access, I hope (?). >> 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. :( Not much difference from the dark place we are in right now with our own infrastructure. :( > 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. 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. Making a fixed infra a dependency for the potential move to gitlab is not reasonable in my opinion. Forcing it to wait on something that has not happened in 15 months and putting the extra work on the shoulders on people who want to handle the move. Its like telling someone who wants to add a new elm widgets to finish interfaces and get it out of beta first. :-) The infra problem should get tackled and if enough people are supporting a move to gitlab and doing the work it would be fair to let them to this in parallel. regards Stefan Schmidt ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
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
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
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. ... > 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 > > > > > > > > ___ > > 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] Gitlab
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 > > > > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > >>> > >>> ___ > >>> enlightenment-devel mailing list > >>>
Re: [E-devel] Gitlab
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 > 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
