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. > You are a Ubuntu user. I am a CentOS|RHEL user. There support is 10 years. Check this: https://wiki.centos.org/About/Product Official party line here: https://access.redhat.com/support/policy/updates/errata TL;DR: CentOS6: until 2020 for maintenance updates CentOS7, until 2024 for maintenance updates. Using the recent/latest is possible with e.g. * Software Collections https://www.softwarecollections.org/en/ * LXC If one needs a 4.x kernel that is doable too via elrepo. But there is a lot of backport happening by RedHat. There is a reason these guys are making gobs of money: they support business. Frankly I wouldn't touch Ubuntu with a 10 feet pole anymore now that I have 100+ servers running CentOS under management. > 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). > To be frank 14.04 is the only decent release I know. All of the other ones have issues of one kind or another. > > Change is unavoidable, it is not just part of life, it *is* life. > Sure. But change is to be managed and the business is what makes money. So, not catering to business needs is a losing proposition. There is this business by Clement and Esteban that apparently will come to life at one point. I guess business forces may have more impact at that time frame. Wait and see. Phil > > > 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/ > > > > > >
