Bugzilla – Full Text Bug Listing
| Summary: | [Profile Applications] Externalize profile applications not working / incomplete | ||
|---|---|---|---|
| Product: | [Modeling] Papyrus | Reporter: | Toni Siljamäki <toni.siljamaki> |
| Component: | Core | Assignee: | Christian Damus <give.a.damus> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | give.a.damus, papyrus-bugs, ronan.barrett |
| Version: | 1.1.0 | ||
| Target Milestone: | M5 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | bbi deploy | ||
| Bug Depends on: | 431953, 431957, 436666 | ||
| Bug Blocks: | 399859, 438966 | ||
|
Description
Toni Siljamäki
Silly me proposing to schedule this for Luna SR2 ... Of course, this is a new feature in Mars! Anyways, the bug in this case is exactly and only the same left-over dangling/orphaned stereotype instances problem that I am tackling in 436666. The actual externalization of the profile is working correctly: the profile application and all of its legitimate stereotype applications are moved into the separate UML resource. The dangling stereotype instances are not actually stereotype applications because they do not extend any UML elements, so they are not owned by the profile application and they do not move with it. When the fix for the missing Stereotype Repair scenario is ported forward to master, it will take care of these objects. *** This bug has been marked as a duplicate of bug 436666 *** Hi Christian. Sorry, but this bug can be closed only after it has been verified to work, requiring Bug 431953, Bug 431957 and Bug 436666 to be fixed and verified. The PW protected attachment in Bug 436666 can be used for testing. https://bugs.eclipse.org/bugs/attachment.cgi?id=250095 /Toni And... Bug 431953, Bug 431957 and Bug 436666 were reported before Papyrus 1.0, to be fixed for Luna SR2 and migrated to the Mars track. This bug is reported for a new profile applications feature provided in Mars. Resolving the bug again because bug 436666 that it duplicates is resolved and bug 431953 is also resolved. It is ready for verification in the latest Mars nightly build. (In reply to Toni Siljamäki from comment #2) > > Sorry, but this bug can be closed only after it has been verified to work, > requiring Bug 431953, Bug 431957 and Bug 436666 to be fixed and verified. No. The usual bugzilla lifecycle (as described in the Eclipse Wiki [1]) follows a progression like so: 1. Developer resolves bug as * fixed, if and when a fix is pushed to git, or * duplicate, if it is the same problem as reported in another bugzilla, or * wontfix, if it is a problem that cannot or needs not be fixed, or * worksforme, if it would be a problem but the software seems to work, or * invalid, if the behaviour described is not a problem anyways The important thing is that the status change is the QA team's cue that the bugzilla is or will soon be ready for verification. 2. Tester verifies bug by: * installing and testing some build that publishes the fix, if bug resolution is fixed * acknowledging the duplicate/wontfix/worksforme/invalid resolution otherwise 3. If verification fails at step 2, then the tester reopens the bug. Otherwise, the tester moves the bug to verified state (resolution unchanged) 4. If the bug is in verified state, then the original reporter or some representative/delegate thereof may signal satisfaction with the resolution and verification by closing the bug. But this state is so rarely used in Eclipse projects that there was a brief discussion a few years ago about removing the closed state from the database Note, in particular, that nowhere in this process does the developer fixing a bug close it. Also, the state transitions are important signals for moving a bugzilla through the process. We cannot wait for somebody to verify that a bug is fixed before transitioning it to the resolved state. How would anyone even know to verify it? The transition to resolved state is the signal that it is ready for verification. If the Papyrus project is using a markedly different process than what I sketched above, then I apologize for not following it and I will adopt it. [1] https://wiki.eclipse.org/Development_Resources/HOWTO/Bugzilla_Use > If the Papyrus project is using a markedly different process than what I sketched above, then I apologize for not following it and I will adopt it.
We don't have a custom process. The only thing which changes a little bit from the standard Eclipse/Bugzilla Process is the "Assigned to Papyrus-Inbox" which indicates that a bug has been confirmed (And it's not exactly specific to Papyrus; although I don't remember where I read this was an alternate way to sort confirmed bugs)
Great Christian! Works now after the cleaning out of "zombies" (garbage) described in Bug 431953 Comment 7 has been fixed. Just verified it on latest Mars nightly. |