Bug submission guidelines
Forum rules
and Helpful information
and Helpful information
IMPORTANT: Please click here and read this first, before asking for help
Also, be nice to others! Read the FreeCAD code of conduct!
Also, be nice to others! Read the FreeCAD code of conduct!
Re: Bug submission guidelines
That's the point of the OP; what you consider bugs, aren't necessarily.
Your own statements here show you aren't attempting to learn how the software works, but are attempting to use it assuming your expectations are how it works.
Follow the guidelines, list your issues in the forum, learn how to use the tool...and then, if you can help, fire up a compiler, help edit the wiki, do regression testing. There are plenty of ways to help...that are more helpful than $hit posting.
Your own statements here show you aren't attempting to learn how the software works, but are attempting to use it assuming your expectations are how it works.
Follow the guidelines, list your issues in the forum, learn how to use the tool...and then, if you can help, fire up a compiler, help edit the wiki, do regression testing. There are plenty of ways to help...that are more helpful than $hit posting.
Star Trek II: The Wrath of Khan: Spock: "...His pattern indicates two-dimensional thinking."
Re: Bug submission guidelines
Oh come on. Be nice to others - yes?drmacro wrote: ↑Mon Dec 07, 2020 11:16 am That's the point of the OP; what you consider bugs, aren't necessarily.
Your own statements here show you aren't attempting to learn how the software works, but are attempting to use it assuming your expectations are how it works.
Follow the guidelines, list your issues in the forum, learn how to use the tool...and then, if you can help, fire up a compiler, help edit the wiki, do regression testing. There are plenty of ways to help...that are more helpful than $hit posting.
I actually am attempting to learn how the software works and I am even attempting to work around or look for solutions where the software doesn't work.
If you think I am not attempting to get to know the software (in detail) and if you consider what I do "$hit posting", then a) your interpretation is malevolent b) terribly wrong.
Sure, some things may not be bugs as such, because opinions differ if an "UI nuisance" is to be considered a bug. Rest assured, I'll come to the crashes and lock-ups in due time.
Code: Select all
Traceback (most recent call last):
File "/tmp/.mount_FreeCAOEstSE/usr/Mod/Draft/DraftGui.py", line 1766, in selectplane
FreeCADGui.runCommand("Draft_SelectPlane")
Base.FreeCADError: No such command 'Draft_SelectPlane'
Traceback (most recent call last):
File "/tmp/.mount_FreeCAOEstSE/usr/Mod/Draft/DraftGui.py", line 1766, in selectplane
FreeCADGui.runCommand("Draft_SelectPlane")
Base.FreeCADError: No such command 'Draft_SelectPlane'
Traceback (most recent call last):
File "/tmp/.mount_FreeCAOEstSE/usr/Mod/Draft/DraftGui.py", line 1766, in selectplane
FreeCADGui.runCommand("Draft_SelectPlane")
Base.FreeCADError: No such command 'Draft_SelectPlane'
1.644e-06 <App> Document.cpp(3171): The graph must be a DAG.
<Exception> Tree.cpp(1846): Dependency loop detected for BatteryBlock#Clone
App::DocumentObjectGroup / Group: Links go out of the allowed scope
Start Editing Box
Start Editing Box
626.32 <App> Document.cpp(3171): The graph must be a DAG.
626.384 <App> Document.cpp(3524): BatteryBlock#Clone still touched after recompute
626.384 <App> Document.cpp(3524): BatteryBlock#Body still touched after recompute
App::DocumentObjectGroup / Group: Links go out of the allowed scope
App::DocumentObjectGroup / Group: Links go out of the allowed scope
App::DocumentObjectGroup / Group: Links go out of the allowed scope
<PartDesignGui> Utils.cpp(72): no body found
<PartDesignGui> Utils.cpp(72): no body found
Re: Bug submission guidelines
BIM Bo wrote: ↑Mon Dec 07, 2020 12:10 pm
Oh come on. Be nice to others - yes?
I actually am attempting to learn how the software works and I am even attempting to work around or look for solutions where the software doesn't work.
If you think I am not attempting to get to know the software (in detail) and if you consider what I do "$hit posting", then a) your interpretation is malevolent b) terribly wrong.
I calls-em as I see-em."I have to state that neither yorick, nor Kunda1, nor chrisb et al. are qualified enough to set up a FreeCAD bug reporting process"
![Cool 8-)](./images/smilies/icon_cool.gif)
Star Trek II: The Wrath of Khan: Spock: "...His pattern indicates two-dimensional thinking."
Re: Bug submission guidelines
The 'Wink' emoticon usually signifies that a statement is made in jest. So maybe @drmacro is taking @"BIM Bo" too seriously here?
Re: Bug submission guidelines
ok.. looks like this thread is just totally derailing. @Bim_Bo has created a separate thread where he can discuss his aggro constructive criticism. I'm considering locking this thread or moving the discussion to a separate thread as to not pollute it.
I'm open to lively discussion but confrontational and impatient manners usually shutdown productive exchanges and quickly become ad hominem encounters that are counter-productive to community morale.
I'm open to lively discussion but confrontational and impatient manners usually shutdown productive exchanges and quickly become ad hominem encounters that are counter-productive to community morale.
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Re: Bug submission guidelines
Let me answer here, because you named me explicitely.BIM Bo wrote: ↑Mon Dec 07, 2020 9:28 am With all due respect, I have to state that neither yorick, nor Kunda1, nor chrisb et al. are qualified enough to set up a FreeCAD bug reporting process.
And why is that? It's simple: You guys are way too knowledgeable with FreeCAD, know your ways and therefore probably already intuitively are able to re-route your way around problems that do occur with this extremely complex application. And/or have set up local environments that somehow magically work and are not even able to reproduce many problems occuring with the plebs.
You must not mix the errors you encounter - where you are probably right, that the power users may no longer meet nor see them - with the bug reporting process. And this process has proven to be useful in the special environment of FreeCAD development.
You are right with your remark on the most recent version. I will add it to the first post.
I know that the process could be made more comfortable for users. However, it was designed to be most comfortable for the developers. Keep them free of any report which isn't caused by a program fault but rather due to wrong handling, or whatever. FreeCAD is not really short of people reporting bugs - although a well done bug report is not an easy thing - but we are very short of good programmers. And every minute we can save for them is a good minute, even if we users have to invest much more time than just a few minutes.I am stumbling over FreeCAD bugs at every 3rd click of the mouse, but am extremely reluctant reporting them via the "defined process" which is tiresome and wrong right from the beginning.
We do this out of respect for the developers.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Bug submission guidelines
Thanks chris. Swift and also done by the right person (from my limited observations here, it was you who pointed the people often to 0.18.x -> 0.19.x)
I understand the need for a process that is shielding devs from noise. After 25+ years in the OSS "business" maybe better than you (as in: you, kunda et al.) think.
So if I may contribute a little with that experience - without someone immediately seeing it as "aggro":
current:
1) use newest version
2) Make sure that what you found is a bug
3) 2. Discuss the problem on the forum first! (numbering wrong there)
4) Make sure your bug can be reproduced.
better:
1) use newest version
2) make sure what you observe can be reproduced
3) discuss the problem on forum, including the FreeCAD version
6/7/8 can become the new 4/5/6
Only someone equipped with the means of reproducing "some obseved effect" hitting the forum can induce a community-driven triage of a potential bug.
And only after this triage (with positive outcome) the bug/regression/whatever is ripe for the tracker.
Observe how I wrote "better" - not "best".
![Wink ;)](./images/smilies/icon_e_wink.gif)
Traceback = bug ?
As a user (re)learning FreeCAD, I relatively often encounter a traceback. Does it make sense to report them? Is the goal of FreeCAD developers such that users should not see tracebacks, or is there a "don't really care attitude" towards them?
Background:
Since I am trying out tools and doing "stupid" things, I probably see more tracebacks than experienced users, which (sub)consciously maneuver around them. If it helps, I can try to report these issue, because the more experienced I get, the less tracebacks I will trigger...
Often tracebacks that I encounter are related to violating implicit precondtions of the tools/operations (that are undocumented). It is often not too hard to work around them. I guess, often it would take quite some effort from developers to make a tool more robust and/or check for these preconditions and generate a meaningful error message. So, the benefit of eliminating tracebacks as a general rule may place too much burden on developers without resulting in much benefit.
Since it is quite some effort to report these tracebacks, I would only report them if the developers/community see an actual benefit.
For example, I reported this traceback, which is arguably caused by "stupid" user behavior (garbage in, garbage out). The tool could be made more robust / user friendly, but this would take quite some effort...
https://forum.freecadweb.org/viewtopic.php?f=3&t=54622
Background:
Since I am trying out tools and doing "stupid" things, I probably see more tracebacks than experienced users, which (sub)consciously maneuver around them. If it helps, I can try to report these issue, because the more experienced I get, the less tracebacks I will trigger...
Often tracebacks that I encounter are related to violating implicit precondtions of the tools/operations (that are undocumented). It is often not too hard to work around them. I guess, often it would take quite some effort from developers to make a tool more robust and/or check for these preconditions and generate a meaningful error message. So, the benefit of eliminating tracebacks as a general rule may place too much burden on developers without resulting in much benefit.
Since it is quite some effort to report these tracebacks, I would only report them if the developers/community see an actual benefit.
For example, I reported this traceback, which is arguably caused by "stupid" user behavior (garbage in, garbage out). The tool could be made more robust / user friendly, but this would take quite some effort...
https://forum.freecadweb.org/viewtopic.php?f=3&t=54622
Re: Traceback = bug ?
If the error occurs as a consequenc of doing something stupid, it may be better to document it in the wiki. This takes time too, I know.hmk wrote: ↑Thu Jan 28, 2021 12:16 pm Since I am trying out tools and doing "stupid" things, I probably see more tracebacks than experienced users, which (sub)consciously maneuver around them. If it helps, I can try to report these issue, because the more experienced I get, the less tracebacks I will trigger...
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Traceback = bug ?
I think that is a reasonable suggestion. I just did that for one issue.chrisb wrote: ↑Thu Jan 28, 2021 2:13 pmIf the error occurs as a consequenc of doing something stupid, it may be better to document it in the wiki. This takes time too, I know.hmk wrote: ↑Thu Jan 28, 2021 12:16 pm Since I am trying out tools and doing "stupid" things, I probably see more tracebacks than experienced users, which (sub)consciously maneuver around them. If it helps, I can try to report these issue, because the more experienced I get, the less tracebacks I will trigger...
Reported here:
Traceback: Using 2 lines for Attachment can fail
https://forum.freecadweb.org/viewtopic. ... 14#p473594
Wiki entry:
"If selecting two lines results in a traceback with "points are collinear. Can't make a plane", try selecting three points instead [1]."
https://wiki.freecadweb.org/index.php?t ... did=848699
However, I am not sure if it will survived the scrutiny of Wiki editors...