Torsten for the recategorisation can you use the categoriser? Because I improved it a bit and like that we will get the same convention everywhere and not yours and mine differently managed. For example, initialize - release does not exist.
In the automaticRecategoriser package I published a while ago (not the one in the image) you can find an analyser for a given selector. It shows the common usage and the outliers. There is also a method to automatically fix outliers and it handles * MCHttpRepository location: 'http://smalltalkhub.com/mc/StephaneDucasse/AutomaticMethodCategorizer/main' user: '' password: '' Tell me what you think. Stef On Sun, Sep 10, 2017 at 7:16 PM, Torsten Bergmann <asta...@gmx.de> wrote: > Hi, > > to explain: > > we have lots of uncategorized methods and non commented classes. For some > time we had to accept this ugly situation that old and legacy code. For Pharo > 4 and 5 > I invested a lot of time to clean this up right before the release date. But > with 6.0 such a round was not done and in 6.0 and 6.1 it looks like a mess > again. > > Why? Because we introduced new features and code and never defined a certain > level of quality for code we include. But our initial goal with Pharo was > (and > hopefully still is) to cleanup things up and do better than before. > > So we should not forget about quality and so I spend some time last on this > again - now for Pharo 7. For instance #setUp and #tearDown in SUnit should be > in "running" as it was defined for TestCase subclasses. Also #hash and #= > should be in "comparing" protocol. Also the goal is coming back to an image > where > all methods are categorized and where all classes have a comment. > > But for me it absolutely makes no sense to reinvest the time over and over > into the same cleanups while others can easily make a mess again. > > So we should RAISE THE QUALITY BAR to ensure that we keep with such a quality > level. Especially as see each build to be a release and the real release once > a year often is more or less a snapshot. > > So I also wrote a new test called "ProperMethodCategorizationTest" and while > cleaning up #hash it was green. So > ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol > showed no problem and I committed and have sent a Pull request. This looked > like any other new contribution. > > What I did not knew at this time was that Iceberg code is not in git > repository - but managed externally. So while I fixed the code in my image > with wrongly categorized hash > method in an Iceberg class (IceSemanticVersion) the system did not show me > that this change did not move to GitHub. > > Now I know - but this has such bad side effect when we do changes and these > packages are in the image - but not managed with the pharo repository. > > Long story short: one can not fix this situation with a simple PR as Iceberg > code is not under the "pharo" repo umbrella. > > I already submitted a PR for Iceberg > > https://github.com/pharo-vcs/iceberg/pull/458 > > and Esteban included that already - but only in Iceberg. We now need to > include Iceberg. > > Several lessons learned from my side: > - doing changes and having green tests in the image is not enough > - also doing a commit and PR does not mean all of your changes are on GitHub > - it is not a good situation when a part of the image code is managed with > "pharo" repository and another part is managed externally - I see this as a > problem of > the new process we should discuss and address > - we should nonetheless try to define tests to show the edges where we can > improve and cleanup (without a test it would not have been noticed that while > I did my best > to cleanup the current way of managing Iceberg prevented my fix to be > into the image in the first place) > > I dont know what need to be done to include a new iceberg version or when > this will happen from Estebans side - but as soon as it is done this test > should be green again. > > Thanks > T. > > > Gesendet: Sonntag, 10. September 2017 um 18:24 Uhr > Von: "Stephane Ducasse" <stepharo.s...@gmail.com> > An: "Pharo Development List" <pharo-dev@lists.pharo.org> > Betreff: Re: [Pharo-dev] argh, tests are failing! > > Yes we know but have no idea how to recategorise Iceberg protocols > > On Sun, Sep 10, 2017 at 1:03 PM, Pavel Krivanek > <pavel.kriva...@gmail.com[mailto:pavel.kriva...@gmail.com]> wrote: > > Of course you are right, the Integrators should really take care on it. > > Before it were only common random failures but the main problem is with this > PR: > https://github.com/pharo-project/pharo/pull/264[https://github.com/pharo-project/pharo/pull/264] > > The new test testHashMethodNeedsToBeInComparingProtocol fails on > classIceSemanticVersion > > -- Pavel > > > 2017-09-10 10:13 GMT+02:00 Guillermo Polito > <guillermopol...@gmail.com[mailto:guillermopol...@gmail.com]>: > Hi all, > > Since a couple of builds we have consistently failing the following tests: > > > GT.EventRecorder.Tests.Core.GTEventRecorderTest.testDeliverNow2[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/GT.EventRecorder.Tests.Core/GTEventRecorderTest/testDeliverNow2/]GT.EventRecorder.Tests.Core.GTEventRecorderTest.testNotDeliveredDataShouldBeResent[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/GT.EventRecorder.Tests.Core/GTEventRecorderTest/testNotDeliveredDataShouldBeResent/]Kernel.Tests.Processes.MutexTest.testFailedCriticalSectionShouldUnblockWaitingOne[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/Kernel.Tests.Processes/MutexTest/testFailedCriticalSectionShouldUnblockWaitingOne/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_2/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_3/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_4/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_5/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_6/]ReleaseTests.Categorization.ProperMethodCategorizationTest.testHashMethodNeedsToBeInComparingProtocol[https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/110/testReport/junit/ReleaseTests.Categorization/ProperMethodCategorizationTest/testHashMethodNeedsToBeInComparingProtocol_7/] > > > Green builds are the only hard metric to say if the build is healthy or not. > > - We should not integrate anything until the build is green again... > > Also, we spent with Pablo a lot of time to have a green build in all > platforms... I'd like to spend my time in other fun stuff than the CI :/ > > -- > > > Guille Polito > > Research Engineer > French National Center for Scientific Research - > http://www.cnrs.fr[http://www.cnrs.fr] > > > Web: http://guillep.github.io[http://guillep.github.io] > Phone: +33 06 52 70 66 13 >
