[ANN] Open meeting regarding the Squeak Release Team

> First of all, I would say, thath I appreciate your work..very much.  
> I admire you, like I admire all the "Squeak's Masters".
>
> This message, is for all the community.
>
> Probably, I'm not the right person to speak, because, I'm only a  
> newbie, learning this fantastic world, and I'm more an observer than  
> a contributor (sad to me).
>
> I'm concerned because in all the time I'm in this list, always thath  
> the team want to improve, or do some thing to the project, the  
> people thath disagree, create a fork, or don't want to help.
>
> The forks are not good for any project. In spanish maillist (as all  
> can say, my english is terrible, and there I can express me better),  
> I said thath IMHO, the best thath Squeak can do, is to go to a  
> minimal Squeak, and all the things has now, could be loaded. and I  
> think all we need to do is help to this, because this, is for all.
>
> Only can express my sadness, because I'm attending how this  
> community is destroyed. Why all don't help? Why all only want his  
> own purposses?.This is what we want to show to the newest members? a  
> selfish community? The best thing we can do, if I don't like  
> something, I will see to other side?
>
> We have a board, true? This was elected by the Squeak community, and  
> IMHO, the opinions of the board, could be voted by the community,  
> and the community, will get a Squeak for all.
>
> The example of Traits. Some wants Traits integrated on the image.  
> Other Don't want it. Ok, a poll for this, and the community may  
> respect the results.
>
> Only is an opinion, and, as the mail you received, I didn't have the  
> value courage to send it.
>
> This mail go with good intentions, but I don't know how express me  
> better, sorry.
>
>
> El 02/02/2008, a las 16:36, stephane ducasse escribió:
>
>> Hi egdar
>>
>> to make sure that I understand that correctly: 3.10 harvested a  
>> couple of fixes (compared with the 685 mantis
>> items marcus closed) and you are telling that 3.11 will in addition  
>> merge everything and reconcile all the forks.
>> This sounds optimistic and not really aligned with the results of  
>> 3.10. Don't you think?
>>
>> Now a couple of weeks ago someone sent me this mail
>> "Just out of curiosity...
>> I wanted to write a mail, along the lines of...
>> I looked into the bugs fixed in 3.10... I'm a bit confused, though,  
>> because there does not seem to be much progress in 3.10 with  
>> respect to bug fixing. Is Mantis up to date? Is Mantis showing what  
>> I think it should (I used the date + status filters)?
>>
>> Below is a comparison of the number of reports for each possible  
>> state in 3.9 (March 1, 2005 - Sept 30, 2006) and 3.10 (Oct 1, 2006  
>> - today):
>> 3.9 3.10 status
>> ----------------------------
>> 276 254 new
>> 19 8 feedback
>> 4 1 acknowledged
>> 2 3 confirmed
>> 70 111 assigned
>> 47 10 resolved
>> 685 25 closed
>>
>> ...but I did not send it (yet)"
>>
>> And you know the saddest part is that is not that 3.10 harvested so  
>> few fixes because this can happen. The saddest part is
>> that this person did not send his email because it means that  
>> people get bored or at the end that we do not succeed to bring  
>> their enthousiasm into the community. With this kind of attitude  
>> will may lose on the long term. I like squeak because people  are  
>> sharing and are enthousiast about it.
>> Of course managing the image with MC does not really work for  
>> streaming changes. I really hope that MC2 will solve that. Colin  
>> told me that it will: MC2 will really load only the difference and  
>> will not have to rescan everything. Now MC2 is not ready and may be  
>> not ready.
>>
>> So I will do 3.9.1 because some people asked me and after I will  
>> really take the time to think about where I put
>> my energy. May do a call for building another fork of something  
>> different from Squeak as it is now or simply do not care.
>> May be other dynamic languages are more fun at the end.
>>
>> Stef
>>
>
>
>

> I was who talked about Traits (Not useful to me and several other  
> persons).
>
> Is only an opinion, my opinion, but not was Edgar who commented so.
>
> Cheers.
>
>
>
> 2008/2/2, stephane ducasse <[hidden email]>:
>> Sure speech, nebraska and a lot of broken code is a useful thing....
>>
>> On Feb 2, 2008, at 1:42 PM, Germán Arduino wrote:
>>
>>> 2008/2/1, Edgar J. De Cleene <[hidden email]>:
>>>>
>>>>
>>>> The point is if we should start from 3.8.2 (without Traits and
>>>> Monticello)
>>>> or we should continue from 3.10 is now.
>>>
>>> My vote is without Traits!!! (Traits: big example of a not useful
>>> thing, IMHO),
>>>
>>> Cheers.
>>>
>>>
>>
>>
>>
>
>

>
>>    traits and the other without. This just didn't arise in the
>>    meeting
>>
>>
> I think that this is missing a point. I may be reading what Andreas  
> said
> wrongly, and I am sure he will be quick to correct me if I am wrong.
>
> I do not think that the issue is with the concept of traits or the  
> fact
> that traits work. It is the application of traits
> to the class/metaclass heirarchy which renders elements of it  
> difficult
> to understand.

> Here are the topics we discussed in our first skype call, from 14:00  
> to
> 15:00 utc. Edgar, Colin, Keith, Esteban, and Matthew participated
> - MC2 supports both PackageInfo-type files, and arbitrary slices.
> - Damien's mc2 work was in the direction of making MC2 emulate MC1,  
> and
> colin didn't use that
> - Projects are something
> - The biggest issue with traits seems to be that the implementation is
>  too complicated to unerstand, and for the tool developers to write
>  tools for.
> - Talk in spanish about traits
> - Could traits be made loadable/unloadable? Is someone working on a
>  simpler implementation? Andreas may be.
> - Will Stateful Traits be simpler to incorperate?
>
> --
> Matthew Fulmer -- http://mtfulmer.wordpress.com/
> Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
>
>

> Hi guys
>
> This is my last email on this topic because I do not want to lose all
> my energy in that. If you can, I can't anymore but at least we proved in
> the past that
> we ere serious about what we did.
>
> I think that if the goal is to produce a better squeak and bring back
> changes from croquet, OLPC,
> Sophie: here is a list of items to **work** on:
>
> - cleaner/leaner UI framework (may be removing MVC is the way to go
> first).
> - more tests more tests more tests.
> - check all the changes one by one from all the streams and good luck.
> - better MC (probably MC2 + deltastreams) so that we can get the best of
> CS and Packages
> at the same time. Atomic loading (did you help colin?)
> - more tests more tests more tests.
> - better packages (in terms of circular dependencies and so on you loading
> X requires Y that requires X).
> - stop maintaining etoy  which is touching too much stuff. (apply the mac
> approach: deprecated experimental
> or old code not maintained anymore).
> - better network packages (squeak deserves better).
> - UI Builder, better browser (OB?).
> - consistent look, unification of browsers (we have far too much of them),
> shortcut all the way down (squeak
> should be usable without a mouse).
> - better compiler (help enhancing the new compiler) and the old one
> (compiler error such as variable shadowing
> should not just appear in the transcript but a real object).
> - harvest fixes (the good ones).
> - more tests more tests more tests.
> - involve people (our process was clearly not optimal but we ask for help
> and few were helping us)
> but the one of 3.10 was a clear failure in term of its communication with
> the simple people around like us.
>
> BTW Smaller does not mean cutting shit in pieces, it means better smaller
> pieces. Because lasagna
> is just a bit better than spaghetti code.
>
> Now if you think that traits is the problem, I urge you to  remove them.
> This is easy and you will be
> the saver of the great squeak community forever. But I still think that our
> problems are elsewhere: class
> depending on subclasses, fat interfaces, broken code, deadcode, spaghetti
> code, old code, lack of documentation,
> lack of tests.
>
> Good luck! you will need a lot of that!
>
> Stef

> - cleaner/leaner UI framework (may be removing MVC is the way to go
> first).
> - more tests more tests more tests.
> - check all the changes one by one from all the streams and good luck.
> - better MC (probably MC2 + deltastreams) so that we can get the best
> of CS and Packages
> at the same time. Atomic loading (did you help colin?)
> - more tests more tests more tests.
> - better packages (in terms of circular dependencies and so on you
> loading X requires Y that requires X).
> - stop maintaining etoy  which is touching too much stuff. (apply the
> mac approach: deprecated experimental
> or old code not maintained anymore).
> - better network packages (squeak deserves better).
> - UI Builder, better browser (OB?).
> - consistent look, unification of browsers (we have far too much of
> them), shortcut all the way down (squeak  
> should be usable without a mouse).
> - better compiler (help enhancing the new compiler) and the old one
> (compiler error such as variable shadowing
> should not just appear in the transcript but a real object).
> - harvest fixes (the good ones).
> - more tests more tests more tests.
> - involve people (our process was clearly not optimal but we ask for
> help and few were helping us)

> Hello Edgar,
>
> EJDC> Sad just now I talking about how 3.11 should be , some start talking
> about
> EJDC> made 3.9.1.....
>
> those who make 3.9.1 just perform a service to those who have based
> commercial (or critical) apps on 3.9.
>
> That's what 3.8. 1 and 2 did for me (and others) who have
> applications in 3.8.
>
> Squeak can be proud that there is a request for maintenance releases.
>
> Cheers
>
> Herbert                            mailto:[hidden email]

>> You are correct. My issue is not as much with traits (outside of my  
>> general prejudices about multiple inheritance ;-) but rather with  
>> the choices that have been made with their application in the class  
>> kernel. I've actually spent a significant amount of time trying to  
>> understand the design and implementation decisions and my main  
>> objection is basically the use of MI in such a mission-critical  
>> piece of the system. From an engineering point of view one could  
>> *easily* make a traits implementation that is a simple extension of  
>> the 3.8 kernel by subclassing for example ClassDescription. The  
>> result would be a small, loadable(!) traits module that does not  
>> change the fundamentals around which that kernel was built.
>
> Cheers,
>  - Andreas
>
>

> Keith Hodges wrote:
> > I think that this is missing a point. I may be reading what Andreas said
> > wrongly, and I am sure he will be quick to correct me if I am wrong.
> >
> > I do not think that the issue is with the concept of traits or the fact
> > that traits work. It is the application of traits
> >  to the class/metaclass heirarchy which renders elements of it difficult
> > to understand.
>
> You are correct. My issue is not as much with traits (outside of my
> general prejudices about multiple inheritance ;-) but rather with the
> choices that have been made with their application in the class kernel.
> I've actually spent a significant amount of time trying to understand
> the design and implementation decisions and my main objection is
> basically the use of MI in such a mission-critical piece of the system.
>  From an engineering point of view one could *easily* make a traits
> implementation that is a simple extension of the 3.8 kernel by
> subclassing for example ClassDescription. The result would be a small,
> loadable(!) traits module that does not change the fundamentals around
> which that kernel was built.
>
> Cheers,
>    - Andreas
>
>