QA/Meetings/2012/November 03

= Agenda = No formal agenda prepared due to conference, open call to discuss anything

= Minutes = Warning: Notes may not be formatted quite right, original minutes can be found here: http://nabble.documentfoundation.org/Libreoffice-qa-QA-Call-tomorrow-Tuesday-1300UTC-td4014857.html']


 * 1) structured manual testing (Yifan?):
 * 2) MozTrap was quickly and ad-hoc demoed at the LibreOffice conference, found quite some interest (QA and RelEng Roundtable)
 * 3) bug wrangling:
 * 4) bugzilla with OpenID would still require registering
 * 5) that kinda defeats the purpose, any other ideas?
 * 6) skip HardHack selection, devs were almosty all at the conference last week (or swamped with preparations)
 * 7) community building/communication (Cor?):
 * 8) Florian did some awesome work to make server installations (and thus master testing) on Windows more accessable:
 * 9) http://flosmind.wordpress.com/2012/10/21/libreoffice-server-installation-gui/
 * 10) blocked by
 * AI:take this to the ESC/Andras (Bjoern)
 * 1) the newly donated virtual machines should be used allow users to remotely login and test master
 * 2) intended to be combined with bibisect
 * 3) a lot of setup work though, still off a few months
 * 4) Florian came up with this work, to improve the quality of filed bugs:
 * 5) https://lh3.googleusercontent.com/-F7WJa3859ik/UGwY8UbpeVI/AAAAAAAAAuo/aH7I5dYz2t4/s2000/BS%2520API.jpg
 * 6) originally intended to be implemented inside LibreOffice (Florian)
 * 7) brainstormed at the german QA weekend
 * 8) would allow easy testdocument inclusion in upload
 * 9) safe detection of version and OS
 * 10) would be localized
 * 11) stats show already 50 unconfirmed bugs/month since the last cleanup
 * 12) multiple issues with implementing this inside LibreOffice itself (Bjoern):
 * 13) privacy
 * 14) proxy/connectivity settings (e.g. corp. firewalls)
 * 15) resources/assumed hard to find a volunteer for
 * 16) we cant adjust old and released versions
 * AI: take to the ESC still, to prove the assumption (Bjoern)
 * 1) maybe better to extend a webbased solution for that (Bjoern/Petr)
 * 2) OS and version can be encoded in the initial "file a bug" url
 * 3) updateable and localizable
 * 4) no 'automatic' inclusion of docs, but that is tricky anyway from a privacy POV
 * 5) while our current infra team is stuffed with work, its in general easier to find talent for this kind of work (and maybe grow the infra team)
 * 6) in theory, it is possible to make the BSA file bugs without the reporter registering (Petr/Bjoern)
 * 7) file them from a [hidden email] account
 * 8) add a bsa-reporter:[hidden email] field in the whiteboard status
 * 9) add some procmail magic to the [hidden email] account that forwards to the bsa-reporter
 * 10) without keeping the original reporter in the loop, bug report quality will only get worse
 * 11) very hackish approach
 * 12) the idea to create to send the bug to a mailing list for review instead of blindly creating a bug is interesting (Bjoern)
 * 13) might help getting more people involved in QA
 * 14) works with local teams in non-english too
 * 15) we could do a testdrive of this with those l10n communities that have enough manpower to handle the incoming native language reports:
 * 16) portuguese/brazil
 * 17) french
 * 18) german
 * 19) english
 * 20) requires those prescreening the report to be responsive and reliable (thus their teams need a certain size)