Hi Stef, On Fri, Mar 25, 2016 at 2:27 PM, stepharo <[email protected]> wrote:
> So guys, you do not want Xtreams (and prefer to use Streams that have been > "designed" decades ago) ;D ? > no bootstrapped core (clement you do not want to have a mini image :) ? > and a new UI frameworks? > yes, of course :-) > I personnally want to have new widgets, a real UI builder and massively > cleaning Spec. > Now I would like to have multiple tool sets - I understand that people > like the new debugger (I do not like it) - > I want the possibility to have a mini tools tool set. > +1 > If you want to clean Pharo you can start cleaning Komitter stupid use of > state pattern generating > a lot of garbage instead of having a single animated morph. > > We should clean Versionner- I have the impression that half of the classes > are not mandatory. > I don't think this is either or. I don't think Hilaire is saying "don't do feature-rich releases". I think Hilaire is saying "do separate feature-rich and consolidation releases". I think Hilaire is making a good suggestion of having some releases being for new functionality and some for consolidation. So perhaps the community could schedule a Pharo N, followed by a Pharo N.1, or schedule a Pharo M, where M is even (or odd) and a Pharo N, where N is odd (or even), and have the N.1, or N is odd (or even) releases being consolidation releases as Hilaire describes, with no new features and only bug fixes and performance improvements. If the community can manage it, it could do one new feature, followed by one consolidation release a year. But if so, the community needs to be serious about the consolidation releases and put real effort into them. The advantage for the broader user base is clear; there is a steady stream of releases that more conservative users can use, that exhibits good stability and better performance than the bleeding edge. Also, there's no reason why these release cycles can't overlap. The only time they must not overlap is when the community needs to focus on the new release. So for example, for two months of the year, six months apart, the community should focus on the new release, be it consolidation or feature-rich, and make sure we release promptly and correctly. But the other ten months of the year there's no reason why the community cannot work on either release. This requires infrastructure such as two repositories, one for each, such as pharo-features and pharo-stable, and the discipline to separate one's work correctly, but it could be a really good thing. I'm sure others can think this through better than I. What do others suggest? Stef > > 2016-03-25 18:18 GMT+01:00 Hilaire <[email protected]>: > >> Not exactly related to Announcement, but I remember when I first port >> DrGeo to Squeak (at that time Pharo did not exist) I used a lot of >> change/update when objects in the canvas changed. It was terribly slow, >> and later opted for a top-down update in the list of object. >> >> So some sometime what look like a cool stuff (decoupled objects) is just >> a drag. >> >> Regarding optimizing, I share my opinion here months ago, I think Pharo >> need consolidation releases: no new features, only bugs fix and speed >> improvement. There are enough new features in Pharo for a couple of >> years, but the product need to *be* solid and *feel* solid. >> > > +1 > > >> >> Hilaire >> >> Le 25/03/2016 12:33, Stephan Eggermont a écrit : >> > On 25-03-16 11:49, Nicolai Hess wrote: >> >> Morphic drasticallly slower ? I would expect morphic code is mostly >> >> the same in pharo and squeak. If pharo is slower, this is a good >> >> starting point for optimising. Can you gives some hints? >> > I do not have the impression that morphic is so much slower. >> > We had/have a problem of too many announcements being send and >> > too many redraws happening. >> > >> > Stephan >> > >> > >> >> -- >> Dr. Geo >> http://drgeo.eu >> >> >> > > -- _,,,^..^,,,_ best, Eliot
