Hi,
I have to agree to your statements, because it the the current state.
Currently it's the best to check each 'verified' issue and close it.
I know 3 scenarios where a problem can occur in Master only :
1. code contributions aren't checked-in in the source tree and the
tested build was done on a local copy
=> error couldn't be found in the tested CWS
2. code contribution in one CWS overwrites code contribution in another
CWS (often code-conflicts from different CWS aren't solved correctly)
=> the error is introduced in Master only, CWSes was correct
3. dependencies from one CWS (e.g. in SVX) shredder changes in another
CWS (couldn't be synced, because both are ready for integration at
the same time)
=> this error can be found on Master only
Isn't it possible to avoid such problems before integration?
to 1 : Doesn't exists any tooling which check, if all your changes are
checked-in to the source tree? Or let's check a build from a CWS
when it is done by a build bot, which gets the sources from the
repository.
to 2 : The best is when CWS with code-conflicts is set back to owner for
resync and fixing the code conflicts. Then this CWS will take
another day, but the conflicts aren't solved by Release Engineers
or by a developer under time pressure. If the CWS has to checked
again by QA representative has to be decided as the case arises.
to 3 : I do not have an easy solution.
I heard that 3. isn't the case very often. Most of the problems came up
because of case 2 and some by case 1. So why not invest in case 1. and
2. more time. I think the effort to invest in verifying every 'verified'
issue is higher than working on solutions to avoid the problems before
integration.
But then we are at the same discussion as some days ago. What can be
done by the QA project and what is the job of a Quality Management?
Thorsten
PS.: And back to the question by Drew. I do not know how to get the
data you wanted, too. I played a little bit with some queries,
but the results weren't what I wanted :-(
Joost Andrae wrote:
Hi Drew,
Recently it was suggested on the list, in a different discussion
thread, that having volunteer qa members close issues, by testing the
issue with a dev. snapshot build, after the internal qa staff had
marked an issue verified is not the best use of their time.
I tend to agree with the idea - even if it does rub against my 'sense
of process' just a bit.
verification of issues within a master build that integrates code where
the bugfix or feature has been worked on is very helpful as you verify
the integration work of code integrators (called release engineers). In
the past not every integration worked as well as expected thus doing
this work is from my point of view helpful.
To do this correctly it's useful to look at this information within the
context of a child workspace (CWS). The EIS application is very useful
to look at one CWS http://eis.services.openoffice.org
(Childworkspace/Browse/per MWS/
eg. OOO310/m15/ooo311gsl03
So, was wondering - is there a report in place that shows the
percentage of re-opened Issues?
You can query for re-opened issues by using the query interface
http://qa.openoffice.org/issues/query.cgi
eg. all re-opened issues with target 3.1.1
http://qa.openoffice.org/issues/buglist.cgi?issue_type=DEFECT&issue_type=ENHANCEMENT&issue_type=FEATURE&issue_type=TASK&issue_type=PATCH&issue_status=REOPENED&target_milestone=OOo+3.1.1&email1=&emailtype1=exact&emailassigned_to1=1&email2=&emailtype2=exact&emailreporter2=1&issueidtype=include&issue_id=&changedin=&votes=&chfieldfrom=&chfieldto=&chfieldvalue=&short_desc=&short_desc_type=allwords&long_desc=&long_desc_type=allwords&issue_file_loc=&issue_file_loc_type=fulltext&status_whiteboard=&status_whiteboard_type=fulltext&keywords=&keywords_type=anytokens&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order='Importance'&Submit+query=Submit+query
gives only one issue...
Sorry to have to ask, I did try to see if I could get a number via the
web query interface to the issue tracker and just don't see how to do so.
questions are mostly helpful for others who never ask...
Kind regards, Joost
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
