Re: [Libreoffice-qa] Reminder: QA Meeting on Wednesday

[Sophie]

Hi Pedro,
Le 25/11/2015 16:16, Pedro a écrit :
> Hi Joel
> 
> 
> jmadero wrote
>>> A sugestion: maybe have a branch dedicated to bug fixes every other year?
>>> Example: let's say 5.1 is dedicated to fixes. Then a slight change of
>>> schedule would postpone 5.2.0 to some months later so that most devs
>>> would
>>> concentrate on 5.1 (of course new features would still be added to Master
>>> in
>>> this period) instead of being split by two concurrent branches...
>> This is literally impossible. We would have very talented developers
>> saying no way - then what? We cannot dictate (we can suggest) what
>> developers do. If we tell Developers "pause all your work and go back
>> and do just regression fixing" they respond with "no" and then . . . the
>> end.
> 
> Have you tried? Maybe some will say no (and they can continue to work on the
> Master branch) and some may agree.
> 
> Do all QA people say No when you ask them to have a Bug Hunting session? Why
> would ALL devs say No???
> 
> Why is it impossible to have a Bug Squashing Session for devs? I bet some
> would find it challenging to fix more bugs than the others.

We call them hackfests, and there are some regressions fixed there. But
as Joel said it has already been discussed, we are not a community who
forces people to work on specific tasks if they don't want too. Instead
we try to invite them, so any idea in this direction is more than welcome.
> 
> Why is it "literally impossible" to have a fix branch? Has something similar
> been proposed at the ESC meeting and rejected?

Bjoern answered you on that topic already
> 
> 
> jmadero wrote
>> Then catching regressions before they happen is, as
>> Sophi suggested, all about growing the community to do testing in Alpha.
> 
> I'm all for growing the community and for doing early tests. In fact I do
> very early testing for Apache OpenOffice (where each release is a regular
> install instead of a parallel Dev install)

Having dev installation allow our testers to chase until which version
the bug exists. At the OOo time, it was the same, only from RC1, install
was a production one. What we need is more people testing at the alpha
and beta stage, we have very few people testing there and it let a too
short time to find regression before the final version. But, we do not
recommend to install the last version until the 3rd one, so we should
find most of the regressions at that time.
> 
> However if there is no commitment from the Devs to fix regressions then it
> really doesn't matter at which stage you catch them...

No, don't mix things :) I can assure you that none of our developers are
happy with regressions. We monitor them closely. That's true that we
don't rely only on the numbers as a regression might affect a very
little number of people and in a very specific work - so it's a real
regression, but it will have much less impact that one affecting hundred
of people. The latter are monitored and attract the attention of the ESC
and are escalated, bibisected then we invite the dev to have a look at
it. If want to help in this area, we always need more people able to
bibisect those bugs and try to find the responsible commit, let me know,
I'll help you with the first steps.

Cheers
Sophie

-- 
Sophie Gautier sophie.gaut...@documentfoundation.org
GSM: +33683901545
IRC: sophi
Co-founder - Release coordinator
The Document Foundation
___
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] LibreOffice releases (was: Reminder: QA Meeting on Wednesday)

[Pedro]

Hi Bjoern


Bjoern Michaelsen wrote
> On Wed, Nov 25, 2015 at 03:40:37AM -0700, Pedro wrote:
>> A sugestion: maybe have a branch dedicated to bug fixes every other year?
>> Example: let's say 5.1 is dedicated to fixes. Then a slight change of
>> schedule would postpone 5.2.0 to some months later so that most devs
>> would
>> concentrate on 5.1 (of course new features would still be added to Master
>> in
>> this period) instead of being split by two concurrent branches...
> 
> We have a "branch dedicated to bug fixes" twice a year. They are called
> "release
> branches" and live for about a year each. More details at:

Maybe my suggestion wasn't clear. I know about the "twice a year" release
branches. My suggestion was exactly to delay the second release of the year
so that developers could have more time to dedicate to a single branch (of
course they could always submit new features to the Master branch)

Looking at this chart
 

you will notice that there are very few times when developers are working on
a single branch. In fact most of the times they are working on 3 branches
simultaneously and therefore the constant "rush before release" that Sophie
mentions.

My suggestion was (as an example) to branch 5.2 later in the year (e.g. in
late October) so that there is 3-4 months to dedicate to 5.1 and therefore
have time to reduce the backlog of confirmed bugs (and even for QA people to
bisect some bugs without having to worry about testing a new branch).

My other suggestion was for TDF to organize a Bug Squashing Session during
this period.

Therefore this does not change the Timed release logic, it just spaces it a
bit to allow time for bug fixing...

Best regards,
Pedro



--
View this message in context: 
http://nabble.documentfoundation.org/Libreoffice-qa-Reminder-QA-Meeting-on-Wednesday-tp4167253p4167378.html
Sent from the QA mailing list archive at Nabble.com.
___
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] LibreOffice releases (was: Reminder: QA Meeting on Wednesday)

[Bjoern Michaelsen]

Hi,

On Wed, Nov 25, 2015 at 03:40:37AM -0700, Pedro wrote:
> A sugestion: maybe have a branch dedicated to bug fixes every other year?
> Example: let's say 5.1 is dedicated to fixes. Then a slight change of
> schedule would postpone 5.2.0 to some months later so that most devs would
> concentrate on 5.1 (of course new features would still be added to Master in
> this period) instead of being split by two concurrent branches...

We have a "branch dedicated to bug fixes" twice a year. They are called "release
branches" and live for about a year each. More details at:

 https://www.youtube.com/watch?v=7DBzRfW8R5k
 
http://conference.libreoffice.org/assets/Conference/Aarhus/Slides/BjoernMichaelsenreleases.pdf

If you need a branch that is living longer than a year, that is possible too,
but nothing volunteers would commit to. It is offered by various L3 supporters
of LibreOffice though:

 http://www.documentfoundation.org/certification/developers/

Best,

Bjoern
___
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] Reminder: QA Meeting on Wednesday

[Pedro]

Hi Joel


jmadero wrote
>> A sugestion: maybe have a branch dedicated to bug fixes every other year?
>> Example: let's say 5.1 is dedicated to fixes. Then a slight change of
>> schedule would postpone 5.2.0 to some months later so that most devs
>> would
>> concentrate on 5.1 (of course new features would still be added to Master
>> in
>> this period) instead of being split by two concurrent branches...
> This is literally impossible. We would have very talented developers
> saying no way - then what? We cannot dictate (we can suggest) what
> developers do. If we tell Developers "pause all your work and go back
> and do just regression fixing" they respond with "no" and then . . . the
> end.

Have you tried? Maybe some will say no (and they can continue to work on the
Master branch) and some may agree.

Do all QA people say No when you ask them to have a Bug Hunting session? Why
would ALL devs say No???

Why is it impossible to have a Bug Squashing Session for devs? I bet some
would find it challenging to fix more bugs than the others.

Why is it "literally impossible" to have a fix branch? Has something similar
been proposed at the ESC meeting and rejected?


jmadero wrote
> Then catching regressions before they happen is, as
> Sophi suggested, all about growing the community to do testing in Alpha.

I'm all for growing the community and for doing early tests. In fact I do
very early testing for Apache OpenOffice (where each release is a regular
install instead of a parallel Dev install)

However if there is no commitment from the Devs to fix regressions then it
really doesn't matter at which stage you catch them...

Best regards,
Pedro



--
View this message in context: 
http://nabble.documentfoundation.org/Libreoffice-qa-Reminder-QA-Meeting-on-Wednesday-tp4167253p4167365.html
Sent from the QA mailing list archive at Nabble.com.
___
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] LibreOffice releases (was: Reminder: QA Meeting on Wednesday)

[Pedro]

Bjoern Michaelsen wrote
> That wouldnt help at all, "delaying the release" is just another name for
> "not
> making an release from master for a longer period of time" and thus would
> result in _more_ regressions, not less.

Let's see: If releases are slowed down there are more regressions, if they
aren't slowed down then there is no time/human resources to fix existing
regressions. Ergo the future is an always increasing number of regressions.
Unless the number of developers increases. But since you can't ask the
developers to do such a boring job, even that won't solve the problem...

Ah, well, sorry for the noise... Back to bugzilla...



--
View this message in context: 
http://nabble.documentfoundation.org/Libreoffice-qa-Reminder-QA-Meeting-on-Wednesday-tp4167253p4167433.html
Sent from the QA mailing list archive at Nabble.com.
___
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] LibreOffice releases

[Joel Madero]

>
> Maybe my suggestion wasn't clear. I know about the "twice a year" release
> branches. My suggestion was exactly to delay the second release of the year
> so that developers could have more time to dedicate to a single branch (of
> course they could always submit new features to the Master branch)
>
> Looking at this chart
> 
>  
>
> you will notice that there are very few times when developers are working on
> a single branch. In fact most of the times they are working on 3 branches
> simultaneously and therefore the constant "rush before release" that Sophie
> mentions.
>
> My suggestion was (as an example) to branch 5.2 later in the year (e.g. in
> late October) so that there is 3-4 months to dedicate to 5.1 and therefore
> have time to reduce the backlog of confirmed bugs (and even for QA people to
> bisect some bugs without having to worry about testing a new branch).
>
> My other suggestion was for TDF to organize a Bug Squashing Session during
> this period.
>
> Therefore this does not change the Timed release logic, it just spaces it a
> bit to allow time for bug fixing...
Nothing prevents developers now to dedicate 100% of their time to
regression squashing between major releasesA developer could have
(by choice) focused entirely on new features for 5.0, and entirely on
regression for 5.1. The fact that they did not implies that as
volunteers, that wasn't of any interest to them. I'm not seeing what
exactly you're proposing anyone do. Do you want TDF to lock LibreOffice
every other major release and say "absolutely no new features or bug
squashing, only regression fixing?" I think you have a misunderstanding
of the relationship that the Document Foundation (entity) has with it's
contributors (volunteers).

Again, nothing is preventing you from reaching out and trying to recruit
developers to focus on regressions.


Best,
Joel
___
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] Reminder: QA Meeting on Wednesday

[Joel Madero]

Hi All,
> BTW would be nice listen from the candidates their opinion about concrete
> matters like this one.

Should have suggested. If you're really interested in knowing candidates
views on specific items you may want to email [board-discuss] list :)

Warmest Regards,
Joel

___
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] Reminder: QA Meeting on Wednesday

[Joel Madero]

Hi There,

On 11/25/2015 02:04 PM, m.a.riosv wrote:
> BTW would be nice listen from the candidates their opinion about concrete
> matters like this one.

I would be surprised if there was any deviation for any of the
candidates - we've discussed this at length on the Board. Hell I just
brought it up today (saying it came up again in QA) and well, there was
unanimous consensus and hopefully one of the developers will write a
nice blog post about this issue to put it to rest once and for all.
Telling others what to do is not how we work. We have a strong culture
of "the doers decide" and the "doers" stick with what they "do" - thus
again, I really do think there is a solution here.


If QA members just bisected each regression (fully bisect) and
prioritized correctly I *honestly* believe that the regression count
would fall. I don't understand why this point is being ignored as it's
literally *completely* in our control.


Anywho, I like the spirited conversation I just don't see any actionable
item. I suggested that Pedro go track down developers to agree with him
but he quickly dismissed that (because he couldn't convince me?) and
asked Robinson or someone else to do the work of bringing up to the ESC.
The ESC has also talked about this at length and rejected it (on several
occasions). I've spoken with many of the developers who join the ESC and
all of them reject this concept of QA dictating what they do, or that
there should be any quasi-dictating by having "fix builds" or the like.
But again, it's not outside of any of your powers to broach the subject
yourselves on the dev list and pitch *concrete actionable ideas*.

At the same time, I highly encourage thinking about compromise positions
- which I think I have actually given a good compromise. If we can go to
the ESC and say "look our QA team is frantically doing *comprehensive
triaging* and bisecting each and every regression, can you take over
now? That seems like a more positive way to move things forward.


Best,
Joel



___
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] LibreOffice releases (was: Reminder: QA Meeting on Wednesday)

[Bjoern Michaelsen]

Hi,

On Wed, Nov 25, 2015 at 10:10:58AM -0700, Pedro wrote:
> Maybe my suggestion wasn't clear. I know about the "twice a year" release
> branches. My suggestion was exactly to delay the second release of the year
> so that developers could have more time to dedicate to a single branch (of
> course they could always submit new features to the Master branch)

That wouldnt help at all, "delaying the release" is just another name for "not
making an release from master for a longer period of time" and thus would
result in _more_ regressions, not less. LibreOffice is already doing
exceptionally long release cycles compared to the rest of the open source
software world.

All of this is being discussed in the linked video, I suggest you watch it.

Best,

Bjoern
___
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] Minutes of the Design Hangout: 2015-11-18

[Jan Holesovsky]

[the meeting on 11th was cancelled]

* Present: Cor, Heiko, Kendy, Samuel
 
* UI changes integrated the last two weeks:

+ form-related controls ta insert and tools menu (Jay)
+ hierarchical organization of slide transitions (Tor)
+ and new slide transitions (Tor, Tomaž)
+ title for image export options dialog (Jay)
+ fix accelerators in start center (Kendy)
+ loading .svg images from image resources (Tomaž)
+ "hide whitespace" improvements (Ashod)
+ new Outline button (Maxim)
+ missing an icon
+ context menu customization (Maxim)
+ new PopupLabel property for uno commands (Maxim)
+ new TooltipLabel property for uno commands (Samuel)
+ shortcut keys missing in undo and redo tooltips (Samuel)
+ tdf#34882 Adding hex and decimal code search (Steve Hart)
+ Impress: Rework the way the display modes are presented (Philippe)

* Update the meeting time (Kendy)

+ Please fill the Doodle until the next meeting (Wed 25th, November 2015):
 http://doodle.com/poll/d4b628cgxanrvmka 

* Table styles (Kendy)
 
+ would be good to have a Friday session about that (Kendy)
+ already collected stuff in a doc (Jay)
+ 
https://docs.google.com/document/d/1FPkf9fn79dXJ5tHpc-meMYxaQpj3nV5sEN6u9HOo2GQ/edit?usp=sharing

+ pending publishing
+ some thing still can be discussed

* Area Tab design session (Heiko/Jay)
 
+ Area Tab - https://bugs.documentfoundation.org/show_bug.cgi?id=94551
  
https://docs.google.com/document/d/1gf7wqYszXnbrbzbyNlLKbJelMb20ssuimxfszcHP_wM/edit?usp=sharing
+ not published yet
 
* Dedicated Design team blog (Heiko)
 
+ https://design.blog.documentfoundation.org/
+ now set up, admins, thank you!

+ Heiko, Jay, Kendy have the credentials
+ Heiko can start writing a post
+ how to reference the author etc.? (Heiko)
+ not possible to have a named posting (Heiko)
+ best to poke the admins - awerner set this up for us (Kendy)
+ will ask for some plugins that will be useful (Heiko)
 
* Bug discussions
 
+ none this week

* NotebookBar (Samuel)

+ https://wiki.documentfoundation.org/Development/NotebookBar
+ screenshot - 
https://wiki.documentfoundation.org/images/f/f5/Notebookbar-writer.png
+ NotebookBar allows to create toolbars with glade (Samuel/Kendy)
+ full control over widgets in the topmost area, defined via a .ui file
+ an optional thing for users (Samuel)
+ menus + toolbars the default
+ now in master, but hidden via an env. variable (Kendy)

+ keep in mind the HIG (Heiko)
+ https://wiki.documentfoundation.org/Design/ToolBar
+ mentions some future enhancements of toolbars that might be helpful 
here (Heiko)
+ eg. grouping
+ possible with Notebookbar
+ eg. 
http://docs.sencha.com/extjs/4.0.7/#!/example/toolbar/toolbars.html ?

+ loading the toolbars from glade (.ui) instead of .xcu files
+ this will probably remove the possibility to make the toolbars 
floating (Kendy)
+ but that is good (Cor, Kendy)

+ can have more sets of toolbars with this (Cor)

+ Will have  a friday session on NotebookBar topic on Fr 27th
 + Please have a look at the following links until then: 
https://wiki.documentfoundation.org/Development/NotebookBar#Resources

* Help updating (Kendy)

+ released a new release (Kendy)

+ online modification prototype (Jay)
+ Liongold on IRC working on that
+ will share that with Jay, and can iterate
+ need a VM from the infra to host the prototype
+ will create another ticket for this (Jay)
  https://redmine.documentfoundation.org/issues/1584
+ would be great to put the code to a repository (Kendy)
+ dev-tools (some subdir there) (Kendy)
+ or a new repo - eg. on github as a start? (Kendy)
+ dev-tools preferred though

+ help-related meta bugs:
+ https://bugs.documentfoundation.org/show_bug.cgi?id=94016
+ https://bugs.documentfoundation.org/show_bug.cgi?id=93580

* Icon Updates / Issues (Jay)

+ icons for slide transitions needed (Kendy)

+ 32pixel sifr icons
+ first 2 from Pappamatti
+ reminded him to push svg too (Jay)
+ to use the Tomaž's code

+ Extra-Large (32x32) Icons for large resolutions
+ Status - 
https://docs.google.com/document/d/1mPqD2gGsMkfVCI6ByUd2XYX1NJm26hcGjRVe6gcCSEU/edit?usp=sharing
+ Integrating it into the options dialog - 
https://bugs.documentfoundation.org/show_bug.cgi?id=95014
+ add a "extra large" entry

+ still something wrong with inheritance (Jay)
+ Samuel will look at one of them
+ https://bugs.documentfoundation.org/show_bug.cgi?id=93866
+ easiest solution: eg. for tango, during build concat tango + 

Re: [Libreoffice-qa] Reminder: QA Meeting on Wednesday

[m.a.riosv]

Hi Pedro,

Thanks for bringing this matter again at discussion, even some people is
bored of it.

Excuse is always on developers, but I have not appreciated such attitude at
least with significant devs, even always there is some exception.

There is not a QA work flow for the whole. The results are your conclusions,
as I have exposed several times, specially new improvements are not
properly, neither improperly, verified.

Well maybe I forgot we have only obligations like to do a deep investigation
about what test, instead receive an adequate communication about what needs
our attention.

BTW would be nice listen from the candidates their opinion about concrete
matters like this one.

Miguel Ángel.




--
View this message in context: 
http://nabble.documentfoundation.org/Libreoffice-qa-Reminder-QA-Meeting-on-Wednesday-tp4167253p4167417.html
Sent from the QA mailing list archive at Nabble.com.
___
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 ESC call ...

[Jan Holesovsky]

Hi Robinson,

Robinson Tryon píše v St 25. 11. 2015 v 16:03 -0500:

> It looks like the rename script got greedy and erroneously modified an
> ODT (sw/qa/complex/writer/testdocuments/TESTXMLID.odt):
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=49c2b9808df8a6b197dec666dfc0cda6321a4306
> 
> Could you add file extension white/black -listing to the script to
> prevent it from modifying non-code files in the future?

Sorry about that, I had there blacklisting of the 'data' subdirs in the
unit tests, but forgot 'testdocuments' of the complex tests, added now:

http://cgit.freedesktop.org/libreoffice/core/commit/?id=55d0a5e43c968798fe52587f9dae256d94e9ce53

All the best,
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] minutes of ESC call ...

[Robinson Tryon]

On Mon, Nov 16, 2015 at 9:04 AM, Jan Holesovsky  wrote:
>> * Further renaming in sw (Kendy/Miklos)
>> + Kendy would again update the script so that Cloph can run it before 
>> the branch-off
>> + script lives in: bin/rename-sw-abbreviations.sh
>
> I've pushed several renames so that running the script causes no
> warnings and no errors, and pushed the updated script:
>
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=3190f5a71dd3e63260edebc345aead4746a269a3
>
> Additional testing appreciated of course :-)

Hi Kendy,
It looks like the rename script got greedy and erroneously modified an
ODT (sw/qa/complex/writer/testdocuments/TESTXMLID.odt):
http://cgit.freedesktop.org/libreoffice/core/commit/?id=49c2b9808df8a6b197dec666dfc0cda6321a4306

Could you add file extension white/black -listing to the script to
prevent it from modifying non-code files in the future?

Thanks,
--R

-- 
Robinson Tryon
QA Engineer - The Document Foundation
LibreOffice Community Outreach Herald
qu...@libreoffice.org
802-379-9482 | IRC: colonelqubit on Freenode
___
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] Reminder: QA Meeting on Wednesday

[Pedro]

Hi Robinson


Robinson Tryon wrote
>> Isn't 16% of Regressions something that TDF should be worried about?
>>
>> (713 out of 4419 open bugs, according to
>> http://nabble.documentfoundation.org/Libreoffice-qa-Minutes-of-ESC-call-2015-11-19-tp4166818.html)
> 
> I definitely would like to see that percentage drop, just as I'd like
> to see our outstanding bug pool drop to at least half. As Bubli
> pointed out last week, there is a certain amount of interpretation to
> how we categorize and prioritize a "data loss bug":
> "Loss of some 10k row sheet full of 2 years of scientific work data is
> in slightly different category than, dunno, loss of text highlighting
> in an article," so perhaps some of our bugs might need re-evaluation,
> and/or we might need to consider regressions in a slightly different
> light?

Obviously there are different degrees of regression (but that is what the
Importance fields are for).

But regressions are a major source of aggravation. People expect
consistency. This is true from software to restaurants. If something that
used to work/be good looses function/quality then people will look somewhere
else.


Robinson Tryon wrote
>> How can QA (Quality Assurance) and TDF motivate the Devs to worry about
>> the
>> consistency of the program?
> 
> I think we're pretty consistent on providing QA/Bugzilla stats to the
> devs, as well as searching-out some critical/widely-affecting bugs and
> getting those in their field of vision.

I think that QA is doing it's best (particularly on having new bugs
triaged). I think what is failing is to convince the Devs that Quality (and
possibly adoption of LO) is affected by regressions and long standing bugs
and that some more time needs to be dedicated to that (however boring that
may be... triaging bugs is not always fun, so QA people know about
boring...)

Now that Collabora has a paid version (by the UK government) which is a 3
year LTS some of these bugs might start to be squashed and contributed back
to the Master branch...

A sugestion: maybe have a branch dedicated to bug fixes every other year?
Example: let's say 5.1 is dedicated to fixes. Then a slight change of
schedule would postpone 5.2.0 to some months later so that most devs would
concentrate on 5.1 (of course new features would still be added to Master in
this period) instead of being split by two concurrent branches...

Pedro



--
View this message in context: 
http://nabble.documentfoundation.org/Libreoffice-qa-Reminder-QA-Meeting-on-Wednesday-tp4167253p4167320.html
Sent from the QA mailing list archive at Nabble.com.
___
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] Reminder: QA Meeting on Wednesday

[Pedro]

Hi Joel


jmadero wrote
> That's unfortunate, we should talk about moving the time and/or finding
> some other way to get dedicated people like yourself on live chat during
> meeting.

If the meeting could be one hour and a half later (14:30 UTC) I could make
it, but that is probably too late for people somewhere else in the world?


jmadero wrote
>> Isn't 16% of Regressions something that TDF should be worried about? 
> I'm not sure what "worried about" really means. If a major issue was
> resolved and the side effect is a minor regression, not so much. If
> instead there are a ton of minor fixes that have created crashers, more
> of an issue. I'd need a lot more information to adequately judge the
> problem.

I think that even  minor regressions are enough to demotivate users. From a
Quality perspective regressions should be a major concern.


jmadero wrote
> From QA perspective it's not our job to judge or dictate how developers
> work. They are volunteers, and they should be respected like volunteers.

QA people are also volunteers. Yet you are not afraid to suggest what should
be done (reducing Unconfirmed bug count, bibisecting) and when (Bug hunting
sessions).
I think you are not disrespecting QA volunteers when you do that...
Is it too much to ask that Developers are organized in a similar way?


jmadero wrote
> Before demanding a lot of other's time, I personally would prefer we do
> our job as good as possible.

Agreed. But since there are less than 500 Unconfirmed bugs (which might not
even be bugs or could be duplicates) and there are nearly 4500 open bugs
(out of which 700 are Regressions) probably it would have a higher impact on
Quality to tackle the largest slice of the pie?

Best regards,
Pedro



--
View this message in context: 
http://nabble.documentfoundation.org/Libreoffice-qa-Reminder-QA-Meeting-on-Wednesday-tp4167253p4167334.html
Sent from the QA mailing list archive at Nabble.com.
___
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] Reminder: QA Meeting on Wednesday

[Sophie]

Hi,
Le 25/11/2015 12:52, Pedro a écrit :
> Hi Joel
> 
> 
> jmadero wrote
>> That's unfortunate, we should talk about moving the time and/or finding
>> some other way to get dedicated people like yourself on live chat during
>> meeting.
> 
> If the meeting could be one hour and a half later (14:30 UTC) I could make
> it, but that is probably too late for people somewhere else in the world?

The issue was with me having the board meeting at the same time. The
only day with no meeting currently for me is Tuesday, so maybe we could
move it later that day?
> 
> 
> jmadero wrote
>>> Isn't 16% of Regressions something that TDF should be worried about? 
>> I'm not sure what "worried about" really means. If a major issue was
>> resolved and the side effect is a minor regression, not so much. If
>> instead there are a ton of minor fixes that have created crashers, more
>> of an issue. I'd need a lot more information to adequately judge the
>> problem.
> 
> I think that even  minor regressions are enough to demotivate users. From a
> Quality perspective regressions should be a major concern.

I agree, but some implementation need major refactoring where
regressions can't be avoid. It's a balance between the two and also a
sprint on finding them before a release.
> 
> 
> jmadero wrote
>> From QA perspective it's not our job to judge or dictate how developers
>> work. They are volunteers, and they should be respected like volunteers.
> 
> QA people are also volunteers. Yet you are not afraid to suggest what should
> be done (reducing Unconfirmed bug count, bibisecting) and when (Bug hunting
> sessions).
> I think you are not disrespecting QA volunteers when you do that...
> Is it too much to ask that Developers are organized in a similar way?

That should be the same, and I personally think it's the same, ESC
meeting are one of the way, regression tests, Jan mentoring are others
and so on. No regression is introduced by purpose, it's a closed work
between QA and development and a rush before a release.
> 
> 
> jmadero wrote
>> Before demanding a lot of other's time, I personally would prefer we do
>> our job as good as possible.
> 
> Agreed. But since there are less than 500 Unconfirmed bugs (which might not
> even be bugs or could be duplicates) and there are nearly 4500 open bugs
> (out of which 700 are Regressions) probably it would have a higher impact on
> Quality to tackle the largest slice of the pie?

Recruiting more testers at alpha and beta stages are imho the most
important part to reduce those regressions. Unfortunately MozTrap
doesn't get enough love from testers and we have few participants during
BH sessions. If we address both, that should solve part of the problem.
Cheers
Sophie

-- 
Sophie Gautier sophie.gaut...@documentfoundation.org
GSM: +33683901545
IRC: sophi
Co-founder - Release coordinator
The Document Foundation
___
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] Reminder: QA Meeting on Wednesday

[Joel Madero]

On 11/25/2015 02:40 AM, Pedro wrote:
>
>
>
> Now that Collabora has a paid version (by the UK government) which is a 3
> year LTS some of these bugs might start to be squashed and contributed back
> to the Master branch...
>
> A sugestion: maybe have a branch dedicated to bug fixes every other year?
> Example: let's say 5.1 is dedicated to fixes. Then a slight change of
> schedule would postpone 5.2.0 to some months later so that most devs would
> concentrate on 5.1 (of course new features would still be added to Master in
> this period) instead of being split by two concurrent branches...
This is literally impossible. We would have very talented developers
saying no way - then what? We cannot dictate (we can suggest) what
developers do. If we tell Developers "pause all your work and go back
and do just regression fixing" they respond with "no" and then . . . the
end.

This has been discussed on and off for years, it's a fine idea,
impossible given our volunteer base and the way we respect that
volunteers can't be told what to do.

Again, if we go and bisect (fully bisect) each regression and add the
developer who accidentally broke the feature I'm relatively sure we'd
have good results. Then catching regressions before they happen is, as
Sophi suggested, all about growing the community to do testing in Alpha.

Best,
Joel
___
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/