Toyota like process for 1.1
Locked
 
|
Hi guys
may be I'm wrong but I have the impression that fixing tests as soon as they are broken in the Unstable branch could be better. Now doing that may stall our energy. So what do you think? May be an alternate process is to make progress and to do green test session from time to time. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Toyota like process for 1.1
|
|
i would prefer we fix them as soon as possible. Look at the effort at
the end of 1.0. It can be really sad to try and fix all the tests at once. Having a green baseline is much easier to manage. Even if we can't fix the bugs immediately, we should at least discuss them and comment them on the tracker. Then at least we can easily discuss what code has just gone into the image. Otherwise it is somewhat of an archeology exercice going through 100s of old updates. this will of course be easier with the continuous integration work. Now of course, some bugs are *really* hard. e.g decompiler bugs. Debugger bugs. These would be great to attack with sessions & sprints. cheers, Mike On Fri, Jan 15, 2010 at 9:48 PM, Stéphane Ducasse <[hidden email]> wrote: > Hi guys > > may be I'm wrong but I have the impression that fixing tests as soon as they are broken > in the Unstable branch could be better. Now doing that may stall our energy. > So what do you think? > May be an alternate process is to make progress and to do green test session from time to time. > > 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: Toyota like process for 1.1
|
|
+1
On Jan 15, 2010, at 22:55 , Michael Roberts wrote: > i would prefer we fix them as soon as possible. Look at the effort at > the end of 1.0. It can be really sad to try and fix all the tests at > once. Having a green baseline is much easier to manage. Even if we > can't fix the bugs immediately, we should at least discuss them and > comment them on the tracker. Then at least we can easily discuss what > code has just gone into the image. Otherwise it is somewhat of an > archeology exercice going through 100s of old updates. this will of > course be easier with the continuous integration work. > > Now of course, some bugs are *really* hard. e.g decompiler bugs. > Debugger bugs. These would be great to attack with sessions & > sprints. > > cheers, > Mike > > On Fri, Jan 15, 2010 at 9:48 PM, Stéphane Ducasse > <[hidden email]> wrote: >> Hi guys >> >> may be I'm wrong but I have the impression that fixing tests as soon as they are broken >> in the Unstable branch could be better. Now doing that may stall our energy. >> So what do you think? >> May be an alternate process is to make progress and to do green test session from time to time. >> >> 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
Em 15/01/2010 19:48, Stéphane Ducasse <[hidden email]> escreveu:
> Hi guys > may be I'm wrong but I have the impression that fixing tests as > soon as they are broken in the Unstable branch could be better. Now > doing that may stall our energy. I think it would reduce the [apparent] speed of new functionality, but not "stall our energy" which I surmise is to have a cool but as bug free as possible Pharo Smalltalk. > So what do you think? Doing this way, as some red tests get on the pile without resolution we can get more attention to the issues. It's a mixture of the Toyota process with a Kanban for squashing the bugs! > May be an alternate process is to make progress and to do green > test session from time to time. Except if we could be _so_ assertive about the non importance of some of the non passing tests, I think the time to time should be as short as today! OK, as a concession could we try to have these gates about every two weeks? -- Cesar Rabak _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Toyota like process for 1.1
|
|
ok guys run the tests and send fixes :)
On Jan 16, 2010, at 3:11 AM, [hidden email] wrote: > Em 15/01/2010 19:48, Stéphane Ducasse <[hidden email]> escreveu: > >> Hi guys >> may be I'm wrong but I have the impression that fixing tests as >> soon as they are broken in the Unstable branch could be better. Now >> doing that may stall our energy. > > I think it would reduce the [apparent] speed of new functionality, but > not "stall our energy" which I surmise is to have a cool but as bug > free as possible Pharo Smalltalk. > >> So what do you think? > > Doing this way, as some red tests get on the pile without resolution > we can get more attention to the issues. > > It's a mixture of the Toyota process with a Kanban for squashing the > bugs! > >> May be an alternate process is to make progress and to do green >> test session from time to time. > > Except if we could be _so_ assertive about the non importance of some > of the non passing tests, I think the time to time should be as short > as today! > > OK, as a concession could we try to have these gates about every two > weeks? > > -- > Cesar Rabak > > _______________________________________________ > 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: Toyota like process for 1.1
|
|
issue 1827 soon in 11162
Fixed - testComplIsSelfEvaluating removed the compiledMethod from the array since the store on probably changed and compiled methods are not self evaluating SimpleSwicthMorph>>testName removed (no external name anymore) AuthorTest>>testDeprecation removed (since the methods are not there anymore) Changed last line since a test should not rely on something on the harddisc testIsFontAvailable "self debug: #testIsFontAvailable" (Locale isoLanguage: 'ja') languageEnvironment removeFonts. self assert: (Locale isoLanguage: 'en') languageEnvironment isFontAvailable. "Next test should fail after installing Japanese font" self assert: (Locale isoLanguage: 'ja') languageEnvironment isFontAvailable not. (Locale isoLanguage: 'ja') languageEnvironment installFont. self assert: (Locale isoLanguage: 'ja') languageEnvironment isFontAvailable not TextDiffBuilderTest>>expectedFailures "these tests are for the new TextDiffBuilder that should be integrated from Squeak-trunk" ^ #(testIfPatchIsMinimal testIfSequence4 testIfSequence6) more to come Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Toyota like process for 1.1
|
|
On Sat, 16 Jan 2010, Stéphane Ducasse wrote:
> issue 1827 soon in 11162 > > Fixed > - testComplIsSelfEvaluating removed the compiledMethod from the array since the store on probably changed and > compiled methods are not self evaluating > > SimpleSwicthMorph>>testName removed (no external name anymore) > > AuthorTest>>testDeprecation removed (since the methods are not there anymore) > > > Changed last line since a test should not rely on something on the harddisc > > testIsFontAvailable > "self debug: #testIsFontAvailable" > (Locale isoLanguage: 'ja') languageEnvironment removeFonts. > self assert: (Locale isoLanguage: 'en') languageEnvironment isFontAvailable. > "Next test should fail after installing Japanese font" > self assert: (Locale isoLanguage: 'ja') languageEnvironment isFontAvailable not. > (Locale isoLanguage: 'ja') languageEnvironment installFont. > self assert: (Locale isoLanguage: 'ja') languageEnvironment isFontAvailable not > > > TextDiffBuilderTest>>expectedFailures > "these tests are for the new TextDiffBuilder that should be integrated from Squeak-trunk" the new TextDiffBuilder should be easy. Levente > > ^ #(testIfPatchIsMinimal testIfSequence4 testIfSequence6) > > > more to come > > 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: Toyota like process for 1.1
|
|
On Jan 16, 2010, at 11:33 AM, Levente Uzonyi wrote: > On Sat, 16 Jan 2010, Stéphane Ducasse wrote: > >> issue 1827 soon in 11162 >> >> Fixed >> - testComplIsSelfEvaluating removed the compiledMethod from the array since the store on probably changed and >> compiled methods are not self evaluating >> >> SimpleSwicthMorph>>testName removed (no external name anymore) >> >> AuthorTest>>testDeprecation removed (since the methods are not there anymore) >> >> >> Changed last line since a test should not rely on something on the harddisc >> >> testIsFontAvailable >> "self debug: #testIsFontAvailable" >> (Locale isoLanguage: 'ja') languageEnvironment removeFonts. >> self assert: (Locale isoLanguage: 'en') languageEnvironment isFontAvailable. >> "Next test should fail after installing Japanese font" >> self assert: (Locale isoLanguage: 'ja') languageEnvironment isFontAvailable not. >> (Locale isoLanguage: 'ja') languageEnvironment installFont. >> self assert: (Locale isoLanguage: 'ja') languageEnvironment isFontAvailable not >> >> >> TextDiffBuilderTest>>expectedFailures >> "these tests are for the new TextDiffBuilder that should be integrated from Squeak-trunk" > > To be exact, these are broken with the current implementation. Integrating the new TextDiffBuilder should be easy. yeap! Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Toyota like process for 1.1
|
|
My only comment is that I see continuous integration for 1.1 but this has absolutely no sense if we don't fix the tests as soon as they happen. So, or we do that, or we remove Continuous Integration for the milestone :)
cheers Mariano On Sat, Jan 16, 2010 at 11:38 AM, Stéphane Ducasse <[hidden email]> wrote:
_______________________________________________ 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 |