Home » Modeling » Papyrus » Bug fixing strategy?(Query about which bugs are considered as having priority)
| Bug fixing strategy? [message #1832089] |
Tue, 08 September 2020 16:23  |
 Olivier Cailloux
Messages: 43
Registered: July 2009 |
Member |
|
|
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 16:27] Report message to a moderator |
|
|
| Re: Bug fixing strategy? [message #1832170 is a reply to message #1832089] |
Thu, 10 September 2020 17:05  |
Ed Willink
Messages: 7655
Registered: July 2009 |
Senior Member |
|
|
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 #1832295 is a reply to message #1832170] |
Tue, 15 September 2020 14:48 |
|
Hello Olivier,
Bug management for the Papyrus team is indeed a complex task:
- Anyone: users and developers can add bugs. This is practical because it allows the community to make the tool more robust and to be transparent about the development in progress.
- Nevertheless this causes a large number of bugs to follow. This task takes a lot of resources. On average it takes us 15 minutes to understand a bug. Read the instructions and reproduce it on the tool. Some bugs are easy to reproduce thanks to the readable instructions and others are much more difficult to reproduce: need to recreate the bug conditions.
Resources are unfortunately not infinite and we live as a research organization based on projects or contracts.
Our contracts and our projects therefore strongly influence the resolution of our bugs or tasks. This is why you can see that we are more focused on one aspect of Papyrus more than another.
I would also like to point out that the contracts are not only MDE innovation but also bug fixes.
Our current goal for papyrus is to improve its stability, and to create and reorganize its documentation.
We also want to split the monolithic code base as much as possible/necessary to compile it in parts and to be able in the future for more modularity.
We still have a lot of work to do and all help is welcome as bug reports for example.
Papyrus team
|
|
| |
Goto Forum:
Current Time: Thu Apr 25 23:02:27 GMT 2024
Powered by FUDForum. Page generated in 0.03555 seconds |
] 
Search
Help
Register
Login
Home
