The main problem is that we are not integrating enough. Please, take 5
minutes and see this example:  Open http://source.wiresong.ca/ob
In pharo1.0-10502-rc1dev09.12.2  the version loaded is
OB-Standard-DamienCassou.438
which actually loads the OB-Standard-lr.434. I really don't understand why
this. Is this a hack to our script to build dev images ???
Why we need to push up again a version ?

Moreover, what happened with OB-Standard-DavidRoethlisberger.437 ? I was not
integratd (if I understood correctly). So, the issue 1373 may be alive
again.

And what about the fix of OB-Standard-DavidRoethlisberger.434 ?

and OB-Standard-dr.433  432 431 430 ... what happens with all those commits
?   They don't seem to be merged.

Is there a reason for this ? I am reading ok the commits ?

Thanks

Mariano


On Wed, Dec 30, 2009 at 9:34 PM, Stéphane Ducasse <[email protected]
> wrote:

> Bart in Morphic may be this is not broken in 3.9
> there was a recordMorph that recorded the mouse location and that could be
> replied after.
> I read the code long time ago and forgot but may.
>
> I remember that on VisualAge there was a tool to capture and replay UI
> tests.
> So I would be really interested to see how far you can go with your idea.
>
> On Dec 30, 2009, at 8:50 PM, Bart Gauquie wrote:
>
> > I highly agree also !!
> >
> > Its related to Pharo for Professional Development thread I started 2
> weeks ago. It basically says the same.
> > My gut feeling is still that stability should be the number one focus.
> Its great to innovate, but innovation must not harm stability.
> >
> > For me stability is keeping regression bugs to a minimum. To test the
> stability of the GUI/Morphic parts of Pharo, I started to create a little
> project: http://www.squeaksource.com/MorphicsRecordNPlay/. This can record
> mouse events and replay them afterwards. My idea was to take this as a sort
> of automated integration testing of Pharo. You can then record all kinds of
> stuff: opening a browser, clicking on a class, try every option out, ... .
> I've also attempted to automatically convert these recordings into sunit
> test cases so they can be automatically replayed, but I stumbled upon
> following limitation : Long method can not be compiled using #compile:
> aString. Havent looked into it further yet. Any ideas here how these can be
> replayed?
> >
> > Kind Regards,
> >
> > Bart
> >
> >
> > 2009/12/30 Mariano Martinez Peck <[email protected]>
> > 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. 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 :(
> >
> > I don't know the best solution for this. I will only give an idea I have,
> but I would really like to hear you ideas and do something with this.
> >
> > 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.
> >
> > 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.
> >
> > 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 ?
> >
> > 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
> >
> >
> >
> > --
> > imagination is more important than knowledge - Albert Einstein
> > Logic will get you from A to B. Imagination will take you everywhere -
> Albert Einstein
> > Learn from yesterday, live for today, hope for tomorrow. The important
> thing is not to stop questioning. - Albert Einstein
> > The true sign of intelligence is not knowledge but imagination. - Albert
> Einstein
> > However beautiful the strategy, you should occasionally look at the
> results. - Sir Winston Churchill
> > It's not enough that we do our best; sometimes we have to do what's
> required. - Sir Winston Churchill
> > _______________________________________________
> > 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