Re: [E-devel] Gitlab/Infrastructure Slowvote
So far that is 6 votes to move to gitlab, either on sponsored hosting or our current infrastructure, while there are just 2 votes to remain with Phab either on our own infrastructure or hosted. Seems like there is a large majority wanting Gitlab instead of Phab. Let's continue voting for another week or so, as many devs have not responded. If Gitlab still has such a large lead in one manner or another after said time, we can then assume the overwhelming preference of our community is to move to Gitlab from Phab and I will make a discussion topic and then perhaps a future vote for discussing how we want to handle it infrastructure wise. On Tue, Oct 2, 2018, 12:39 AM wrote: > Morning Guys, > > To answer your questions. > > In regards to a server to migrate the infrastructure to I am ready to > sponsor such an endeavour. I am also ready to rebuild the existing > server. > > The question here becomes is the community ready for this to happen? I > think this is what the vote is for. I am not trying to push beber to the > side I know he is busy and I am willing to step up and get things goign > in terms of being rebuilt. > > Regards, > Jonathan. > > On 2018-09-26 14:48, 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 > ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab/Infrastructure Slowvote
Morning Guys, To answer your questions. In regards to a server to migrate the infrastructure to I am ready to sponsor such an endeavour. I am also ready to rebuild the existing server. The question here becomes is the community ready for this to happen? I think this is what the vote is for. I am not trying to push beber to the side I know he is busy and I am willing to step up and get things goign in terms of being rebuilt. Regards, Jonathan. On 2018-09-26 14:48, 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
On Thu, 27 Sep 2018 00:17:53 +0100 Bertrand Jacquin said: > > 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. absolutely. we're on the same page. :) -- - 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
> 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] 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] 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: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
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
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
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
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
Re: [E-devel] Gitlab
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
Re: [E-devel] Gitlab
Seeing as I have infra access what can I do to help? On 2018-09-25 21:17, Bertrand Jacquin wrote: 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. 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. 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 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. 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. ___ 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
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. > 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. > 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 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. > 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. -- 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] Gitlab
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. > (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. -- 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] Gitlab
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 -- 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] Gitlab
Hi Guys, From a performance stand point wouldn't bare metal be a better option to opt for? On 2018-09-24 11:32, 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. 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. 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. 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 /". :) I am 100% for removing myself from the burden and willing to see what shape things will take. > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Bertrand ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
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. 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. 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. 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 /". :) > I am 100% for removing myself from the burden and willing to see what > shape things will take. > > > 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 > > 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
Re: [E-devel] Gitlab
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. (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. > > > 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 > >
Re: [E-devel] Gitlab
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. 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 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. > Again, I'm 100% for someone else to take over and do it's own mistakes. > > -- > 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
Hi Guys, In terms of infra what can i help with what needs to be sorted? On 2018-09-22 14:57, Bertrand Jacquin wrote: > 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 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. Again, I'm 100% for someone else to take over and do it's own mistakes. ___ 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
> > 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 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. Again, I'm 100% for someone else to take over and do it's own mistakes. -- 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] Gitlab
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 > > 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 -- 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] Gitlab
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. I am 100% for removing myself from the burden and willing to see what shape things will take. > 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 > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- 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] Gitlab
On Sat, 15 Sep 2018 11:13:26 + jaquil...@eagleeyet.net said: > Here is as valid point to bring up. When was the last time the version > of phab was updated? im sure there is a newer version that fixes alot of > the issues that you guys might be encountering. actually it has gotten updates every ~6 months or so at least over time by beber. last update appears to be sept 2... > On 2018-09-15 08:45, Carsten Haitzler wrote: > > On Fri, 14 Sep 2018 12:57:07 +0200 Stefan Schmidt > > > > said: > > > >> 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. > > > > I totally agree. I tend to leave things alone if they work. If they > > don't... I > > often find that I have had to stick my fingers in and figure it out. > > I'd like > > others to be able to do the same. It's a necessity of our project to be > > able to > > do this. > > > >> >> 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 (?). > > > > I have. to both. :( I need to try again. > > > >> >> 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. :( > > > > At least it's ours and we aren't footing a monthly bill... > > > >> > 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. > > > > 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
Re: [E-devel] Gitlab
Here is as valid point to bring up. When was the last time the version of phab was updated? im sure there is a newer version that fixes alot of the issues that you guys might be encountering. On 2018-09-15 08:45, Carsten Haitzler wrote: On Fri, 14 Sep 2018 12:57:07 +0200 Stefan Schmidt said: 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. I totally agree. I tend to leave things alone if they work. If they don't... I often find that I have had to stick my fingers in and figure it out. I'd like others to be able to do the same. It's a necessity of our project to be able to do this. >> 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 (?). I have. to both. :( I need to try again. >> 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. :( At least it's ours and we aren't footing a monthly bill... > 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. 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. 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. :-) It's a change of management/direction away from being dumped onto the community's laps. What we have works. It has its warts. Everything else does too. The infra problem should get tackled
Re: [E-devel] Gitlab
On Fri, 14 Sep 2018 12:57:07 +0200 Stefan Schmidt said: > 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. I totally agree. I tend to leave things alone if they work. If they don't... I often find that I have had to stick my fingers in and figure it out. I'd like others to be able to do the same. It's a necessity of our project to be able to do this. > >> 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 (?). I have. to both. :( I need to try again. > >> 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. :( At least it's ours and we aren't footing a monthly bill... > > 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. 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. > 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. :-) It's a change of management/direction away from being dumped onto the community's laps. What we have works. It has its warts. Everything else does too. > 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.
Re: [E-devel] Gitlab
On Fri, 14 Sep 2018 12:29:43 +0200 Jonathan Aquilina said: > I can sponsor a Linode vps for this until we get the server back in shape I hope you have bottomless pockets :) It won't happen if this is done. If there is no pain there will be zero movement. By doing this you avoid pain and "things work fine" so no one will care. :) > 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.
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
Re: [E-devel] Gitlab
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 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 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
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 >> 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
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 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
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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
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. > 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. 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. 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. regards Stefan Schmidt ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
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
Re: [E-devel] Gitlab
On Thu, 30 Aug 2018 13:11:54 +0200 Xavi Artigas said: > Hi, > > Since you explicitly asked for my opinion... I know git, but I have never > used Gitlab (or Github) to submit patches for review, and I only learned > Phab when I got here. Therefore I have too little background to be of any > help, I think > > However, if somebody could explain what would change regarding the current > process (Instead of "arc diff" what would I need to do? Would "Tasks" > become "Issues"?) I would appreciate it. > > Once thing that jumped at me is that we would miss all the comments on the > patch reviews? Don't we have an awful lot of information there? > Also, playing with the prototype at > https://gitlab-prototype.s-opensource.org/, I do not se the hierarchical > dependency of tasks. Would it be gone? Well those are my kind of concerns. Loss of information in a move. Also everyone has to adapt to something new. Is it worth it? I don't know, but even if it is, the effort required to set it up is going to be very large. > Xavi > > On Thu, 30 Aug 2018 at 10:42, Stefan Schmidt > wrote: > > > Hello. > > > > On 08/28/2018 05:08 PM, Stephen Houston wrote: > > > Hello, > > > > > > Just checking in here on the status of this - Does there need to be a > > > slowvote or does it seem that everyone is on board here or do people > > > disagree and want to voice why? > > > > I have not replied to this so far (a longer reply to Mike's mail will > > come in a bit). > > > > There can be seen some support in this thread, but I honestly think we > > are missing opinions from many other active people before we should go > > further here. In particular I would like to hear opinions from hermet, > > bu5hman, netstar, q66, raster, vtorri, xavi, chris, derek, yohoho, beber > > and more I forgot. > > > > A slowvote that would ask for general acceptance of a move to gitlab > > (not on all the details) might be a good step to understand if the > > people not commented yet are in the yes, no or don't care camp. > > > > More detailed comments on the proposal in a separate mail. > > > > regards > > Stefan Schmidt > > > > > > > > -- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
On Mon, 3 Sep 2018 12:05:12 +0200 Vincent Torri said: > On Mon, Sep 3, 2018 at 10:59 AM Al Poole wrote: > > > > Hello, > > > > I agree with you there Marcel. It's an awful lot of work with zero > > guaranteed improvement > > and a lot of time not spent on development nor fixing bugs That is why my opinion is that any move has to be clearly absolutely worth it. At this point I am unconvinced it is, but keeping mind I haven't poked around gitlab yet - I haven't had the time. I am just speaking from many years of experience. There is no silver bullet. Phab has its issues. Gitlab will too. If we had nothing and no history, data etc then it wouldn't be much of a question on what to choose today, but we have a wealth of data inside phab and losing or degrading that is going to hurt a lot and my take is that unless it will be a pretty-much-perfect migration of data, sit and wait for better solutions to appear. I need to look though... -- - 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 07/09/2018 01:36, Christopher Michael wrote: > Having never used GitLab before, I cannot really form an opinion here. > Yea, I took a few minutes to check out the link that was sent to the > read-only instance, however that is not really enough to make any kind > of informed decision as I am unable to "kick the tires" on it (as in, > try it out in a real world scenario). > > dh > I'm pretty sure gitlab is allowing you to host open source projects on there public instance, so if you want to kick the tires of it i'm pretty sure you can make an account and create a couple of repos to play with there. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B 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
+1 for Gitlab. I have been back and forth on this thread, and couldn't pinpoint where I should comment. So I comment on OP. It felt to me that using Phabricator had become quite a burden, and while git-phab tries to bridge to methodologies like reviewing whole branches, Gitlab offers it out of the box in the form of "merge requests" (much like Github's "pull requests"). The above pretty much states the obvious for most of the folks involved in this thread, but I wanted to lay out my reason to use Gitlab. Admittedly, I myself got a bit lost on the thread, so I couldn't really determine if there is an agreement that we NEED Gitlab. So, let's have a Slowvote? Thanks. -- Best, Danny (herdsman) Hirt On 8/10/18 9:09 PM, Mike Blumenkrantz wrote: Hello, For some time now, everyone in the community has been expressing significant dissatisfaction with the current project management software, Phabricator. A number of individuals have proposed switching to Gitlab for various reasons. Some will recall that recently all of the FDO infrastructure migrated from Phabricator to Gitlab thanks in large part to an incredible, hand-crafted migration script authored by notable open source figure Daniel Stone. While this script was not exactly what could be used to migrate our own infrastructure, it gave me an idea. Thanks to a low-pay intern who just graduated and whose name I don't recall, work began to modify the original FDO migration script and update it to handle various features exclusive to our usage of Phabricator. Thanks to generous hosting provided by the basement of the intern's parents, I was able to review the work as it progressed to see if it would be worth showing to the community. Weeks have passed, and now, thanks to many sleepless nights and long weekends that this devoted intern spent doing devops work, I was able to provide justification for more robust hosting and acquire a cloud service to host an official proof-of-concept for a Gitlab migration: https://gitlab-prototype.s-opensource.org/ Some notes: * This is read-only for now * User creation is disabled, don't bother trying * Issues with their comments have been imported * Patch submissions have been imported (the intern screwed up some of the early imports so there are a few patches without the diff inlined) - Comments on patch submissions cannot be imported because Phabricator has no API for retrieving comments on patch review * Wiki pages are not imported since some decision-making is required As is easily noticeable, not all projects have been imported by my intern. Importing the repo takes some time on its own, and then running the migration script takes a variable amount of time on top of that depending on the size of the project (EFL was estimated to take 10+ hours to fully import). Wiki pages have not been imported. On Gitlab, a wiki is project-specific and so it is impossible to do a 1:1 copy unless we decided to stick everything onto a specific project. We would have to decide how we want to do this. If we decided to switch to Gitlab, there would be a number of questions that need to be answered: Q: How do we migrate? A: Gitlab cannot accurately mirror all of Phabricator, it can only do a one-time migration of projects. This means we would at some point lock phab and then begin migrating, likely over a weekend for the major projects with the remainders being added later. Q: What happens to phab? A: We would likely want to keep phab in read-only mode for a while after the migration since all the migrated tickets/patches will provide links to it. We can later evaluate if we need to keep it running. Q: Where would this be hosted? A: The provided link here is a cloud service which will be funded for the foreseeable future. At present I am very strongly opposed to hosting this anywhere on the existing EFL infrastructure since it has been impossible for anyone to get access to any part of the server or to have tasks reliably handled in anything but a random and notification-less manner. A community project cannot have infrastructure which is unable to be accessed, managed, or maintained by the community which is using it. Regards, Mike -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
Having never used GitLab before, I cannot really form an opinion here. Yea, I took a few minutes to check out the link that was sent to the read-only instance, however that is not really enough to make any kind of informed decision as I am unable to "kick the tires" on it (as in, try it out in a real world scenario). dh On 09/06/2018 11:07 AM, Mike Blumenkrantz wrote: We've had some great feedback in this thread, but this is a big decision and there are still a number of key people who have not replied, making any sort of transition infeasible at this time. As for who is doing migration: I am willing to help with this and teach people everything that is needed for migration/setup. This does not, however, mean that I will handle it all by myself; I am not a primary driver for switching off phabricator--though I do think it is objectively worse than gitlab for many things--I am just the guy who put together some script modifications and spent 5 minutes setting up a cloud instance. On Wed, Sep 5, 2018 at 8:11 AM Stefan Schmidt wrote: Hello. I can't find answers to my questions raised in this reply. As I just had a private conversation with q66 on the potential move let me ask one core question again. Who is driving this transition and doing the work to get it all deployed? People seem to be under the impression it would be you or your intern, but I never heard a confirmation on this. If any of the supporters in this thread want to step up and driving this now would be a good time. regards Stefan Schmidt On 09/04/2018 05:45 PM, Mike Blumenkrantz wrote: I've uploaded the script from my intern here: https://git.enlightenment.org/devs/zmike/bztogl.git/ In the event that anyone is interested in using this script on a different gitlab instance (which can be trivially set up locally using the official community edition gitlab docker image): * have phabricator api token * have gitlab api token * import project repository using gitlab web interface * edit L760 of bztogl/phabtogl.py to point to gitlab instance * run example: phabtogl --token $gitlab_token --target-project efl/efl --project efl --callsign EFL - script may stall and need to be run a few times per project Feel free to commit any changes to the script directly to this repo. On Thu, Aug 30, 2018 at 5:28 AM Stefan Schmidt < ste...@datenfreihafen.org> wrote: Hello. On 08/10/2018 08:09 PM, Mike Blumenkrantz wrote: https://gitlab-prototype.s-opensource.org/ Thanks to the intern without name to get a real PoC out for this. While people have advocating for such a move no one before her/him spent the actual time to get this demonstrated! This will help us to understand the details of a potential move way better. Some notes: * This is read-only for now * User creation is disabled, don't bother trying * Issues with their comments have been imported Cool * Patch submissions have been imported (the intern screwed up some of the early imports so there are a few patches without the diff inlined) - Comments on patch submissions cannot be imported because Phabricator has no API for retrieving comments on patch review That is a bit of a pity. One could think of scraping the original diffusion web pages for the comments. Not sure if it would really be worth the effort spent on a script doing that. If we are able to clear out our patch queue enough this issue would minor. * Wiki pages are not imported since some decision-making is required As is easily noticeable, not all projects have been imported by my intern. Importing the repo takes some time on its own, and then running the migration script takes a variable amount of time on top of that depending on the size of the project (EFL was estimated to take 10+ hours to fully import). As a first demonstration this helps already. If the community wants to go this way we can have further steps where we import more projects and check for consistency and sanity. I would expect there would be several of such cycles before we are happy and would make a final switch Wiki pages have not been imported. On Gitlab, a wiki is project-specific and so it is impossible to do a 1:1 copy unless we decided to stick everything onto a specific project. We would have to decide how we want to do this. Hmm. The way we used the phab wiki was really for the overall community and not individual projects. Having said that I would think that most of the wiki pages could be attached to efl, EFL or Terminology. The rest will most likely be pages on process (commits guidelines, releases, etc) There will also be a ton of outdated pages which could simply be removed. In the end we would need to go through all of them and decide what to do. e.g move process docs into dokuwiki, remove outdated ones, move to a specific project. If we should do this sortign before or after me moved all pages over I am on the fence. It would be cleaner to only import the sorted pages but that can delay the
Re: [E-devel] Gitlab
I am interested in helping with this project. I would also be very interested in taking charge of a bug triaging team. and closing out fixed bugs as well as this will give us a chance to have a clean tracker with only open and valid bugs On 2018-09-06 15:07, Mike Blumenkrantz wrote: We've had some great feedback in this thread, but this is a big decision and there are still a number of key people who have not replied, making any sort of transition infeasible at this time. As for who is doing migration: I am willing to help with this and teach people everything that is needed for migration/setup. This does not, however, mean that I will handle it all by myself; I am not a primary driver for switching off phabricator--though I do think it is objectively worse than gitlab for many things--I am just the guy who put together some script modifications and spent 5 minutes setting up a cloud instance. On Wed, Sep 5, 2018 at 8:11 AM Stefan Schmidt wrote: Hello. I can't find answers to my questions raised in this reply. As I just had a private conversation with q66 on the potential move let me ask one core question again. Who is driving this transition and doing the work to get it all deployed? People seem to be under the impression it would be you or your intern, but I never heard a confirmation on this. If any of the supporters in this thread want to step up and driving this now would be a good time. regards Stefan Schmidt On 09/04/2018 05:45 PM, Mike Blumenkrantz wrote: > I've uploaded the script from my intern here: > https://git.enlightenment.org/devs/zmike/bztogl.git/ > > In the event that anyone is interested in using this script on a different > gitlab instance (which can be trivially set up locally using the official > community edition gitlab docker image): > * have phabricator api token > * have gitlab api token > * import project repository using gitlab web interface > * edit L760 of bztogl/phabtogl.py to point to gitlab instance > * run example: phabtogl --token $gitlab_token --target-project efl/efl > --project efl --callsign EFL > - script may stall and need to be run a few times per project > > Feel free to commit any changes to the script directly to this repo. > > On Thu, Aug 30, 2018 at 5:28 AM Stefan Schmidt < ste...@datenfreihafen.org> > wrote: > >> Hello. >> >> On 08/10/2018 08:09 PM, Mike Blumenkrantz wrote: >>> >>> https://gitlab-prototype.s-opensource.org/ >> >> Thanks to the intern without name to get a real PoC out for this. >> While people have advocating for such a move no one before her/him spent >> the actual time to get this demonstrated! >> >> This will help us to understand the details of a potential move way better. >> >>> >>> Some notes: >>> * This is read-only for now >>> * User creation is disabled, don't bother trying >>> * Issues with their comments have been imported >> >> Cool >> >>> * Patch submissions have been imported (the intern screwed up some of the >>> early imports so there are a few patches without the diff inlined) >>> - Comments on patch submissions cannot be imported because Phabricator >>> has no API for retrieving comments on patch review >> >> That is a bit of a pity. One could think of scraping the original >> diffusion web pages for the comments. Not sure if it would really be >> worth the effort spent on a script doing that. >> >> If we are able to clear out our patch queue enough this issue would minor. >> >>> * Wiki pages are not imported since some decision-making is required >>> >>> As is easily noticeable, not all projects have been imported by my >> intern. >>> Importing the repo takes some time on its own, and then running the >>> migration script takes a variable amount of time on top of that depending >>> on the size of the project (EFL was estimated to take 10+ hours to fully >>> import). >> >> As a first demonstration this helps already. If the community wants to >> go this way we can have further steps where we import more projects and >> check for consistency and sanity. I would expect there would be several >> of such cycles before we are happy and would make a final switch >> >>> Wiki pages have not been imported. On Gitlab, a wiki is project-specific >>> and so it is impossible to do a 1:1 copy unless we decided to stick >>> everything onto a specific project. We would have to decide how we want >> to >>> do this. >> >> Hmm. The way we used the phab wiki was really for the overall community >> and not individual projects. Having said that I would think that most of >> the wiki pages could be attached to efl, EFL or Terminology. The rest >> will most likely be pages on process (commits guidelines, releases, etc) >> >> There will also be a ton of outdated pages which could simply be removed. >> >> In the end we would need to go through all of them and decide what to >> do. e.g move process docs into dokuwiki, remove outdated ones, move to a >> specific project. >> >> If we should do this sortign before or
Re: [E-devel] Gitlab
We've had some great feedback in this thread, but this is a big decision and there are still a number of key people who have not replied, making any sort of transition infeasible at this time. As for who is doing migration: I am willing to help with this and teach people everything that is needed for migration/setup. This does not, however, mean that I will handle it all by myself; I am not a primary driver for switching off phabricator--though I do think it is objectively worse than gitlab for many things--I am just the guy who put together some script modifications and spent 5 minutes setting up a cloud instance. On Wed, Sep 5, 2018 at 8:11 AM Stefan Schmidt wrote: > Hello. > > I can't find answers to my questions raised in this reply. > > As I just had a private conversation with q66 on the potential move let > me ask one core question again. > > Who is driving this transition and doing the work to get it all deployed? > > People seem to be under the impression it would be you or your intern, > but I never heard a confirmation on this. If any of the supporters in > this thread want to step up and driving this now would be a good time. > > regards > Stefan Schmidt > > > On 09/04/2018 05:45 PM, Mike Blumenkrantz wrote: > > I've uploaded the script from my intern here: > > https://git.enlightenment.org/devs/zmike/bztogl.git/ > > > > In the event that anyone is interested in using this script on a > different > > gitlab instance (which can be trivially set up locally using the official > > community edition gitlab docker image): > > * have phabricator api token > > * have gitlab api token > > * import project repository using gitlab web interface > > * edit L760 of bztogl/phabtogl.py to point to gitlab instance > > * run example: phabtogl --token $gitlab_token --target-project efl/efl > > --project efl --callsign EFL > > - script may stall and need to be run a few times per project > > > > Feel free to commit any changes to the script directly to this repo. > > > > On Thu, Aug 30, 2018 at 5:28 AM Stefan Schmidt < > ste...@datenfreihafen.org> > > wrote: > > > >> Hello. > >> > >> On 08/10/2018 08:09 PM, Mike Blumenkrantz wrote: > >>> > >>> https://gitlab-prototype.s-opensource.org/ > >> > >> Thanks to the intern without name to get a real PoC out for this. > >> While people have advocating for such a move no one before her/him spent > >> the actual time to get this demonstrated! > >> > >> This will help us to understand the details of a potential move way > better. > >> > >>> > >>> Some notes: > >>> * This is read-only for now > >>> * User creation is disabled, don't bother trying > >>> * Issues with their comments have been imported > >> > >> Cool > >> > >>> * Patch submissions have been imported (the intern screwed up some of > the > >>> early imports so there are a few patches without the diff inlined) > >>> - Comments on patch submissions cannot be imported because > Phabricator > >>> has no API for retrieving comments on patch review > >> > >> That is a bit of a pity. One could think of scraping the original > >> diffusion web pages for the comments. Not sure if it would really be > >> worth the effort spent on a script doing that. > >> > >> If we are able to clear out our patch queue enough this issue would > minor. > >> > >>> * Wiki pages are not imported since some decision-making is required > >>> > >>> As is easily noticeable, not all projects have been imported by my > >> intern. > >>> Importing the repo takes some time on its own, and then running the > >>> migration script takes a variable amount of time on top of that > depending > >>> on the size of the project (EFL was estimated to take 10+ hours to > fully > >>> import). > >> > >> As a first demonstration this helps already. If the community wants to > >> go this way we can have further steps where we import more projects and > >> check for consistency and sanity. I would expect there would be several > >> of such cycles before we are happy and would make a final switch > >> > >>> Wiki pages have not been imported. On Gitlab, a wiki is > project-specific > >>> and so it is impossible to do a 1:1 copy unless we decided to stick > >>> everything onto a specific project. We would have to decide how we want > >> to > >>> do this. > >> > >> Hmm. The way we used the phab wiki was really for the overall community > >> and not individual projects. Having said that I would think that most of > >> the wiki pages could be attached to efl, EFL or Terminology. The rest > >> will most likely be pages on process (commits guidelines, releases, etc) > >> > >> There will also be a ton of outdated pages which could simply be > removed. > >> > >> In the end we would need to go through all of them and decide what to > >> do. e.g move process docs into dokuwiki, remove outdated ones, move to a > >> specific project. > >> > >> If we should do this sortign before or after me moved all pages over I > >> am on the fence. It would be cleaner to only import the
Re: [E-devel] Gitlab
Hello. I can't find answers to my questions raised in this reply. As I just had a private conversation with q66 on the potential move let me ask one core question again. Who is driving this transition and doing the work to get it all deployed? People seem to be under the impression it would be you or your intern, but I never heard a confirmation on this. If any of the supporters in this thread want to step up and driving this now would be a good time. regards Stefan Schmidt On 09/04/2018 05:45 PM, Mike Blumenkrantz wrote: > I've uploaded the script from my intern here: > https://git.enlightenment.org/devs/zmike/bztogl.git/ > > In the event that anyone is interested in using this script on a different > gitlab instance (which can be trivially set up locally using the official > community edition gitlab docker image): > * have phabricator api token > * have gitlab api token > * import project repository using gitlab web interface > * edit L760 of bztogl/phabtogl.py to point to gitlab instance > * run example: phabtogl --token $gitlab_token --target-project efl/efl > --project efl --callsign EFL > - script may stall and need to be run a few times per project > > Feel free to commit any changes to the script directly to this repo. > > On Thu, Aug 30, 2018 at 5:28 AM Stefan Schmidt > wrote: > >> Hello. >> >> On 08/10/2018 08:09 PM, Mike Blumenkrantz wrote: >>> >>> https://gitlab-prototype.s-opensource.org/ >> >> Thanks to the intern without name to get a real PoC out for this. >> While people have advocating for such a move no one before her/him spent >> the actual time to get this demonstrated! >> >> This will help us to understand the details of a potential move way better. >> >>> >>> Some notes: >>> * This is read-only for now >>> * User creation is disabled, don't bother trying >>> * Issues with their comments have been imported >> >> Cool >> >>> * Patch submissions have been imported (the intern screwed up some of the >>> early imports so there are a few patches without the diff inlined) >>> - Comments on patch submissions cannot be imported because Phabricator >>> has no API for retrieving comments on patch review >> >> That is a bit of a pity. One could think of scraping the original >> diffusion web pages for the comments. Not sure if it would really be >> worth the effort spent on a script doing that. >> >> If we are able to clear out our patch queue enough this issue would minor. >> >>> * Wiki pages are not imported since some decision-making is required >>> >>> As is easily noticeable, not all projects have been imported by my >> intern. >>> Importing the repo takes some time on its own, and then running the >>> migration script takes a variable amount of time on top of that depending >>> on the size of the project (EFL was estimated to take 10+ hours to fully >>> import). >> >> As a first demonstration this helps already. If the community wants to >> go this way we can have further steps where we import more projects and >> check for consistency and sanity. I would expect there would be several >> of such cycles before we are happy and would make a final switch >> >>> Wiki pages have not been imported. On Gitlab, a wiki is project-specific >>> and so it is impossible to do a 1:1 copy unless we decided to stick >>> everything onto a specific project. We would have to decide how we want >> to >>> do this. >> >> Hmm. The way we used the phab wiki was really for the overall community >> and not individual projects. Having said that I would think that most of >> the wiki pages could be attached to efl, EFL or Terminology. The rest >> will most likely be pages on process (commits guidelines, releases, etc) >> >> There will also be a ton of outdated pages which could simply be removed. >> >> In the end we would need to go through all of them and decide what to >> do. e.g move process docs into dokuwiki, remove outdated ones, move to a >> specific project. >> >> If we should do this sortign before or after me moved all pages over I >> am on the fence. It would be cleaner to only import the sorted pages but >> that can delay the move for some time. >> >>> If we decided to switch to Gitlab, there would be a number of questions >>> that need to be answered: >>> Q: How do we migrate? >>> A: Gitlab cannot accurately mirror all of Phabricator, it can only do a >>> one-time migration of projects. This means we would at some point lock >> phab >>> and then begin migrating, likely over a weekend for the major projects >> with >>> the remainders being added later. >> >> As written above I would expect that we would have more trial runs on >> the migration while fine tuning the script and reviewing the results. If >> we are happy with what we have for a project we could lock it for a >> weekend and move the projects over. >> >>> Q: What happens to phab? >>> A: We would likely want to keep phab in read-only mode for a while after >>> the migration since all the migrated tickets/patches will provide
Re: [E-devel] Gitlab
I've uploaded the script from my intern here: https://git.enlightenment.org/devs/zmike/bztogl.git/ In the event that anyone is interested in using this script on a different gitlab instance (which can be trivially set up locally using the official community edition gitlab docker image): * have phabricator api token * have gitlab api token * import project repository using gitlab web interface * edit L760 of bztogl/phabtogl.py to point to gitlab instance * run example: phabtogl --token $gitlab_token --target-project efl/efl --project efl --callsign EFL - script may stall and need to be run a few times per project Feel free to commit any changes to the script directly to this repo. On Thu, Aug 30, 2018 at 5:28 AM Stefan Schmidt wrote: > Hello. > > On 08/10/2018 08:09 PM, Mike Blumenkrantz wrote: > > > > https://gitlab-prototype.s-opensource.org/ > > Thanks to the intern without name to get a real PoC out for this. > While people have advocating for such a move no one before her/him spent > the actual time to get this demonstrated! > > This will help us to understand the details of a potential move way better. > > > > > Some notes: > > * This is read-only for now > > * User creation is disabled, don't bother trying > > * Issues with their comments have been imported > > Cool > > > * Patch submissions have been imported (the intern screwed up some of the > > early imports so there are a few patches without the diff inlined) > > - Comments on patch submissions cannot be imported because Phabricator > > has no API for retrieving comments on patch review > > That is a bit of a pity. One could think of scraping the original > diffusion web pages for the comments. Not sure if it would really be > worth the effort spent on a script doing that. > > If we are able to clear out our patch queue enough this issue would minor. > > > * Wiki pages are not imported since some decision-making is required > > > > As is easily noticeable, not all projects have been imported by my > intern. > > Importing the repo takes some time on its own, and then running the > > migration script takes a variable amount of time on top of that depending > > on the size of the project (EFL was estimated to take 10+ hours to fully > > import). > > As a first demonstration this helps already. If the community wants to > go this way we can have further steps where we import more projects and > check for consistency and sanity. I would expect there would be several > of such cycles before we are happy and would make a final switch > > > Wiki pages have not been imported. On Gitlab, a wiki is project-specific > > and so it is impossible to do a 1:1 copy unless we decided to stick > > everything onto a specific project. We would have to decide how we want > to > > do this. > > Hmm. The way we used the phab wiki was really for the overall community > and not individual projects. Having said that I would think that most of > the wiki pages could be attached to efl, EFL or Terminology. The rest > will most likely be pages on process (commits guidelines, releases, etc) > > There will also be a ton of outdated pages which could simply be removed. > > In the end we would need to go through all of them and decide what to > do. e.g move process docs into dokuwiki, remove outdated ones, move to a > specific project. > > If we should do this sortign before or after me moved all pages over I > am on the fence. It would be cleaner to only import the sorted pages but > that can delay the move for some time. > > > If we decided to switch to Gitlab, there would be a number of questions > > that need to be answered: > > Q: How do we migrate? > > A: Gitlab cannot accurately mirror all of Phabricator, it can only do a > > one-time migration of projects. This means we would at some point lock > phab > > and then begin migrating, likely over a weekend for the major projects > with > > the remainders being added later. > > As written above I would expect that we would have more trial runs on > the migration while fine tuning the script and reviewing the results. If > we are happy with what we have for a project we could lock it for a > weekend and move the projects over. > > > Q: What happens to phab? > > A: We would likely want to keep phab in read-only mode for a while after > > the migration since all the migrated tickets/patches will provide links > to > > it. We can later evaluate if we need to keep it running. > > With all the reference to tickets and differentials we might need keep > it around read only for a long time. The alternative would be to have > all the old issues and differentials imported as well and have a > re-write mapping for the links in our http server. Not very attractive > either. > > > 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
Re: [E-devel] Gitlab
On Mon, Sep 3, 2018 at 10:59 AM Al Poole wrote: > > Hello, > > I agree with you there Marcel. It's an awful lot of work with zero > guaranteed improvement and a lot of time not spent on development nor fixing bugs Vincent -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
Hello, I agree with you there Marcel. It's an awful lot of work with zero guaranteed improvement. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
Hello, On 8/30/18 10:41 AM, Stefan Schmidt wrote: Hello. On 08/28/2018 05:08 PM, Stephen Houston wrote: Hello, Just checking in here on the status of this - Does there need to be a slowvote or does it seem that everyone is on board here or do people disagree and want to voice why? I have not replied to this so far (a longer reply to Mike's mail will come in a bit). There can be seen some support in this thread, but I honestly think we are missing opinions from many other active people before we should go further here. In particular I would like to hear opinions from hermet, bu5hman, netstar, q66, raster, vtorri, xavi, chris, derek, yohoho, beber and more I forgot. I am completely in favor of going to a new platform. However, i am a bit skeptical what would be expected. In most IRC converstations it sounded like the biggest problem was the tooling and the not obvious task stuff. But in the end we end up with tooling where you need to access your browser, find the correct branch etc. then create a PR, is that obvious to everyone ? Also, a lot of complains where into the direction of missing CI stuff in phab or in general bad CI integration, with gitlab this is not really better. If we dont include or hookup a few buildplaces, nothing gets really better. And in the end, our bugtracker has been a incredible mess until some cleanup action took place. If we don't do this again and again, things will likely not get better at all. There have been a long long list of projects that have migrated to gitlab. However, others are also managing to use phab (haskell, kde, freebsd, blender). What I want to say with this is, phabricator is not that bad, others are also managing to work with it :) tldr: We maintained and handled our phab instance bad, if we do the same with gitlab, nothing will really change IMO. A slowvote that would ask for general acceptance of a move to gitlab (not on all the details) might be a good step to understand if the people not commented yet are in the yes, no or don't care camp. More detailed comments on the proposal in a separate mail. regards Stefan Schmidt -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
On Thu, Aug 30, 2018, at 10:41, Stefan Schmidt wrote: > Hello. > > On 08/28/2018 05:08 PM, Stephen Houston wrote: > > Hello, > > > > Just checking in here on the status of this - Does there need to be a > > slowvote or does it seem that everyone is on board here or do people > > disagree and want to voice why? > > I have not replied to this so far (a longer reply to Mike's mail will > come in a bit). > > There can be seen some support in this thread, but I honestly think we > are missing opinions from many other active people before we should go > further here. In particular I would like to hear opinions from hermet, > bu5hman, netstar, q66, raster, vtorri, xavi, chris, derek, yohoho, beber > and more I forgot. >From my side, I fully support a move to another system, be it Gitlab or >something else, as long as there is a reasonable git integration with a pull >request system. I'd prefer self-hosting but when it comes to it I realize that >it might not be possible with our current server situation, so I won't be >against a hosted solution either. D5 > > A slowvote that would ask for general acceptance of a move to gitlab > (not on all the details) might be a good step to understand if the > people not commented yet are in the yes, no or don't care camp. > > More detailed comments on the proposal in a separate mail. > > regards > Stefan Schmidt > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
Hi, Since you explicitly asked for my opinion... I know git, but I have never used Gitlab (or Github) to submit patches for review, and I only learned Phab when I got here. Therefore I have too little background to be of any help, I think However, if somebody could explain what would change regarding the current process (Instead of "arc diff" what would I need to do? Would "Tasks" become "Issues"?) I would appreciate it. Once thing that jumped at me is that we would miss all the comments on the patch reviews? Don't we have an awful lot of information there? Also, playing with the prototype at https://gitlab-prototype.s-opensource.org/, I do not se the hierarchical dependency of tasks. Would it be gone? Xavi On Thu, 30 Aug 2018 at 10:42, Stefan Schmidt wrote: > Hello. > > On 08/28/2018 05:08 PM, Stephen Houston wrote: > > Hello, > > > > Just checking in here on the status of this - Does there need to be a > > slowvote or does it seem that everyone is on board here or do people > > disagree and want to voice why? > > I have not replied to this so far (a longer reply to Mike's mail will > come in a bit). > > There can be seen some support in this thread, but I honestly think we > are missing opinions from many other active people before we should go > further here. In particular I would like to hear opinions from hermet, > bu5hman, netstar, q66, raster, vtorri, xavi, chris, derek, yohoho, beber > and more I forgot. > > A slowvote that would ask for general acceptance of a move to gitlab > (not on all the details) might be a good step to understand if the > people not commented yet are in the yes, no or don't care camp. > > More detailed comments on the proposal in a separate mail. > > regards > Stefan Schmidt > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
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. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
Hello. On 08/10/2018 08:15 PM, Mike Blumenkrantz wrote: > To list some pros and cons for a switch: > > PROS: > * Greatly improved patch review UI > Gitlab is similar in workflow and usage to Github, so it will be much > easier to use the patch review tools What patch review tools are you talking about here besides the web UI? > * Simplified patch submission workflow > Gitlab uses git and does not require external tools such as arc/git-phab This is indeed a very big plus in my view. The move from arc to git-phab helped but its still cumbersome compared to just use git directly. > * Actively developed > Phabricator is basically closed-source at this point, and they develop only > as they decide to or as people pay them to. Gitlab is open source and the > developers actively reply to tickets and fix issues I would not go as far as calling it closed source. They have a clear view and agenda they want phab to develop into. Problems arise if this is not the same vision we want to use phab and if we have little influence. On the other hand it is not like we have been really dicing into it and proposed patches to them in a big way either. > CONS: > * Does require having people manage a migration A key point. Who would handle the migration and do all the manual work involved? I remember that Daniel and Tom spend many, many days on the git and phab migration. Is the intern without name available to do this? If not who else would do it? > * Will take time to migrate As I outlined in my other mail I would expect several iterations with reviews of the results, moving a project at a time over when happy. > * Will take time to adjust to new tools/workflows It would also mean updating our docs on contributions (as sparse as they might be) One con missing here is the fact that the language of the system used is switching from php to ruby. Personally I do not care, but we had modifications on the phab code in the past to help against some spam attacks. With php that was possible because people here with C background just hacked on it. To the best of my knowledge we have nobody with a ruby background here though. We could hope that we never come into the situation that we would need to modify it, but its a risk we need to keep in mind. regards Stefan Schmidt -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
Hello. On 08/10/2018 08:09 PM, Mike Blumenkrantz wrote: > > https://gitlab-prototype.s-opensource.org/ Thanks to the intern without name to get a real PoC out for this. While people have advocating for such a move no one before her/him spent the actual time to get this demonstrated! This will help us to understand the details of a potential move way better. > > Some notes: > * This is read-only for now > * User creation is disabled, don't bother trying > * Issues with their comments have been imported Cool > * Patch submissions have been imported (the intern screwed up some of the > early imports so there are a few patches without the diff inlined) > - Comments on patch submissions cannot be imported because Phabricator > has no API for retrieving comments on patch review That is a bit of a pity. One could think of scraping the original diffusion web pages for the comments. Not sure if it would really be worth the effort spent on a script doing that. If we are able to clear out our patch queue enough this issue would minor. > * Wiki pages are not imported since some decision-making is required > > As is easily noticeable, not all projects have been imported by my intern. > Importing the repo takes some time on its own, and then running the > migration script takes a variable amount of time on top of that depending > on the size of the project (EFL was estimated to take 10+ hours to fully > import). As a first demonstration this helps already. If the community wants to go this way we can have further steps where we import more projects and check for consistency and sanity. I would expect there would be several of such cycles before we are happy and would make a final switch > Wiki pages have not been imported. On Gitlab, a wiki is project-specific > and so it is impossible to do a 1:1 copy unless we decided to stick > everything onto a specific project. We would have to decide how we want to > do this. Hmm. The way we used the phab wiki was really for the overall community and not individual projects. Having said that I would think that most of the wiki pages could be attached to efl, EFL or Terminology. The rest will most likely be pages on process (commits guidelines, releases, etc) There will also be a ton of outdated pages which could simply be removed. In the end we would need to go through all of them and decide what to do. e.g move process docs into dokuwiki, remove outdated ones, move to a specific project. If we should do this sortign before or after me moved all pages over I am on the fence. It would be cleaner to only import the sorted pages but that can delay the move for some time. > If we decided to switch to Gitlab, there would be a number of questions > that need to be answered: > Q: How do we migrate? > A: Gitlab cannot accurately mirror all of Phabricator, it can only do a > one-time migration of projects. This means we would at some point lock phab > and then begin migrating, likely over a weekend for the major projects with > the remainders being added later. As written above I would expect that we would have more trial runs on the migration while fine tuning the script and reviewing the results. If we are happy with what we have for a project we could lock it for a weekend and move the projects over. > Q: What happens to phab? > A: We would likely want to keep phab in read-only mode for a while after > the migration since all the migrated tickets/patches will provide links to > it. We can later evaluate if we need to keep it running. With all the reference to tickets and differentials we might need keep it around read only for a long time. The alternative would be to have all the old issues and differentials imported as well and have a re-write mapping for the links in our http server. Not very attractive either. > 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. regards Stefan Schmidt -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
Hello. On 08/28/2018 05:08 PM, Stephen Houston wrote: > Hello, > > Just checking in here on the status of this - Does there need to be a > slowvote or does it seem that everyone is on board here or do people > disagree and want to voice why? I have not replied to this so far (a longer reply to Mike's mail will come in a bit). There can be seen some support in this thread, but I honestly think we are missing opinions from many other active people before we should go further here. In particular I would like to hear opinions from hermet, bu5hman, netstar, q66, raster, vtorri, xavi, chris, derek, yohoho, beber and more I forgot. A slowvote that would ask for general acceptance of a move to gitlab (not on all the details) might be a good step to understand if the people not commented yet are in the yes, no or don't care camp. More detailed comments on the proposal in a separate mail. regards Stefan Schmidt -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
Hello, Just checking in here on the status of this - Does there need to be a slowvote or does it seem that everyone is on board here or do people disagree and want to voice why? Stephen On Fri, Aug 17, 2018 at 9:02 PM Carsten Haitzler wrote: > On Thu, 16 Aug 2018 10:29:15 -0400 Mike Blumenkrantz > said: > > > I am a bit curious where you think we need this much work with triaging? > > > > The biggest issue that we will have here is actually from our > > passive-aggressive method of rejecting things we don't like. For example, > > there are many, many patches that have been rejected and are idle for a > > long time but not abandoned. These will not be closed using the current > > a lot of patches are rejected or have been asked for changes and the > submitter > never does it and they don't abandon. to forcibly kill it off you have to > first > commandeer then abandon as the new submitter. i got tired of doing that > and just > waited for submitters to do it. invariably many did not. > > this isn't passive-agreessive. it's submitters not ackowledging the patch > should be abandoned. > > this is of course different to patches that were forgotten about. > > i think your characterization here is entirely wrong. > > > migration method. There are also unlimited tickets set to 'pending on > user > > input' which are dead; these also will not be closed. Most likely both of > > these types of open items should just be closed during migration. > > probably. > > > On Sat, Aug 11, 2018 at 2:56 AM Jonathan Aquilina < > jaquil...@eagleeyet.net> > > wrote: > > > > > Guess then would be to migrate everything and I’ll work on triaging the > > > bigs after > > > > > > Sent from my iPhone > > > > > > > On 11 Aug 2018, at 08:23, Pierre Couderc wrote: > > > > > > > >> On 08/11/2018 07:30 AM, jaquil...@eagleeyet.net wrote: > > > >> If we are going to migrate I think we should migrate tickets slowly > to > > > see which ones are still valid and not pollute the new tracker with > issues > > > that are either moot or no longer valid. > > > >> > > > > Mmm, it is not logical. Migrate is a thing. Process tickets is > another > > > thing. Trying to do 2 independant things simulteaneoulsy? > > > > > > > > > > > > -- > > > > Check out the vibrant tech community on one of the world's most > > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > > ___ > > > > enlightenment-devel mailing list > > > > enlightenment-devel@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > > > > > -- > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > ___ > > > enlightenment-devel mailing list > > > enlightenment-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > -- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > Carsten Haitzler - ras...@rasterman.com > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
On Thu, 16 Aug 2018 10:29:15 -0400 Mike Blumenkrantz said: > I am a bit curious where you think we need this much work with triaging? > > The biggest issue that we will have here is actually from our > passive-aggressive method of rejecting things we don't like. For example, > there are many, many patches that have been rejected and are idle for a > long time but not abandoned. These will not be closed using the current a lot of patches are rejected or have been asked for changes and the submitter never does it and they don't abandon. to forcibly kill it off you have to first commandeer then abandon as the new submitter. i got tired of doing that and just waited for submitters to do it. invariably many did not. this isn't passive-agreessive. it's submitters not ackowledging the patch should be abandoned. this is of course different to patches that were forgotten about. i think your characterization here is entirely wrong. > migration method. There are also unlimited tickets set to 'pending on user > input' which are dead; these also will not be closed. Most likely both of > these types of open items should just be closed during migration. probably. > On Sat, Aug 11, 2018 at 2:56 AM Jonathan Aquilina > wrote: > > > Guess then would be to migrate everything and I’ll work on triaging the > > bigs after > > > > Sent from my iPhone > > > > > On 11 Aug 2018, at 08:23, Pierre Couderc wrote: > > > > > >> On 08/11/2018 07:30 AM, jaquil...@eagleeyet.net wrote: > > >> If we are going to migrate I think we should migrate tickets slowly to > > see which ones are still valid and not pollute the new tracker with issues > > that are either moot or no longer valid. > > >> > > > Mmm, it is not logical. Migrate is a thing. Process tickets is another > > thing. Trying to do 2 independant things simulteaneoulsy? > > > > > > > > -- > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > ___ > > > enlightenment-devel mailing list > > > enlightenment-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > -- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
Also to add I think stuff wiht lack of activity or things have changed for now should be closed as well. I see the issue tracker as something for key issues that are reproducible as well as key things that need to get done that are key for a release or bugs to be fixed. On 2018-08-16 14:38, Jonathan Aquilina wrote: The way I see it if there is lack of activity it gets closed and if need be reopened when the issue resurfaced Sent from my iPhone On 16 Aug 2018, at 16:29, Mike Blumenkrantz wrote: I am a bit curious where you think we need this much work with triaging? The biggest issue that we will have here is actually from our passive-aggressive method of rejecting things we don't like. For example, there are many, many patches that have been rejected and are idle for a long time but not abandoned. These will not be closed using the current migration method. There are also unlimited tickets set to 'pending on user input' which are dead; these also will not be closed. Most likely both of these types of open items should just be closed during migration. On Sat, Aug 11, 2018 at 2:56 AM Jonathan Aquilina wrote: Guess then would be to migrate everything and I’ll work on triaging the bigs after Sent from my iPhone On 11 Aug 2018, at 08:23, Pierre Couderc wrote: On 08/11/2018 07:30 AM, jaquil...@eagleeyet.net wrote: If we are going to migrate I think we should migrate tickets slowly to see which ones are still valid and not pollute the new tracker with issues that are either moot or no longer valid. Mmm, it is not logical. Migrate is a thing. Process tickets is another thing. Trying to do 2 independant things simulteaneoulsy? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
The way I see it if there is lack of activity it gets closed and if need be reopened when the issue resurfaced Sent from my iPhone > On 16 Aug 2018, at 16:29, Mike Blumenkrantz > wrote: > > I am a bit curious where you think we need this much work with triaging? > > The biggest issue that we will have here is actually from our > passive-aggressive method of rejecting things we don't like. For example, > there are many, many patches that have been rejected and are idle for a > long time but not abandoned. These will not be closed using the current > migration method. There are also unlimited tickets set to 'pending on user > input' which are dead; these also will not be closed. Most likely both of > these types of open items should just be closed during migration. > > On Sat, Aug 11, 2018 at 2:56 AM Jonathan Aquilina > wrote: > >> Guess then would be to migrate everything and I’ll work on triaging the >> bigs after >> >> Sent from my iPhone >> On 11 Aug 2018, at 08:23, Pierre Couderc wrote: On 08/11/2018 07:30 AM, jaquil...@eagleeyet.net wrote: If we are going to migrate I think we should migrate tickets slowly to >> see which ones are still valid and not pollute the new tracker with issues >> that are either moot or no longer valid. >>> Mmm, it is not logical. Migrate is a thing. Process tickets is another >> thing. Trying to do 2 independant things simulteaneoulsy? >>> >>> >> -- >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> ___ >>> enlightenment-devel mailing list >>> enlightenment-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> >> >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
I am a bit curious where you think we need this much work with triaging? The biggest issue that we will have here is actually from our passive-aggressive method of rejecting things we don't like. For example, there are many, many patches that have been rejected and are idle for a long time but not abandoned. These will not be closed using the current migration method. There are also unlimited tickets set to 'pending on user input' which are dead; these also will not be closed. Most likely both of these types of open items should just be closed during migration. On Sat, Aug 11, 2018 at 2:56 AM Jonathan Aquilina wrote: > Guess then would be to migrate everything and I’ll work on triaging the > bigs after > > Sent from my iPhone > > > On 11 Aug 2018, at 08:23, Pierre Couderc wrote: > > > >> On 08/11/2018 07:30 AM, jaquil...@eagleeyet.net wrote: > >> If we are going to migrate I think we should migrate tickets slowly to > see which ones are still valid and not pollute the new tracker with issues > that are either moot or no longer valid. > >> > > Mmm, it is not logical. Migrate is a thing. Process tickets is another > thing. Trying to do 2 independant things simulteaneoulsy? > > > > > -- > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
On 08/10/2018 08:09 PM, Mike Blumenkrantz wrote: for a Gitlab migration: https://gitlab-prototype.s-opensource.org/ +1 for quitting phabricator.. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
+1 (both for using gitlab and the hosting) 2018-08-12 2:04 GMT+02:00 Simon Lees : > > > On 11/08/18 03:39, Mike Blumenkrantz wrote: > > Hello, > > > > For some time now, everyone in the community has been expressing > > significant dissatisfaction with the current project management software, > > Phabricator. A number of individuals have proposed switching to Gitlab > for > > various reasons. > > > > Some will recall that recently all of the FDO infrastructure migrated > from > > Phabricator to Gitlab thanks in large part to an incredible, hand-crafted > > migration script authored by notable open source figure Daniel Stone. > While > > this script was not exactly what could be used to migrate our own > > infrastructure, it gave me an idea. > > > > Thanks to a low-pay intern who just graduated and whose name I don't > > recall, work began to modify the original FDO migration script and update > > it to handle various features exclusive to our usage of Phabricator. > Thanks > > to generous hosting provided by the basement of the intern's parents, I > was > > able to review the work as it progressed to see if it would be worth > > showing to the community. > > > > Weeks have passed, and now, thanks to many sleepless nights and long > > weekends that this devoted intern spent doing devops work, I was able to > > provide justification for more robust hosting and acquire a cloud service > > to host an official proof-of-concept for a Gitlab migration: > > > > https://gitlab-prototype.s-opensource.org/ > > > > Some notes: > > * This is read-only for now > > * User creation is disabled, don't bother trying > > * Issues with their comments have been imported > > * Patch submissions have been imported (the intern screwed up some of the > > early imports so there are a few patches without the diff inlined) > > - Comments on patch submissions cannot be imported because Phabricator > > has no API for retrieving comments on patch review > > * Wiki pages are not imported since some decision-making is required > > > > As is easily noticeable, not all projects have been imported by my > intern. > > Importing the repo takes some time on its own, and then running the > > migration script takes a variable amount of time on top of that depending > > on the size of the project (EFL was estimated to take 10+ hours to fully > > import). > > > > Wiki pages have not been imported. On Gitlab, a wiki is project-specific > > and so it is impossible to do a 1:1 copy unless we decided to stick > > everything onto a specific project. We would have to decide how we want > to > > do this. > > > > If we decided to switch to Gitlab, there would be a number of questions > > that need to be answered: > > Q: How do we migrate? > > A: Gitlab cannot accurately mirror all of Phabricator, it can only do a > > one-time migration of projects. This means we would at some point lock > phab > > and then begin migrating, likely over a weekend for the major projects > with > > the remainders being added later. > > > > Q: What happens to phab? > > A: We would likely want to keep phab in read-only mode for a while after > > the migration since all the migrated tickets/patches will provide links > to > > it. We can later evaluate if we need to keep it running. > > > > Q: Where would this be hosted? > > A: The provided link here is a cloud service which will be funded for the > > foreseeable future. At present I am very strongly opposed to hosting this > > anywhere on the existing EFL infrastructure since it has been impossible > > for anyone to get access to any part of the server or to have tasks > > reliably handled in anything but a random and notification-less manner. A > > community project cannot have infrastructure which is unable to be > > accessed, managed, or maintained by the community which is using it. > > > > +1 from me, we have a self hosted gitlab at work (not that I use it > regularly as most of our stuff is on github). > > Also +1 for cloud hosting, but bonus points if we have a setup created > with salt, puppet that means we can automate the setup of the VM's > so that we can easily migrate to another cloud provider in the future > should we need or want to. > > -- > > Simon Lees (Simotek)http://simotek.net > > Emergency Update Team keybase.io/simotek > SUSE Linux Adelaide Australia, UTC+10:30 > GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- Check
Re: [E-devel] Gitlab
On 11/08/18 03:39, Mike Blumenkrantz wrote: > Hello, > > For some time now, everyone in the community has been expressing > significant dissatisfaction with the current project management software, > Phabricator. A number of individuals have proposed switching to Gitlab for > various reasons. > > Some will recall that recently all of the FDO infrastructure migrated from > Phabricator to Gitlab thanks in large part to an incredible, hand-crafted > migration script authored by notable open source figure Daniel Stone. While > this script was not exactly what could be used to migrate our own > infrastructure, it gave me an idea. > > Thanks to a low-pay intern who just graduated and whose name I don't > recall, work began to modify the original FDO migration script and update > it to handle various features exclusive to our usage of Phabricator. Thanks > to generous hosting provided by the basement of the intern's parents, I was > able to review the work as it progressed to see if it would be worth > showing to the community. > > Weeks have passed, and now, thanks to many sleepless nights and long > weekends that this devoted intern spent doing devops work, I was able to > provide justification for more robust hosting and acquire a cloud service > to host an official proof-of-concept for a Gitlab migration: > > https://gitlab-prototype.s-opensource.org/ > > Some notes: > * This is read-only for now > * User creation is disabled, don't bother trying > * Issues with their comments have been imported > * Patch submissions have been imported (the intern screwed up some of the > early imports so there are a few patches without the diff inlined) > - Comments on patch submissions cannot be imported because Phabricator > has no API for retrieving comments on patch review > * Wiki pages are not imported since some decision-making is required > > As is easily noticeable, not all projects have been imported by my intern. > Importing the repo takes some time on its own, and then running the > migration script takes a variable amount of time on top of that depending > on the size of the project (EFL was estimated to take 10+ hours to fully > import). > > Wiki pages have not been imported. On Gitlab, a wiki is project-specific > and so it is impossible to do a 1:1 copy unless we decided to stick > everything onto a specific project. We would have to decide how we want to > do this. > > If we decided to switch to Gitlab, there would be a number of questions > that need to be answered: > Q: How do we migrate? > A: Gitlab cannot accurately mirror all of Phabricator, it can only do a > one-time migration of projects. This means we would at some point lock phab > and then begin migrating, likely over a weekend for the major projects with > the remainders being added later. > > Q: What happens to phab? > A: We would likely want to keep phab in read-only mode for a while after > the migration since all the migrated tickets/patches will provide links to > it. We can later evaluate if we need to keep it running. > > Q: Where would this be hosted? > A: The provided link here is a cloud service which will be funded for the > foreseeable future. At present I am very strongly opposed to hosting this > anywhere on the existing EFL infrastructure since it has been impossible > for anyone to get access to any part of the server or to have tasks > reliably handled in anything but a random and notification-less manner. A > community project cannot have infrastructure which is unable to be > accessed, managed, or maintained by the community which is using it. > +1 from me, we have a self hosted gitlab at work (not that I use it regularly as most of our stuff is on github). Also +1 for cloud hosting, but bonus points if we have a setup created with salt, puppet that means we can automate the setup of the VM's so that we can easily migrate to another cloud provider in the future should we need or want to. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
On 12/08/18 07:09, Vinícius dos Santos Oliveira wrote: > Just curious. I'm not a developer. > > But what will happen to Gerrit? I remember one comment of Rasterman years > ago that he fell in love with Gerrit. What will the migration mean to > Gerrit? > Last time we changed our tools / processes we chose phab over gerrit, now we would be using gitlab instead. So it wouldn't mean anything as we still wouldn't be using it :-) > 2018-08-10 15:09 GMT-03:00 Mike Blumenkrantz > : > >> Hello, >> >> For some time now, everyone in the community has been expressing >> significant dissatisfaction with the current project management software, >> Phabricator. A number of individuals have proposed switching to Gitlab for >> various reasons. >> >> Some will recall that recently all of the FDO infrastructure migrated from >> Phabricator to Gitlab thanks in large part to an incredible, hand-crafted >> migration script authored by notable open source figure Daniel Stone. While >> this script was not exactly what could be used to migrate our own >> infrastructure, it gave me an idea. >> >> Thanks to a low-pay intern who just graduated and whose name I don't >> recall, work began to modify the original FDO migration script and update >> it to handle various features exclusive to our usage of Phabricator. Thanks >> to generous hosting provided by the basement of the intern's parents, I was >> able to review the work as it progressed to see if it would be worth >> showing to the community. >> >> Weeks have passed, and now, thanks to many sleepless nights and long >> weekends that this devoted intern spent doing devops work, I was able to >> provide justification for more robust hosting and acquire a cloud service >> to host an official proof-of-concept for a Gitlab migration: >> >> https://gitlab-prototype.s-opensource.org/ >> >> Some notes: >> * This is read-only for now >> * User creation is disabled, don't bother trying >> * Issues with their comments have been imported >> * Patch submissions have been imported (the intern screwed up some of the >> early imports so there are a few patches without the diff inlined) >> - Comments on patch submissions cannot be imported because Phabricator >> has no API for retrieving comments on patch review >> * Wiki pages are not imported since some decision-making is required >> >> As is easily noticeable, not all projects have been imported by my intern. >> Importing the repo takes some time on its own, and then running the >> migration script takes a variable amount of time on top of that depending >> on the size of the project (EFL was estimated to take 10+ hours to fully >> import). >> >> Wiki pages have not been imported. On Gitlab, a wiki is project-specific >> and so it is impossible to do a 1:1 copy unless we decided to stick >> everything onto a specific project. We would have to decide how we want to >> do this. >> >> If we decided to switch to Gitlab, there would be a number of questions >> that need to be answered: >> Q: How do we migrate? >> A: Gitlab cannot accurately mirror all of Phabricator, it can only do a >> one-time migration of projects. This means we would at some point lock phab >> and then begin migrating, likely over a weekend for the major projects with >> the remainders being added later. >> >> Q: What happens to phab? >> A: We would likely want to keep phab in read-only mode for a while after >> the migration since all the migrated tickets/patches will provide links to >> it. We can later evaluate if we need to keep it running. >> >> Q: Where would this be hosted? >> A: The provided link here is a cloud service which will be funded for the >> foreseeable future. At present I am very strongly opposed to hosting this >> anywhere on the existing EFL infrastructure since it has been impossible >> for anyone to get access to any part of the server or to have tasks >> reliably handled in anything but a random and notification-less manner. A >> community project cannot have infrastructure which is unable to be >> accessed, managed, or maintained by the community which is using it. >> >> Regards, >> Mike >> >> -- >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > > > -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech
Re: [E-devel] Gitlab
Just curious. I'm not a developer. But what will happen to Gerrit? I remember one comment of Rasterman years ago that he fell in love with Gerrit. What will the migration mean to Gerrit? 2018-08-10 15:09 GMT-03:00 Mike Blumenkrantz : > Hello, > > For some time now, everyone in the community has been expressing > significant dissatisfaction with the current project management software, > Phabricator. A number of individuals have proposed switching to Gitlab for > various reasons. > > Some will recall that recently all of the FDO infrastructure migrated from > Phabricator to Gitlab thanks in large part to an incredible, hand-crafted > migration script authored by notable open source figure Daniel Stone. While > this script was not exactly what could be used to migrate our own > infrastructure, it gave me an idea. > > Thanks to a low-pay intern who just graduated and whose name I don't > recall, work began to modify the original FDO migration script and update > it to handle various features exclusive to our usage of Phabricator. Thanks > to generous hosting provided by the basement of the intern's parents, I was > able to review the work as it progressed to see if it would be worth > showing to the community. > > Weeks have passed, and now, thanks to many sleepless nights and long > weekends that this devoted intern spent doing devops work, I was able to > provide justification for more robust hosting and acquire a cloud service > to host an official proof-of-concept for a Gitlab migration: > > https://gitlab-prototype.s-opensource.org/ > > Some notes: > * This is read-only for now > * User creation is disabled, don't bother trying > * Issues with their comments have been imported > * Patch submissions have been imported (the intern screwed up some of the > early imports so there are a few patches without the diff inlined) > - Comments on patch submissions cannot be imported because Phabricator > has no API for retrieving comments on patch review > * Wiki pages are not imported since some decision-making is required > > As is easily noticeable, not all projects have been imported by my intern. > Importing the repo takes some time on its own, and then running the > migration script takes a variable amount of time on top of that depending > on the size of the project (EFL was estimated to take 10+ hours to fully > import). > > Wiki pages have not been imported. On Gitlab, a wiki is project-specific > and so it is impossible to do a 1:1 copy unless we decided to stick > everything onto a specific project. We would have to decide how we want to > do this. > > If we decided to switch to Gitlab, there would be a number of questions > that need to be answered: > Q: How do we migrate? > A: Gitlab cannot accurately mirror all of Phabricator, it can only do a > one-time migration of projects. This means we would at some point lock phab > and then begin migrating, likely over a weekend for the major projects with > the remainders being added later. > > Q: What happens to phab? > A: We would likely want to keep phab in read-only mode for a while after > the migration since all the migrated tickets/patches will provide links to > it. We can later evaluate if we need to keep it running. > > Q: Where would this be hosted? > A: The provided link here is a cloud service which will be funded for the > foreseeable future. At present I am very strongly opposed to hosting this > anywhere on the existing EFL infrastructure since it has been impossible > for anyone to get access to any part of the server or to have tasks > reliably handled in anything but a random and notification-less manner. A > community project cannot have infrastructure which is unable to be > accessed, managed, or maintained by the community which is using it. > > Regards, > Mike > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/ -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
I'm all in favour moving to a self-hosted Gitlab instance. Phabricator is pretty awful and is not very approachable. Also, Gitlab has really overtaken Phab in both popularity and maturity in the last 5 years since we switched. This will also reduce the admin burden of managing Gitolite, and needing all repo creation to go through me. So a huge +1 from me. -- Tom On Fri, Aug 10, 2018 at 7:09 PM, Mike Blumenkrantz wrote: > Hello, > > For some time now, everyone in the community has been expressing > significant dissatisfaction with the current project management software, > Phabricator. A number of individuals have proposed switching to Gitlab for > various reasons. > > Some will recall that recently all of the FDO infrastructure migrated from > Phabricator to Gitlab thanks in large part to an incredible, hand-crafted > migration script authored by notable open source figure Daniel Stone. While > this script was not exactly what could be used to migrate our own > infrastructure, it gave me an idea. > > Thanks to a low-pay intern who just graduated and whose name I don't > recall, work began to modify the original FDO migration script and update > it to handle various features exclusive to our usage of Phabricator. Thanks > to generous hosting provided by the basement of the intern's parents, I was > able to review the work as it progressed to see if it would be worth > showing to the community. > > Weeks have passed, and now, thanks to many sleepless nights and long > weekends that this devoted intern spent doing devops work, I was able to > provide justification for more robust hosting and acquire a cloud service > to host an official proof-of-concept for a Gitlab migration: > > https://gitlab-prototype.s-opensource.org/ > > Some notes: > * This is read-only for now > * User creation is disabled, don't bother trying > * Issues with their comments have been imported > * Patch submissions have been imported (the intern screwed up some of the > early imports so there are a few patches without the diff inlined) > - Comments on patch submissions cannot be imported because Phabricator > has no API for retrieving comments on patch review > * Wiki pages are not imported since some decision-making is required > > As is easily noticeable, not all projects have been imported by my intern. > Importing the repo takes some time on its own, and then running the > migration script takes a variable amount of time on top of that depending > on the size of the project (EFL was estimated to take 10+ hours to fully > import). > > Wiki pages have not been imported. On Gitlab, a wiki is project-specific > and so it is impossible to do a 1:1 copy unless we decided to stick > everything onto a specific project. We would have to decide how we want to > do this. > > If we decided to switch to Gitlab, there would be a number of questions > that need to be answered: > Q: How do we migrate? > A: Gitlab cannot accurately mirror all of Phabricator, it can only do a > one-time migration of projects. This means we would at some point lock phab > and then begin migrating, likely over a weekend for the major projects with > the remainders being added later. > > Q: What happens to phab? > A: We would likely want to keep phab in read-only mode for a while after > the migration since all the migrated tickets/patches will provide links to > it. We can later evaluate if we need to keep it running. > > Q: Where would this be hosted? > A: The provided link here is a cloud service which will be funded for the > foreseeable future. At present I am very strongly opposed to hosting this > anywhere on the existing EFL infrastructure since it has been impossible > for anyone to get access to any part of the server or to have tasks > reliably handled in anything but a random and notification-less manner. A > community project cannot have infrastructure which is unable to be > accessed, managed, or maintained by the community which is using it. > > Regards, > Mike > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
Guess then would be to migrate everything and I’ll work on triaging the bigs after Sent from my iPhone > On 11 Aug 2018, at 08:23, Pierre Couderc wrote: > >> On 08/11/2018 07:30 AM, jaquil...@eagleeyet.net wrote: >> If we are going to migrate I think we should migrate tickets slowly to see >> which ones are still valid and not pollute the new tracker with issues that >> are either moot or no longer valid. >> > Mmm, it is not logical. Migrate is a thing. Process tickets is another thing. > Trying to do 2 independant things simulteaneoulsy? > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
On 08/11/2018 07:30 AM, jaquil...@eagleeyet.net wrote: If we are going to migrate I think we should migrate tickets slowly to see which ones are still valid and not pollute the new tracker with issues that are either moot or no longer valid. Mmm, it is not logical. Migrate is a thing. Process tickets is another thing. Trying to do 2 independant things simulteaneoulsy? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
If we are going to migrate I think we should migrate tickets slowly to see which ones are still valid and not pollute the new tracker with issues that are either moot or no longer valid. On 2018-08-10 18:09, Mike Blumenkrantz wrote: Hello, For some time now, everyone in the community has been expressing significant dissatisfaction with the current project management software, Phabricator. A number of individuals have proposed switching to Gitlab for various reasons. Some will recall that recently all of the FDO infrastructure migrated from Phabricator to Gitlab thanks in large part to an incredible, hand-crafted migration script authored by notable open source figure Daniel Stone. While this script was not exactly what could be used to migrate our own infrastructure, it gave me an idea. Thanks to a low-pay intern who just graduated and whose name I don't recall, work began to modify the original FDO migration script and update it to handle various features exclusive to our usage of Phabricator. Thanks to generous hosting provided by the basement of the intern's parents, I was able to review the work as it progressed to see if it would be worth showing to the community. Weeks have passed, and now, thanks to many sleepless nights and long weekends that this devoted intern spent doing devops work, I was able to provide justification for more robust hosting and acquire a cloud service to host an official proof-of-concept for a Gitlab migration: https://gitlab-prototype.s-opensource.org/ Some notes: * This is read-only for now * User creation is disabled, don't bother trying * Issues with their comments have been imported * Patch submissions have been imported (the intern screwed up some of the early imports so there are a few patches without the diff inlined) - Comments on patch submissions cannot be imported because Phabricator has no API for retrieving comments on patch review * Wiki pages are not imported since some decision-making is required As is easily noticeable, not all projects have been imported by my intern. Importing the repo takes some time on its own, and then running the migration script takes a variable amount of time on top of that depending on the size of the project (EFL was estimated to take 10+ hours to fully import). Wiki pages have not been imported. On Gitlab, a wiki is project-specific and so it is impossible to do a 1:1 copy unless we decided to stick everything onto a specific project. We would have to decide how we want to do this. If we decided to switch to Gitlab, there would be a number of questions that need to be answered: Q: How do we migrate? A: Gitlab cannot accurately mirror all of Phabricator, it can only do a one-time migration of projects. This means we would at some point lock phab and then begin migrating, likely over a weekend for the major projects with the remainders being added later. Q: What happens to phab? A: We would likely want to keep phab in read-only mode for a while after the migration since all the migrated tickets/patches will provide links to it. We can later evaluate if we need to keep it running. Q: Where would this be hosted? A: The provided link here is a cloud service which will be funded for the foreseeable future. At present I am very strongly opposed to hosting this anywhere on the existing EFL infrastructure since it has been impossible for anyone to get access to any part of the server or to have tasks reliably handled in anything but a random and notification-less manner. A community project cannot have infrastructure which is unable to be accessed, managed, or maintained by the community which is using it. Regards, Mike -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Gitlab
I am 100% for this move. Both to gitlab and regardless of gitlab, to a new infrastructure. I would add another plus... gitlabs CI/CD tools seem to be way better than phabs. On Fri, Aug 10, 2018, 1:16 PM Mike Blumenkrantz < michael.blumenkra...@gmail.com> wrote: > To list some pros and cons for a switch: > > PROS: > * Greatly improved patch review UI > Gitlab is similar in workflow and usage to Github, so it will be much > easier to use the patch review tools > * Simplified patch submission workflow > Gitlab uses git and does not require external tools such as arc/git-phab > * Actively developed > Phabricator is basically closed-source at this point, and they develop only > as they decide to or as people pay them to. Gitlab is open source and the > developers actively reply to tickets and fix issues > > CONS: > * Does require having people manage a migration > * Will take time to migrate > * Will take time to adjust to new tools/workflows > > On Fri, Aug 10, 2018 at 2:09 PM Mike Blumenkrantz < > michael.blumenkra...@gmail.com> wrote: > > > Hello, > > > > For some time now, everyone in the community has been expressing > > significant dissatisfaction with the current project management software, > > Phabricator. A number of individuals have proposed switching to Gitlab > for > > various reasons. > > > > Some will recall that recently all of the FDO infrastructure migrated > from > > Phabricator to Gitlab thanks in large part to an incredible, hand-crafted > > migration script authored by notable open source figure Daniel Stone. > While > > this script was not exactly what could be used to migrate our own > > infrastructure, it gave me an idea. > > > > Thanks to a low-pay intern who just graduated and whose name I don't > > recall, work began to modify the original FDO migration script and update > > it to handle various features exclusive to our usage of Phabricator. > Thanks > > to generous hosting provided by the basement of the intern's parents, I > was > > able to review the work as it progressed to see if it would be worth > > showing to the community. > > > > Weeks have passed, and now, thanks to many sleepless nights and long > > weekends that this devoted intern spent doing devops work, I was able to > > provide justification for more robust hosting and acquire a cloud service > > to host an official proof-of-concept for a Gitlab migration: > > > > https://gitlab-prototype.s-opensource.org/ > > > > Some notes: > > * This is read-only for now > > * User creation is disabled, don't bother trying > > * Issues with their comments have been imported > > * Patch submissions have been imported (the intern screwed up some of the > > early imports so there are a few patches without the diff inlined) > > - Comments on patch submissions cannot be imported because Phabricator > > has no API for retrieving comments on patch review > > * Wiki pages are not imported since some decision-making is required > > > > As is easily noticeable, not all projects have been imported by my > intern. > > Importing the repo takes some time on its own, and then running the > > migration script takes a variable amount of time on top of that depending > > on the size of the project (EFL was estimated to take 10+ hours to fully > > import). > > > > Wiki pages have not been imported. On Gitlab, a wiki is project-specific > > and so it is impossible to do a 1:1 copy unless we decided to stick > > everything onto a specific project. We would have to decide how we want > to > > do this. > > > > If we decided to switch to Gitlab, there would be a number of questions > > that need to be answered: > > Q: How do we migrate? > > A: Gitlab cannot accurately mirror all of Phabricator, it can only do a > > one-time migration of projects. This means we would at some point lock > phab > > and then begin migrating, likely over a weekend for the major projects > with > > the remainders being added later. > > > > Q: What happens to phab? > > A: We would likely want to keep phab in read-only mode for a while after > > the migration since all the migrated tickets/patches will provide links > to > > it. We can later evaluate if we need to keep it running. > > > > Q: Where would this be hosted? > > A: The provided link here is a cloud service which will be funded for the > > foreseeable future. At present I am very strongly opposed to hosting this > > anywhere on the existing EFL infrastructure since it has been impossible > > for anyone to get access to any part of the server or to have tasks > > reliably handled in anything but a random and notification-less manner. A > > community project cannot have infrastructure which is unable to be > > accessed, managed, or maintained by the community which is using it. > > > > Regards, > > Mike > > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Re: [E-devel] Gitlab
To list some pros and cons for a switch: PROS: * Greatly improved patch review UI Gitlab is similar in workflow and usage to Github, so it will be much easier to use the patch review tools * Simplified patch submission workflow Gitlab uses git and does not require external tools such as arc/git-phab * Actively developed Phabricator is basically closed-source at this point, and they develop only as they decide to or as people pay them to. Gitlab is open source and the developers actively reply to tickets and fix issues CONS: * Does require having people manage a migration * Will take time to migrate * Will take time to adjust to new tools/workflows On Fri, Aug 10, 2018 at 2:09 PM Mike Blumenkrantz < michael.blumenkra...@gmail.com> wrote: > Hello, > > For some time now, everyone in the community has been expressing > significant dissatisfaction with the current project management software, > Phabricator. A number of individuals have proposed switching to Gitlab for > various reasons. > > Some will recall that recently all of the FDO infrastructure migrated from > Phabricator to Gitlab thanks in large part to an incredible, hand-crafted > migration script authored by notable open source figure Daniel Stone. While > this script was not exactly what could be used to migrate our own > infrastructure, it gave me an idea. > > Thanks to a low-pay intern who just graduated and whose name I don't > recall, work began to modify the original FDO migration script and update > it to handle various features exclusive to our usage of Phabricator. Thanks > to generous hosting provided by the basement of the intern's parents, I was > able to review the work as it progressed to see if it would be worth > showing to the community. > > Weeks have passed, and now, thanks to many sleepless nights and long > weekends that this devoted intern spent doing devops work, I was able to > provide justification for more robust hosting and acquire a cloud service > to host an official proof-of-concept for a Gitlab migration: > > https://gitlab-prototype.s-opensource.org/ > > Some notes: > * This is read-only for now > * User creation is disabled, don't bother trying > * Issues with their comments have been imported > * Patch submissions have been imported (the intern screwed up some of the > early imports so there are a few patches without the diff inlined) > - Comments on patch submissions cannot be imported because Phabricator > has no API for retrieving comments on patch review > * Wiki pages are not imported since some decision-making is required > > As is easily noticeable, not all projects have been imported by my intern. > Importing the repo takes some time on its own, and then running the > migration script takes a variable amount of time on top of that depending > on the size of the project (EFL was estimated to take 10+ hours to fully > import). > > Wiki pages have not been imported. On Gitlab, a wiki is project-specific > and so it is impossible to do a 1:1 copy unless we decided to stick > everything onto a specific project. We would have to decide how we want to > do this. > > If we decided to switch to Gitlab, there would be a number of questions > that need to be answered: > Q: How do we migrate? > A: Gitlab cannot accurately mirror all of Phabricator, it can only do a > one-time migration of projects. This means we would at some point lock phab > and then begin migrating, likely over a weekend for the major projects with > the remainders being added later. > > Q: What happens to phab? > A: We would likely want to keep phab in read-only mode for a while after > the migration since all the migrated tickets/patches will provide links to > it. We can later evaluate if we need to keep it running. > > Q: Where would this be hosted? > A: The provided link here is a cloud service which will be funded for the > foreseeable future. At present I am very strongly opposed to hosting this > anywhere on the existing EFL infrastructure since it has been impossible > for anyone to get access to any part of the server or to have tasks > reliably handled in anything but a random and notification-less manner. A > community project cannot have infrastructure which is unable to be > accessed, managed, or maintained by the community which is using it. > > Regards, > Mike > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
