You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Yuzhen Fan <fa...@gmail.com> on 2013/06/06 13:54:29 UTC
Triage for AOO 4.0.0 Release Blockers
Hi All,
Here is the list of identified candidates[1]/[2] which are proposed to be
4.0.0 release blockers. Please indicate your selections for release
blockers by giving 1 vote to 1 bug (the vote field is beside the importance
field, in a bug form). We hope to get the vote score this week, any bugs
you think most critical to you, please bring out and let's discuss.
[1]
https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=4.0.0_release_blocker%3F&sharer_id=249289&list_id=64740
[2] Also attach the file for the list
(AOO4.0.0_release_blocker_candidates.ods)
Regards,
Yu Zhen
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Andre Fischer <aw...@gmail.com>.
On 20.06.2013 17:09, Oliver-Rainer Wittmann wrote:
> Hi,
>
> On 06.06.2013 13:54, Yuzhen Fan wrote:
>> Hi All,
>>
>> Here is the list of identified candidates[1]/[2] which are proposed to
>> be 4.0.0 release blockers. Please indicate your selections for release
>> blockers by giving 1 vote to 1 bug (the vote field is beside the
>> importance field, in a bug form). We hope to get the vote score this
>> week, any bugs you think most critical to you, please bring out and
>> let's discuss.
>>
>> [1]
>> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=4.0.0_release_blocker%3F&sharer_id=249289&list_id=64740
>>
>> [2] Also attach the file for the list
>> (AOO4.0.0_release_blocker_candidates.ods)
>>
>
> Armin, Jürgen, Andre and myself reviewed in the last days the list of
> issues which had been requested for release blocker (release blocker
> flag = '?') and are not solved.
>
> We propose the following issues as release blockers [1]:
> - 120250
> - 120443 (actually 121772 - 120443 is a dup. of this one)
> - 120513
> - 120559
> - 121008
> - 121143
> - 121256
121256 can also be removed because it got fixed in the meantime.
> - 121435
> - 121479
> - 121751
> - 121925
> - 121968
> - 121977
> - 122163
> - 122300
>
> Any objections to mark these issues as release blocker?
>
> [1]
> https://issues.apache.org/ooo/buglist.cgi?quicksearch=120250%20120443%20120513%20120559%20121008%20121143%20121256%20121435%20121479%20121751%20121925%20121968%20121977%20122163%20122300%20121772&list_id=68303
>
>
> Best regards, Oliver.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Andre Fischer <aw...@gmail.com>.
On 20.06.2013 17:09, Oliver-Rainer Wittmann wrote:
> Hi,
>
> On 06.06.2013 13:54, Yuzhen Fan wrote:
>> Hi All,
>>
>> Here is the list of identified candidates[1]/[2] which are proposed to
>> be 4.0.0 release blockers. Please indicate your selections for release
>> blockers by giving 1 vote to 1 bug (the vote field is beside the
>> importance field, in a bug form). We hope to get the vote score this
>> week, any bugs you think most critical to you, please bring out and
>> let's discuss.
>>
>> [1]
>> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=4.0.0_release_blocker%3F&sharer_id=249289&list_id=64740
>>
>> [2] Also attach the file for the list
>> (AOO4.0.0_release_blocker_candidates.ods)
>>
>
> Armin, Jürgen, Andre and myself reviewed in the last days the list of
> issues which had been requested for release blocker (release blocker
> flag = '?') and are not solved.
>
> We propose the following issues as release blockers [1]:
> - 120250
Bug 120250 can be removed from this list, it is now fixed.
-Andre
> - 120443 (actually 121772 - 120443 is a dup. of this one)
> - 120513
> - 120559
> - 121008
> - 121143
> - 121256
> - 121435
> - 121479
> - 121751
> - 121925
> - 121968
> - 121977
> - 122163
> - 122300
>
> Any objections to mark these issues as release blocker?
>
> [1]
> https://issues.apache.org/ooo/buglist.cgi?quicksearch=120250%20120443%20120513%20120559%20121008%20121143%20121256%20121435%20121479%20121751%20121925%20121968%20121977%20122163%20122300%20121772&list_id=68303
>
>
> Best regards, Oliver.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Andre Fischer <aw...@gmail.com>.
On 21.06.2013 12:39, Edwin Sharp wrote:
> My meaning is, respecting current users of OpenOffice who reported bugs and see those bugs not resolved while new features (sidebar) are being introduced.
> I think they deserve at least an explanation how introducing new features is more important from fixing bugs that bothers them (after all, they took the time to report them).
That is an interesting view on things but one that I don't share. Some
random thoughts on this:
- Fixing a bug usually takes a lot more time and effort than reporting one.
- There where a log of bugs fixed. More will be fixed in the coming weeks.
- It is no a display of disrespect when a certain bug is not fixed.
- There is no anonymous force of nature that fixes bugs in OpenOffice
and just has to be pointed in the right direction. The work is done by
individuals with a free will who can and do choose what they are working
on. You and I can express wishes but ultimately we can not control the
work of volunteers.
- The sidebar is a feature for everybody not only for a small minority
of users. Therefore it is an important improvement that benefits a lot
of people, including those who report bugs that don't get fixed.
- The assumption that introducing a new feature like the sidebar is more
important than fixing bugs is wrong and a little offensive. We are
doing both.
Regards,
Andre
>
> On Fri, Jun 21, 2013, at 10:22, Andre Fischer wrote:
>>>> 7. the judgment of introducing the sidebar with so many pending bugs should be justified to demonstrate openness
>> I don't understand the second part of the sentence.
>>
>> I have divided the bugs regarding the sidebar into three categories. For
>> each category exists one meta issue:
>>
>> 1. Bugs that have to be fixed for the 4.0 release are covered by issue
>> 121420 (https://issues.apache.org/ooo/show_bug.cgi?id=121420)
>> At the moment there are no open bugs blocking it.
>>
>> 2. Bugs that should be addressed after the 4.0 release are marked as
>> blockers of issue 122364
>> (https://issues.apache.org/ooo/show_bug.cgi?id=122364)
>> These are bugs that don't have a big impact on the majority of users or
>> would require a tremendous amount of work to fix them. There are six
>> bugs in this category.
>>
>> 3. Requested enhancements form the third category described by issue
>> 122257 (https://issues.apache.org/ooo/show_bug.cgi?id=122257). There
>> are 18 feature requests or enhancements.
>>
>>
>> As said above, only bugs in the first category will be fixed for the 4.0
>> release. At the moment there are no such open bugs.
>>
>> -Andre
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Edwin Sharp <el...@mail-page.com>.
My meaning is, respecting current users of OpenOffice who reported bugs and see those bugs not resolved while new features (sidebar) are being introduced.
I think they deserve at least an explanation how introducing new features is more important from fixing bugs that bothers them (after all, they took the time to report them).
On Fri, Jun 21, 2013, at 10:22, Andre Fischer wrote:
>
> >> 7. the judgment of introducing the sidebar with so many pending bugs should be justified to demonstrate openness
>
> I don't understand the second part of the sentence.
>
> I have divided the bugs regarding the sidebar into three categories. For
> each category exists one meta issue:
>
> 1. Bugs that have to be fixed for the 4.0 release are covered by issue
> 121420 (https://issues.apache.org/ooo/show_bug.cgi?id=121420)
> At the moment there are no open bugs blocking it.
>
> 2. Bugs that should be addressed after the 4.0 release are marked as
> blockers of issue 122364
> (https://issues.apache.org/ooo/show_bug.cgi?id=122364)
> These are bugs that don't have a big impact on the majority of users or
> would require a tremendous amount of work to fix them. There are six
> bugs in this category.
>
> 3. Requested enhancements form the third category described by issue
> 122257 (https://issues.apache.org/ooo/show_bug.cgi?id=122257). There
> are 18 feature requests or enhancements.
>
>
> As said above, only bugs in the first category will be fixed for the 4.0
> release. At the moment there are no such open bugs.
>
> -Andre
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Andre Fischer <aw...@gmail.com>.
On 21.06.2013 08:57, Jürgen Schmidt wrote:
> On 6/20/13 8:01 PM, Edwin Sharp wrote:
>> Yes.
>> please allow to share the following objections:
>> 1. in general, bugs shouldn't be rated
> I disagree here and you always rate issues starting with setting a
> priority. And as always you can't fix them all with a fix number of
> developers. It simply doesn't work. That means you have to prioritize
> and that is quite normal.
>
>> 2. most are crashes - "release blocker" can be other than crash - i.e. copy chart from Calc into Writer results in chart area without curve. this is a huge bug that doesn't involve a crash
> exactly and we have defined some criteria for issues, crashes, data loss
> and security issues have always high priority. Regressions are also very
> important especially when often used functionality is broken.
>
> It is documented in the wiki but I haven't the reference in place yet,
> have to look for it.
>
>> 3. with all the respect to Norwegian users, print dialog too wide is a negligible problem
> not for this specific user group and the fix is already available.
>
>> 4. there should be a documented evidence to the bug evaluation process, based on approved SOP
> I am not sure if I understand you here
>
>> 5. the general public has no declared release date - no need to rush as there is no commitment to fulfill
> no but the project have committed to a release date and I believe the
> majority of the community support the new release. You have to set a
> date and have define what is important for this date. You can always do
> more and can fix more issues but that won't work very well.
>
>> 6. "minor" bugs should also get attention and be targeted
> definitely but not short in front of a release. And of course nobody
> prevent anybody from fixing such issues. We have a lot of them, many are
> probably not longer valid and can be closed, other are not easy to fix
> and so on. A good start would be of course to simply check older issues
> if they are still valid or not.
>
>> 7. the judgment of introducing the sidebar with so many pending bugs should be justified to demonstrate openness
I don't understand the second part of the sentence.
I have divided the bugs regarding the sidebar into three categories. For
each category exists one meta issue:
1. Bugs that have to be fixed for the 4.0 release are covered by issue
121420 (https://issues.apache.org/ooo/show_bug.cgi?id=121420)
At the moment there are no open bugs blocking it.
2. Bugs that should be addressed after the 4.0 release are marked as
blockers of issue 122364
(https://issues.apache.org/ooo/show_bug.cgi?id=122364)
These are bugs that don't have a big impact on the majority of users or
would require a tremendous amount of work to fix them. There are six
bugs in this category.
3. Requested enhancements form the third category described by issue
122257 (https://issues.apache.org/ooo/show_bug.cgi?id=122257). There
are 18 feature requests or enhancements.
As said above, only bugs in the first category will be fixed for the 4.0
release. At the moment there are no such open bugs.
-Andre
> as far as I know we haven't pending bugs here. Don't mix this up with
> improvement or feature requests. Maybe I don't understand you and you
> can explain it again
>
>> 8. RTF is rarely used today - no reason for two appearances in the list
> RTF is as far as I known relevant for Ms interoperability in general and
> important for other MS filters as well. Even the pure format is not used
> often the functionality is important. If somebody knows more please
> correct me.
>
>> 9. Are there no "critical" bugs in Math, Draw and Base?
> probably yes and probably many other critical bugs in other areas that
> are not detected yet or not proposed as showstopper
>
>> 10. Are there enough volunteers to treat these "release blockers" on time?
> we hope we can fix them all but volunteers are never enough ;-)
>
> If you think that other issue should be showstopper as well, please
> propose them on the dev list and we can discuss them. That's the way how
> we want to handle it
>
> Further discussion should take place on the dev list
>
>
> Juergen
>
>
>> Thank you
>>
>>
>>
>> On Thu, Jun 20, 2013, at 18:09, Oliver-Rainer Wittmann wrote:
>>> Hi,
>>> Any objections to mark these issues as release blocker?
>>>
>>> [1]
>>> https://issues.apache.org/ooo/buglist.cgi?quicksearch=120250%20120443%20120513%20120559%20121008%20121143%20121256%20121435%20121479%20121751%20121925%20121968%20121977%20122163%20122300%20121772&list_id=68303
>>>
>>>
>>> Best regards, Oliver.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Sub Phil <ph...@gmail.com>.
>IMHO there are no bad ideas here. They are just mistimed ;-)
It would be mad to change the bug policy now, but for the future it might
have an impact.
2013/6/21 Rob Weir <ro...@apache.org>
> On Fri, Jun 21, 2013 at 11:09 AM, Sub Phil <ph...@gmail.com> wrote:
> > Bug policy debate and so on..
> >
> > Well, just sharing experience from as a past developper and notorious bug
> > fighter.
> >
> > There is no other point in creating a database of bugs and not treating
> > them, than to have an ultra-complicated list of known issues (so complex
> > that users report are duplicated) and frustrated reporters (and testers).
> >
> > "It is no a display of disrespect when a certain bug is not fixed."
> > Yes until you have a list of open bugs, which generated itself a list of
> > duplicates...
> > What matters is the evolution ratio closed / confirmed by release (e.g.
> > 3.4.1) and cumulated version (3.4.x).
> >
>
> Metrics like this could be useful if we're measuring defects not
> defect reports. Unfortunately the duplicates, plus the "how do I?"
> and other non-defects that users enter , make this difficult to
> estimate. My impression is that close to half of the Bugzilla reports
> are invalid. We'd need to do a major clean up of Bugzilla before we
> even knew how many actual defects are there.
>
> > "I would like to add another one. I am a developer. When I spend time
> on
> > fixing bugs then I sometimes wish there where a big list of all open bugs
> > that are sorted according to importance. I would go down the list and
> grab
> > a bug from the top that lies in the area of my expertise (Impress, UI,
> > Slideshow, Sidebar). Without such a list I have to prioritize bugs by
> > myself. And if I do that then I use my own judgement of which bug is
> > important and which is not."
> >
>
> To the extent that rated priority is a motivation to volunteers, this
> is true. But we have all sorts of volunteers. I think some of them
> have enough stress in their real lives that they don't want to take
> "high priority" issues and world rather work on lower priority ones,
> where there is less urgency.
>
> Also, much of this depends on where we are in the release. Once we
> have completed regression testing we want to avoid introducing
> additional risk. So it is no longer "open season" for fixing just any
> defect. We need to weigh the risks involved. In many cases, for less
> serious bugs, we fix them in a later release, so they can undergo a
> full test pass.
>
> > This further illustrate the fact that in order to handle these list, one
> > has introduced techniques such as priority and vote for bug.
> >
> > My own experience shows, that all these are not good policy for bug
> > treatment, it's a dispair.
> >
>
> Prioritization is not despair. It is just acknowledging that changing
> the code after testing has completed is risky, and that we should only
> make changes now where absolutely necessary. Despair is what users
> feel when we don't show such precautions and see a last minute fix
> introduce a serious bug that is not caught before release.
>
> > Bug should be assigned in groups regarding a feature with final objective
> > in mind.
> > What do I mean by feature.
> > Take for instance in Calc, the pivot table function.
> > All bug regarding pivot table should be treated together, or most of
> them.
> > Why concentrating?
> > Because:
> > 1/ It takes time to fix a bug, because one needs to understand or
> > re-understand the implementation.
> > "- Fixing a bug usually takes a lot more time and effort than reporting
> one.
> > Also, often because test case scenario are not narrow enough - see my
> other
> > post.
> >
> > 2/ By taking all bugs related to a piece of source code, each time you
> > become more familliar and so more efficient. In a sense you proof reading
> > it several times, you get leverage on bug handling.
> >
> > 3/ By reviewing several related bugs, you reduce the risk or regression,
> as
> > you've been through it several times, each time with a deeper
> understanding.
> >
>
> This is a good practice to follow, before the main test pass
> completes. After than we intentionally aim to minimize the changes to
> the code. Otherwise we don't have a good sense of what the quality is
> we're release.
>
> Bugs are bad, but with testing we can at least have a degree of
> confidence that there are no defects above a certain severity level.
> If we make unrestrained changes after the test pass then our degree of
> confidence is reduced or eliminated.
>
> > "The other thing to note is that bug fixes are not risk-free. Studies
> > have shown that 25% of defects in code are side effects of changes".
> > FFmpeg is really a good example for regression, to a point I stopped
> > reporting (first you have to convince it's a bug, then it lays pending
> to a
> > wish to fix it and then you find older release which works...)
> >
>
> I know it can be frustrating as a tester to see defects you reported
> go unfixed in a release. I've been there.
>
> > 4/ Having fixed a bulk of related feature bugs, report the fix is
> > implemented to all different reporters. They will(hopefully if done in a
> > reasonable time, not like me who got a mail for a bug I posted 2 years
> > ago...) test "their" bug and by doing so improve the total quality
> control
> > and reduce regression risk.
> >
> >
> >
> > What do I mean by assigning by objective.
> >
> > Well, here is for me where the votes should take place, grouped by user,
> > tester and developer (might have different interests).
> >
> > Suppose, pivot table code is considered as a mess by developpers and
> ought
> > to be re-written by next release. There is no point in fixing pivot table
> > bug now.
> >
> > Suppose users consider that priority should be assigned in this order
> > 1. fix doc format issues
> > 2. fix grammar check issues
> >
> > It has to be respected and if there is a "critical" bug in another field,
> > well if it will wait.
> >
>
> All good ideas. But we do need to respect where we are in the release
> cycle for AOO 4.0. Main testing is done. Main bug fixing is done.
> We're not going back to do feature work, clean up or whatever for this
> release. We're fixing a few remaining severe issues in preparation
> for release. The time to suggest specific other bugs for this
> release was many months ago. Of course, this is a great time to
> suggest specific bugs for AOO 4.1. Along with feature work for AOO
> 4.1 it would be great if we could identify priority bugs to fix in
> that release, so fixes could be integrated into the release before the
> AOO 4.1 test passes conclude.
>
> IMHO there are no bad ideas here. They are just mistimed ;-)
>
> Regards,
>
> -Rob
>
> > One should not vote for a bug, but rather for an expected behaviour.
> >
> > Phil
> >
> > 2013/6/21 Andre Fischer <aw...@gmail.com>
> >
> >> On 21.06.2013 13:42, Edwin Sharp wrote:
> >>
> >>> Dear Andre
> >>> This is exactly the problem!
> >>> When you grab a bug from the top and critical bugs continuously enter
> the
> >>> list -
> >>> The minor bugs at the bottom will never get attention.
> >>>
> >> You make that sound like it where a bad thing.
> >> A bug is critical because it affects man users and/or causes data loss
> >> (and one or the other additional property). Therefore it should be
> fixed
> >> before minor bugs are fixed.
> >> This is how it should work. If it does not then I see two reasons for
> it:
> >>
> >> - There is not one single sorted list of bugs. Everybody has his or her
> >> own idea of which bug is important and which isn't.
> >>
> >> - The way in which bugs are ordered is not good enough. This ordering
> is
> >> certainly not easy to define and it will be impossible to define it in a
> >> way that makes everybody happy. But if there where one central list of
> >> ordered bugs then we could at least try. And everybody could help to
> >> improve it. With such a list you have to rely on my judgement or that
> of
> >> other developers.
> >>
> >> -Andre
> >>
> >>
> >>> On Fri, Jun 21, 2013, at 14:24, Andre Fischer wrote:
> >>>
> >>>>
> >>>> All good ideas.
> >>>>
> >>>> I would like to add another one. I am a developer. When I spend time
> >>>> on fixing bugs then I sometimes wish there where a big list of all
> open
> >>>> bugs that are sorted according to importance. I would go down the
> list
> >>>> and grab a bug from the top that lies in the area of my expertise
> >>>> (Impress, UI, Slideshow, Sidebar). Without such a list I have to
> >>>> prioritize bugs by myself. And if I do that then I use my own
> judgement
> >>>> of which bug is important and which is not.
> >>>>
> >>>> Regards,
> >>>> Andre
> >>>>
> >>>>
> >>>> ------------------------------**------------------------------**
> >>> ---------
> >>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.**apache.org<
> qa-unsubscribe@openoffice.apache.org>
> >>> For additional commands, e-mail: qa-help@openoffice.apache.org
> >>>
> >>>
> >>
> >>
> ------------------------------**------------------------------**---------
> >> To unsubscribe, e-mail: qa-unsubscribe@openoffice.**apache.org<
> qa-unsubscribe@openoffice.apache.org>
> >> For additional commands, e-mail: qa-help@openoffice.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
>
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Rob Weir <ro...@apache.org>.
On Fri, Jun 21, 2013 at 11:09 AM, Sub Phil <ph...@gmail.com> wrote:
> Bug policy debate and so on..
>
> Well, just sharing experience from as a past developper and notorious bug
> fighter.
>
> There is no other point in creating a database of bugs and not treating
> them, than to have an ultra-complicated list of known issues (so complex
> that users report are duplicated) and frustrated reporters (and testers).
>
> "It is no a display of disrespect when a certain bug is not fixed."
> Yes until you have a list of open bugs, which generated itself a list of
> duplicates...
> What matters is the evolution ratio closed / confirmed by release (e.g.
> 3.4.1) and cumulated version (3.4.x).
>
Metrics like this could be useful if we're measuring defects not
defect reports. Unfortunately the duplicates, plus the "how do I?"
and other non-defects that users enter , make this difficult to
estimate. My impression is that close to half of the Bugzilla reports
are invalid. We'd need to do a major clean up of Bugzilla before we
even knew how many actual defects are there.
> "I would like to add another one. I am a developer. When I spend time on
> fixing bugs then I sometimes wish there where a big list of all open bugs
> that are sorted according to importance. I would go down the list and grab
> a bug from the top that lies in the area of my expertise (Impress, UI,
> Slideshow, Sidebar). Without such a list I have to prioritize bugs by
> myself. And if I do that then I use my own judgement of which bug is
> important and which is not."
>
To the extent that rated priority is a motivation to volunteers, this
is true. But we have all sorts of volunteers. I think some of them
have enough stress in their real lives that they don't want to take
"high priority" issues and world rather work on lower priority ones,
where there is less urgency.
Also, much of this depends on where we are in the release. Once we
have completed regression testing we want to avoid introducing
additional risk. So it is no longer "open season" for fixing just any
defect. We need to weigh the risks involved. In many cases, for less
serious bugs, we fix them in a later release, so they can undergo a
full test pass.
> This further illustrate the fact that in order to handle these list, one
> has introduced techniques such as priority and vote for bug.
>
> My own experience shows, that all these are not good policy for bug
> treatment, it's a dispair.
>
Prioritization is not despair. It is just acknowledging that changing
the code after testing has completed is risky, and that we should only
make changes now where absolutely necessary. Despair is what users
feel when we don't show such precautions and see a last minute fix
introduce a serious bug that is not caught before release.
> Bug should be assigned in groups regarding a feature with final objective
> in mind.
> What do I mean by feature.
> Take for instance in Calc, the pivot table function.
> All bug regarding pivot table should be treated together, or most of them.
> Why concentrating?
> Because:
> 1/ It takes time to fix a bug, because one needs to understand or
> re-understand the implementation.
> "- Fixing a bug usually takes a lot more time and effort than reporting one.
> Also, often because test case scenario are not narrow enough - see my other
> post.
>
> 2/ By taking all bugs related to a piece of source code, each time you
> become more familliar and so more efficient. In a sense you proof reading
> it several times, you get leverage on bug handling.
>
> 3/ By reviewing several related bugs, you reduce the risk or regression, as
> you've been through it several times, each time with a deeper understanding.
>
This is a good practice to follow, before the main test pass
completes. After than we intentionally aim to minimize the changes to
the code. Otherwise we don't have a good sense of what the quality is
we're release.
Bugs are bad, but with testing we can at least have a degree of
confidence that there are no defects above a certain severity level.
If we make unrestrained changes after the test pass then our degree of
confidence is reduced or eliminated.
> "The other thing to note is that bug fixes are not risk-free. Studies
> have shown that 25% of defects in code are side effects of changes".
> FFmpeg is really a good example for regression, to a point I stopped
> reporting (first you have to convince it's a bug, then it lays pending to a
> wish to fix it and then you find older release which works...)
>
I know it can be frustrating as a tester to see defects you reported
go unfixed in a release. I've been there.
> 4/ Having fixed a bulk of related feature bugs, report the fix is
> implemented to all different reporters. They will(hopefully if done in a
> reasonable time, not like me who got a mail for a bug I posted 2 years
> ago...) test "their" bug and by doing so improve the total quality control
> and reduce regression risk.
>
>
>
> What do I mean by assigning by objective.
>
> Well, here is for me where the votes should take place, grouped by user,
> tester and developer (might have different interests).
>
> Suppose, pivot table code is considered as a mess by developpers and ought
> to be re-written by next release. There is no point in fixing pivot table
> bug now.
>
> Suppose users consider that priority should be assigned in this order
> 1. fix doc format issues
> 2. fix grammar check issues
>
> It has to be respected and if there is a "critical" bug in another field,
> well if it will wait.
>
All good ideas. But we do need to respect where we are in the release
cycle for AOO 4.0. Main testing is done. Main bug fixing is done.
We're not going back to do feature work, clean up or whatever for this
release. We're fixing a few remaining severe issues in preparation
for release. The time to suggest specific other bugs for this
release was many months ago. Of course, this is a great time to
suggest specific bugs for AOO 4.1. Along with feature work for AOO
4.1 it would be great if we could identify priority bugs to fix in
that release, so fixes could be integrated into the release before the
AOO 4.1 test passes conclude.
IMHO there are no bad ideas here. They are just mistimed ;-)
Regards,
-Rob
> One should not vote for a bug, but rather for an expected behaviour.
>
> Phil
>
> 2013/6/21 Andre Fischer <aw...@gmail.com>
>
>> On 21.06.2013 13:42, Edwin Sharp wrote:
>>
>>> Dear Andre
>>> This is exactly the problem!
>>> When you grab a bug from the top and critical bugs continuously enter the
>>> list -
>>> The minor bugs at the bottom will never get attention.
>>>
>> You make that sound like it where a bad thing.
>> A bug is critical because it affects man users and/or causes data loss
>> (and one or the other additional property). Therefore it should be fixed
>> before minor bugs are fixed.
>> This is how it should work. If it does not then I see two reasons for it:
>>
>> - There is not one single sorted list of bugs. Everybody has his or her
>> own idea of which bug is important and which isn't.
>>
>> - The way in which bugs are ordered is not good enough. This ordering is
>> certainly not easy to define and it will be impossible to define it in a
>> way that makes everybody happy. But if there where one central list of
>> ordered bugs then we could at least try. And everybody could help to
>> improve it. With such a list you have to rely on my judgement or that of
>> other developers.
>>
>> -Andre
>>
>>
>>> On Fri, Jun 21, 2013, at 14:24, Andre Fischer wrote:
>>>
>>>>
>>>> All good ideas.
>>>>
>>>> I would like to add another one. I am a developer. When I spend time
>>>> on fixing bugs then I sometimes wish there where a big list of all open
>>>> bugs that are sorted according to importance. I would go down the list
>>>> and grab a bug from the top that lies in the area of my expertise
>>>> (Impress, UI, Slideshow, Sidebar). Without such a list I have to
>>>> prioritize bugs by myself. And if I do that then I use my own judgement
>>>> of which bug is important and which is not.
>>>>
>>>> Regards,
>>>> Andre
>>>>
>>>>
>>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.**apache.org<qa...@openoffice.apache.org>
>>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.**apache.org<qa...@openoffice.apache.org>
>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Sub Phil <ph...@gmail.com>.
Bug policy debate and so on..
Well, just sharing experience from as a past developper and notorious bug
fighter.
There is no other point in creating a database of bugs and not treating
them, than to have an ultra-complicated list of known issues (so complex
that users report are duplicated) and frustrated reporters (and testers).
"It is no a display of disrespect when a certain bug is not fixed."
Yes until you have a list of open bugs, which generated itself a list of
duplicates...
What matters is the evolution ratio closed / confirmed by release (e.g.
3.4.1) and cumulated version (3.4.x).
"I would like to add another one. I am a developer. When I spend time on
fixing bugs then I sometimes wish there where a big list of all open bugs
that are sorted according to importance. I would go down the list and grab
a bug from the top that lies in the area of my expertise (Impress, UI,
Slideshow, Sidebar). Without such a list I have to prioritize bugs by
myself. And if I do that then I use my own judgement of which bug is
important and which is not."
This further illustrate the fact that in order to handle these list, one
has introduced techniques such as priority and vote for bug.
My own experience shows, that all these are not good policy for bug
treatment, it's a dispair.
Bug should be assigned in groups regarding a feature with final objective
in mind.
What do I mean by feature.
Take for instance in Calc, the pivot table function.
All bug regarding pivot table should be treated together, or most of them.
Why concentrating?
Because:
1/ It takes time to fix a bug, because one needs to understand or
re-understand the implementation.
"- Fixing a bug usually takes a lot more time and effort than reporting one.
Also, often because test case scenario are not narrow enough - see my other
post.
2/ By taking all bugs related to a piece of source code, each time you
become more familliar and so more efficient. In a sense you proof reading
it several times, you get leverage on bug handling.
3/ By reviewing several related bugs, you reduce the risk or regression, as
you've been through it several times, each time with a deeper understanding.
"The other thing to note is that bug fixes are not risk-free. Studies
have shown that 25% of defects in code are side effects of changes".
FFmpeg is really a good example for regression, to a point I stopped
reporting (first you have to convince it's a bug, then it lays pending to a
wish to fix it and then you find older release which works...)
4/ Having fixed a bulk of related feature bugs, report the fix is
implemented to all different reporters. They will(hopefully if done in a
reasonable time, not like me who got a mail for a bug I posted 2 years
ago...) test "their" bug and by doing so improve the total quality control
and reduce regression risk.
What do I mean by assigning by objective.
Well, here is for me where the votes should take place, grouped by user,
tester and developer (might have different interests).
Suppose, pivot table code is considered as a mess by developpers and ought
to be re-written by next release. There is no point in fixing pivot table
bug now.
Suppose users consider that priority should be assigned in this order
1. fix doc format issues
2. fix grammar check issues
It has to be respected and if there is a "critical" bug in another field,
well if it will wait.
One should not vote for a bug, but rather for an expected behaviour.
Phil
2013/6/21 Andre Fischer <aw...@gmail.com>
> On 21.06.2013 13:42, Edwin Sharp wrote:
>
>> Dear Andre
>> This is exactly the problem!
>> When you grab a bug from the top and critical bugs continuously enter the
>> list -
>> The minor bugs at the bottom will never get attention.
>>
> You make that sound like it where a bad thing.
> A bug is critical because it affects man users and/or causes data loss
> (and one or the other additional property). Therefore it should be fixed
> before minor bugs are fixed.
> This is how it should work. If it does not then I see two reasons for it:
>
> - There is not one single sorted list of bugs. Everybody has his or her
> own idea of which bug is important and which isn't.
>
> - The way in which bugs are ordered is not good enough. This ordering is
> certainly not easy to define and it will be impossible to define it in a
> way that makes everybody happy. But if there where one central list of
> ordered bugs then we could at least try. And everybody could help to
> improve it. With such a list you have to rely on my judgement or that of
> other developers.
>
> -Andre
>
>
>> On Fri, Jun 21, 2013, at 14:24, Andre Fischer wrote:
>>
>>>
>>> All good ideas.
>>>
>>> I would like to add another one. I am a developer. When I spend time
>>> on fixing bugs then I sometimes wish there where a big list of all open
>>> bugs that are sorted according to importance. I would go down the list
>>> and grab a bug from the top that lies in the area of my expertise
>>> (Impress, UI, Slideshow, Sidebar). Without such a list I have to
>>> prioritize bugs by myself. And if I do that then I use my own judgement
>>> of which bug is important and which is not.
>>>
>>> Regards,
>>> Andre
>>>
>>>
>>> ------------------------------**------------------------------**
>> ---------
>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.**apache.org<qa...@openoffice.apache.org>
>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.**apache.org<qa...@openoffice.apache.org>
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
>
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Andre Fischer <aw...@gmail.com>.
On 21.06.2013 13:42, Edwin Sharp wrote:
> Dear Andre
> This is exactly the problem!
> When you grab a bug from the top and critical bugs continuously enter the list -
> The minor bugs at the bottom will never get attention.
You make that sound like it where a bad thing.
A bug is critical because it affects man users and/or causes data loss
(and one or the other additional property). Therefore it should be
fixed before minor bugs are fixed.
This is how it should work. If it does not then I see two reasons for it:
- There is not one single sorted list of bugs. Everybody has his or her
own idea of which bug is important and which isn't.
- The way in which bugs are ordered is not good enough. This ordering
is certainly not easy to define and it will be impossible to define it
in a way that makes everybody happy. But if there where one central
list of ordered bugs then we could at least try. And everybody could
help to improve it. With such a list you have to rely on my judgement
or that of other developers.
-Andre
>
> On Fri, Jun 21, 2013, at 14:24, Andre Fischer wrote:
>>
>> All good ideas.
>>
>> I would like to add another one. I am a developer. When I spend time
>> on fixing bugs then I sometimes wish there where a big list of all open
>> bugs that are sorted according to importance. I would go down the list
>> and grab a bug from the top that lies in the area of my expertise
>> (Impress, UI, Slideshow, Sidebar). Without such a list I have to
>> prioritize bugs by myself. And if I do that then I use my own judgement
>> of which bug is important and which is not.
>>
>> Regards,
>> Andre
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Edwin Sharp <el...@mail-page.com>.
Dear Andre
This is exactly the problem!
When you grab a bug from the top and critical bugs continuously enter the list -
The minor bugs at the bottom will never get attention.
On Fri, Jun 21, 2013, at 14:24, Andre Fischer wrote:
>
>
> All good ideas.
>
> I would like to add another one. I am a developer. When I spend time
> on fixing bugs then I sometimes wish there where a big list of all open
> bugs that are sorted according to importance. I would go down the list
> and grab a bug from the top that lies in the area of my expertise
> (Impress, UI, Slideshow, Sidebar). Without such a list I have to
> prioritize bugs by myself. And if I do that then I use my own judgement
> of which bug is important and which is not.
>
> Regards,
> Andre
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Andre Fischer <aw...@gmail.com>.
On 21.06.2013 13:09, Sub Phil wrote:
> Regarding "classification" of bugs (critical, etc.) and bug fixing.
>
> The core question is how to increase the throughput of bug fixing, i.e.
> increase the number of fixes?
>
> If one analyse bug reporting process & fixing, it is usually done as
> 1/ User report bug
> 2/ Tester try to reproduce it, then
> 2.1/ confirm or not
> 2.2/ sets a priority
> 3/ Some developper will fix it when has time and very othen if feels like
> it, instead of developping some new features (s)he likes.
>
> This is a very bad way to handle bug and discourage reporter, tester and
> possibly developper. Indeed, often bug are fixed weeks later, not months if
> ever and priority are very subjective.
>
> How to improve that?
> 1/ First by reducing time between bug reporting and fixing and only
> delaying fixing when it's too ressource consumming.
> Work on it as it is hot reported and user expect to verify the fix.
>
> 2/ By notifing bug reporter of current ressources (for instance, red flag
> lack ressouce so handles only critical bugs)
>
>
> How to improve the time between bug reporting and fixing?
> By cracking down the problem to its core root.
>
> Irrelevant of the bug seriousness, there are user familliar with bug
> reporting and some not.
> So the first role of the bug tester is to validate it and have a test
> scenario.
> When there is a test scenario, then 6 things are often short-circuited, but
> would accelerate the bug fixing process.
>
> 0/ When lacking time, well how frequent in its USE does the bug appear,
> i.e. is it rather of general use or rather specific to some expert user?
>
> 1/ Simplify the reproducable bug test case to its core form.
> For instance, if it's a spreadsheet.
> Are all columns usefull? No, delete the rest.
> Are all lines usefull? No, delete the rest.
> Is the formating relevant? No, remove it.
> Is it file format specific?
> Is it language specific?
> Etc.
> Snif the trail of the bug to find its root.
>
>
> 2/ Narrow down the process involved to generate the bug, in order to
> identify the precise component
> For example,
> In the process to reproduce the bug, are they steps one can omit, what
> about changing the order sequence.
>
>
> 3/ If applicable, make a run-time debug run to narrow down which component
> of the code has the problem.
> See my post on run-time debug & tracing tools.
>
> Try to report something as
> Crash when executing line 1234 of file blabla.c
>
> 4/ Set a priority according the IMPACT it has one the confidence one has in
> the product.
> Examples.
> * Imagine Calc can't handle CSV files, with semi-colon as delimiter. Well,
> annoying, but there are temporary work around.
>
> * Now suppose Calc, take
> https://issues.apache.org/ooo/show_bug.cgi?id=119836
> Won't you fear to use pivot?
>
> 5/ Ideally, make a macro to run the test case.
All good ideas.
I would like to add another one. I am a developer. When I spend time
on fixing bugs then I sometimes wish there where a big list of all open
bugs that are sorted according to importance. I would go down the list
and grab a bug from the top that lies in the area of my expertise
(Impress, UI, Slideshow, Sidebar). Without such a list I have to
prioritize bugs by myself. And if I do that then I use my own judgement
of which bug is important and which is not.
Regards,
Andre
> Yours,
>
> Philippe
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Sub Phil <ph...@gmail.com>.
Regarding "classification" of bugs (critical, etc.) and bug fixing.
The core question is how to increase the throughput of bug fixing, i.e.
increase the number of fixes?
If one analyse bug reporting process & fixing, it is usually done as
1/ User report bug
2/ Tester try to reproduce it, then
2.1/ confirm or not
2.2/ sets a priority
3/ Some developper will fix it when has time and very othen if feels like
it, instead of developping some new features (s)he likes.
This is a very bad way to handle bug and discourage reporter, tester and
possibly developper. Indeed, often bug are fixed weeks later, not months if
ever and priority are very subjective.
How to improve that?
1/ First by reducing time between bug reporting and fixing and only
delaying fixing when it's too ressource consumming.
Work on it as it is hot reported and user expect to verify the fix.
2/ By notifing bug reporter of current ressources (for instance, red flag
lack ressouce so handles only critical bugs)
How to improve the time between bug reporting and fixing?
By cracking down the problem to its core root.
Irrelevant of the bug seriousness, there are user familliar with bug
reporting and some not.
So the first role of the bug tester is to validate it and have a test
scenario.
When there is a test scenario, then 6 things are often short-circuited, but
would accelerate the bug fixing process.
0/ When lacking time, well how frequent in its USE does the bug appear,
i.e. is it rather of general use or rather specific to some expert user?
1/ Simplify the reproducable bug test case to its core form.
For instance, if it's a spreadsheet.
Are all columns usefull? No, delete the rest.
Are all lines usefull? No, delete the rest.
Is the formating relevant? No, remove it.
Is it file format specific?
Is it language specific?
Etc.
Snif the trail of the bug to find its root.
2/ Narrow down the process involved to generate the bug, in order to
identify the precise component
For example,
In the process to reproduce the bug, are they steps one can omit, what
about changing the order sequence.
3/ If applicable, make a run-time debug run to narrow down which component
of the code has the problem.
See my post on run-time debug & tracing tools.
Try to report something as
Crash when executing line 1234 of file blabla.c
4/ Set a priority according the IMPACT it has one the confidence one has in
the product.
Examples.
* Imagine Calc can't handle CSV files, with semi-colon as delimiter. Well,
annoying, but there are temporary work around.
* Now suppose Calc, take
https://issues.apache.org/ooo/show_bug.cgi?id=119836
Won't you fear to use pivot?
5/ Ideally, make a macro to run the test case.
Yours,
Philippe
2013/6/21 Oliver-Rainer Wittmann <or...@googlemail.com>
> Hi,
>
> On 21.06.2013 08:57, Jürgen Schmidt wrote:
>
>> On 6/20/13 8:01 PM, Edwin Sharp wrote:
>>
>>> Yes. please allow to share the following objections: 1. in general,
>>> bugs shouldn't be rated
>>>
>>
>> I disagree here and you always rate issues starting with setting a
>> priority. And as always you can't fix them all with a fix number of
>> developers. It simply doesn't work. That means you have to
>> prioritize and that is quite normal.
>>
>> 2. most are crashes - "release blocker" can be other than crash -
>>> i.e. copy chart from Calc into Writer results in chart area without
>>> curve. this is a huge bug that doesn't involve a crash
>>>
>> exactly and we have defined some criteria for issues, crashes, data
>> loss and security issues have always high priority. Regressions are
>> also very important especially when often used functionality is
>> broken.
>>
>> It is documented in the wiki but I haven't the reference in place
>> yet, have to look for it.
>>
>> 3. with all the respect to Norwegian users, print dialog too wide
>>> is a negligible problem
>>>
>> not for this specific user group and the fix is already available.
>>
>> 4. there should be a documented evidence to the bug evaluation
>>> process, based on approved SOP
>>>
>> I am not sure if I understand you here
>>
>> 5. the general public has no declared release date - no need to
>>> rush as there is no commitment to fulfill
>>>
>> no but the project have committed to a release date and I believe
>> the majority of the community support the new release. You have to
>> set a date and have define what is important for this date. You can
>> always do more and can fix more issues but that won't work very
>> well.
>>
>> 6. "minor" bugs should also get attention and be targeted
>>>
>> definitely but not short in front of a release. And of course nobody
>> prevent anybody from fixing such issues. We have a lot of them, many
>> are probably not longer valid and can be closed, other are not easy
>> to fix and so on. A good start would be of course to simply check
>> older issues if they are still valid or not.
>>
>> 7. the judgment of introducing the sidebar with so many pending
>>> bugs should be justified to demonstrate openness
>>>
>> as far as I know we haven't pending bugs here. Don't mix this up
>> with improvement or feature requests. Maybe I don't understand you
>> and you can explain it again
>>
>> 8. RTF is rarely used today - no reason for two appearances in the
>>> list
>>>
>> RTF is as far as I known relevant for Ms interoperability in general
>> and important for other MS filters as well. Even the pure format is
>> not used often the functionality is important. If somebody knows more
>> please correct me.
>>
>> Just some more background on the RTF filter:
> The RTF format is used on copy-and-paste actions between OpenOffice
> applications and other applications.
> For example, issue 120023 is caused by a defect in the RTF filter.
>
>
> Best regards, Oliver.
>
> 9. Are there no "critical" bugs in Math, Draw and Base?
>>>
>> probably yes and probably many other critical bugs in other areas
>> that are not detected yet or not proposed as showstopper
>>
>> 10. Are there enough volunteers to treat these "release blockers"
>>> on time?
>>>
>> we hope we can fix them all but volunteers are never enough ;-)
>>
>> If you think that other issue should be showstopper as well, please
>> propose them on the dev list and we can discuss them. That's the way
>> how we want to handle it
>>
>> Further discussion should take place on the dev list
>>
>>
>> Juergen
>>
>>
>> Thank you
>>>
>>>
>>>
>>> On Thu, Jun 20, 2013, at 18:09, Oliver-Rainer Wittmann wrote:
>>>
>>>> Hi, Any objections to mark these issues as release blocker?
>>>>
>>>> [1]
>>>> https://issues.apache.org/ooo/**buglist.cgi?quicksearch=**
>>>> 120250%20120443%20120513%**20120559%20121008%20121143%**
>>>> 20121256%20121435%20121479%**20121751%20121925%20121968%**
>>>> 20121977%20122163%20122300%**20121772&list_id=68303<https://issues.apache.org/ooo/buglist.cgi?quicksearch=120250%20120443%20120513%20120559%20121008%20121143%20121256%20121435%20121479%20121751%20121925%20121968%20121977%20122163%20122300%20121772&list_id=68303>
>>>>
>>>>
>>>>
>>>>
>>>> Best regards, Oliver.
>
>>
>>>> ------------------------------**------------------------------**
>>>> ---------
>>>>
>>>>
>>>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.**apache.org<qa...@openoffice.apache.org>
>
>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>>>
>>>>
>>> ------------------------------**------------------------------**
>>> ---------
>>>
>>>
>>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.**apache.org<qa...@openoffice.apache.org>
>
>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>>
>>>
>>
>> ------------------------------**------------------------------**---------
>>
>>
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<de...@openoffice.apache.org>
>
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.**apache.org<qa...@openoffice.apache.org>
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
>
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 21.06.2013 08:57, Jürgen Schmidt wrote:
> On 6/20/13 8:01 PM, Edwin Sharp wrote:
>> Yes. please allow to share the following objections: 1. in general,
>> bugs shouldn't be rated
>
> I disagree here and you always rate issues starting with setting a
> priority. And as always you can't fix them all with a fix number of
> developers. It simply doesn't work. That means you have to
> prioritize and that is quite normal.
>
>> 2. most are crashes - "release blocker" can be other than crash -
>> i.e. copy chart from Calc into Writer results in chart area without
>> curve. this is a huge bug that doesn't involve a crash
> exactly and we have defined some criteria for issues, crashes, data
> loss and security issues have always high priority. Regressions are
> also very important especially when often used functionality is
> broken.
>
> It is documented in the wiki but I haven't the reference in place
> yet, have to look for it.
>
>> 3. with all the respect to Norwegian users, print dialog too wide
>> is a negligible problem
> not for this specific user group and the fix is already available.
>
>> 4. there should be a documented evidence to the bug evaluation
>> process, based on approved SOP
> I am not sure if I understand you here
>
>> 5. the general public has no declared release date - no need to
>> rush as there is no commitment to fulfill
> no but the project have committed to a release date and I believe
> the majority of the community support the new release. You have to
> set a date and have define what is important for this date. You can
> always do more and can fix more issues but that won't work very
> well.
>
>> 6. "minor" bugs should also get attention and be targeted
> definitely but not short in front of a release. And of course nobody
> prevent anybody from fixing such issues. We have a lot of them, many
> are probably not longer valid and can be closed, other are not easy
> to fix and so on. A good start would be of course to simply check
> older issues if they are still valid or not.
>
>> 7. the judgment of introducing the sidebar with so many pending
>> bugs should be justified to demonstrate openness
> as far as I know we haven't pending bugs here. Don't mix this up
> with improvement or feature requests. Maybe I don't understand you
> and you can explain it again
>
>> 8. RTF is rarely used today - no reason for two appearances in the
>> list
> RTF is as far as I known relevant for Ms interoperability in general
> and important for other MS filters as well. Even the pure format is
> not used often the functionality is important. If somebody knows more
> please correct me.
>
Just some more background on the RTF filter:
The RTF format is used on copy-and-paste actions between OpenOffice
applications and other applications.
For example, issue 120023 is caused by a defect in the RTF filter.
Best regards, Oliver.
>> 9. Are there no "critical" bugs in Math, Draw and Base?
> probably yes and probably many other critical bugs in other areas
> that are not detected yet or not proposed as showstopper
>
>> 10. Are there enough volunteers to treat these "release blockers"
>> on time?
> we hope we can fix them all but volunteers are never enough ;-)
>
> If you think that other issue should be showstopper as well, please
> propose them on the dev list and we can discuss them. That's the way
> how we want to handle it
>
> Further discussion should take place on the dev list
>
>
> Juergen
>
>
>> Thank you
>>
>>
>>
>> On Thu, Jun 20, 2013, at 18:09, Oliver-Rainer Wittmann wrote:
>>> Hi, Any objections to mark these issues as release blocker?
>>>
>>> [1]
>>> https://issues.apache.org/ooo/buglist.cgi?quicksearch=120250%20120443%20120513%20120559%20121008%20121143%20121256%20121435%20121479%20121751%20121925%20121968%20121977%20122163%20122300%20121772&list_id=68303
>>>
>>>
>>>
>>>
Best regards, Oliver.
>>>
>>> ---------------------------------------------------------------------
>>>
>>>
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Andre Fischer <aw...@gmail.com>.
On 21.06.2013 08:57, Jürgen Schmidt wrote:
> On 6/20/13 8:01 PM, Edwin Sharp wrote:
>> Yes.
>> please allow to share the following objections:
>> 1. in general, bugs shouldn't be rated
> I disagree here and you always rate issues starting with setting a
> priority. And as always you can't fix them all with a fix number of
> developers. It simply doesn't work. That means you have to prioritize
> and that is quite normal.
>
>> 2. most are crashes - "release blocker" can be other than crash - i.e. copy chart from Calc into Writer results in chart area without curve. this is a huge bug that doesn't involve a crash
> exactly and we have defined some criteria for issues, crashes, data loss
> and security issues have always high priority. Regressions are also very
> important especially when often used functionality is broken.
>
> It is documented in the wiki but I haven't the reference in place yet,
> have to look for it.
>
>> 3. with all the respect to Norwegian users, print dialog too wide is a negligible problem
> not for this specific user group and the fix is already available.
>
>> 4. there should be a documented evidence to the bug evaluation process, based on approved SOP
> I am not sure if I understand you here
>
>> 5. the general public has no declared release date - no need to rush as there is no commitment to fulfill
> no but the project have committed to a release date and I believe the
> majority of the community support the new release. You have to set a
> date and have define what is important for this date. You can always do
> more and can fix more issues but that won't work very well.
>
>> 6. "minor" bugs should also get attention and be targeted
> definitely but not short in front of a release. And of course nobody
> prevent anybody from fixing such issues. We have a lot of them, many are
> probably not longer valid and can be closed, other are not easy to fix
> and so on. A good start would be of course to simply check older issues
> if they are still valid or not.
>
>> 7. the judgment of introducing the sidebar with so many pending bugs should be justified to demonstrate openness
I don't understand the second part of the sentence.
I have divided the bugs regarding the sidebar into three categories. For
each category exists one meta issue:
1. Bugs that have to be fixed for the 4.0 release are covered by issue
121420 (https://issues.apache.org/ooo/show_bug.cgi?id=121420)
At the moment there are no open bugs blocking it.
2. Bugs that should be addressed after the 4.0 release are marked as
blockers of issue 122364
(https://issues.apache.org/ooo/show_bug.cgi?id=122364)
These are bugs that don't have a big impact on the majority of users or
would require a tremendous amount of work to fix them. There are six
bugs in this category.
3. Requested enhancements form the third category described by issue
122257 (https://issues.apache.org/ooo/show_bug.cgi?id=122257). There
are 18 feature requests or enhancements.
As said above, only bugs in the first category will be fixed for the 4.0
release. At the moment there are no such open bugs.
-Andre
> as far as I know we haven't pending bugs here. Don't mix this up with
> improvement or feature requests. Maybe I don't understand you and you
> can explain it again
>
>> 8. RTF is rarely used today - no reason for two appearances in the list
> RTF is as far as I known relevant for Ms interoperability in general and
> important for other MS filters as well. Even the pure format is not used
> often the functionality is important. If somebody knows more please
> correct me.
>
>> 9. Are there no "critical" bugs in Math, Draw and Base?
> probably yes and probably many other critical bugs in other areas that
> are not detected yet or not proposed as showstopper
>
>> 10. Are there enough volunteers to treat these "release blockers" on time?
> we hope we can fix them all but volunteers are never enough ;-)
>
> If you think that other issue should be showstopper as well, please
> propose them on the dev list and we can discuss them. That's the way how
> we want to handle it
>
> Further discussion should take place on the dev list
>
>
> Juergen
>
>
>> Thank you
>>
>>
>>
>> On Thu, Jun 20, 2013, at 18:09, Oliver-Rainer Wittmann wrote:
>>> Hi,
>>> Any objections to mark these issues as release blocker?
>>>
>>> [1]
>>> https://issues.apache.org/ooo/buglist.cgi?quicksearch=120250%20120443%20120513%20120559%20121008%20121143%20121256%20121435%20121479%20121751%20121925%20121968%20121977%20122163%20122300%20121772&list_id=68303
>>>
>>>
>>> Best regards, Oliver.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Andre Fischer <aw...@gmail.com>.
On 21.06.2013 08:57, Jürgen Schmidt wrote:
> On 6/20/13 8:01 PM, Edwin Sharp wrote:
>> Yes.
>> please allow to share the following objections:
>> 1. in general, bugs shouldn't be rated
> I disagree here and you always rate issues starting with setting a
> priority. And as always you can't fix them all with a fix number of
> developers. It simply doesn't work. That means you have to prioritize
> and that is quite normal.
>
>> 2. most are crashes - "release blocker" can be other than crash - i.e. copy chart from Calc into Writer results in chart area without curve. this is a huge bug that doesn't involve a crash
> exactly and we have defined some criteria for issues, crashes, data loss
> and security issues have always high priority. Regressions are also very
> important especially when often used functionality is broken.
>
> It is documented in the wiki but I haven't the reference in place yet,
> have to look for it.
>
>> 3. with all the respect to Norwegian users, print dialog too wide is a negligible problem
> not for this specific user group and the fix is already available.
>
>> 4. there should be a documented evidence to the bug evaluation process, based on approved SOP
> I am not sure if I understand you here
>
>> 5. the general public has no declared release date - no need to rush as there is no commitment to fulfill
> no but the project have committed to a release date and I believe the
> majority of the community support the new release. You have to set a
> date and have define what is important for this date. You can always do
> more and can fix more issues but that won't work very well.
>
>> 6. "minor" bugs should also get attention and be targeted
> definitely but not short in front of a release. And of course nobody
> prevent anybody from fixing such issues. We have a lot of them, many are
> probably not longer valid and can be closed, other are not easy to fix
> and so on. A good start would be of course to simply check older issues
> if they are still valid or not.
>
>> 7. the judgment of introducing the sidebar with so many pending bugs should be justified to demonstrate openness
> as far as I know we haven't pending bugs here. Don't mix this up with
> improvement or feature requests. Maybe I don't understand you and you
> can explain it again
>
>> 8. RTF is rarely used today - no reason for two appearances in the list
> RTF is as far as I known relevant for Ms interoperability in general and
> important for other MS filters as well. Even the pure format is not used
> often the functionality is important. If somebody knows more please
> correct me.
>
>> 9. Are there no "critical" bugs in Math, Draw and Base?
> probably yes and probably many other critical bugs in other areas that
> are not detected yet or not proposed as showstopper
I have just make a quick check how many bugs belong to which area.
Bugzilla is currently down for its daily maintenance (or whatever) so
there may be errors.
Writer, 8 bugs: 120250, 120513, 121143, 121435, 121479, 121751, 121925,
121977
Calc, 1 bug: 121008
Impress, 2 bugs: 121256, 120559
General, 4 bugs: 120443, 121968, 122163, 122300
So, half of the bugs where found in Writer. These numbers are not
unexpected. Writer is the application that is used by most of our users
(but I don't have the numbers to prove it, does anybody else?). Math,
Draw and Base are our least used applications. I would just have
expected a few more bugs for Calc. But the total number of bugs is not
very large and a statistical analysis not really valid.
-Andre
>
>> 10. Are there enough volunteers to treat these "release blockers" on time?
> we hope we can fix them all but volunteers are never enough ;-)
>
> If you think that other issue should be showstopper as well, please
> propose them on the dev list and we can discuss them. That's the way how
> we want to handle it
>
> Further discussion should take place on the dev list
>
>
> Juergen
>
>
>> Thank you
>>
>>
>>
>> On Thu, Jun 20, 2013, at 18:09, Oliver-Rainer Wittmann wrote:
>>> Hi,
>>> Any objections to mark these issues as release blocker?
>>>
>>> [1]
>>> https://issues.apache.org/ooo/buglist.cgi?quicksearch=120250%20120443%20120513%20120559%20121008%20121143%20121256%20121435%20121479%20121751%20121925%20121968%20121977%20122163%20122300%20121772&list_id=68303
>>>
>>>
>>> Best regards, Oliver.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 21.06.2013 08:57, Jürgen Schmidt wrote:
> On 6/20/13 8:01 PM, Edwin Sharp wrote:
>> Yes. please allow to share the following objections: 1. in general,
>> bugs shouldn't be rated
>
> I disagree here and you always rate issues starting with setting a
> priority. And as always you can't fix them all with a fix number of
> developers. It simply doesn't work. That means you have to
> prioritize and that is quite normal.
>
>> 2. most are crashes - "release blocker" can be other than crash -
>> i.e. copy chart from Calc into Writer results in chart area without
>> curve. this is a huge bug that doesn't involve a crash
> exactly and we have defined some criteria for issues, crashes, data
> loss and security issues have always high priority. Regressions are
> also very important especially when often used functionality is
> broken.
>
> It is documented in the wiki but I haven't the reference in place
> yet, have to look for it.
>
>> 3. with all the respect to Norwegian users, print dialog too wide
>> is a negligible problem
> not for this specific user group and the fix is already available.
>
>> 4. there should be a documented evidence to the bug evaluation
>> process, based on approved SOP
> I am not sure if I understand you here
>
>> 5. the general public has no declared release date - no need to
>> rush as there is no commitment to fulfill
> no but the project have committed to a release date and I believe
> the majority of the community support the new release. You have to
> set a date and have define what is important for this date. You can
> always do more and can fix more issues but that won't work very
> well.
>
>> 6. "minor" bugs should also get attention and be targeted
> definitely but not short in front of a release. And of course nobody
> prevent anybody from fixing such issues. We have a lot of them, many
> are probably not longer valid and can be closed, other are not easy
> to fix and so on. A good start would be of course to simply check
> older issues if they are still valid or not.
>
>> 7. the judgment of introducing the sidebar with so many pending
>> bugs should be justified to demonstrate openness
> as far as I know we haven't pending bugs here. Don't mix this up
> with improvement or feature requests. Maybe I don't understand you
> and you can explain it again
>
>> 8. RTF is rarely used today - no reason for two appearances in the
>> list
> RTF is as far as I known relevant for Ms interoperability in general
> and important for other MS filters as well. Even the pure format is
> not used often the functionality is important. If somebody knows more
> please correct me.
>
Just some more background on the RTF filter:
The RTF format is used on copy-and-paste actions between OpenOffice
applications and other applications.
For example, issue 120023 is caused by a defect in the RTF filter.
Best regards, Oliver.
>> 9. Are there no "critical" bugs in Math, Draw and Base?
> probably yes and probably many other critical bugs in other areas
> that are not detected yet or not proposed as showstopper
>
>> 10. Are there enough volunteers to treat these "release blockers"
>> on time?
> we hope we can fix them all but volunteers are never enough ;-)
>
> If you think that other issue should be showstopper as well, please
> propose them on the dev list and we can discuss them. That's the way
> how we want to handle it
>
> Further discussion should take place on the dev list
>
>
> Juergen
>
>
>> Thank you
>>
>>
>>
>> On Thu, Jun 20, 2013, at 18:09, Oliver-Rainer Wittmann wrote:
>>> Hi, Any objections to mark these issues as release blocker?
>>>
>>> [1]
>>> https://issues.apache.org/ooo/buglist.cgi?quicksearch=120250%20120443%20120513%20120559%20121008%20121143%20121256%20121435%20121479%20121751%20121925%20121968%20121977%20122163%20122300%20121772&list_id=68303
>>>
>>>
>>>
>>>
Best regards, Oliver.
>>>
>>> ---------------------------------------------------------------------
>>>
>>>
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Edwin Sharp <el...@mail-page.com>.
Thank you for this feedback.
On Fri, Jun 21, 2013, at 9:57, Jürgen Schmidt wrote:
> On 6/20/13 8:01 PM, Edwin Sharp wrote:
> > Yes.
> > please allow to share the following objections:
> > 1. in general, bugs shouldn't be rated
>
> I disagree here and you always rate issues starting with setting a
> priority. And as always you can't fix them all with a fix number of
> developers. It simply doesn't work. That means you have to prioritize
> and that is quite normal.
>
> > 2. most are crashes - "release blocker" can be other than crash - i.e. copy chart from Calc into Writer results in chart area without curve. this is a huge bug that doesn't involve a crash
> exactly and we have defined some criteria for issues, crashes, data loss
> and security issues have always high priority. Regressions are also very
> important especially when often used functionality is broken.
>
> It is documented in the wiki but I haven't the reference in place yet,
> have to look for it.
>
> > 3. with all the respect to Norwegian users, print dialog too wide is a negligible problem
> not for this specific user group and the fix is already available.
>
> > 4. there should be a documented evidence to the bug evaluation process, based on approved SOP
> I am not sure if I understand you here
>
> > 5. the general public has no declared release date - no need to rush as there is no commitment to fulfill
> no but the project have committed to a release date and I believe the
> majority of the community support the new release. You have to set a
> date and have define what is important for this date. You can always do
> more and can fix more issues but that won't work very well.
>
> > 6. "minor" bugs should also get attention and be targeted
> definitely but not short in front of a release. And of course nobody
> prevent anybody from fixing such issues. We have a lot of them, many are
> probably not longer valid and can be closed, other are not easy to fix
> and so on. A good start would be of course to simply check older issues
> if they are still valid or not.
>
> > 7. the judgment of introducing the sidebar with so many pending bugs should be justified to demonstrate openness
> as far as I know we haven't pending bugs here. Don't mix this up with
> improvement or feature requests. Maybe I don't understand you and you
> can explain it again
>
> > 8. RTF is rarely used today - no reason for two appearances in the list
> RTF is as far as I known relevant for Ms interoperability in general and
> important for other MS filters as well. Even the pure format is not used
> often the functionality is important. If somebody knows more please
> correct me.
>
> > 9. Are there no "critical" bugs in Math, Draw and Base?
> probably yes and probably many other critical bugs in other areas that
> are not detected yet or not proposed as showstopper
>
> > 10. Are there enough volunteers to treat these "release blockers" on time?
> we hope we can fix them all but volunteers are never enough ;-)
>
> If you think that other issue should be showstopper as well, please
> propose them on the dev list and we can discuss them. That's the way how
> we want to handle it
>
> Further discussion should take place on the dev list
>
>
> Juergen
>
>
> > Thank you
> >
> >
> >
> > On Thu, Jun 20, 2013, at 18:09, Oliver-Rainer Wittmann wrote:
> >> Hi,
> >> Any objections to mark these issues as release blocker?
> >>
> >> [1]
> >> https://issues.apache.org/ooo/buglist.cgi?quicksearch=120250%20120443%20120513%20120559%20121008%20121143%20121256%20121435%20121479%20121751%20121925%20121968%20121977%20122163%20122300%20121772&list_id=68303
> >>
> >>
> >> Best regards, Oliver.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: qa-help@openoffice.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: qa-help@openoffice.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 6/20/13 8:01 PM, Edwin Sharp wrote:
> Yes.
> please allow to share the following objections:
> 1. in general, bugs shouldn't be rated
I disagree here and you always rate issues starting with setting a
priority. And as always you can't fix them all with a fix number of
developers. It simply doesn't work. That means you have to prioritize
and that is quite normal.
> 2. most are crashes - "release blocker" can be other than crash - i.e. copy chart from Calc into Writer results in chart area without curve. this is a huge bug that doesn't involve a crash
exactly and we have defined some criteria for issues, crashes, data loss
and security issues have always high priority. Regressions are also very
important especially when often used functionality is broken.
It is documented in the wiki but I haven't the reference in place yet,
have to look for it.
> 3. with all the respect to Norwegian users, print dialog too wide is a negligible problem
not for this specific user group and the fix is already available.
> 4. there should be a documented evidence to the bug evaluation process, based on approved SOP
I am not sure if I understand you here
> 5. the general public has no declared release date - no need to rush as there is no commitment to fulfill
no but the project have committed to a release date and I believe the
majority of the community support the new release. You have to set a
date and have define what is important for this date. You can always do
more and can fix more issues but that won't work very well.
> 6. "minor" bugs should also get attention and be targeted
definitely but not short in front of a release. And of course nobody
prevent anybody from fixing such issues. We have a lot of them, many are
probably not longer valid and can be closed, other are not easy to fix
and so on. A good start would be of course to simply check older issues
if they are still valid or not.
> 7. the judgment of introducing the sidebar with so many pending bugs should be justified to demonstrate openness
as far as I know we haven't pending bugs here. Don't mix this up with
improvement or feature requests. Maybe I don't understand you and you
can explain it again
> 8. RTF is rarely used today - no reason for two appearances in the list
RTF is as far as I known relevant for Ms interoperability in general and
important for other MS filters as well. Even the pure format is not used
often the functionality is important. If somebody knows more please
correct me.
> 9. Are there no "critical" bugs in Math, Draw and Base?
probably yes and probably many other critical bugs in other areas that
are not detected yet or not proposed as showstopper
> 10. Are there enough volunteers to treat these "release blockers" on time?
we hope we can fix them all but volunteers are never enough ;-)
If you think that other issue should be showstopper as well, please
propose them on the dev list and we can discuss them. That's the way how
we want to handle it
Further discussion should take place on the dev list
Juergen
> Thank you
>
>
>
> On Thu, Jun 20, 2013, at 18:09, Oliver-Rainer Wittmann wrote:
>> Hi,
>> Any objections to mark these issues as release blocker?
>>
>> [1]
>> https://issues.apache.org/ooo/buglist.cgi?quicksearch=120250%20120443%20120513%20120559%20121008%20121143%20121256%20121435%20121479%20121751%20121925%20121968%20121977%20122163%20122300%20121772&list_id=68303
>>
>>
>> Best regards, Oliver.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Rob Weir <ro...@apache.org>.
On Thu, Jun 20, 2013 at 2:01 PM, Edwin Sharp <el...@mail-page.com> wrote:
> Yes.
> please allow to share the following objections:
> 1. in general, bugs shouldn't be rated
> 2. most are crashes - "release blocker" can be other than crash - i.e. copy chart from Calc into Writer results in chart area without curve. this is a huge bug that doesn't involve a crash
> 3. with all the respect to Norwegian users, print dialog too wide is a negligible problem
> 4. there should be a documented evidence to the bug evaluation process, based on approved SOP
> 5. the general public has no declared release date - no need to rush as there is no commitment to fulfill
> 6. "minor" bugs should also get attention and be targeted
> 7. the judgment of introducing the sidebar with so many pending bugs should be justified to demonstrate openness
> 8. RTF is rarely used today - no reason for two appearances in the list
> 9. Are there no "critical" bugs in Math, Draw and Base?
> 10. Are there enough volunteers to treat these "release blockers" on time?
> Thank you
>
We have a debate like this before every release. There are items
worth considering:
1. All software has bugs.
2. The more you test the more bugs you find. (Every class of testers
finds a new class of bugs)
3. The time needed to fix all bugs in OpenOffice is measured in years,
not weeks.
4. AOO 4.0 contains fixes to many, many bugs already, including fixes
for serious bugs from AOO 3.4.1 and earlier.
So there is no one perfect answer. Spending more time to fix bugs in
AOO 4.0 does two things:
1. Improves the quality of AOO 4.0, which is good for future AOO 4.0 users.
2. Delays the delivery of the existing bug fixes and new features,
which is bad for AOO 3.4 users (around 50 million of them)
So it is important to watch out for quality and the satisfaction of
our users. But we should also consider the 3.4 users, who are
patiently waiting for bug fixes that have already been made.
(Some might say that the solution here is to have a 3.4.2 release,
etc. But that doesn't change anything. You still have the tension
between those who want to fix more bugs (there are always more) and
those who want to release the fixes we already have).
Since we are weighing the value of potential new bug fixes against the
value of already made bug fixes, some sort of bug prioritization is
reasonable, I think.
The other thing to note is that bug fixes are not risk-free. Studies
have shown that 25% of defects in code are side effects of changes to
other areas of the code, including bug fixes. So once we have
completed the regression test passes we need to be very selective
about what bugs we fixed and the potential impact of the fix.
Changing code after regression is risky, since we have no full test
pass left to find any new bugs introduced.
It is likely we have a 4.1 (or even 4.0.1) release later this year.
If we want to focus on bug fixing there then that could be possible,
but we'd want to do that *before* a regression test pass, so we can
ensure that no new bugs are introduced.
I agree with you that we are not date-driven. Quality is what
matters. But quality in the abstract is not the focus. It is the
quality that end-users actually have on their machines, their actual
experience. And the quality they experience does not change until we
actually release a new version.
Regards,
-Rob
>
>
> On Thu, Jun 20, 2013, at 18:09, Oliver-Rainer Wittmann wrote:
>> Hi,
>> Any objections to mark these issues as release blocker?
>>
>> [1]
>> https://issues.apache.org/ooo/buglist.cgi?quicksearch=120250%20120443%20120513%20120559%20121008%20121143%20121256%20121435%20121479%20121751%20121925%20121968%20121977%20122163%20122300%20121772&list_id=68303
>>
>>
>> Best regards, Oliver.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 6/20/13 8:01 PM, Edwin Sharp wrote:
> Yes.
> please allow to share the following objections:
> 1. in general, bugs shouldn't be rated
I disagree here and you always rate issues starting with setting a
priority. And as always you can't fix them all with a fix number of
developers. It simply doesn't work. That means you have to prioritize
and that is quite normal.
> 2. most are crashes - "release blocker" can be other than crash - i.e. copy chart from Calc into Writer results in chart area without curve. this is a huge bug that doesn't involve a crash
exactly and we have defined some criteria for issues, crashes, data loss
and security issues have always high priority. Regressions are also very
important especially when often used functionality is broken.
It is documented in the wiki but I haven't the reference in place yet,
have to look for it.
> 3. with all the respect to Norwegian users, print dialog too wide is a negligible problem
not for this specific user group and the fix is already available.
> 4. there should be a documented evidence to the bug evaluation process, based on approved SOP
I am not sure if I understand you here
> 5. the general public has no declared release date - no need to rush as there is no commitment to fulfill
no but the project have committed to a release date and I believe the
majority of the community support the new release. You have to set a
date and have define what is important for this date. You can always do
more and can fix more issues but that won't work very well.
> 6. "minor" bugs should also get attention and be targeted
definitely but not short in front of a release. And of course nobody
prevent anybody from fixing such issues. We have a lot of them, many are
probably not longer valid and can be closed, other are not easy to fix
and so on. A good start would be of course to simply check older issues
if they are still valid or not.
> 7. the judgment of introducing the sidebar with so many pending bugs should be justified to demonstrate openness
as far as I know we haven't pending bugs here. Don't mix this up with
improvement or feature requests. Maybe I don't understand you and you
can explain it again
> 8. RTF is rarely used today - no reason for two appearances in the list
RTF is as far as I known relevant for Ms interoperability in general and
important for other MS filters as well. Even the pure format is not used
often the functionality is important. If somebody knows more please
correct me.
> 9. Are there no "critical" bugs in Math, Draw and Base?
probably yes and probably many other critical bugs in other areas that
are not detected yet or not proposed as showstopper
> 10. Are there enough volunteers to treat these "release blockers" on time?
we hope we can fix them all but volunteers are never enough ;-)
If you think that other issue should be showstopper as well, please
propose them on the dev list and we can discuss them. That's the way how
we want to handle it
Further discussion should take place on the dev list
Juergen
> Thank you
>
>
>
> On Thu, Jun 20, 2013, at 18:09, Oliver-Rainer Wittmann wrote:
>> Hi,
>> Any objections to mark these issues as release blocker?
>>
>> [1]
>> https://issues.apache.org/ooo/buglist.cgi?quicksearch=120250%20120443%20120513%20120559%20121008%20121143%20121256%20121435%20121479%20121751%20121925%20121968%20121977%20122163%20122300%20121772&list_id=68303
>>
>>
>> Best regards, Oliver.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Edwin Sharp <el...@mail-page.com>.
Yes.
please allow to share the following objections:
1. in general, bugs shouldn't be rated
2. most are crashes - "release blocker" can be other than crash - i.e. copy chart from Calc into Writer results in chart area without curve. this is a huge bug that doesn't involve a crash
3. with all the respect to Norwegian users, print dialog too wide is a negligible problem
4. there should be a documented evidence to the bug evaluation process, based on approved SOP
5. the general public has no declared release date - no need to rush as there is no commitment to fulfill
6. "minor" bugs should also get attention and be targeted
7. the judgment of introducing the sidebar with so many pending bugs should be justified to demonstrate openness
8. RTF is rarely used today - no reason for two appearances in the list
9. Are there no "critical" bugs in Math, Draw and Base?
10. Are there enough volunteers to treat these "release blockers" on time?
Thank you
On Thu, Jun 20, 2013, at 18:09, Oliver-Rainer Wittmann wrote:
> Hi,
> Any objections to mark these issues as release blocker?
>
> [1]
> https://issues.apache.org/ooo/buglist.cgi?quicksearch=120250%20120443%20120513%20120559%20121008%20121143%20121256%20121435%20121479%20121751%20121925%20121968%20121977%20122163%20122300%20121772&list_id=68303
>
>
> Best regards, Oliver.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 22.06.2013 09:55, Oliver-Rainer Wittmann wrote:
> Hi,
>
> Am 20.06.2013 um 17:09 schrieb Oliver-Rainer Wittmann <or...@googlemail.com>:
>
>> Hi,
>>
>> On 06.06.2013 13:54, Yuzhen Fan wrote:
>>> Hi All,
>>>
>>> Here is the list of identified candidates[1]/[2] which are proposed to
>>> be 4.0.0 release blockers. Please indicate your selections for release
>>> blockers by giving 1 vote to 1 bug (the vote field is beside the
>>> importance field, in a bug form). We hope to get the vote score this
>>> week, any bugs you think most critical to you, please bring out and
>>> let's discuss.
>>>
>>> [1]
>>> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=4.0.0_release_blocker%3F&sharer_id=249289&list_id=64740
>>> [2] Also attach the file for the list
>>> (AOO4.0.0_release_blocker_candidates.ods)
>>
>> Armin, Jürgen, Andre and myself reviewed in the last days the list of issues which had been requested for release blocker (release blocker flag = '?') and are not solved.
>>
>> We propose the following issues as release blockers [1]:
>> - 120250
>> - 120443 (actually 121772 - 120443 is a dup. of this one)
>> - 120513
>> - 120559
>> - 121008
>> - 121143
>> - 121256
>> - 121435
>
> Has been fixed in the meanwhile. Thus, it can removed from the list.
This statement is only meant for 121435
just to avoid unambigious interpretation ;-)
Best regards, Oliver.
>
> Best regards, Oliver.
>
>> - 121479
>> - 121751
>> - 121925
>> - 121968
>> - 121977
>> - 122163
>> - 122300
>>
>> Any objections to mark these issues as release blocker?
>>
>> [1] https://issues.apache.org/ooo/buglist.cgi?quicksearch=120250%20120443%20120513%20120559%20121008%20121143%20121256%20121435%20121479%20121751%20121925%20121968%20121977%20122163%20122300%20121772&list_id=68303
>>
>>
>> Best regards, Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 22.06.2013 09:55, Oliver-Rainer Wittmann wrote:
> Hi,
>
> Am 20.06.2013 um 17:09 schrieb Oliver-Rainer Wittmann <or...@googlemail.com>:
>
>> Hi,
>>
>> On 06.06.2013 13:54, Yuzhen Fan wrote:
>>> Hi All,
>>>
>>> Here is the list of identified candidates[1]/[2] which are proposed to
>>> be 4.0.0 release blockers. Please indicate your selections for release
>>> blockers by giving 1 vote to 1 bug (the vote field is beside the
>>> importance field, in a bug form). We hope to get the vote score this
>>> week, any bugs you think most critical to you, please bring out and
>>> let's discuss.
>>>
>>> [1]
>>> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=4.0.0_release_blocker%3F&sharer_id=249289&list_id=64740
>>> [2] Also attach the file for the list
>>> (AOO4.0.0_release_blocker_candidates.ods)
>>
>> Armin, Jürgen, Andre and myself reviewed in the last days the list of issues which had been requested for release blocker (release blocker flag = '?') and are not solved.
>>
>> We propose the following issues as release blockers [1]:
>> - 120250
>> - 120443 (actually 121772 - 120443 is a dup. of this one)
>> - 120513
>> - 120559
>> - 121008
>> - 121143
>> - 121256
>> - 121435
>
> Has been fixed in the meanwhile. Thus, it can removed from the list.
This statement is only meant for 121435
just to avoid unambigious interpretation ;-)
Best regards, Oliver.
>
> Best regards, Oliver.
>
>> - 121479
>> - 121751
>> - 121925
>> - 121968
>> - 121977
>> - 122163
>> - 122300
>>
>> Any objections to mark these issues as release blocker?
>>
>> [1] https://issues.apache.org/ooo/buglist.cgi?quicksearch=120250%20120443%20120513%20120559%20121008%20121143%20121256%20121435%20121479%20121751%20121925%20121968%20121977%20122163%20122300%20121772&list_id=68303
>>
>>
>> Best regards, Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
Am 20.06.2013 um 17:09 schrieb Oliver-Rainer Wittmann <or...@googlemail.com>:
> Hi,
>
> On 06.06.2013 13:54, Yuzhen Fan wrote:
>> Hi All,
>>
>> Here is the list of identified candidates[1]/[2] which are proposed to
>> be 4.0.0 release blockers. Please indicate your selections for release
>> blockers by giving 1 vote to 1 bug (the vote field is beside the
>> importance field, in a bug form). We hope to get the vote score this
>> week, any bugs you think most critical to you, please bring out and
>> let's discuss.
>>
>> [1]
>> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=4.0.0_release_blocker%3F&sharer_id=249289&list_id=64740
>> [2] Also attach the file for the list
>> (AOO4.0.0_release_blocker_candidates.ods)
>
> Armin, Jürgen, Andre and myself reviewed in the last days the list of issues which had been requested for release blocker (release blocker flag = '?') and are not solved.
>
> We propose the following issues as release blockers [1]:
> - 120250
> - 120443 (actually 121772 - 120443 is a dup. of this one)
> - 120513
> - 120559
> - 121008
> - 121143
> - 121256
> - 121435
Has been fixed in the meanwhile. Thus, it can removed from the list.
Best regards, Oliver.
> - 121479
> - 121751
> - 121925
> - 121968
> - 121977
> - 122163
> - 122300
>
> Any objections to mark these issues as release blocker?
>
> [1] https://issues.apache.org/ooo/buglist.cgi?quicksearch=120250%20120443%20120513%20120559%20121008%20121143%20121256%20121435%20121479%20121751%20121925%20121968%20121977%20122163%20122300%20121772&list_id=68303
>
>
> Best regards, Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
Am 20.06.2013 um 17:09 schrieb Oliver-Rainer Wittmann <or...@googlemail.com>:
> Hi,
>
> On 06.06.2013 13:54, Yuzhen Fan wrote:
>> Hi All,
>>
>> Here is the list of identified candidates[1]/[2] which are proposed to
>> be 4.0.0 release blockers. Please indicate your selections for release
>> blockers by giving 1 vote to 1 bug (the vote field is beside the
>> importance field, in a bug form). We hope to get the vote score this
>> week, any bugs you think most critical to you, please bring out and
>> let's discuss.
>>
>> [1]
>> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=4.0.0_release_blocker%3F&sharer_id=249289&list_id=64740
>> [2] Also attach the file for the list
>> (AOO4.0.0_release_blocker_candidates.ods)
>
> Armin, Jürgen, Andre and myself reviewed in the last days the list of issues which had been requested for release blocker (release blocker flag = '?') and are not solved.
>
> We propose the following issues as release blockers [1]:
> - 120250
> - 120443 (actually 121772 - 120443 is a dup. of this one)
> - 120513
> - 120559
> - 121008
> - 121143
> - 121256
> - 121435
Has been fixed in the meanwhile. Thus, it can removed from the list.
Best regards, Oliver.
> - 121479
> - 121751
> - 121925
> - 121968
> - 121977
> - 122163
> - 122300
>
> Any objections to mark these issues as release blocker?
>
> [1] https://issues.apache.org/ooo/buglist.cgi?quicksearch=120250%20120443%20120513%20120559%20121008%20121143%20121256%20121435%20121479%20121751%20121925%20121968%20121977%20122163%20122300%20121772&list_id=68303
>
>
> Best regards, Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 06.06.2013 13:54, Yuzhen Fan wrote:
> Hi All,
>
> Here is the list of identified candidates[1]/[2] which are proposed to
> be 4.0.0 release blockers. Please indicate your selections for release
> blockers by giving 1 vote to 1 bug (the vote field is beside the
> importance field, in a bug form). We hope to get the vote score this
> week, any bugs you think most critical to you, please bring out and
> let's discuss.
>
> [1]
> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=4.0.0_release_blocker%3F&sharer_id=249289&list_id=64740
> [2] Also attach the file for the list
> (AOO4.0.0_release_blocker_candidates.ods)
>
Armin, Jürgen, Andre and myself reviewed in the last days the list of
issues which had been requested for release blocker (release blocker
flag = '?') and are not solved.
We propose the following issues as release blockers [1]:
- 120250
- 120443 (actually 121772 - 120443 is a dup. of this one)
- 120513
- 120559
- 121008
- 121143
- 121256
- 121435
- 121479
- 121751
- 121925
- 121968
- 121977
- 122163
- 122300
Any objections to mark these issues as release blocker?
[1]
https://issues.apache.org/ooo/buglist.cgi?quicksearch=120250%20120443%20120513%20120559%20121008%20121143%20121256%20121435%20121479%20121751%20121925%20121968%20121977%20122163%20122300%20121772&list_id=68303
Best regards, Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 06.06.2013 13:54, Yuzhen Fan wrote:
> Hi All,
>
> Here is the list of identified candidates[1]/[2] which are proposed to
> be 4.0.0 release blockers. Please indicate your selections for release
> blockers by giving 1 vote to 1 bug (the vote field is beside the
> importance field, in a bug form). We hope to get the vote score this
> week, any bugs you think most critical to you, please bring out and
> let's discuss.
>
> [1]
> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=4.0.0_release_blocker%3F&sharer_id=249289&list_id=64740
> [2] Also attach the file for the list
> (AOO4.0.0_release_blocker_candidates.ods)
>
Armin, Jürgen, Andre and myself reviewed in the last days the list of
issues which had been requested for release blocker (release blocker
flag = '?') and are not solved.
We propose the following issues as release blockers [1]:
- 120250
- 120443 (actually 121772 - 120443 is a dup. of this one)
- 120513
- 120559
- 121008
- 121143
- 121256
- 121435
- 121479
- 121751
- 121925
- 121968
- 121977
- 122163
- 122300
Any objections to mark these issues as release blocker?
[1]
https://issues.apache.org/ooo/buglist.cgi?quicksearch=120250%20120443%20120513%20120559%20121008%20121143%20121256%20121435%20121479%20121751%20121925%20121968%20121977%20122163%20122300%20121772&list_id=68303
Best regards, Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Rob Weir <ro...@apache.org>.
On Fri, Jun 7, 2013 at 10:34 AM, I. Park <ip...@gmail.com> wrote:
> Hello Rob,
>
> O.k., I'm not too sure if your "incorrectly marked CONFIRMED" topic
> mentioned below has to do with Bugzilla, but I noticed on couple
> occasions that when filling out new bugs the CONFIRMED is set by
> default. I had to go back a few times and change it to UNCONFIRMED.
>
That's fine. When a tester enters a new bug it probably should be
marked CONFIRMED. That's because testers know what they are doing and
would only enter a bug report for a bug that was real and
reproducible.
-Rob
> Just my two-cents.
>
> I. Park
>
> On Thu, Jun 6, 2013 at 8:33 PM, Rob Weir <ro...@apache.org> wrote:
>> On Thu, Jun 6, 2013 at 8:47 AM, Jürgen Schmidt <jo...@gmail.com> wrote:
>>> On 6/6/13 1:54 PM, Yuzhen Fan wrote:
>>>> Hi All,
>>>>
>>>> Here is the list of identified candidates[1]/[2] which are proposed to
>>>> be 4.0.0 release blockers. Please indicate your selections for release
>>>> blockers by giving 1 vote to 1 bug (the vote field is beside the
>>>> importance field, in a bug form). We hope to get the vote score this
>>>> week, any bugs you think most critical to you, please bring out and
>>>> let's discuss.
>>>
>>> Please wait, I think we have not agreed on this approach. Voting in the
>>> issue is not really helpful. I believe many of these issues can be
>>> removed from list and are probably not valid at all.
>>>
>>> I prefer to discuss showstopper issues on the list as we did for AOO 3.4.
>>>
>>
>> With 3.4 we proposed each release blocker on the list, in its own
>> thread, right? But it is not going the be much better if we start
>> with 90 new threads.
>>
>> It looks like all the proposed release blockers are marked confirmed.
>> A few of them pre-date AOO 3.4, but most are more recent.
>>
>> But with a further look I see some were incorrectly marked
>> "CONFIRMED". I think some volunteers when they first started set that
>> field after trying to confirm a defect, without understanding that
>> this state should only set if the confirmation test was successful.
>> So we need to review the comments on each bug to see which ones are
>> actually reproduced. I'll try to clean up a few tonight while I
>> watch TV.
>>
>> Also, we probably need to prioritize. For example, a "shallow crash"
>> (a crash in a common. top-level operation) is higher priority than a
>> crash that only occurs with a specific malformed document.
>>
>> -Rob
>>
>>> Juergen
>>>
>>>
>>>>
>>>> [1]
>>>> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=4.0.0_release_blocker%3F&sharer_id=249289&list_id=64740
>>>> [2] Also attach the file for the list
>>>> (AOO4.0.0_release_blocker_candidates.ods)
>>>>
>>>> Regards,
>>>> Yu Zhen
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>>>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by "I. Park" <ip...@gmail.com>.
Hello Rob,
O.k., I'm not too sure if your "incorrectly marked CONFIRMED" topic
mentioned below has to do with Bugzilla, but I noticed on couple
occasions that when filling out new bugs the CONFIRMED is set by
default. I had to go back a few times and change it to UNCONFIRMED.
Just my two-cents.
I. Park
On Thu, Jun 6, 2013 at 8:33 PM, Rob Weir <ro...@apache.org> wrote:
> On Thu, Jun 6, 2013 at 8:47 AM, Jürgen Schmidt <jo...@gmail.com> wrote:
>> On 6/6/13 1:54 PM, Yuzhen Fan wrote:
>>> Hi All,
>>>
>>> Here is the list of identified candidates[1]/[2] which are proposed to
>>> be 4.0.0 release blockers. Please indicate your selections for release
>>> blockers by giving 1 vote to 1 bug (the vote field is beside the
>>> importance field, in a bug form). We hope to get the vote score this
>>> week, any bugs you think most critical to you, please bring out and
>>> let's discuss.
>>
>> Please wait, I think we have not agreed on this approach. Voting in the
>> issue is not really helpful. I believe many of these issues can be
>> removed from list and are probably not valid at all.
>>
>> I prefer to discuss showstopper issues on the list as we did for AOO 3.4.
>>
>
> With 3.4 we proposed each release blocker on the list, in its own
> thread, right? But it is not going the be much better if we start
> with 90 new threads.
>
> It looks like all the proposed release blockers are marked confirmed.
> A few of them pre-date AOO 3.4, but most are more recent.
>
> But with a further look I see some were incorrectly marked
> "CONFIRMED". I think some volunteers when they first started set that
> field after trying to confirm a defect, without understanding that
> this state should only set if the confirmation test was successful.
> So we need to review the comments on each bug to see which ones are
> actually reproduced. I'll try to clean up a few tonight while I
> watch TV.
>
> Also, we probably need to prioritize. For example, a "shallow crash"
> (a crash in a common. top-level operation) is higher priority than a
> crash that only occurs with a specific malformed document.
>
> -Rob
>
>> Juergen
>>
>>
>>>
>>> [1]
>>> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=4.0.0_release_blocker%3F&sharer_id=249289&list_id=64740
>>> [2] Also attach the file for the list
>>> (AOO4.0.0_release_blocker_candidates.ods)
>>>
>>> Regards,
>>> Yu Zhen
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Rob Weir <ro...@apache.org>.
On Thu, Jun 6, 2013 at 8:47 AM, Jürgen Schmidt <jo...@gmail.com> wrote:
> On 6/6/13 1:54 PM, Yuzhen Fan wrote:
>> Hi All,
>>
>> Here is the list of identified candidates[1]/[2] which are proposed to
>> be 4.0.0 release blockers. Please indicate your selections for release
>> blockers by giving 1 vote to 1 bug (the vote field is beside the
>> importance field, in a bug form). We hope to get the vote score this
>> week, any bugs you think most critical to you, please bring out and
>> let's discuss.
>
> Please wait, I think we have not agreed on this approach. Voting in the
> issue is not really helpful. I believe many of these issues can be
> removed from list and are probably not valid at all.
>
> I prefer to discuss showstopper issues on the list as we did for AOO 3.4.
>
With 3.4 we proposed each release blocker on the list, in its own
thread, right? But it is not going the be much better if we start
with 90 new threads.
It looks like all the proposed release blockers are marked confirmed.
A few of them pre-date AOO 3.4, but most are more recent.
But with a further look I see some were incorrectly marked
"CONFIRMED". I think some volunteers when they first started set that
field after trying to confirm a defect, without understanding that
this state should only set if the confirmation test was successful.
So we need to review the comments on each bug to see which ones are
actually reproduced. I'll try to clean up a few tonight while I
watch TV.
Also, we probably need to prioritize. For example, a "shallow crash"
(a crash in a common. top-level operation) is higher priority than a
crash that only occurs with a specific malformed document.
-Rob
> Juergen
>
>
>>
>> [1]
>> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=4.0.0_release_blocker%3F&sharer_id=249289&list_id=64740
>> [2] Also attach the file for the list
>> (AOO4.0.0_release_blocker_candidates.ods)
>>
>> Regards,
>> Yu Zhen
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Rob Weir <ro...@apache.org>.
On Thu, Jun 6, 2013 at 8:47 AM, Jürgen Schmidt <jo...@gmail.com> wrote:
> On 6/6/13 1:54 PM, Yuzhen Fan wrote:
>> Hi All,
>>
>> Here is the list of identified candidates[1]/[2] which are proposed to
>> be 4.0.0 release blockers. Please indicate your selections for release
>> blockers by giving 1 vote to 1 bug (the vote field is beside the
>> importance field, in a bug form). We hope to get the vote score this
>> week, any bugs you think most critical to you, please bring out and
>> let's discuss.
>
> Please wait, I think we have not agreed on this approach. Voting in the
> issue is not really helpful. I believe many of these issues can be
> removed from list and are probably not valid at all.
>
> I prefer to discuss showstopper issues on the list as we did for AOO 3.4.
>
With 3.4 we proposed each release blocker on the list, in its own
thread, right? But it is not going the be much better if we start
with 90 new threads.
It looks like all the proposed release blockers are marked confirmed.
A few of them pre-date AOO 3.4, but most are more recent.
But with a further look I see some were incorrectly marked
"CONFIRMED". I think some volunteers when they first started set that
field after trying to confirm a defect, without understanding that
this state should only set if the confirmation test was successful.
So we need to review the comments on each bug to see which ones are
actually reproduced. I'll try to clean up a few tonight while I
watch TV.
Also, we probably need to prioritize. For example, a "shallow crash"
(a crash in a common. top-level operation) is higher priority than a
crash that only occurs with a specific malformed document.
-Rob
> Juergen
>
>
>>
>> [1]
>> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=4.0.0_release_blocker%3F&sharer_id=249289&list_id=64740
>> [2] Also attach the file for the list
>> (AOO4.0.0_release_blocker_candidates.ods)
>>
>> Regards,
>> Yu Zhen
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 6/6/13 1:54 PM, Yuzhen Fan wrote:
> Hi All,
>
> Here is the list of identified candidates[1]/[2] which are proposed to
> be 4.0.0 release blockers. Please indicate your selections for release
> blockers by giving 1 vote to 1 bug (the vote field is beside the
> importance field, in a bug form). We hope to get the vote score this
> week, any bugs you think most critical to you, please bring out and
> let's discuss.
Please wait, I think we have not agreed on this approach. Voting in the
issue is not really helpful. I believe many of these issues can be
removed from list and are probably not valid at all.
I prefer to discuss showstopper issues on the list as we did for AOO 3.4.
Juergen
>
> [1]
> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=4.0.0_release_blocker%3F&sharer_id=249289&list_id=64740
> [2] Also attach the file for the list
> (AOO4.0.0_release_blocker_candidates.ods)
>
> Regards,
> Yu Zhen
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Edwin Sharp <el...@mail-page.com>.
Yes.
As long as we don't waste time implementing kindergarten user interfaces and worrying about compatibility to propriety file formats.
On Thu, Jun 6, 2013, at 18:45, Peter Junge wrote:
> That implies all bugs will get fixed if their priority is above low?
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Peter Junge <pe...@gmx.org>.
That implies all bugs will get fixed if their priority is above low?
On 6/6/2013 11:32 PM, Edwin Sharp wrote:
> Don't be naive.
> A bug with a low priority will never get fixed.
>
> On Thu, Jun 6, 2013, at 16:20, Jürgen Schmidt wrote:
>> On 6/6/13 2:13 PM, Edwin Sharp wrote:
>>
>>
>> you are correct but I believe it is intended to get a priority list. We
>> have long list of bugs and that can't be fixed all. We always get new
>> bugs and have to decide o demand if they are critical or not to move a
>> release.
>>
>> But in general bugs should be fixed all or should be marked as invalid
>> or whatever applies.
>>
>> Juergen
>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: qa-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Edwin Sharp <el...@mail-page.com>.
Don't be naive.
A bug with a low priority will never get fixed.
On Thu, Jun 6, 2013, at 16:20, Jürgen Schmidt wrote:
> On 6/6/13 2:13 PM, Edwin Sharp wrote:
>
>
> you are correct but I believe it is intended to get a priority list. We
> have long list of bugs and that can't be fixed all. We always get new
> bugs and have to decide o demand if they are critical or not to move a
> release.
>
> But in general bugs should be fixed all or should be marked as invalid
> or whatever applies.
>
> Juergen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 6/6/13 2:13 PM, Edwin Sharp wrote:
> I can understand voting for a new logo.
>
> But voting for bugs?
>
> A bug is a bug and needs to be fixed.
you are correct but I believe it is intended to get a priority list. We
have long list of bugs and that can't be fixed all. We always get new
bugs and have to decide o demand if they are critical or not to move a
release.
But in general bugs should be fixed all or should be marked as invalid
or whatever applies.
Juergen
>
>
>
> On Thu, Jun 6, 2013, at 14:54, Yuzhen Fan wrote:
>
> Hi All,
>
> Here is the list of identified candidates[1]/[2] which are proposed to
> be 4.0.0 release blockers. Please indicate your selections for release
> blockers by giving 1 vote to 1 bug (the vote field is beside the
> importance field, in a bug form). We hope to get the vote score this
> week, any bugs you think most critical to you, please bring out and
> let's discuss.
>
> [1]
> [1]https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=ru
> n&namedcmd=4.0.0_release_blocker%3F&sharer_id=249289&list_id=64740
> [2] Also attach the file for the list
> (AOO4.0.0_release_blocker_candidates.ods)
>
> Regards,
> Yu Zhen
>
>
>
> ---------------------------------------------------------------------
>
> To unsubscribe, e-mail: [2]qa-unsubscribe@openoffice.apache.org
>
> For additional commands, e-mail: [3]qa-help@openoffice.apache.org
>
> Email had 1 attachment:
> * AOO4.0.0_release_blocker_candidates.ods
> * 26k (application/vnd.oasis.opendocument.spreadsheet)
>
> References
>
> 1. https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=4.0.0_release_blocker%3F&sharer_id=249289&list_id=64740
> 2. mailto:qa-unsubscribe@openoffice.apache.org
> 3. mailto:qa-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Edwin Sharp <el...@mail-page.com>.
I can understand voting for a new logo.
But voting for bugs?
A bug is a bug and needs to be fixed.
On Thu, Jun 6, 2013, at 14:54, Yuzhen Fan wrote:
Hi All,
Here is the list of identified candidates[1]/[2] which are proposed to
be 4.0.0 release blockers. Please indicate your selections for release
blockers by giving 1 vote to 1 bug (the vote field is beside the
importance field, in a bug form). We hope to get the vote score this
week, any bugs you think most critical to you, please bring out and
let's discuss.
[1]
[1]https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=ru
n&namedcmd=4.0.0_release_blocker%3F&sharer_id=249289&list_id=64740
[2] Also attach the file for the list
(AOO4.0.0_release_blocker_candidates.ods)
Regards,
Yu Zhen
---------------------------------------------------------------------
To unsubscribe, e-mail: [2]qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: [3]qa-help@openoffice.apache.org
Email had 1 attachment:
* AOO4.0.0_release_blocker_candidates.ods
* 26k (application/vnd.oasis.opendocument.spreadsheet)
References
1. https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=4.0.0_release_blocker%3F&sharer_id=249289&list_id=64740
2. mailto:qa-unsubscribe@openoffice.apache.org
3. mailto:qa-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 06.06.2013 15:26, FR web forum wrote:
>> any bugs you think most critical to you, please bring out and let's discuss
> Since AOO 3.4.0, two issues with Calc are poisoning:
> https://issues.apache.org/ooo/show_bug.cgi?id=119177
> https://issues.apache.org/ooo/show_bug.cgi?id=120559
> These 2 bugs may be related.
> And with Writer, emailing wizard sending has behavior random:
> https://issues.apache.org/ooo/show_bug.cgi?id=121143
>
> Many people have been reported it on the FR forum.
> And the advice given is to "install LibO".
>
I will set the release blocker request flag for these issues in order to
have them on discussion table.
Best regards, Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: Triage for AOO 4.0.0 Release Blockers
Posted by FR web forum <oo...@free.fr>.
>any bugs you think most critical to you, please bring out and let's discuss
Since AOO 3.4.0, two issues with Calc are poisoning:
https://issues.apache.org/ooo/show_bug.cgi?id=119177
https://issues.apache.org/ooo/show_bug.cgi?id=120559
These 2 bugs may be related.
And with Writer, emailing wizard sending has behavior random:
https://issues.apache.org/ooo/show_bug.cgi?id=121143
Many people have been reported it on the FR forum.
And the advice given is to "install LibO".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org