I agree.!

Now what I suggest is that we do not release a pharo-dev image without having 
tested it.

> Hi folks. I am really concerned about the instability of the dev and web 
> images. WE CANNOT RELEASE a RC where you cannot even double click in a class. 
> This cannot happens.

I agree.

> We all know that all software can have bugs. But again, we cannot release 
> images, and even RC images, which are supposed to be quite stable, where you 
> cannot right click a class, you cannot refactor, you cannot even right click 
> in the code pane. And don't told me "I use the keyboard" because I don't care 
> what you do. A lot of people use the mouse. 

:)

> I have already said it several times. Most of the people don't care how nice, 
> fast, clean, open source and well programmed is the Pharo Core image if they 
> cannot use the Dev or Web image. 
> 
> Remember that our users are external users, you even don't care about the 
> core. They just use Pharo, they are not developers. 
> 
> I really think we need to fix this. You are giving a bad impression of 
> something which is not true. You are doing AN EXCELLENT work with PharoCore. 
> Why to wast all of this for this kind of situations? It is a pity :(

yes

> 1) We are building a dev image per month more or lest. 5 days before en of 
> months (more or less), the dev image should be built. 
> 
> 2) During 5 years, some people will use that image as a beta tester. I would 
> ideally to have different users: different OS, different browsers, etc.
> This people will use that image for their work for those 5 days and report 
> any bug that appears. Of course, not all people can do that. 
> How is volunteer to be beta tester ?  We can create a wiki page for that if 
> you are agree with the idea.

This is a good idea.


>  3) After those 5 days, if the image is stable enough, it is released. If it 
> is not, it is just not released. Nobody will kill you if one month you don't 
> release a new image. In addition, is better not to release an unstable image 
> that releasing it and not be able to do a single right click. 

Let us give a try. 
Now we should fix the current one. 

> 
> In Canonical, all the employees MUST to use for one month or more each Ubuntu 
> release. We are not employee, but we can do something similar.
> 
> What do you think ?

Sounds cool.


> 
> Cheers
> 
> Mariano
> 
> 
> ---------- Forwarded message ----------
> From: Stan Shepherd <[email protected]>
> Date: Wed, Dec 30, 2009 at 6:26 PM
> Subject: [Pharo-project] Issue 1721:  Refactoring appears to be broken in web 
> dev image. e.g. OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols
> To: [email protected]
> 
> 
> 
> NB this logs a particular walkback, but the whole area appears to be
> unworkable in the web dev image. Please could the maintainers click, right
> click, middle click on each part of refactoring browser, take each menu
> item, etc. This will be much quicker than logging one bug at a time.
> If this turns out to be the last one, my apologies in advance.
> Thanks.   ...Stan
> 
> 
> VM: unix - i686 - linux-gnu - Pharo0.1 of 16 May 2008 [latest update:
> #10074]
> Image: PharoCore1.0rc1 [Latest update: #10502] pharo1.0-10502-rc1web09.12.2
> 
> Class browser used (if applicable):  OR2PackageBrowser.
> 
> OBClassNode(Object)>>doesNotUnderstand: #dynamicProtocols
>        Receiver: OBClassNode<ShortIntegerArray>
>        Arguments and temporary variables:
>                aMessage:       dynamicProtocols
>                exception:      MessageNotUnderstood: 
> OBClassNode>>dynamicProtocols
>                resumeValue:    nil
>        Receiver's instance variables:
>                metaNode:       Class
> #allCategory->AllMethodCategory
> #categories->MethodCategory
> #dy...etc...
>                navigation:     an O2DefaultEdgeNavigation
>                theClass:       ShortIntegerArray
> 
> O2MetaEdge>>nodesForParent:
>        Receiver: #dynamicProtocols->DynamicProtocols
>        Arguments and temporary variables:
>                aNode:  OBClassNode<ShortIntegerArray>
>        Receiver's instance variables:
>                label:  'dynamicProtocols'
>                selector:       #dynamicProtocols
>                metaNode:       DynamicProtocols
> #methods->Method
> 
>                navigation:     an O2DefaultEdgeNavigation
>                isDropEdge:     nil
> 
> ...
> --
> View this message in context: 
> http://n2.nabble.com/Issue-1721-Refactoring-appears-to-be-broken-in-web-dev-image-e-g-OBClassNode-Object-doesNotUnderstans-tp4233114p4233114.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> 
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to