Hi Mike, On Oct 6, 2009, at 22:36 , Michael Roberts wrote:

i would mark the decompiler tests as 1.1. I would also mark the debugger highlight bug as 1.1. I think these are going to take time.

I agree. Do you want to update the tracker?

then we have to review the sunits and see what is realistic to fix and what is 'unknown'.

I noticed that after the recent closure fixes there are a couple of new failures and errors. For instance AuthorTest>>#testDeprecatedSendsRemoved (I guess the reported senders of a selector changed with some closure changes). see http://code.google.com/p/pharo/wiki/BaselineTestResults

For everything we don't understand mark and comment #expectedFailures. what would be really helpful would be any writeup on the issue tracker for analysis on sunit failures if folks have time.

ok. I think we should seriously check the remaining errors/failures before marking them.

I would like to see a few process things discussed -how we maintain 1.0 stable branch -how we maintain 1.1 alpha. i.e do we try out some other package meta system? that could be worth some hacking at the start of the cycle to see the mechanism. It is not something to mess around with when we get near beta.

We can use the current update stream as the 1.0 stable branch and create a new stream, maybe based on another mechanism, for 1.1 alpha. I think we should get all tests green and the remaining issues fixed before declaring a release candidate. There are also 3 OmniBrowser issues in the list and I wonder whether somebody plans to fix them? If we concentrate on these tasks in the next days and during the sprint, I am sure we are able to get a reasonable RC1 within the next 14 days. Cheers, Adrian

cheers, Mike

2009/10/6 Stéphane Ducasse <stephane.ducasse@inria.fr>:

...

Begin forwarded message:

From: pharo-project-owner@lists.gforge.inria.fr Date: October 6, 2009 8:47:09 PM GMT+02:00 To: stephane.ducasse@free.fr Subject: next steps... to we create a release candidate and open a 1.1 alpha?

You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at pharo-project-owner@lists.gforge.inria.fr.

From: stephane ducasse <stephane.ducasse@free.fr> Date: October 6, 2009 8:47:04 PM GMT+02:00 To: Pharo Development <Pharo-project@lists.gforge.inria.fr> Subject: next steps... to we create a release candidate and open a 1.1 alpha?

Hi guys

I would like to know what are the important bugs or fixes to be integrated that cannot wait for 1.1. And it would be nice to tag a release candidate (really soon now).

We get a pharo sprint the 17 and I would like to get a lot of the pending fixes integrated since then and that people can kill some problems on 1.1

Stef

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Oct 7, 2009, at 09:23 , Stéphane Ducasse wrote: [...]

ok but I would really like to integrate all the cool fixes of nicolas. so this is why I was thinking about 1.1 alpha. too

Then we could open a new stream already now. We just have to take care that we don't forget to finish 1.0! ;) We also need to think about the process: if there is a fix we will have to decide whether it is critical and hence also needs to go into the maintenance stream of 1.0. So one fix suddenly needs to be integrated twice... Adrian

Stef

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Wed, Oct 7, 2009 at 8:19 AM, Adrian Lienhard <adi@netstyle.ch> wrote:

Hi Mike,

On Oct 6, 2009, at 22:36 , Michael Roberts wrote:

...

i would mark [...]

I agree. Do you want to update the tracker?

i've updated the debugger highlight. i'll mark the decompiler tests later in the week. they don't yet have a # i think.

I noticed that after the recent closure fixes there are a couple of new failures and errors. For instance AuthorTest>>#testDeprecatedSendsRemoved (I guess the reported senders of a selector changed with some closure changes).

see http://code.google.com/p/pharo/wiki/BaselineTestResults

yes, i saw and the recent thread. one of the things that is difficult with merging eliot's changes is knowing what is intentional or not between the pharo base and the change. it would be good if we could comment or annotate key 'pharo fixes' (to the compiler & machinery) so that it is obvious in a diff browser. if we genuinely think we have a fix then we can feed it back to eliot. we are likely to want to take compiler changes for sometime, presumably all the way to the JIT.

ok. I think we should seriously check the remaining errors/failures before marking them.

yes i would like a serious review but of course it requires folks to do it. now you're back from your holiday ;-)... the other thing i thought was a good candidate for 1.0 was the latest MC patch stef posted. those semantics are vital, and look an increment on previous changes we had taken to load the compiler. i just wanted to test it before recommending. cheers, Mike