+ 100
On Fri, Jul 28, 2017 at 3:25 PM, Sven Van Caekenberghe <s...@stfx.eu> wrote:
>
>> On 28 Jul 2017, at 15:13, p...@highoctane.be wrote:
>>
>> Changing too many things at once is indeed annoying.
>>
>> Now, I am ready to live with that but at one point, I think that we will
>> have to move to something like I see done in other fast evolving ecosystems.
>>
>> In Hadoop for example, Hortonworks (a distribution) moved to a set of slow
>> evolving substrate that is stable and know to stay stable for a long period
>> (HDFS, YARN) and a set fast moving releases for projects that do build on
>> top (Spark).
>>
>> Holding back on the new things makes you feel like you use a tool of the
>> past. Living on the bleeding edge is not doable because you need to solve
>> too many non business centric issues.
>>
>> There needs to be a combination.
>>
>> As far as I am concerned, I worked in 3.0 a lot, skipped the whole 4.0 ship,
>> embarked on the 5.0 and, albeit if I did a bit on 6.0, I may not develop
>> production code on it at the moment. 7.0 looks okay but there are lot of
>> changing things there, so, that is also too much for me.
>>
>> 6.1 can lure me in with Iceberg and 64-bit UFFI and fast inspectors on large
>> collections. I need a platform I can understand and build upon.
>>
>> There needs to be a semblance of LTS in this.
>
> But even the LTS concept does not solve all problems.
>
> Every 2 years there is a new LTS, which is supported for 5 years.
>
> But in most projects (the same happened here), you are lazy and wait 5 years
> until you *have* to upgrade.
>
> And by then the difference between what you started with (say 12.04) and the
> current stable (say 16.04) can already be huge (remember, you skipped one LTS
> release) and the next one is already coming (18.04).
>
> Change is unavoidable, it is not just part of life, it *is* life.
>
>> Maybe a 6.1, 6.2, 6.3 story and a 7.x line with boostrap magic and what not.
>>
>> 6.x is a great platform and has a lot going for it if stable enough.
>>
>> I have projects coming my way and using Pharo is an option. Now, I need
>> something that is not going to shift under my feet.
>>
>> Especially if I want to embark crew along.
>>
>> Phil
>>
>> On Fri, Jul 28, 2017 at 11:00 AM, 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/
>>
>
>
