2016-03-25 19:32 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:

Hi Stef,

On Fri, Mar 25, 2016 at 2:27 PM, stepharo <stepharo@free.fr> 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?

In my opinion, that sounds like a very good and more serious approach for the whole community. The only problem I see is an explosion of Pharo flavors like happened in Squeak years ago, because many people want promotion of their own image (which is ok but also reflects lack of consensus), but is better than having new core projects with developers abandoning before time or obscure decisions imposing a new debugger without ANY poll.

Now I don't want to waste time on definitions of "solid", but I can tell you Pharo now feels slow.

About having to ask "spend some time optimising tools" just a few weeks before a release... Sorry guys I know you work a lot on making good quality stuff, but seems like the current way of integrating tools **is NOT working**.

Where is the policy for integrating packages and tools into the core?

Where are the priorities? Why they are priorities? How many votes gets each?

Want more contributors?
Start with clean visible rules and listen to users.

We all want UFFI, Xtreams, mini-image, new UI frameworks & builder, etc. but not at any cost.

Hern��n