[Pharo-project] Non-pharo reports in pharo bugtracker...
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@iam.unibe.ch http://www.iam.unibe.ch/~denker
+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@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
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@iam.unibe.ch http://www.iam.unibe.ch/~denker
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@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
I agree but we should look at them also from time to time. :) On Sep 18, 2008, at 10:27 AM, 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@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Adrian Lienhard -
Marcus Denker -
Norbert Hartl -
Stéphane Ducasse