September 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Non-pharo reports in pharo bugtracker...

by Norbert Hartl

On Thu, 2008-09-18 at 12:34 +0200, Adrian Lienhard wrote: > On Sep 18, 2008, at 11:58 , Norbert Hartl wrote: > > > On Thu, 2008-09-18 at 10:27 +0200, Marcus Denker wrote: > >> Hi, > >> > >> There are reports in the pharo tracker that are not solvable because > >> the software the bug > >> is reported about is not part of pharo. > >> > >> I wonder if that makes sense... from the bug-fixing of Squeak, I have > >> found that it's very > >> important to keep the numner of open issues as small as possible. > >> (the > >> nearly 1000 open reports > >> they gatheres when doing 3.10 in Squeak is completely unmanagable, > >> for > >> example). > >> > >> I would suggest to put these reports on a wiki page, instead of the > >> bugstracker. Or report them > >> to the developers of the package. > > > > I put all of those tickets into the tracker. As pharo started it did > > it from 3.9 and not from 3.10. We agreed that we should have a look at > > all changes made in 3.10 to include the important ones. So it was the > > right choice to put all into the pharo tracker. > > yes, I think this made a lot of sense for the issues fixed in 3.10. We > dealt with a couple of them already and now we can decide which ones > we want to fix and which ones to ignore. > Norbert, did you create issues for each change that went into 3.10? > Yes! I worked through the update stream to find every single update. After that I tried to assign them to the right set of mantis reports. For every update number in squeak I opened a ticket and included the information about the mantis tickets as well. I started to change every subject line to include the mantis bug number(s). But this far I have only added this to one third of the tickets. But I'll do the rest in the near future. Norbert > > You are right that it is much more clever to have a look at a problem > > _before_ opening a ticket. But this way you lose an automatic way to > > keep track of the things "already dealt with". That's the same reason > > I included the mantis ticket number in the subject of the pharo > > tickets. > > This way you can easily and fast find the ticket number in the pharo > > tracker. Knowing that an issue from mantis has been dealt with in > > pharo > > has its value, too. > > > > We have to build a convention how to do it. > > I think for the Mantis issues other than the ones that went into 3.10 > we should only create issues in our bugtracker if we explicitly want > to integrate a fix. I.e., we should not automatically create issues > for all issues created in Mantis (would be too much work anyway). Like > this we can keep the number of open reports low as Marcus suggests. > > Adrian > > > > > > > > > Norbert > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 18, 2008

Re: [Pharo-project] Non-pharo reports in pharo bugtracker...

by Adrian Lienhard

On Sep 18, 2008, at 11:58 , Norbert Hartl wrote: > On Thu, 2008-09-18 at 10:27 +0200, Marcus Denker wrote: >> Hi, >> >> There are reports in the pharo tracker that are not solvable because >> the software the bug >> is reported about is not part of pharo. >> >> I wonder if that makes sense... from the bug-fixing of Squeak, I have >> found that it's very >> important to keep the numner of open issues as small as possible. >> (the >> nearly 1000 open reports >> they gatheres when doing 3.10 in Squeak is completely unmanagable, >> for >> example). >> >> I would suggest to put these reports on a wiki page, instead of the >> bugstracker. Or report them >> to the developers of the package. > > I put all of those tickets into the tracker. As pharo started it did > it from 3.9 and not from 3.10. We agreed that we should have a look at > all changes made in 3.10 to include the important ones. So it was the > right choice to put all into the pharo tracker. yes, I think this made a lot of sense for the issues fixed in 3.10. We dealt with a couple of them already and now we can decide which ones we want to fix and which ones to ignore. Norbert, did you create issues for each change that went into 3.10? > You are right that it is much more clever to have a look at a problem > _before_ opening a ticket. But this way you lose an automatic way to > keep track of the things "already dealt with". That's the same reason > I included the mantis ticket number in the subject of the pharo > tickets. > This way you can easily and fast find the ticket number in the pharo > tracker. Knowing that an issue from mantis has been dealt with in > pharo > has its value, too. > > We have to build a convention how to do it. I think for the Mantis issues other than the ones that went into 3.10 we should only create issues in our bugtracker if we explicitly want to integrate a fix. I.e., we should not automatically create issues for all issues created in Mantis (would be too much work anyway). Like this we can keep the number of open reports low as Marcus suggests. Adrian > > > Norbert > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 18, 2008

Re: [Pharo-project] Non-pharo reports in pharo bugtracker...

by Marcus Denker

On 18.09.2008, at 11:58, Norbert Hartl wrote: > On Thu, 2008-09-18 at 10:27 +0200, Marcus Denker wrote: >> Hi, >> >> There are reports in the pharo tracker that are not solvable because >> the software the bug >> is reported about is not part of pharo. >> >> I wonder if that makes sense... from the bug-fixing of Squeak, I have >> found that it's very >> important to keep the numner of open issues as small as possible. >> (the >> nearly 1000 open reports >> they gatheres when doing 3.10 in Squeak is completely unmanagable, >> for >> example). >> >> I would suggest to put these reports on a wiki page, instead of the >> bugstracker. Or report them >> to the developers of the package. > > I put all of those tickets into the tracker. No, these are great! The problem are more reports about OB, AST, RB and things like that... > As pharo started it did > it from 3.9 and not from 3.10. We agreed that we should have a look at > all changes made in 3.10 to include the important ones. So it was the > right choice to put all into the pharo tracker. > > You are right that it is much more clever to have a look at a problem > _before_ opening a ticket. But this way you lose an automatic way to > keep track of the things "already dealt with". That's the same reason > I included the mantis ticket number in the subject of the pharo > tickets. > This way you can easily and fast find the ticket number in the pharo > tracker. Knowing that an issue from mantis has been dealt with in > pharo > has its value, too. > > We have to build a convention how to do it. > -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 18, 2008

[Pharo-project] [ANN] update 10073

by Marcus Denker

update 10073 ------------ - Issue 44: 7094 FixClassCompatibilityForClassVar (M6472) - Issue 86: 7138 TransformationMorph-isSticky - Issue 89: 7141 PrintingArraysWithMetaclasses - Issue 42: 7092 TTCFontDNUfix (M5309) - Issue 176:failing tests in 70072 - delete ParagraphEditor>>#initializeTextEditorMenus (never called, has undeclared) - revert Issue 95: 7149 ChangeHooksTest-tearDown-M6702-rej (broke tests) - MorphExtension now stores properties in SmallIdentityDictionary. - in loadscript: Smalltalk associations do: [:each | each beReadWriteBindingAnnouncing: true] Because it recompiles all methods multiple times, the update takes a while to load. (this is to be able to remove ReadOnlyVariableBinding, which has never seen any use) Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 18, 2008

Re: [Pharo-project] Non-pharo reports in pharo bugtracker...

by Norbert Hartl

On Thu, 2008-09-18 at 10:27 +0200, Marcus Denker wrote: > Hi, > > There are reports in the pharo tracker that are not solvable because > the software the bug > is reported about is not part of pharo. > > I wonder if that makes sense... from the bug-fixing of Squeak, I have > found that it's very > important to keep the numner of open issues as small as possible. (the > nearly 1000 open reports > they gatheres when doing 3.10 in Squeak is completely unmanagable, for > example). > > I would suggest to put these reports on a wiki page, instead of the > bugstracker. Or report them > to the developers of the package. I put all of those tickets into the tracker. As pharo started it did it from 3.9 and not from 3.10. We agreed that we should have a look at all changes made in 3.10 to include the important ones. So it was the right choice to put all into the pharo tracker. You are right that it is much more clever to have a look at a problem _before_ opening a ticket. But this way you lose an automatic way to keep track of the things "already dealt with". That's the same reason I included the mantis ticket number in the subject of the pharo tickets. This way you can easily and fast find the ticket number in the pharo tracker. Knowing that an issue from mantis has been dealt with in pharo has its value, too. We have to build a convention how to do it. Norbert

Sept. 18, 2008

Re: [Pharo-project] Bugs on bugs.squeak.org

by Adrian Lienhard

I agree. I spend a lot of time trying to understand Mantis reports because there typically are duplicates and related reports and fixes proposed are later reported being buggy etc. Adrian On Sep 18, 2008, at 10:43 , Marcus Denker wrote: > Hi, > > bugs.squeak.org is a mess. (and people wonder why I always stress > that doing harvesting was a lot of work... we got > the tracker down to 250 entries with 3.9, if I remember correctly). > > Even for 3.11, they will have some real work ahead to get this in > some form of managable shape. > > Now for Pharo, I don't see that we can benefit from the bug-tracker > at all anymore: there is so much stuff, no > way to do here anything in a strategic, "all covering" way, as we > did for example when moving from BFAV to Mantis. > > So if someone has reported a bug against Squeak, the only way I see > this change ending up in pharo is that the > bug is reported again on the pharo tracker. So if you want something > to be fixed: > > http://code.google.com/p/pharo/issues/list > > (down to 79 open issues, we already fixed and closed 96 reports) > > Marcus > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 18, 2008

Re: [Pharo-project] Non-pharo reports in pharo bugtracker...

by Adrian Lienhard

+1 On Sep 18, 2008, at 10:27 , Marcus Denker wrote: > Hi, > > There are reports in the pharo tracker that are not solvable because > the software the bug > is reported about is not part of pharo. > > I wonder if that makes sense... from the bug-fixing of Squeak, I > have found that it's very > important to keep the numner of open issues as small as possible. > (the nearly 1000 open reports > they gatheres when doing 3.10 in Squeak is completely unmanagable, > for example). > > I would suggest to put these reports on a wiki page, instead of the > bugstracker. Or report them > to the developers of the package. > > Marcus > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 18, 2008

[Pharo-project] Bugs on bugs.squeak.org

by Marcus Denker

Hi, bugs.squeak.org is a mess. (and people wonder why I always stress that doing harvesting was a lot of work... we got the tracker down to 250 entries with 3.9, if I remember correctly). Even for 3.11, they will have some real work ahead to get this in some form of managable shape. Now for Pharo, I don't see that we can benefit from the bug-tracker at all anymore: there is so much stuff, no way to do here anything in a strategic, "all covering" way, as we did for example when moving from BFAV to Mantis. So if someone has reported a bug against Squeak, the only way I see this change ending up in pharo is that the bug is reported again on the pharo tracker. So if you want something to be fixed: http://code.google.com/p/pharo/issues/list (down to 79 open issues, we already fixed and closed 96 reports) Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 18, 2008

[Pharo-project] Non-pharo reports in pharo bugtracker...

by Marcus Denker

Hi, There are reports in the pharo tracker that are not solvable because the software the bug is reported about is not part of pharo. I wonder if that makes sense... from the bug-fixing of Squeak, I have found that it's very important to keep the numner of open issues as small as possible. (the nearly 1000 open reports they gatheres when doing 3.10 in Squeak is completely unmanagable, for example). I would suggest to put these reports on a wiki page, instead of the bugstracker. Or report them to the developers of the package. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 18, 2008

Re: [Pharo-project] Re: Monticello 1.5

by Alexandre Bergel

> p.s. Alexander, please don't edit Installer and break it for everyone > else. Installer is for all squeak images, not just for Pharo. > p.p.s. Please keep sufficient compatibility in Pharo so at least > Installer can get past the initial bootstrap. Ah!! Some methods are deprecated solely in Pharo. Since Installer is calling some deprecated methods in Pharo, some unit tests related to the authoring go red because these test check there is no call do this deprecated method in the image. Probably this test should be moved somethere else. Maybe having an image verifier or something would help to ensure some basic invariant in the image (such as no call to deprecated method). Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 17, 2008