Re: Defects need be fixed with high priority in AOO 4.0
Yuzhen Fan wrote: Thanks for your comment, here is the updated process based on the feedback 1. Get candidate bugs by query: severity = blocker, critical and status = unconfirmed, confirmed, reopened OR keyword includes "crash". Regressions are also candidates for fixing in the next release. So the "regression" keyword should be used too when building the initial list of candidate issues to be reviewed. Regards, Andrea. - To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org For additional commands, e-mail: qa-h...@openoffice.apache.org
Re: Defects need be fixed with high priority in AOO 4.0
Thanks for your comment, here is the updated process based on the feedback
1. Get candidate bugs by query: severity = blocker, critical and status =
unconfirmed, confirmed, reopened OR keyword includes "crash".
2. For every candidate bug above, set field " 4.0 release blocker" to "?"
to propose it as a blocker, and and then discuss it on the dev/qa mailing
list. If there is consensus it is a blocker then the value is changed to
"+".
3. Mark bugs to priority = P1(immediate) after get consensus from
discussing on the dev/qa mailing list
4. Assign these bugs to development volunteers (let bug assignee prioritize
his or her bugs except P1) for fixing and QA to verify once get resolved.
Regards,
Yu Zhen
On Thu, May 9, 2013 at 10:44 AM, Liu Ping wrote:
> hi,Rob
>
> I inform Priority and Severity fields from BZ help
>
>1.
>
>*Priority:* The bug assignee uses this field to prioritize his or her
>bugs. It's a good idea not to change this on other people's bugs.
>2.
>
>*Severity:* This indicates how severe the problem is - from blocker
>("application unusable") to trivial ("minor cosmetic issue"). You can
> also
>use this field to indicate whether a bug is an enhancement request.
>
> if you are interested in other fields ,you can get from
>
> https://issues.apache.org/ooo/docs/en/html/bug_page.html
>
> For the level for Priority and Severity , refer
> http://www.mediawiki.org/wiki/Bugzilla/Fields
>
> SeverityMeaningBlockerBlocks further development and/or testing work.
> CriticalCrashes, loss of data (internally, not your edit preview!) in a
> widely used and important component.MajorMajor loss of function in an
> important area.NormalDefault/average.MinorMinor loss of function, or other
> problem that does not affect many people or where an easy workaround is
> present.TrivialCosmetic problem like misspelled words or misaligned text
> which does not really cause problems.EnhancementRequest for a new feature
> or change in functionality for an existing feature.
>
> PriorityMeaningimmediateMust be fixed immediately (means: "Drop any other
> work"). Reports should have an assignee set in the "Assigned to" field, and
> both assignees and further affected parties (e.g. Engineering
> Management)
> should also be informed by private email, to be on the safe
> side.highestShould
> be fixed as next task by a team and certainly before the next deployment.
> Teams should only have very few issues (preferably one) with highest
> priority at the same time. Reports should have an assignee set in the
> "Assigned to" field. In case of Platform
> Engineering >tickets,
> notify
> RobLa separately.highNot
> the next task, but should be fixed soon. Depending on teams & manpower this
> can take between one and six months.normalMedium priority; would be good to
> get fixed somewhere in the future. Contributed patches might speed fixing
> up.low
>
> This can be fixed, but we're not going to worry about it. Patches very
> welcome and required for progress.
>
> lowest
>
> This can be fixed, but we're not going to worry about it. Patches very
> welcome and required for progress.
>
>
>
>
>
>
>
>
> On Wed, May 8, 2013 at 9:08 PM, Rob Weir wrote:
>
> > On Wed, May 8, 2013 at 8:54 AM, Yuzhen Fan wrote:
> > > Hi,
> > >
> > > We have pretty high backlog for unresolved defects, we need to clean
> them
> > > as much as possible before we exit full regression. Before we focus on
> > the
> > > fixing work, let's set the filter and get the defect list with high
> > > priority.
> > >
> > > I would suggest we use this way:
> > > 1. Get candidate defects by query: severity = blocker, critical and
> > status
> > > = unconfirmed, confirmed, reopened
> > > 2. Evaluate them and set/unset Flags as 4.0.0_release_blocker to get
> > defect
> > > list with high priority
> > > 3. Assign these defects to development volunteers for fixing and QA to
> > > verify once get resolved
> > >
> > > You comment and suggestion are welcome!
> > >
> >
> > Maybe someone can help clarify something: The BZ form has two fields
> > for rating bugs: P1/P2/P3/P4 field and a
> > blocker/critical/major/normal/minor/trivial field. What is the
> > difference?
> >
> > Also, the 4.0 release blocker has 3 values: ?/+/-. The way we did it
> > before was to set the field to "?" to propose it as a blocker, and
> > then discuss it on the dev mailing list. If there was consensus it
> > was a blocker then the value is changed to "+".
> >
> > -Rob
> >
> >
> > > Regards,
> > > Yu Zhen
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> > For additional commands, e-mail: dev-h...@openoffice.apache.org
> >
> >
>
Re: Defects need be fixed with high priority in AOO 4.0
hi,Rob
I inform Priority and Severity fields from BZ help
1.
*Priority:* The bug assignee uses this field to prioritize his or her
bugs. It's a good idea not to change this on other people's bugs.
2.
*Severity:* This indicates how severe the problem is - from blocker
("application unusable") to trivial ("minor cosmetic issue"). You can also
use this field to indicate whether a bug is an enhancement request.
if you are interested in other fields ,you can get from
https://issues.apache.org/ooo/docs/en/html/bug_page.html
For the level for Priority and Severity , refer
http://www.mediawiki.org/wiki/Bugzilla/Fields
SeverityMeaningBlockerBlocks further development and/or testing work.
CriticalCrashes, loss of data (internally, not your edit preview!) in a
widely used and important component.MajorMajor loss of function in an
important area.NormalDefault/average.MinorMinor loss of function, or other
problem that does not affect many people or where an easy workaround is
present.TrivialCosmetic problem like misspelled words or misaligned text
which does not really cause problems.EnhancementRequest for a new feature
or change in functionality for an existing feature.
PriorityMeaningimmediateMust be fixed immediately (means: "Drop any other
work"). Reports should have an assignee set in the "Assigned to" field, and
both assignees and further affected parties (e.g. Engineering
Management)
should also be informed by private email, to be on the safe side.highestShould
be fixed as next task by a team and certainly before the next deployment.
Teams should only have very few issues (preferably one) with highest
priority at the same time. Reports should have an assignee set in the
"Assigned to" field. In case of Platform
Engineeringtickets,
notify
RobLa separately.highNot
the next task, but should be fixed soon. Depending on teams & manpower this
can take between one and six months.normalMedium priority; would be good to
get fixed somewhere in the future. Contributed patches might speed fixing
up.low
This can be fixed, but we're not going to worry about it. Patches very
welcome and required for progress.
lowest
This can be fixed, but we're not going to worry about it. Patches very
welcome and required for progress.
On Wed, May 8, 2013 at 9:08 PM, Rob Weir wrote:
> On Wed, May 8, 2013 at 8:54 AM, Yuzhen Fan wrote:
> > Hi,
> >
> > We have pretty high backlog for unresolved defects, we need to clean them
> > as much as possible before we exit full regression. Before we focus on
> the
> > fixing work, let's set the filter and get the defect list with high
> > priority.
> >
> > I would suggest we use this way:
> > 1. Get candidate defects by query: severity = blocker, critical and
> status
> > = unconfirmed, confirmed, reopened
> > 2. Evaluate them and set/unset Flags as 4.0.0_release_blocker to get
> defect
> > list with high priority
> > 3. Assign these defects to development volunteers for fixing and QA to
> > verify once get resolved
> >
> > You comment and suggestion are welcome!
> >
>
> Maybe someone can help clarify something: The BZ form has two fields
> for rating bugs: P1/P2/P3/P4 field and a
> blocker/critical/major/normal/minor/trivial field. What is the
> difference?
>
> Also, the 4.0 release blocker has 3 values: ?/+/-. The way we did it
> before was to set the field to "?" to propose it as a blocker, and
> then discuss it on the dev mailing list. If there was consensus it
> was a blocker then the value is changed to "+".
>
> -Rob
>
>
> > Regards,
> > Yu Zhen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>
Defects need be fixed with high priority in AOO 4.0
Hi, We have pretty high backlog for unresolved defects, we need to clean them as much as possible before we exit full regression. Before we focus on the fixing work, let's set the filter and get the defect list with high priority. I would suggest we use this way: 1. Get candidate defects by query: severity = blocker, critical and status = unconfirmed, confirmed, reopened 2. Evaluate them and set/unset Flags as 4.0.0_release_blocker to get defect list with high priority 3. Assign these defects to development volunteers for fixing and QA to verify once get resolved You comment and suggestion are welcome! Regards, Yu Zhen
