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.stinckwich@gmail.com> wrote:



On Fri, Jul 28, 2017 at 9:34 AM, Hilaire <hilaire@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/