Re: [Libreoffice-qa] Cleaning bug list

[Jan Holesovsky]

Hi Joel,

On 2012-06-15 at 23:09 -0700, Joel Madero wrote:

> I brainstormed a bit today and I came up with this flowchart. Looking
> for input. I read through email threads and see that prioritizing bugs
> has been an interesting discussion but as of now looks to be pretty
> unsettled. I'm going to make a similar chart for myself for setting
> bugs status. These kinds of things help me, not sure if they help
> others, but if they do, feel free to comment :)

I like it - thanks for that! :-)

> This is meant as a general guideline, possibly to put up on the wiki
> for future and current QA/Devs to have a bit of focus. It's NOT meant
> to be me forcing everyone to conform as I know that QA requires quite
> a bit of discretion.

Yes, it would be great to have that in the Wiki.

Regards,
Kendy

___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Cleaning bug list

[Petr Mladek]

Joel Madero píše v Pá 15. 06. 2012 v 23:09 -0700:
> I brainstormed a bit today and I came up with this flowchart. Looking
> for input. I read through email threads and see that prioritizing bugs
> has been an interesting discussion but as of now looks to be pretty
> unsettled. I'm going to make a similar chart for myself for setting
> bugs status. These kinds of things help me, not sure if they help
> others, but if they do, feel free to comment :)

Cool! I like the logic. Also the flowchart is easier to understand than
any text.

I only miss regressions handling. There were long discussions that
regressions should have higher priority than other bugs. Also we add the
"regression" flag into Whiteboard.

I think how to best handle it in the flow chart. I would add a
subprocess at the end of each way. The question is what to do in this
subprocess. We need to set "regression" in whiteboard. We also would
want to increase the priority or even severity by one level.

> This is meant as a general guideline, possibly to put up on the wiki
> for future and current QA/Devs to have a bit of focus. It's NOT meant
> to be me forcing everyone to conform as I know that QA requires quite
> a bit of discretion.

Sounds great! It is even impossible to use it as a strict rule because
different people might have different opinion about how each function is
important and how many users are affected. We need to add there a text
that people should not fight about the severities and priorities. They
are just helper tools for developers. Each volunteer developers has its
own opinion anyway ;-)

By the way. I wonder how complicated would be to rotate the chart to
have the main questions from top to bottom. You know, it is much easier
to scroll the page up and down using the mouse wheel.

I am looking forward to see it on the wiki.

Thanks a lot for working on this.


Best Regards,
Petr

___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] New Bugzilla Version Picker items – 2

[Petr Mladek]

Petr Mladek píše v Čt 14. 06. 2012 v 16:40 +0200:
> What about the following scheme?
> 
> Help / AboutBugzilla Picker Info
> --
> 3.6.0.0.alpha13.6.0.0.alpha1
> 3.6.0.0.beta1   3.6.0.0.beta1
> 3.6.0.0.beta2   3.6.0.0.beta2
> 3.6.0.1 3.6.0.1 rc
> 3.6.0.2 3.6.0.2 rc

We agreed on this scheme on the QA call on Friday and we are going to
use it from now on. We will already use it for 3.6.0.0.beta2.

It seems to be the best compromise. It has the advantages:

+ easy to understand for normal users, alpha, beta flags are
  known from other projects, so they set reasonable expectations
+ correct alphabetical sorting in RPM, bugzilla
+ "easy" to parse (alpha/beta strings delimited by dot)

The result is that we could have the same version everywhere: git tags,
source tarballs, about dialog, bugzilla, ...


Please, stop discussion here. I am sure that you could come with many
more inventive solutions but we need to use something in the end :-)


Best Regards,
Petr

___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Bibisecting

[Rainer Bielefeld]

Hi all,

unfortunately I still was too lazy to learn enough concerning 
bibisecting, but it would be great if those who already have some 
experience would do some bibisecting for Bugs where that seems useful:

- LibO 3.5 or later
- Reproduced for Linux

I created a new Whiteboard key word *bibisectrequest*, details how to 
use and how you can get info concerning  every new request immediately 
by feed you find here: 



@Florian:
Can you please invite Gerald?

Best Regards


Rainer

___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Cleaning bug list

[Rainer Bielefeld]

Joel Madero schrieb:

I brainstormed a bit today and I came up with this flowchart.



Hi Joel,

great to see that all in a chart, your conclusions and definitions seem 
plausible.


But the chart also shows the limitations of that concept: It's really 
sophisticated, and no developer will sit at his's desk to decide whether 
he should fix a Bug with Severity=major and Priority=normal before or 
after a bug with  Severity=normal and Priority=high  ;-)


But as you stated, such a chart can give some orientation, and so I 
think it should be shown in the Wiki. Not on one of the current existing 
Pages like BugTriage or similar, but on a page where should gather 
detailed background information what would blow up those pages too much, 
but nevertheless are interesting or important to know for all who want 
to gain more knowledge concerning th bugfixing, QA or whatever else process.


The question is whether the Priority entry is evaluated by anyone, IMHO 
most here see that as a personal statement (of reporter?) concerning 
importance of the bug - and ignore it.


Best regards


Rainer
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Cleaning bug list

[Joel Madero]

I'll modify the orientation today or tomorrow and try to see where 
regression should fit. I think that it has to go in Priority and not in 
Severity. As for how devs use it, I agree completely that right now it's 
almost useless but maybe if it becomes more uniform and it actually 
provides some information as to what the bug is doingwho knows. For 
instance for me, at this point my abilities are pretty low so trivial 
bugs seem to be the go to...hopefully in the future this changes. As for 
users prioritizing themselves, I've (mentioned/suggested/got irritated 
with) in comments a couple users setting Severity to Critical for 
something as minor as Conditional Formatting, it's almost to the point 
that it is useless to "let" the end user categorize their own bugs like 
this.


Maybe regression should automatically set Priority to "Highest" 
regardless of how many people are affected.


Ok off to work. Glad it at least seems a little useful. I have such 
limited experience in programming/programming projects that I just felt 
a bit overwhelmed so this helped me quite a bit last night when I was 
going through bugs.



Joel

On 06/18/2012 04:21 AM, Rainer Bielefeld wrote:

Joel Madero schrieb:

I brainstormed a bit today and I came up with this flowchart.



Hi Joel,

great to see that all in a chart, your conclusions and definitions 
seem plausible.


But the chart also shows the limitations of that concept: It's really 
sophisticated, and no developer will sit at his's desk to decide 
whether he should fix a Bug with Severity=major and Priority=normal 
before or after a bug with  Severity=normal and Priority=high  ;-)


But as you stated, such a chart can give some orientation, and so I 
think it should be shown in the Wiki. Not on one of the current 
existing Pages like BugTriage or similar, but on a page where should 
gather detailed background information what would blow up those pages 
too much, but nevertheless are interesting or important to know for 
all who want to gain more knowledge concerning th bugfixing, QA or 
whatever else process.


The question is whether the Priority entry is evaluated by anyone, 
IMHO most here see that as a personal statement (of reporter?) 
concerning importance of the bug - and ignore it.


Best regards


Rainer


___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Cleaning bug list

[Petr Mladek]

Rainer Bielefeld píše v Po 18. 06. 2012 v 13:21 +0200:
> Joel Madero schrieb:
> > I brainstormed a bit today and I came up with this flowchart.
> 
> 
> Hi Joel,
> 
> great to see that all in a chart, your conclusions and definitions seem 
> plausible.
> 
> But the chart also shows the limitations of that concept: It's really 
> sophisticated, and no developer will sit at his's desk to decide whether 
> he should fix a Bug with Severity=major and Priority=normal before or 
> after a bug with  Severity=normal and Priority=high  ;-)

You are right, developers will not strictly follow the severity and
priority. On the other hand, they care of the usability of the
application. They are actively working on the most annoying bugs. They
prioritize bugs themselves, so why not help them.

Note that MAB is only a workaround because all the other bugs are not
prioritized.

I think that it is hard job to prioritize all bugs. It will cause some
troubles because different people might have different opinions. Though,
I think that we should try it.


> But as you stated, such a chart can give some orientation, and so I 
> think it should be shown in the Wiki. Not on one of the current existing 
> Pages like BugTriage or similar, but on a page where should gather 
> detailed background information what would blow up those pages too much, 
> but nevertheless are interesting or important to know for all who want 
> to gain more knowledge concerning th bugfixing, QA or whatever else process.

You are right that we need to keep the bugtriage page easy to do not
scare people. It would make sense to describe the prioritization on
extra page and just link it from the BugTriage page.

BTW: Recently someone said that the Bugtriage page was not easy to
understand (state CONFIRMED). I think that some people might prefer the
graphics flow chart over the text. It would be nice to have similar flow
chart also for the overall bugtriage process :-)


> The question is whether the Priority entry is evaluated by anyone, IMHO 
> most here see that as a personal statement (of reporter?) concerning 
> importance of the bug - and ignore it.

Good question. My opinion is:

+ severity defines how much a bug affect the functionality
+ priority defines order in which it should be fixed

It means that, some feature might have higher priority because of
marketing reasons. Also some less severe bug might have higher priority
because it affects many users.

Hmm, when I think about it, I would propose another prioritization:

1. Define severity by symptoms.

+ this is well handled in the flow chart.

+ alternative proposal is at at
  http://wiki.documentfoundation.org/BugReport_Details#Severity
  is reasonable. 
  
+ I think that they both describe the same things different way.
  I do not have any strong opinion what formulation is easier to
  understand. We would need feedback from more people ;-)


2. Define priority more clever way:

+ the default priority should basically follow the severity; it
  means that critical bugs should have high priority, ...

+ the number of affected users and visibility should shift it
  higher or lower, though

+ it is already somehow handled in the flowchart. Well, I would,
  allow to skip even more levels. For example, typo
  in the main menu is minor bug but it might have even
  highest priority. Such bug in final release would look
  amateurish and would bring bad feeling from users.
  
  Hmm, I am not sure how to effectively describe it in the
  flowchart.

+ with this logic, the bugs with the high and highest priority
  should be mentioned in MAB.

+ anyway, developers should have the final word about
  priorities (for assigned bugs); they might want to organize
  their daily work by it 

Best Regards,
Petr




___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

[Libreoffice-qa] New Bugzilla Branch Version Picker items – 3

[Rainer Bielefeld]

Hi all,

I am happy to see that we have a solution for the general problem, I 
will change picker texts with 3.6.0.0.beta2


The remaining problem is what we will do with

3.7.0.0.alpha1+daily
3.7.0.0.alpha2+daily
3.7.0.0.beta1+ daily
3.7.0.0.beta2+ daily
3.7.1.0.alpha1+daily
3.7.2.0.alpha1+daily
3.7.3.0.alpha1+daily
3.7.4.0.alpha1+daily
3.7.5.0.alpha1+daily
3.7.6.0.alpha1+daily

what are possible versions for the daily builds available during life 
cycle of 3.7 branch.


Those are a horrible lot of versions filling the picker with nearby 0 
reports/version (a "x.x.5" does not produce many regressions, and only 
few users will test dailies).


I would like to have a common "Branch Daily" in Bugzilla Version picker 
for these Versions, for example *"3.7.0.0.alpha++"* (this way only 
visible in Bugzilla, not in "Help About").


With acceptable workload it would be possible to create all those 
versions from above (also to have the possibility to use a Atom Feed 
"ticker" as "early warning system" and to shift them all to such a 
"3.7.0.0.alpha++" 1/4 year after life cycle of the branch has been 
terminated. So only 1 Branch version would remain for the picker instead 
of 10 (or so).


a) @petr:
Is my assumption concerning the "Daily" numeration (without remark 
"Daily" in "Help/About") correct?


@all:
Your Ideas?

Discussion please on !

Best Regards


Rainer
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Cleaning bug list

[Petr Mladek]

Joel Madero píše v Po 18. 06. 2012 v 07:04 -0700:
> I'll modify the orientation today or tomorrow and try to see where 
> regression should fit. I think that it has to go in Priority and not in 
> Severity.

Makes sense.

>  As for how devs use it, I agree completely that right now it's 
> almost useless but maybe if it becomes more uniform and it actually 
> provides some information as to what the bug is doingwho knows.

I think that normal developers might ignore unconfirmed bugs. The will
be happy if confirmed bugs are prioritized some "standardized" way.

>  For instance for me, at this point my abilities are pretty low so trivial 
> bugs seem to be the go to...

Heh, even minor bug might be hard to fix. On the other hand, crashes are
sometimes easier because backtrace and valgrind log points to the
probleamtic code ;-)

> As for users prioritizing themselves, I've (mentioned/suggested/got irritated 
> with) in comments a couple users setting Severity to Critical for 
> something as minor as Conditional Formatting, it's almost to the point 
> that it is useless to "let" the end user categorize their own bugs like 
> this.

Sure. Well, it can be solved by filtering the non-confirmed bugs.

> Maybe regression should automatically set Priority to "Highest" 
> regardless of how many people are affected.

I would still prefer to take in account the seriousness and visibility.
If it takes months to report a regression, it means that nobody active
used the functionality for a long time. Such a regression could wait a
bit longer ;-)


> Ok off to work. Glad it at least seems a little useful. I have such 
> limited experience in programming/programming projects that I just felt 
> a bit overwhelmed so this helped me quite a bit last night when I was 
> going through bugs.

I am sure that it will help others as well. It is possible that some
people did not start triaging because they were not sure how to do it.

Thanks for working on it.


Best Regards,
Petr

___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] New Bugzilla Branch Version Picker items – 3

[Petr Mladek]

Rainer Bielefeld píše v Po 18. 06. 2012 v 17:16 +0200:
> Hi all,
> 
> I am happy to see that we have a solution for the general problem, I 
> will change picker texts with 3.6.0.0.beta2
> 
> The remaining problem is what we will do with

Ah, I forgot this ;-)

> 3.7.0.0.alpha1+daily
> 3.7.0.0.alpha2+daily
> 3.7.0.0.beta1+ daily
> 3.7.0.0.beta2+ daily

These will be used in the about dialog.

> 3.7.1.0.alpha1+daily
> 3.7.2.0.alpha1+daily
> 3.7.3.0.alpha1+daily
> 3.7.4.0.alpha1+daily
> 3.7.5.0.alpha1+daily
> 3.7.6.0.alpha1+daily

We do not allow dangerous changes for bugfix releases => the daily
builds should have the quality of release candidates. So, there will be:

3.7.1.0+  daily
3.7.2.0+  daily
3.7.3.0+  daily
3.7.4.0+  daily
3.7.5.0+  daily
3.7.6.0+  daily

> what are possible versions for the daily builds available during life 
> cycle of 3.7 branch.

We have one alpha, three betas, three release candidates for .0 release,
and two release candidates for bugfix releases.

> Those are a horrible lot of versions filling the picker with nearby 0 
> reports/version (a "x.x.5" does not produce many regressions, and only 
> few users will test dailies).
>
> I would like to have a common "Branch Daily" in Bugzilla Version picker 
> for these Versions, for example *"3.7.0.0.alpha++"* (this way only 
> visible in Bugzilla, not in "Help About").
> 
> With acceptable workload it would be possible to create all those 
> versions from above (also to have the possibility to use a Atom Feed 
> "ticker" as "early warning system" and to shift them all to such a 
> "3.7.0.0.alpha++" 1/4 year after life cycle of the branch has been 
> terminated. So only 1 Branch version would remain for the picker instead 
> of 10 (or so).

Nice trick.

Another solution would be to omit these daily builds versions in
bugzilla at all. It is motivated by these ideas:

+ 3.6.0.0.beta2+ version is incomplete anyway; there are more
  daily builds with this version; reporter should cut&paste
  the whole buildid from the about dialog anyway

+ daily builds are used only by active QA testers; they
  are more experienced and could handle the missing "+"
  versions in bugzilla reasonably


Best Regards,
Petr

___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Cleaning bug list

[Petr Mladek]

Joel Madero píše v Po 18. 06. 2012 v 09:32 -0700:
> Version 2, changed orientation and tried to take comments into
> account. Let me know what you all think.

It is much better readable. I finally got a better picture :-)

Well, I think that it still need some thinking. You set "inability to
safe" as major. I think that it should be blocker. The application
would be almost useless with this bug ;-)


I suggest the following changes in the top levels:

   Q: "Does bug cause crash, loss of data[*], inability to install,
   broken core function, e.g. inability to safe any writer
   documents, print?

+ A: "yes":
=> Q: "Does it affect almost all users within everyday usage and
   is it a regression?"
+ A: "yes" => blocker, highest, MAB
+ A: "no"  => critical, high, MAB 
  I would leave the 


+ A: "no"
=> Q: "Does bug involve a serious glitch such as tediously
   slow, inability to open particular documents, install
   some extensions, print on some printers?

+ A: "yes": => "major", high

IMHO, the rest might stay as is. Well, it would be great to create
several examples also for the other categories. I do not have power to
invent them now, though ;-)

[*] Note that data loss might be caused by incomplete import. If it is
not a regression, it might be marked by developers as an enhancement.
Note that it needs many developer/years to support some file formats.
OOXML format is described on several thousands of pages...

I am very happy with the progress and the state.

Thanks a lot for working on it.


Best Regards,
Petr

___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] Cleaning bug list

[Joel Madero]

I agree with the save comment, I'll change that right now. Also
realized I didn't put a note in for regressions so I added to the
bottom notes:

**Regressions**
Special attention should be paid to regressions. In most cases a
regression calls for an increase in priority but in some cases it will
not. If the regression is not elevated to a higher priority, a comment
may be useful to explain why this decision was made


Joel

On Mon, Jun 18, 2012 at 10:54 AM, Petr Mladek  wrote:
> Joel Madero píše v Po 18. 06. 2012 v 09:32 -0700:
>> Version 2, changed orientation and tried to take comments into
>> account. Let me know what you all think.
>
> It is much better readable. I finally got a better picture :-)
>
> Well, I think that it still need some thinking. You set "inability to
> safe" as major. I think that it should be blocker. The application
> would be almost useless with this bug ;-)
>
>
> I suggest the following changes in the top levels:
>
>   Q: "Does bug cause crash, loss of data[*], inability to install,
>       broken core function, e.g. inability to safe any writer
>       documents, print?
>
>    + A: "yes":
>        => Q: "Does it affect almost all users within everyday usage and
>               is it a regression?"
>                + A: "yes" => blocker, highest, MAB
>                + A: "no"  => critical, high, MAB
>                  I would leave the
>
>
>    + A: "no"
>        => Q: "Does bug involve a serious glitch such as tediously
>               slow, inability to open particular documents, install
>               some extensions, print on some printers?
>
>                + A: "yes": => "major", high
>
> IMHO, the rest might stay as is. Well, it would be great to create
> several examples also for the other categories. I do not have power to
> invent them now, though ;-)
>
> [*] Note that data loss might be caused by incomplete import. If it is
> not a regression, it might be marked by developers as an enhancement.
> Note that it needs many developer/years to support some file formats.
> OOXML format is described on several thousands of pages...
>
> I am very happy with the progress and the state.
>
> Thanks a lot for working on it.
>
>
> Best Regards,
> Petr
>
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

[Libreoffice-qa] Messages to libreoffice-qa rejected

[Rainer Bielefeld]

Hi all,

some of your messages you write as an answer to other messages are 
rejected, currently I can't find out why.


In my details view the Subject line is scrambled, looks like "Subject: 
=?windows-1252?Q?Re=3A_=5BLibreoffice-qa=5D_New_Bugzilla_?=

 =?windows-1252?Q?Version_Picker_items_=96_2?="

My suspect is that that is "somehow" related to "Content-Type: 
text/plain; charset=windows-1252; format=flowed" what I find in those 
mail headings.


What ever that might mean.

Best regards


Rainer Bielefeld
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] New Bugzilla Version Picker items – 2

[MiguelAngel]

El 15/06/12 13:27, Petr Mladek escribió:

Hi Florian,

On Thu, 2012-06-14 at 10:07 +0200, Florian Reisinger wrote:

Hi!

I am not sure anyone has seen my  suggestion:

Alpha 1: 3.6.0a1
Beta 1: 3.6.0b1
RC 1: 3.6.0r0
RC 2: 3.6.0r1


Ah, this does not work because we could not mention "r" (same as "rc")
in the about dialog. We do not want to rebuild/upload new build just to
remove this string for the final release.


Best Regards,
Petr

___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/



But I think many users are confused with the use of RC2 as final version.

Miguel Ángel.
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/

Re: [Libreoffice-qa] minutes of the libreoffice qa call 2012-06-14

[David Tardon]

On Fri, Jun 15, 2012 at 05:50:37PM +0200, Bjoern Michaelsen wrote:
> Hi all,
> 
> here are the minutes of todays QA call.
> 
> community building/communication (Cor?):
>- beta testers for 3.6.0 beta 1
>- 3.6.0 beta 1 available in ppa (Bjoern)
>  - Wheres a good howto? (Florian)
>- 
> http://www.webupd8.org/2012/06/libreoffice-360-beta-1-released-ubuntu.html
>- best to install in a VM still
>  - unfortunately no ppa stats:
>https://bugs.launchpad.net/launchpad/+bug/1006323
>- so far 16 beta bug reports in the first two weeks (vs. 25 for 3.5)
>  - might just be better quality
>  - we need more beta testers
> AI:- Are there any Bug Hunting Sessions in the pipe? (Cors)
>- SUSE will prepare packages for the beta for testing too (Petr)
> AI:  - Could Fedora do this too? (Caolan?)

I plan to prepare them during this week.

D.
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/