Hi P.O., the problem with this is that when an error occurs during testing it is not immediately clear whether this indicates a bug in the interpreter or the test case. So the onus should be on the person servicing the bug to categorize it as an interpreter, test case or platform bug - one could imaging that on a specific platform an otherwise correct implementation triggers an error in a system service - when a workaround is needed or possible then would be the next decision. So this practice needs change.
best regards, René. > On 18 Sep 2024, at 15:41, P.O. Jonsson <oor...@jonases.se> wrote: > > Hi again Josep Maria, > > I did not create the current practice, in fact I was just as upset as you and > others the first time my bug report was closed as „invalid“ :-( > > Having learned a bit more about the release procedure I realized that there > was reason for this stricter definition of „Bugs“; when preparing for the > release one want to list all improvements and bugs fixed in the > Interpreter/language, hence any bugs in a test case are not really relevant > at that point and only create additional work. > > Rather than trying to tweak the wordings I would be in favor of creating a > new category of „bugs“ in the bug tracker that could involve anything that is > not a bug in the Interpreter itself. When I look at Sourcforge there is a > category „Test Cases“ under Tickets that is sparingly used. Would it not be > possible to agree to file/move all bugreuports for test cases to that > category? > > Hälsningar/Regards/Grüsse, > P.O. Jonsson > oor...@jonases.se > > > > >> Am 18.09.2024 um 10:46 schrieb Josep Maria Blasco >> <jose.maria.bla...@gmail.com>: >> >> Hi P.O., >> >> Well, not everybody seems to appreciate the "invalid" treatment, see >> https://sourceforge.net/p/oorexx/bugs/1976/?limit=25#2ef9 as a recent >> example. >> >> To state the obvious, when somebody spends her time detecting and >> documenting a bug, she's working for free for the project, she's giving to >> the community. >> >> For example, somebody who detects a malfunction in the test suite has to: a) >> know that the test suite exists; b) have the test suite installed; c) have >> run the test suite (which takes some time), and d) document the said >> malfunction. >> >> All of this requires a non-inconsiderable skill set. "Invalid" ---says >> Google, following Oxford--- means "not legally recognized because it >> contravenes a regulation or law" (as a noun, it means "a person made weak or >> disabled by illness or injury"). >> >> To summarize, we have a certain user, let's call her A. A has a considerable >> skillset. A has donated her free time and resources to the community to >> report what she considers to be a bug. This bug happens to refer to the test >> suite. Then A is told that her contribution is not legally recognized >> "because it contravenes a regulation or law". >> >> To me, this looks like a fantastic recipe to alienate A from the community. >> Specially when, as far as I know, there is no established protocol to report >> bugs in the test suite. >> >> Words are not meaningless identifiers. They are important, because they >> happen to have meanings. Meanings are dangerous: they can please and hurt, >> they can bind and unbind. When used wrongly, they can alienate very valuable >> people. People we need, because we are not precisely a huge community. >> >> My impression is that new, different names should be chosen, with some >> urgency. Names that do not have these ugly connotations: "Invalid", for >> example, is a toxic word. And the work that somebody has done for the >> community should always be acknowledged and appreciated. When I work on a >> project, the results R of my work may be wrong, but the fact F that I have >> worked can never be wrong. "Invalid" might apply to R, but never to F. One >> has to be careful. >> >> Josep Maria >> >> Missatge de ooRexx <oor...@jonases.se <mailto:oor...@jonases.se>> del dia >> dt., 17 de set. 2024 a les 23:03: >>> Hi Joseph Maria, >>> >>> If the reason for the behavior emanates from a change to the code it is a >>> bug and should be reported in the bug tracker, as you did. >>> >>> Bugs in the test cases are not considered bugs and will be closed as >>> “invalid” by the developers, only bugs in the interpreter are considered >>> bugs. Hence “Feature”. One can report them to this list if the developers >>> did not already spot them. >>> >>> Hälsningar/Regards/Grüsse, >>> ooRexx >>> oor...@jonases.se >>> <mailto:oor...@jonases.se>_______________________________________________ >> Oorexx-devel mailing list >> Oorexx-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
