[Pharo-project] Toyota like process for 1.1
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
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 <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
+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 <stephane.ducasse@inria.fr> 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 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
Em 15/01/2010 19:48, Stéphane Ducasse <stephane.ducasse@inria.fr> 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
ok guys run the tests and send fixes :) On Jan 16, 2010, at 3:11 AM, csrabak@bol.com.br wrote:
Em 15/01/2010 19:48, Stéphane Ducasse <stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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. Levente
^ #(testIfPatchIsMinimal testIfSequence4 testIfSequence6)
more to come
Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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 < stephane.ducasse@inria.fr> wrote:
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (6)
-
Adrian Lienhard -
csrabak＠bol.com.br -
Levente Uzonyi -
Mariano Martinez Peck -
Michael Roberts -
Stéphane Ducasse