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
Hi, François,
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
_______________________________________________
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
|