Thanks a lot for your feedback on how you are proceeding. It is useful. Remi S. in charge of Papyrus is not here this week. I should see him on Monday, and ask him if he could propose something. So I will come back in one week with I hope some answers. I hope we could at least close bugs resolved in 2010… J Thanks again. Francois De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Ed Willink Envoyé : lundi 25 janvier 2016 17:44 À : mdt-papyrus.dev@xxxxxxxxxxx Objet : Re: [mdt-papyrus.dev] closing old bugs Hi
For OCL (and QVTd) I do a bulk close at the time of the annual release review of all bugs that have been RESOLVED for over a year. This allows a year in which the not-formally verified by can be sensibly reopened. I generally only close earlier if some particularly irritating reporter is determined to argue about a WONTFIX. In this way a bug is verified and closed through the absence of reopening problems.
Regards
Ed Willink On 25/01/2016 14:45, Christian W. Damus wrote: Hi, François, (sorry for the spam; I hit the send button by mistake, as you can tell) Sure, it wouldn’t be difficult to bulk close verified bugs at the end of a release, provided those bugs were targeting that release, which is easy enough to filter in the bugzilla target field if it is properly filled, which it almost never is in our bugs. But, again, who is the QA for Papyrus that does the verification of bugs? Do we have a QA team dedicated to testing the Papyrus project in general and bugzilla items specifically? I don’t mind a more rigorous process, because it could help to focus our attention as developers to the details, but I’m not seeing yet where the resources are to support it and what the value is to our goals. Thanks, Christian Sure, it wouldn’t be difficult to bulk close verified bugs at the end of a release (provided those bugs were targeting that release, which is easy enough to filter in the ). On 25 January, 2016 at 09:30:33, LE FEVRE FRANCOIS (francois.le-fevre@xxxxxx) wrote: Hi Christian, Thanks for your feedback, you are asking the right questions. I am really answering directly to your question. Nevertheless here some additional elements To my point of view as we are migrating to new major version (thanks a lot for you email on the API), we could also take time to improve our Bugzilla workflow. To my point of view, I would like we follow the Eclipse convention. The QA could be in charge to switch from fixed to verified the bug. I have found in the Eclipse documentation that “When the project does a major release, the VERIFIED bugs are changed to CLOSED.” Francois [1]: https://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use Hi, When I run bugzilla reports, I lump all resolved, verified, and closed bugs together as logically “completed” because (correct me if I’m wrong) Papyrus doesn’t have a formal QA process in which a QA team tests resolved bugs to move them into verified state (or reopen them [1]), after which the original reporter can close them if in agreement with the verification results. Some projects in the Eclipse Modeling family actually use the verified state to indicate that fixes for bugs that were in the resolved state have actually been published to the update site. This transition was at one time automated by the builds. So, I guess my question is what precisely do we think would be the value (for Papyrus) of following bugs through a process beyond the resolved state? What meaning do we want to assign to verified (if any) and closed states to distinguish them from resolved? And who is responsible for transitions through these states? Cheers, Christian
[1]: Note that the very transition from resolved -> reopened implies a “closedness” of the resolved state.
_______________________________________________ mdt-papyrus.dev mailing list mdt-papyrus.dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
|