next steps... to we create a release candidate and open a 1.1 alpha?
Locked
next steps... to we create a release candidate and open a 1.1 alpha?
 
|
Begin forwarded message:
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: next steps... to we create a release candidate and open a 1.1 alpha?
|
|
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. then we have to review the sunits and see what is realistic to fix and what is 'unknown'. 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. 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. cheers, Mike 2009/10/6 Stéphane Ducasse <[hidden email]>: > > > Begin forwarded message: > > From: [hidden email] > Date: October 6, 2009 8:47:09 PM GMT+02:00 > To: [hidden email] > 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 > [hidden email]. > > > From: stephane ducasse <[hidden email]> > Date: October 6, 2009 8:47:04 PM GMT+02:00 > To: Pharo Development <[hidden email]> > 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: next steps... to we create a release candidate and open a 1.1 alpha?
|
|
On Oct 6, 2009, at 10:36 PM, 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. > then we have to review the sunits and see what is realistic to fix and > what is 'unknown'. 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. yes. > I would like to see a few process things discussed > -how we maintain 1.0 stable branch may be marking some important 1.1 fixes > -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. true. Metacello is nearly ready and I would like to play with it. Moose/Mondrian/Glamour, Glass are using it. I would like to see how it works with first the external packages of core. Because as soon as we really cut we will be in trouble. Stef > > cheers, > Mike > > 2009/10/6 Stéphane Ducasse <[hidden email]>: >> >> >> Begin forwarded message: >> >> From: [hidden email] >> Date: October 6, 2009 8:47:09 PM GMT+02:00 >> To: [hidden email] >> 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 >> [hidden email]. >> >> >> From: stephane ducasse <[hidden email]> >> Date: October 6, 2009 8:47:04 PM GMT+02:00 >> To: Pharo Development <[hidden email]> >> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
On 2009-10-06, at 11:53 AM, Stéphane Ducasse wrote: >> 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). http://code.google.com/p/pharo/issues/detail?id=1258 -- = = = ======================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: next steps... to we create a release candidate and open a 1.1 alpha?
|
|
In reply to this post by Michael Roberts-2
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 <[hidden email]>: >> >> >> Begin forwarded message: >> >> From: [hidden email] >> Date: October 6, 2009 8:47:09 PM GMT+02:00 >> To: [hidden email] >> 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 >> [hidden email]. >> >> >> From: stephane ducasse <[hidden email]> >> Date: October 6, 2009 8:47:04 PM GMT+02:00 >> To: Pharo Development <[hidden email]> >> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: next steps... to we create a release candidate and open a 1.1 alpha?
|
|
apparently there is a bug in senders would be good to investigate that.
>> 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. 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 Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: next steps... to we create a release candidate and open a 1.1 alpha?
|
|
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: next steps... to we create a release candidate and open a 1.1 alpha?
|
|
yes
this is why I'm holding the horses :) now I think that we could have a release candidate soon and do not wait for the sprint and we can iterate. the first things is to really go over the issues list and retag it. stef On Oct 7, 2009, at 9:36 AM, Adrian Lienhard wrote: > > 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: next steps... to we create a release candidate and open a 1.1 alpha?
|
|
In reply to this post by Adrian Lienhard
On Wed, Oct 7, 2009 at 8:19 AM, Adrian Lienhard <[hidden email]> 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |