I totally do not agree with many of the arguments in this thread. But I do not want to discuss them under this label. Please start a new thread, if you want to.
> On 26 Mar 2016, at 05:40, Hernán Morales Durand <[email protected]> > wrote: > > > > 2016-03-25 19:32 GMT-03:00 Eliot Miranda <[email protected]>: > 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? > > 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
