You are viewing a plain text version of this content. The canonical link for it is here.
Posted to qa@openoffice.apache.org by Yuzhen Fan <fa...@gmail.com> on 2013/05/08 14:54:59 UTC
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
Re: Defects need be fixed with high priority in AOO 4.0
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Wed, May 08, 2013 at 08:54:59PM +0800, 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!
There should be search that includes the "crash" keyword, crashes are
release blockers if reproducible and affect basic functionality.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: Defects need be fixed with high priority in AOO 4.0
Posted by Andrea Pescetti <pe...@apache.org>.
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: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Defects need be fixed with high priority in AOO 4.0
Posted by Andrea Pescetti <pe...@apache.org>.
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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Defects need be fixed with high priority in AOO 4.0
Posted by Yuzhen Fan <fa...@gmail.com>.
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 <do...@gmail.com> 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<http://www.mediawiki.org/wiki/Wikimedia_Engineering>)
> 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<http://www.mediawiki.org/wiki/Wikimedia_Platform_Engineering
> >tickets,
> notify
> RobLa <http://meta.wikimedia.org/wiki/User:RobLa-WMF> 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 <ro...@apache.org> wrote:
>
> > On Wed, May 8, 2013 at 8:54 AM, Yuzhen Fan <fa...@gmail.com> 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-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
> >
>
Re: Defects need be fixed with high priority in AOO 4.0
Posted by Yuzhen Fan <fa...@gmail.com>.
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 <do...@gmail.com> 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<http://www.mediawiki.org/wiki/Wikimedia_Engineering>)
> 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<http://www.mediawiki.org/wiki/Wikimedia_Platform_Engineering
> >tickets,
> notify
> RobLa <http://meta.wikimedia.org/wiki/User:RobLa-WMF> 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 <ro...@apache.org> wrote:
>
> > On Wed, May 8, 2013 at 8:54 AM, Yuzhen Fan <fa...@gmail.com> 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-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
> >
>
Re: Defects need be fixed with high priority in AOO 4.0
Posted by Liu Ping <do...@gmail.com>.
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<http://www.mediawiki.org/wiki/Wikimedia_Engineering>)
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<http://www.mediawiki.org/wiki/Wikimedia_Platform_Engineering>tickets,
notify
RobLa <http://meta.wikimedia.org/wiki/User:RobLa-WMF> 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 <ro...@apache.org> wrote:
> On Wed, May 8, 2013 at 8:54 AM, Yuzhen Fan <fa...@gmail.com> 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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Defects need be fixed with high priority in AOO 4.0
Posted by Liu Ping <do...@gmail.com>.
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<http://www.mediawiki.org/wiki/Wikimedia_Engineering>)
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<http://www.mediawiki.org/wiki/Wikimedia_Platform_Engineering>tickets,
notify
RobLa <http://meta.wikimedia.org/wiki/User:RobLa-WMF> 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 <ro...@apache.org> wrote:
> On Wed, May 8, 2013 at 8:54 AM, Yuzhen Fan <fa...@gmail.com> 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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: Defects need be fixed with high priority in AOO 4.0
Posted by Rob Weir <ro...@apache.org>.
On Wed, May 8, 2013 at 8:54 AM, Yuzhen Fan <fa...@gmail.com> 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-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org