Home » Modeling » Papyrus » Bug fixing strategy?(Query about which bugs are considered as having priority)
| Bug fixing strategy? [message #1832089] |
Tue, 08 September 2020 12:23  |
Eclipse User |
|
|
|
Dear Papyrus community,
I use the Papyrus software for teaching and find it much useful. I especially appreciate its strict respect for the UML standard. (Some of the docs created for this course are here, if this can be useful to anybody.)
Having investigated a bit the evolution of number of reported and solved bugs, I observe that the development of Papyrus is very active, with an impressive number of bugs being created, and an equally impressive number of bugs being solved, over time (at least, until recently; I didn't check for the last months). However, there are more bugs created than solved, and the total number of open bugs increases over time. These observations lead to two questions, which should not at all be taken as me pointing failures or trying to teach lessons to anyone, but that I ask for my information and for taking decisions about my course.
First, I would like to know how bugs are prioritized. This I ask in order to be able to evaluate, beforehand, how likely I am to receive some attention when I post a bug report. (Because posting clear, reproducible bug reports takes time, and because knowing this helps decide how much effort should be spent to find a workaround, depending on the bug being foreseen to be short lived or there for good.) As a case in point, I posted a bug report and a related forum post, which got no attention, although this is a rather important useability problem, it seems to me, which several students of mine vocally complained about. (I posted other requests for help to the forum which I believe describe bugs and I similarly wondered whether reporting these problems as bugs would help the Papyrus project and myself or whether it would be a pure waste of time.)
Second, and relatedly, I wonder about the general development strategy of Papyrus. The growing number of open bugs suggests that feature addition is prioritized over bug fixing, but this could be misleading (for example, because maybe most of these apparent open bugs could be simply outdated and now invalid). If feature addition is indeed prioritized over bug fixing, do the Papyrus architects intend to reverse this approach at some point in the future? Or is it that some area of Papyrus is considered as having priority over another area (which would then accumulate bugs that nobody intends to fix in the foreseeable future)? This I ask because I would like to know whether continuing to build a UML course on top of Papyrus is a good long term idea. I must say that currently, some useability bugs are quite annoying for my students. Given all the good things about Papyrus, and it being open-source, I do find it an excellent software overall, but still, I wonder about whether I will have to make my students suffer these useability problems forever, and whether I should expect more problems to come, or on the contrary whether there is hope that it will improve over time for the features I need the most (being, roughly speaking, the design of UML diagrams, especially class, sequence, use case diagrams).
Thank you for any pointer.
[Updated on: Tue, 08 September 2020 12:27] by Moderator |
|
|
| Re: Bug fixing strategy? [message #1832170 is a reply to message #1832089] |
Thu, 10 September 2020 13:05  |
| Eclipse User |
|
|
|
Hi
I can't answer for the Papyrus team, just for my motivations with OCL which Papyrus exploits. I suspect that the Papyrus developers struggle with similar not enough time / resources problems that have to be compromised with a desire to help real users.
Bugzilla is my log book / conscience, so I raise many bugs about what I would like to do, many of which are enhancements. Many are actually fixed but not resolved/closed. There are too many OMG+Eclipse, OCL+QVT bugs now for me to do my annual review so any bug analysis statistics will be suspect.
I endeavour to look at all bugs from non-idiot users promptly, however some get lost, so a ping may be prudent.
Dealing with a bug is much easier if the bug reporter makes it attractive: a clear short description of the problem and a simple repro which is/can be converted to a JUnit test case to demonstrate the problem and to stop any recurrence.
However as per https://wiki.eclipse.org/OCL/ForumNetiquette I encourage an exploratory forum message first, since if dealing with a misunderstnading / functional impossibility there is no point wasting time on a repro for a known problem or a clear INVALID/WONTFIX.
Ultimately, if I feel that there is a real user with a real problem, I try hard to find a fix. If a fix seems hard, it may take a few years for a sensible inspiration to strike such as solving the "why can't QVTo do M2T" issue..
Regards
Ed Willink
|
|
| |
| Re: Bug fixing strategy? [message #1832650 is a reply to message #1832295] |
Tue, 22 September 2020 14:22 |
| Eclipse User |
|
|
|
Thank you both for your answers. I fully understand the problem of finite resources.
As indicated in my original post, I have been somewhat disappointed by some lack of attention drawn to some bug reports of mine (for example, this one). But I realize that no process is perfect. I am reassured to know that the developers are willing to pay attention to them.
In the coming days I will try to bump my previous attempts at reports about possible bugs, both in the forum and in the bug tracking tool.
|
|
|
Goto Forum:
Current Time: Mon Jul 28 09:03:00 EDT 2025
Powered by FUDForum. Page generated in 0.04455 seconds |
Home