Re: [Libreoffice-qa] Litmus, a proposal
2012.03.22 01:00, Pedro rašė: Bjoern Michaelsen wrote Register mail just took a while. Which brings us to the original problem: why doesn't it support OpenID from the beginning? In a little over a month, AskLibO already has nearly 600 users. How much clearer does the message need to be? Mozilla plans to implement BrowserID in the tool: https://bugzilla.mozilla.org//show_bug.cgi?id=700751 . I don't think they would be willing to implement OpenID themselves, but I don't think they would try to sabotage anyone from doing so either. Rimas ___ 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] Litmus, a proposal
On Wed, Mar 21, 2012 at 10:44:46PM -0700, Pedro wrote: I thought it was what WE (you , me, TDF, the LO project,etc) are missing. That is already perfectly clear -- as you know we already have a bug for that -- and thus need no repeating. But punching the codeconductor devs for not having your pet feature in a prerelease of their free (as in free beer and as in free speech) product is absolutely not. Complaining does not help us one bit here, getting a web developer from your friends interested in implementing this is (hint, hint ;) )! 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] Litmus, a proposal
Hi Pedro, On Thu, Mar 22, 2012 at 10:04:51AM +0100, Bjoern Michaelsen wrote: That is already perfectly clear -- as you know we already have a bug for that -- and thus need no repeating. But punching the codeconductor devs for not having your pet feature in a prerelease of their free (as in free beer and as in free speech) product is absolutely not. Complaining does not help us one bit here, getting a web developer from your friends interested in implementing this is (hint, hint ;) )! Sorry, if that sounds to harsh, but reality sometimes is. Indeed, we might also consider to use some funds on topics like this, but for example in this case, we need to really know if Caseconductor is suitable at all for what we do (see my comments). So if you cant dig out a warm body implementing OpenID for Litmus/Caseconductor/Bugzilla (which admittedly isnt easy), the next best thing is finding out if the hope put into caseconductor is justified, or if it is doing too much/is too confusing for us. So: Are you maybe interested in having a good look at: https://caseconductor-dev.allizom.org/ http://readthedocs.org/docs/case-conductor/en/latest/index.html and compare it seriously with what we have at: https://tcm.documentfoundation.org/ because we obviously need to know that before throwing money in that direction? That would be an awesome, constructive contribution. 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] Litmus, a proposal
Hi Björn Your comments make perfect sense. I am available to help with a serious comparison of Litmus vs Caseconductor. But if Mozilla is going to drop Litmus, does that make sense? Or should you (TDF) collaborate with Mozilla to make sure that the new tool suits our needs, since the old one will be dead soon? The email from Rimas made me realize that obviously Mozilla is implementing BrowserID (it is their tool after all). From a not-so-knowledgeable point of view OpenID seems more widely adopted but it does provide a lot of information about you to your OpenID provider. Maybe BrowserID is indeed a wiser option from a privacy point of view... http://security.stackexchange.com/questions/5323/what-are-the-downsides-of-browserid-compared-to-openid-oauth-facebook Thoughts? Regards, Pedro -- View this message in context: http://nabble.documentfoundation.org/Libreoffice-qa-Litmus-a-proposal-tp3845560p3848156.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] Regressions in Open Source projects ...
Hi Petr, all, On Thu, Mar 22, 2012 at 02:44:38PM +0100, Petr Mladek wrote: I agree with Marcus that often it is not easy to say what functionality is affected. Various changes might have many side effects. Still, developers are the ones with the best guess there. I am a bit scared by adding another channel and layer. Developers already have to provide commit message, update bugzilla, ask for review on the mailing list. You will find from the rest of the mail, that I dont want to forced devs to write a nicely formatted complete testcase, but simple a oneline hint at what to test along with the review request to the mailing list. The example was (again inspired by Rainers picks) please test copy-paste in calc. I explicitly do _not_ want another channel, but to have the QA-readable stuff in the review requests (an existing channel). It might be enough to write good commit messages and do not forget to mention the related bug numbers. I think that we are quite good with the bug numbers but we could do more user friendly commit messages. They are sometimes too technical, so normal user or QA does not have any idea what functionality is affected. I dont think commit messages are the best place to start putting this. Devs usually are reluctant to make guesses -- esp. if they are archived for eternity as commit messages are. So even if we would have a commit message template containing a might also affect: line the results would be thin, I guess. It might be worth a try though. Developers are already pretty overloaded. I doubt that they have time to write detailed testcases in Litmus. I did explicitly state, they are not required to provide detailed testcases, but draft oneliners for QA to pick up. It does not make sense to write one line in Litmus when it is already mentioned in the commit log. The oneline is not intended to be written on Litmus, but in the review request (or as a reply to a QA guy asking the dev you seem to have commited 100 changes this major, could you kindly give me an overview what those are about. Commit message might do so too, but see my reservations above. (That being said: Nobody would mind developers to do stuff on Litmus themselves). I suggest that QA volunteers follow commit messages (would be my week summary still useful here?) and check affected areas. They might ask the developer when in doubts. It will teach developers to write better commit messages, ... Weekly summary: I guess less so. Now that we have core, te webinterface is better that those summaries. Also: QA guys browsing the git log could would allow to have someone watching sw, someone watching sc etc. to allow divide and conquer approaches (*). As for better commit messages: Once a commit is done, it cant be changed. On a review request, one can ask back and append (reply) the missing info. If that is done viciously, we might end up with the good stuff in the commit message already (devs are a lazy, but clever bunch). The same is valid for features. We already have release notes in the wiki page. QA guys could watch it and play with new features. They might just document in Litmus what they did. I would think this is doing it the wrong way around: Devs-Release Notes-QA is just tricky and errorprone. The release notes are out of sync with the commits, so non-devs will always be insecure about when something is in a build and from which point on the new feature is considered ready for testing. Thus a lot of frustrating and wasteful QA: That is buggy Dev: Yeah, I know, its not done yet. exchanges coming our way. IMHO, what really should happen is Devs-QA-Release Notes, thus devs explain to QA what they are doing (not in release notes, but along commits) and ideally QA (maybe together with the dev) then writes the release note entries. This ensures: - that QA understands what is going on - that QA learns what is ready when - that the release notes are actually readable by mere mortals early Also we must not set wrong expectations. If we force developers to provide a lot of information for QA, they would think that their changes are heavily tested and become less careful about their changes. I would think the effect is opposite. It forces devs to think (and maybe try) themselves how and if their change can be tested -- this alone might raise the test coverage. ;) It would be great to ask for testing if we have many volunteers and people asking what need testing but I do not see such people. I think this is a chicken and egg problem, we have so few people there as there is no clear proposed offering what can be done. I firmly believe this is a build it and they will come field of dreams situation. IMHO the way to go is automated testing and adding a test case for fixed bugs im possible. I fear that most of the time not even devs know all affected features so how should a normal user or qa person know what to test. I agree here. There is strength in numbers. If
[Libreoffice-qa] Minutes - QA related - TSC call 2012-03-22
Hi, you can find a summery concerning QA related discussion of the Engineering Steering Committee on http://wiki.documentfoundation.org/RBd/TSC_Call_Minutes Kind 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] Litmus, a proposal
Bjoern Michaelsen wrote Can you maybe be on the QA call tomorrrow? I'm afraid not. 15:00 UTC on any weekday is during my work hours. I will read the minutes later. Regards, Pedro -- View this message in context: http://nabble.documentfoundation.org/Libreoffice-qa-Litmus-a-proposal-tp3845560p3850021.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/
