Just to chip in - I hope we can get past this bump (and I think it is a bump).
I am actually ecstatic that recent improvements - a 64bit vm, a minimal image and git integration, have opened the door to Pharo working on AWS Lambda. Also having a CI system to help crank these things out is also a big win. So I applaud the work, progress and vision that has got us here ! All large systems accrue infrastructure and unexpected dependencies that take effort to modernise. I don't think this is solely a Pharo thing. (I just recently worked with a Java team that used SnapCI for builds, and when it was shut down it was 6+ weeks to migrate off it and stabilise things). We are close - we just need to rally around to get a good stable base that can support the next round of revolution (aka P7). Tim Sent from my iPhone > On 28 Jul 2017, at 11:00, Serge Stinckwich <serge.stinckw...@gmail.com> wrote: > > > >> On Fri, Jul 28, 2017 at 9:34 AM, Hilaire <hila...@drgeo.eu> wrote: >> I don't share your enthusiasm. >> >> I once set up a satisfactory build environment for DrGeo, based on P3. As >> long as I stay with P3, I can concentrate on DrGeo code: write the code, >> then fire up a build script to deploy the application. Now porting to P6 is >> a pain: the infrastructure to deploy a desktop application has not evolve >> since P3, I have to build again a deployment environment from scratch (VM >> support, shrinked/built image, I don't know the promise of minimal image >> build up is not palpable for me). >> >> Now If I have to spend days on that, I am not sure I will do it again, I >> can't compete against other geometry application if I have to fight against >> pharo too. What I want is to concentrate working on DrGeo not Pharo, sorry >> to make it explicit but I can't much offer to do both. >> > > I have sometimes the same concerns with Pharo or some tools of the Pharo > ecosystem. I know that we are trying to do our best and regarding the number > of core developers we have already an incredible platform. But sometimes, you > need to very simple updates and because of subtle problems with > VM/configurations/CI/ etc ... this is not that simple and we need to spend > times on boring stuff. > > There is no simple solution. > > One solution might be that the core developers only focus on core Pharo > functionalities but I think this is somewhat difficult, because most of the > dev are from RMOD. RMOD is a research unit and could not spend all his > money/effort on an engineering process. > > Another solution is to grow our community. More people, more companies to > sustain more engineers through the consortium. The more people we are able to > attract, the more people will help to develop working solutions for problems > like deployment or to have bug-fixing intermediate releases. > > This is why we all need in the community to do as much as possible > advertisements: lectures at universities, talk to your colleague about Pharo, > do demos in companies, at open-source forums, use Twitter do talk about Pharo > ecosystem, the software you are developing with Pharo. > Don't hide problems but talk about our nice platform and our community. > > We have done this with Stephane in the early days of Pharo at open-source > forums in France and I remember that you come in the community after we meet > you in one of these forums :-) > So DrGeo2 exists because of this kind of advertisement. > > Regards, > > -- > Serge Stinckwich > UCN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/
