Re: [Libreoffice-qa] [libreoffice-l10n] L10n of Florian's Windows installer

[Rimas Kudelis]

Hi Florian,

would it work if you got one CSV file for each language? Each file would
contain three columns:
Name | en-US string | target string

If that would do, we wouldn't need any conversion at all to fill these
files in Pootle, I believe.

Rimas

2013.08.28 11:38, Florian Reisinger rašė:
> Hi all,
>
> It is okay for me, but I have not used Pootle a lot...
> For me it would be the best to give you a xls [I use a program to import
> them into the .resx file format] file and get one in return from time to
> time, or if I ask to...
>
> I hope that this is okay for all of you :)
>
> Am 28.08.2013 10:11, schrieb Sophie:
>> Hi Chris, Florian, all,
>> Le 28/08/2013 01:00, Chris Leonard a écrit :
>>> It would really help you manage translation workflow if you just
>>> posted the POT to the Pootle "templates" language.  You can easily
>>> create a new project for this if you want it seperate from other
>>> projects.
>>>
>>> If this is spreadsheet based, using csv2po and po2csv might be needed.
>> Taking into account the number of localizations we have now I think that
>> would be the best for all of us.
>> Florian, is it ok for you if we use Pootle to maintain the localization
>> flow, this is where we are used to work for all the LibreOffice projects.
>> Cheers
>> Sophie
>>
>

___
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] Moztrap OpenID support - go for testing!

[Rimas Kudelis]

Hi Yifan!

2012.10.11 12:43, Yi Fan Jiang rašė:
> I have brought OpenID to Moztrap this week, the following is the test
> page for login:
>
> http://vm12.documentfoundation.org/openid/login/

thats awesome!

> I will update the main login page to add openid support next weekend
> if no critical issue found.
>
> Functions currently supported (testing required)
> 
>
> * Based on EMAIL address, native login/Mozilla Persona/OpenID are all
> mapped to the same user in Moztrap now, so they should be seamlessly
> worked together. Those details as follows.
>
> - If you have a native registered moztrap user or ever used Mozilla
> Persona to login, and your openid provides an exact same EMAIL of such
> an account, the original user and openid user will be treated exactly
> identical.
>
> Actually you should feel nothing changed except inputting password is no
> longer needed :)

Great! Except here's a critical issue for you: I have just managed to
log on to MozTrap as you!!!

Here's the proof: http://i.imgur.com/eF0Cl.png .

In case you're wondering how I did this: I logged on to my weblog, set
my email in my profile to yfji...@suse.com, and used its OpenID provider
to log in to the test website. Since I don't need to proove to my weblog
or the demo site that the email is indeed mine, I basically have full
control over MozTrap now. So, not a good thing. This needs some
rethinking. Most obvious option would be to use the OpenID URL (or
whatever it is that OpenID provides as the identifier) as id when
logging in using OpenID. This would also have a nice "side effect" that
the user could change their primary email, and still be able to log in
with the same user id and permissions.

Regards!
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] Reporting Ignorant User on FDO?

[Rimas Kudelis]

2012.09.13 08:32, Roman Eisele rašė:

Am 12.09.12 09:34, schrieb David Tardon:

I suggest to reply to any such comment of his by citing
https://issues.apache.org/ooo/show_bug.cgi?id=120107#c1 (the user name
and email looks familiar, does it not? :-)


This is a wonderful idea, both simple and elegant. My compliments!


Wonderful, indeed!

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] Online update in 3.6

[Rimas Kudelis]

2012.08.03 11:37, klaus-jürgen weghorn ol rašė:

Hi Jan,
Am 03.08.2012 10:04, schrieb Jan Holesovsky:


 Fixed now, the update
to RC4 should be offered.  Thanks again for the testing!


Works. Thanks.



Hi,

the update string is somewhat fuzzy though: for me it says I have 
3.6.0.2 installed, and the update is 3.6.0 RC4. I know that the laste 
digit is the RC number,  but still I think it would be nicer if same 
numbering scheme was used for both version numbers.


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] Investigating Caseconductor for next QA call

[Rimas Kudelis]

Hi Bjoern,

2012.03.30 15:17, Bjoern Michaelsen rašė:

Hi Sophie,

On Fri, Mar 30, 2012 at 12:05:24PM +0200, Sophie Gautier wrote:

I'm not Pedro or Rimas, but I would have time to have a look for the
end of next week. If you think I'm not enough skilled, no problem.

That would be excellent! And if anything, you would be overskilled as my
primary concern with Caseconductor so far is that it is to
confusing/overengineered to attract people into easily contributing. So having
a look at that would be most appreciated.

I still would love to have Rimas have a look at Caseconductor too if possible,
as he was having high hopes in it, that I dont want to simple brush away without
a better look.


Sorry, but I don't think I'll have enough time for proper investigation 
anytime soon (definitely not till the end of April). I fully trust 
Sophie though. I think she's the person who actually does some QA (as 
opposed to me), and she's definitely better organized than myself. :) I 
think Sophie has some contacts at Mozilla QA, perhaps they could brief 
her (and us, by extension) about working with CC?


As for the high hopes – I think it's an overestimation. I've created 
myself an account in the test server, but just like you, I haven't 
figured out what I can do next, but then again, I didn't have much time 
to stare at it and click things either. CC *looks* drastically different 
than Litmus, maybe that's the culprit.


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

[Rimas Kudelis]

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

[Rimas Kudelis]

2012.03.21 21:27, Bjoern Michaelsen rašė:

On Wed, Mar 21, 2012 at 11:45:29AM -0700, Pedro wrote:

But adding it to the "easy hacks" doesn't it mean that it's off limits to
the usual collaborators

No, it only means that these task do not require a particulary deep knowledge
of some arcane corners of the LibreOffice codebase.


In fact, it has nothing to do with the LibreOffice codebase. :)

For the reference:
* I have a Litmus TODO list at 
https://wiki.documentfoundation.org/Litmus_TODO. I'd be glad if you 
added bugzilla links and missing entries to it. As I've mentioned 
before, it would be really nice to maintain that TODO in one place 
instead of scattering it in Bugzilla, mailing lists and the wiki.

* Our Litmus source code is available at http://gitorious.org/litmus .
* As I mentioned on one of the bugs, I don't think Mozilla is interested 
in improving Litmus anymore. They have a new tool just behind the 
corner. This one, I think: http://caseconductor.wordpress.com/ . Once 
they launch it (and from the page, it seems they plan to release on 30th 
this month), we may want to have a look at it too. I don't know, but it 
may not make sense to keep improving Litmus at that point. After all, if 
they settled for a rewrite, you just have to expect it to be so much 
better than the old tool, right? :)


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] [TESTED] Re: 3.5.1 Online Update testing

[Rimas Kudelis]

2012.03.09 17:28, Pedro rašė:

Christian Lohmaier-2 wrote

it is the server that
makes the decision whether there is an update, not LibreOffice.
LibreOffice just displays the server's response.

So the server response needs to be fixed to properly identify my current RC1
as 3.5.1.1?

If LO sets two update channels the server would only report updates at (or
even display) the w level (using the x.y.z.w naming) to those who
deliberately choose to be on the Beta channel and would report only higher
updates to all other users.

Can this be done?


IMO, that would be indeed a good move.

Regarding implementation, I guess we could have a checkbox in the Update 
preferences dialog, which would allow the user to opt in or out of 
betas. Or this could also be a drop-down list with three channels to 
choose from:

* betas/RC's
* releases
* conservative releases

This would make the request for update have one more parameter. Should 
be quite easy to implement, I think.


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] Make use of your karma - feel free to retag/edit posts (Fwd: Q&A forum feedback)

[Rimas Kudelis]

2012.03.02 14:09, Christian Lohmaier rašė:

On Fri, Mar 2, 2012 at 11:15 AM, Pedro  wrote:

I never received a copy of my sent email (I assume you rejected my previous
suggestion of enabling the form to send a copy to the author)

Yes, I regard it as pointless. If you want a copy for your own
records, send mail to the website list directly. After all it will
reach the same group of people (+ a couple more)

You receiving a copy will not prevent me from making mistakes when
answering, so...

When not receiving a reply, you need to resend/ping people anyway, no
matter whether you did receive a copy or not.


It is convenient to have a record of what you have suggested though. 
Receiving the message also means that the server "really works". Plus, 
not everyone knows that askbot feedback is to be sent to the website 
list. So, I wouldn't regard it as pointless, and if enabling this 
feature is as easy as checking a box, I would enable it if I were you.


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] FDO bugzilla setting for following all bug reports of certain module ?

[Rimas Kudelis]

2012.03.02 09:13, Alex Thurgood rašė:

Hi all,

I have been rummaging around FDO bugzilla trying to find a way to make 
myself automatically get CC on bugs filed fot the database module. As 
yet, I've not found any easier way to do this than by querying for all 
bugs where the database module is specified, then opening each one and 
adding myself manually, which naturally is not very efficient, and 
will take me about 3 years...


Anyway, so just wondering if any of you had any ideas how to solve 
this in an elegant way...


Thanks for any pointers.


In your preferences, you can choose to follow the default assignee of 
database bugs. And a few other people. I think this would do the job.


Regards,
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] manual testing

[Rimas Kudelis]

Hello,

2012.02.27 13:30, Pedro wrote:

Sophie Gautier wrote

No, Litmus is an online tool to manage manual test cases.

-snip-

It's really simple to use for the tester, he just has to reproduce what
he is reading on the Litmus site into LibreOffice and then mark the test
as passed, skip or failed, nothing more :)


Yes, that was my understanding of Litmus.


I don't know why you assume it's a Windows-only tool then. Don't you 
have a web browser in your other OS? :)



One thing that could be done to make the Litmus site more  user attractive
would be to add an OpenID login option (like in the ask.libreoffice.org
site)

Personally I haven't tested Litmus because I really don't feel like
registering to yet another site (I have already registered to three mailing
lists, the Nabble site and the wiki)


OpenID integration is a great idea indeed. I too hate to create separate 
logins for each website or service, and then end up with a bunch of 
different passwords I can't remember and/or a bunch of shared passwords 
that are insecure...


I've added this suggestion to the TODO list 
(https://wiki.documentfoundation.org/Litmus_TODO), but I can't promise I 
will be looking into it anytime soon. Litmus' source is available 
though, so I'd welcome contributions. ;)


Regards,
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] RC3 released as Final version???

[Rimas Kudelis]

2012.02.15 00:14, Pedro rašė:

Olav Dahlum wrote

This should be fixed ASAP from a marketing point of view. It's all about
expectations, so renaming the tarball etc is just not good enough.
Leif did also receive a similar complaint earlier, so this should be
taken very seriously. This is not the first time I've addressed the
dangers of such practices.


Thanks you, Olav. I was starting to think I was the only mad person here.

Apparently even Cor finds this normal.

Cor, please show me ONE program that does this and I will agree with you.

  This is completely absurd for me...


I think the other vendors do it the other way around (well, at least 
Mozilla does, AFAIR): their RC releases indicate themselves as final, so 
after renaming, this simply becomes true, and no recompilation is necessary.


One way to address this and still allow identifying which RC this is 
easily would be to implement my suggestion from 
https://bugs.freedesktop.org/show_bug.cgi?id=42239. This way, the about 
dialog in RC3 would look somewhat like this:


LibreOffice 3.5.0
Build ID: libreoffice-3.5.0.3

In this case, the fourth number in Build ID line would represent the RC 
number.


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] [Libreoffice] weird shortcut key for repeat action in Writer

[Rimas Kudelis]

Hi Pedro,

2012.01.23 13:07, Pedro Lino ras(e.:
>
>
> All we should need is localised versions of key names like Ctrl, Del,
> Ins (that are on almost every keyboard [1], but whose names can
> change) and global versions of key names for
> alphanumeric/script-specific keys (which might not be on every
> keyboard, but whose names are the same internationally).
> So, looking at the code, we'd need to just move the keyboard language
> specific data to the specific locales. This also seems a lot more
> scalable than for every localiser having to ask a developer to add
> their native keys into this code.
>
>
> That would be too simple. See my example in the previous email.
> You would need to match the keys for EACH keyboard model, regardless
> of Locale.
>
> This is particularly true for laptops (at least in Portugal...). All
> laptops sold in Portugal have a Portuguese layout but the Special keys
> (like Ctrl, Alt, Insert) have the English text. Obviously
> manufacturers do this to save on producing specific keys. So Locale
> doesn't solve the problem.

I think you'd just have to choose which label to use. Correctly matching
key names with the keyboard model is hardly impossible. I would say
you'd just have to choose whether to use Inserir or Insert, and stick to
that choice. Which strings you would choose would be completely up to
you, but you could of course take popularity and other factors into account.

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] [Libreoffice] New Windows tinderbox: Windows 2008R2

[Rimas Kudelis]

Hi,

2011.11.29 10:15, Rainer Bielefeld rašė:
> Rainer Bielefeld schrieb:
>
>>> GUID) aren't possible with MSI. If what Rainer wants is to have stable
>>> version of LibreOffice installed along with a testing version,
>
> Or more precisely:
>
> I have 10 ... 20 Master versions on my PC so that I can check where a
> regression came into the code.
>
>
> That could be done with the MinGW builds, but they are new and still
> lousy buggy, it will still cost some time until they will be in a
> shape that the can be used for "real life" tests.

Well, possible solutions I can think of:

a) use GUID #1 for rc/release builds, GUID #1 or #2 for betas, and a
random GUID for each nightly. One drawback here is that you would not be
able to check that installation over an already existing installation
works correctly in nightlies.
b) it's probably possible to provide zip/xz/whatever archives of nightly
builds along with the installer. This would allow you to test everything
except installation of LibO, having as many parallel LibreOffices as you
need.

Either way, you should probably file this problem in bugzilla or relay
it to the build people, cause I'm just talking – they are the ones who
will have to solve it.

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] [Libreoffice] New Windows tinderbox: Windows 2008R2

[Rimas Kudelis]

Hi,

2011.11.29 09:19, Rainer Bielefeld rašė:
> Michael Meeks schrieb:
>
>> I believe we switched our packaging format from NSIS .exe's to the
>> new .msi installs that you see now.
>
> the problem simply might be missing manual. We have a "how to" on
> 
> for doing a server installation with "setup.exe", and as soon as we
> have a description how to get the same result with the .msi the
> problem has been solved.

I may be wrong, and forgive me if I am, but AFAIK, parallel
installations of the same product (that is, a product with the same
GUID) aren't possible with MSI. If what Rainer wants is to have stable
version of LibreOffice installed along with a testing version, then a
solution to that would probably be having separate GUID's for stable and
testing versions.

Regards,
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] Test Structure in Litmus

[Rimas Kudelis]

Hi all, and note I'm on the list now. :)

2011.11.16 20:12, Petr Mladek rašė:
> Petr Mladek píše v St 16. 11. 2011 v 15:31 +0100:
>> Rimas pointed out that testers define their platform when entering a "
>> test run". It actually affects the statistics. The number of finished
>> test cases is counted separately for each platform
> Rimas found that also "build id#" and "locale" affects the number of
> finished test cases at https://tcm.documentfoundation.org/run_tests.cgi
>
>
> Why is it a problem?
>
>
> 1. problem with "build id#"
> ===
>
> Imagine the following scenario:
>
>   1. create test run for 3.5.0
>   2. people enter the build id "3.5.0-beta1"
>   3. they do some tests and the result is:
>   + 100% of P1 tests finished
>   + 100% of P2 tests finished
>   + 20% of P3 tests finished
>   4. beta2 is available => people enter build id "3.5.0-beta2
>
>   Result: They will see:
>
>   + 0% of P1 tests finished
>   + 0% of P2 tests finished
>   + 0% of P3 tests finished
>
>   Expected Result:
>
>   + 100% of P1 tests finished
>   + 100% of P2 tests finished
>   + 20% of P3 tests finished
>
> By other words, people will start the testing from the beginning with
> beta2. They will never tests more complicated scenarios (P3, P4 stuff)
>
> Is this what we want?
>
> I prefer to do deep testing during the beta phase => we should not
> restart it with every beta => we should continue where we ended with
> previous beta => the "build id#" must not affect the number of finished
> test cases
>
> Solution (by Rimas):
> 
>
> Remove "build id#" from the UI, use the value 'UNUSED' in the database.
> The real version is defined in the test run name.

The fact that it is a problem was a bit of a surprise for me actually. I
thought there would be at least a few people who'd go through ALL tests
for each build that needs testing. Since I hope that the number of
testers might grow in future, or some other circumstance might change, I
suggested to hide the Build ID field instead of fully dropping it,
leaving the possibility to reverse this at some later point.

> 2. problem with locale:
> ===
>
> Imagine the following scenario:
>
>   1. one person do test run in "de" locale; the result is:
>+ 25% P1 functional (lang-independent) tests finished
>  + 25% P1 l10n (lang-dependent) tests finished
>   2. other person start test run in "fr" locale
>
> Result:
>
>   + "fr" person see:
>   + 0% P1 functional tests finsihed
>   + 0% P1 l10n tests finished
>=> does all tests again
>
> Expected Restult:
>
>   + "fr" person see:
>   + 25% P1 functional tests finished
>   + 0% P1 l10n tests finished
>  => continue with other functional tests and repeat the l10n
>   tests
>
> By other words, the functional tests are duplicated inside one test run
> for each locale; the l10n tests are currently duplicated even twice
> (once by the groups, once by the locale in the test run)

Sorry, I don't quite get this paragraph above. I think I get the problem
from our chat yesterday however.

> Possible solutions by Rimas a me:
> -
>
> 1. Have two separate test runs (branches) for functional tests and l10n
>tests. Ask people to always use "en" locale for functional tests
>group.
>
>Advantages:
>
>   + easy to implement
>   + close to what we have now
>
>Disadvantages:
>
>   + "locale" setting might be used to select localization of the
>test case text => people would be forced to see functional
>tests in English locale

That's not true ATM, since the language the tests are shown in has no
relation to the language as of yet.

>   + many QA people do not know English; they might be discouraged
>   to do the biggest group of functional tests
>   + non-intuitive solution; people need to follow an ugly rule
>   defined somewhere

I think it may be possible to extend Litmus to allow restricting
testruns by locale, and leave English as the only possible locale to run
functional tests on. That would still be a workaround though...

> 2. Remove the locale setting in the "run tests" dialog and ignore it as
>we suggest to ignore the "build id". Note that the l10n tests are
>duplicated in the subgroups:
>
>Advantages:
>
>   + easy to implement
>   + close to what we have now
>   + the l10n tests are localized without hacking Litmus server
>   code
>   + allows to create extra l10n test case for a particular
>   language (is it an advantage? creates a mess?)
>
>Disadvantages:
>
>   + it might be hard to maintain the l10n tests because you need
>   to monitor changes in the "en" group

Re: [Libreoffice-qa] Test case naming

[Rimas Kudelis]

Hi Petr,

2011.11.15 17:30, Petr Mladek rašė:
> Rimas Kudelis píše v Út 15. 11. 2011 v 13:43 +0200:
>>  Also, maybe I shouldn't look that far into future, but I hope that
>>  there will come a day when proper localization of testcases will be
>>  possible (that is, instead of creating a clone of testcase X in
>>  another language, we would actually be able to translate testcase X
>>  into that language). With that in mind, current testgroups (which
>>  represent different locales) would become unneeded.
> I am not sure if the l10n tests will be pure word-to-word translation.
> Some things are done completely different in different languages, for
> example the layout of the letter template, right-to-left language
> features, decimal number delimiter, dates. I am sure that some
> languages would need special tests.

I didn't say they have to be translated word-to-word. They should be
*localized*, and I would expect a localized testcase to suggest
localized number and date formats and other stuff.

RTL, on the other hand, might probably need a few additional testcases.
Though not many, I would guess.

> BTW: How is the localization used during test run?

It's not. It's just shown in the test results.

> I know that I select locale in the "Run Tests - Your Chosen Test Run"
> dialog, see
> https://wiki.documentfoundation.org/Litmus/Litmus_User_Guide#Enter_Test_Configuration
>
> If I select "de", will I see only the "de" test cases from the l10n
> branch? I am not sure if it is important but it would be nice.

No, currently you will still see all testcases.

My idea with localizable testcases though is pretty much about this. If
testcase X was localized instead of duplicated, it would only be shown
once, in user's preferred locale (I don't know yet how exactly the user
would "prefer" that locale though and what a user who would want to test
more than one locale would do).

>> My suggestion is to have a single branch, but carry Priority, Locale and
>> Component information in the Testgroup, and to represent test type by a
>> subgroup. That is, what is now a branch, would become a subgroup, and
>> everything else would become a testgroup (see the attached PDF file).
> Hmm, I am afraid that we would get too many testgroups. It produces 7
> (General, Base, Calc, Draw, Impress, Math, Writer) testgroups for one
> language. We have 109 localizations in sources => we could end up with
> more than 700 test groups.

Which I guess is not realistic, at least in the short term.  ;) Right
now we only have four languages into which testcases are translated.
With 50, it's of course a different story, but with 4 to 10... it's
probably still manageable enough.

>> This allows to:
>> * create testruns based on priority, locale, component, or any
>> combination of these
> The question is what test runs we will want to create.
>
>> * create a single catch-all testrun for a single version of LibO
> would be nice
>
>> * share the same General Functional Tests subgroup between testgroups
>> designated for different locales (that is, you would create this
>> subgroup once, and add it to all locale groups)
> I am not sure what you mean with this. Could we share subgroups between
> test groups in Litmus? Is it clearly visible or is hard to maintain and
> see?

Like I mentioned before, when you create/edit a testgroup, you can add
the subgroups you want to it. So subgroups can be shared, yes.

> BTW: What do you mean with the "Basis Functional Test"? We do not have
> this subgroup in the current structure.

Don't we?
https://tcm.documentfoundation.org/manage_testgroups.cgi?testgroup_id=58

>> * drop 75% of the testgroups (there would be about 28 of them initially)
>> if/when proper testcase localization is implemented, still not rendering
>> the remaining testgroups useless.
> I am not sure if we really could drop them. Well, the question is if we
> need to split between lang-dependent and lang-independent on the top
> level.

I don't think there are many lang-dependent testcases. Desired result
may depend on the language, yes, but the testcase itself?

> Heh, it seems that it is quite complex problem. I am going to write
> another mail where I will try to summarize some ideas :-)

Good luck with that. :)

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] Creating test cases for Litmus server

[Rimas Kudelis]

2011.11.15 10:42, Petr Mladek rašė:
> Rimas Kudelis píše v Po 14. 11. 2011 v 21:53 +0200:
>>> I have described how to contribute a test case at
>>> https://wiki.documentfoundation.org/QA/Testing/Test_Cases_Contribution
>>>
>>> It allows both ways: wiki page and mailing list.
>> Petr, did you account for the fact the the initial assumption (only
>> super admins can add testcases) is now invalid? Is current granularity
>> sufficient, or is there a demand for even more control over who can do what?
> My understanding is that people can't edit test cases out of box.
> Someone needs to add them to the special group.
>
> I think that we should not give these rights automatically. It should
> work the same way like the commit rights for git LO sources. People need
> to send few patches first. If they are good, they get commit rights.
>
> Does it make sense?

Sure it does! :)

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] Test case naming

[Rimas Kudelis]

On 2011.11.14 12:28, Petr Mladek wrote:
> Yifan Jiang píše v Ne 13. 11. 2011 v 18:46 +0800:
>> For example:
>>
>> #EN - w001 xxx
>>
>> is supposed to have the same content with (but in different version of
>> language):
>>
>> #FR - w001 xxx
>> #DE - w001 xxx
>> #pt-BR - w001 xxx
>>
>> These give us reasonable information showing which cases are supposed
>> to be "synced" to each other (they may not have exact same steps of
>> testing because of the diversity of language settings, but they should
>> test the same areas). So for current testing organization, I think
>> these ids are still playing their role in L10N test
>> branches. Otherwise, syncing of cases could be painful.

Ah, this makes sense.

> So, the number 001, 002, 003, 004 is a l10n test case number (something
> like bugzilla number). Would be enough to mention it in brackets at the
> end of the test case summary? I mean something like:
>
> p1 - test case summary (w#1,en)
> p1 - another test case summary (w#2,en)
>
> and localized
>
> p1 - test case summary (w#1,en)
> p1 - popis testu (w#1,cs)
> p1 - Testfall Zusammenfassung (w#1,cs)
>
> I know that it is not ideal because it wont be that easy to sort the
> test cases by the id and compare the list. On the other hand, syncing
> localized test cases will not be easy anyway. I think that the bug
> priority is more important sorting criteria
>
> Note that
>
> p1 #EN - w001 test case summary looks confusing to me. There are just
> too many identifiers in the prefix. And it does not help with sorting as
> well.

P1 W01EN would be shorter. Still admittedly quite ugly though.

>>  Meanwhile in Function Regression testing branch, by the fact we are
>>  now using a single case to host all language versions of test case, it
>>  may not make sense to keep the id any more.

Note the testcase still has its real id (used in the database). If
needed, it could be made more visible.

> This way, it would look the same for function regression test and
> localization regression tests. The localization regression test will
> just have some extra identification in the brackets.

Like you said, this would make different testcases harder to associate
with each other. OTOH, I guess only the admins often see them all in the
same place.

 I suggest to split test cases into several levels by priorities:
>> Actually it is a great idea to have priority here, at least they are
>> helpful for us to define subset of test runs. For example, we can
>> create "smoke test runs" by select P1 only test cases when creating a
>> test run from a full regression branch containing all cases.
> Exactly
>
>> That is to say, even before we sort out how order of the test cases
>> could be implemented, we can always create specific test runs on
>> demand via the information of the priority "tags".
> BTW: How do you suggest to create the priority "tag"? Is there any
> better solution than to put it into prefix of the test case summary?

Well, as an alternative, branches/groups/subgroups could be reviewed
again. :)

Also, Litmus allows marking certain test runs as recommended and shows
them on top. This means that separate P1 testruns could be created and
promoted on Litmus homepage.

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] Creating test cases for Litmus server

[Rimas Kudelis]

Hi,

On 2011.11.14 16:27, Petr Mladek wrote:
> Sophie Gautier píše v Pá 04. 11. 2011 v 17:13 +0100:
>> On Fri, Nov 4, 2011 at 10:27 AM, Petr Mladek  wrote:
>>> Sophie Gautier píše v Čt 03. 11. 2011 v 21:30 +0100:
 The best way for the moment, would be to add the tests on the wiki and
 and admin to add them to Litmus. I know it's less easy and open than
 we would like however.
>>> Yes, it might be a good workaround if the transition works reasonable
>>> fast. We could create admins from people that contribute many good test
>>> cases. So, it might balance the load on admins.
>> yes
>>> Alternatively, people might send test cases to the libreoffice-qa
>>> mailing list and add [TESTCASE] into the subject. It would work the same
>>> way like [PATCH] on the developer mailing list.
>> it's a good idea too :)
> I have described how to contribute a test case at
> https://wiki.documentfoundation.org/QA/Testing/Test_Cases_Contribution
>
> It allows both ways: wiki page and mailing list.

Petr, did you account for the fact the the initial assumption (only
super admins can add testcases) is now invalid? Is current granularity
sufficient, or is there a demand for even more control over who can do what?

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] Test case naming

[Rimas Kudelis]

2011.11.14 12:07, Petr Mladek rašė:
> Rimas Kudelis píše v So 12. 11. 2011 v 22:46 +0200:
>> 2011.11.11 22:14, Petr Mladek rašė:
>>> The list of existing test cases looks the following way in Litmus:
>>>
>>> id   # testcase summary  # subgroup
>>> ---
>>> 1066 # g001 - Installing LibreOffice # General
>>> 1061 # g002 - Uninstalling LibreOffice   # General
>>> 1053 # g003 - First launch of LibreOffice# General
>>> 1063 # g004 - Creating a new document# General
>>> 1048 # w002 - Importing MS Word documents# Writer
>>> 1052 # w003 - Exporting ODF text document to MS Word formats # Writer 
>>> 1049 # w004 - PDF export of text docs# Writer
>>> 1054 # w001 - Creating a new text document   # Writer
>> If you look at what you pasted (and at your image) again, you'll notice
>> that #w001 is the only testcase that wasn't shown in its expected
>> position, and that is because it wasn't positioned correctly inside the
>> subgroup. I've just corrected its position and it's now shown where
>> expected.
> Interesting. So, the test cases are not sorted alphabetically. Am I
> right? How do you define the sorting inside the group? Are you able to
> do it from the UI? I do not see this possibility in the "Manage
> Testcases" interface :-)

When you are creating/editing a subgroup and adding testcases to it, you
can sort testcases as you like.
Similarly, when you are creating/editing a testgroup and adding
subgroups to it, you can sort subgroups as you like.

So yes, this is available in the UI.

>> However, I'm afraid we can't randomize testcase order by
>> default. Currently, this would probably have to be done manually each
>> time a relevant subgroup is updated. That would be a PITA. On the other
>> hand, it's not really that bad. You can still run the tests in random
>> order, but you will always see them in the specified order.
> I agree. We do not need to randomize the test cases in the view. It
> might be enough to ask people to run it randomly.

Good. :)

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] Test case naming

[Rimas Kudelis]

Hello Petr, and everyone,

2011.11.11 22:14, Petr Mladek rašė:
> The list of existing test cases looks the following way in Litmus:
>
> id   # testcase summary  # subgroup
> ---
> 1066 # g001 - Installing LibreOffice # General
> 1061 # g002 - Uninstalling LibreOffice   # General
> 1053 # g003 - First launch of LibreOffice# General
> 1063 # g004 - Creating a new document# General
> 1048 # w002 - Importing MS Word documents# Writer
> 1052 # w003 - Exporting ODF text document to MS Word formats # Writer 
> 1049 # w004 - PDF export of text docs# Writer
> 1054 # w001 - Creating a new text document   # Writer
>
> See also the screenshot at http://download.go-oo.org/qa/test-case-list.png
>
>
> I see two problems here:
>
> 1. The test cases are ordered by the id, so the first writer test case
>is the last in the list.

No, they are not ordered by id. Actually, I've just digged, and the
order is as specified for subgroups inside a testgroup, and then as
specified for testcases inside each subgroup.

If you look at what you pasted (and at your image) again, you'll notice
that #w001 is the only testcase that wasn't shown in its expected
position, and that is because it wasn't positioned correctly inside the
subgroup. I've just corrected its position and it's now shown where
expected.

>I wonder how complicated would be to hack Litmus to sort it by
>the testcase summary.

This is thus irrelevant, cause there's nothing to modify. :)

> 2. I am not sure what is the meaning of the numbers 001, 002, 003.
>
>It looks like they define the order in which we should process the
>test cases. If this is true, it does not look ideal:
>
>   + if we do another important test case, we will need to rename
>   all less important test cases to keep the right order
>
> + test cases will be checked by many people; we can't force them
>   to do it in an exact order; the result would be that all
>   people will test the same test case in parallel
>
>   Hmm, we need to encourage people to do the test cases in
>   random order. We still should somehow prioritize the test
>   cases.

I personally don't like current naming with ugly prefices at all, but
it's Yifan's call, and I suppose he has a good reason for that naming
scheme. However, I'm afraid we can't randomize testcase order by
default. Currently, this would probably have to be done manually each
time a relevant subgroup is updated. That would be a PITA. On the other
hand, it's not really that bad. You can still run the tests in random
order, but you will always see them in the specified order.

> I suggest to split test cases into several levels by priorities:
>
>   P1 - highest: used for very basic tests, e.g. app can be
>  installed; it starts; is able to load/save some test
>  documents; so it a kind of smoketest
>
> P2 - high: test very common functionality that is used by most
>  users. e.g. able to write text, insert picture; draw
>  elements; create table; use function in calc; create graph,
>  run presentation
>
> P3 - medium: test common functionality that is used by typical
>  a bit experienced office user, e.g. create borders around
>  tables; do animation between slides; modify text style;
>  modify master slide page;
>
> P4 - low: test functionality for hi-tech users, e.g. writing
>  macros, using Calc solver, complex operations with data
>  bases
>
> I suggest to use the names:
>
> p1g - 
> p1w - 
> p2g - 
> p2w - 
>
> Then we will have all p1 test cases listed before p2 test cases.
>
>
> What do you think?

Prioritizing is probably a good idea, but like I said, random order
would require some Litmus modification. While certainly possible (and
probably quite easy), I'm not sure that is what we indeed want.

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] Creating test cases for Litmus server

[Rimas Kudelis]

Hi again,

2011.11.05 09:55, Rimas Kudelis rašė:
> 2011.11.04 08:56, Yifan Jiang rašė:
>> On Thu, Nov 03, 2011 at 05:32:03PM +0100, Petr Mladek wrote:
>>> On Wed, 2011-11-02 at 14:32 +0800, Yifan Jiang wrote:
>>>> IMHO we may make the access more open at least with the problems resolved:
>>>>
>>>> 1. At the moment, the only user group can edit testcases is the
>>>> Litmus Super Admin, which has an access to manage everything including
>>>> other people's account. AFAIK, we had a particular Test run Admin group
>>>> designed for test case editing but it didn't work properly currently :(
> Well, it's obvious that we need more groups than folks from Mozilla did.
> I'm not sure though whether or not it's hard to implement (without
> knowing Perl). I guess it shouldn't be. I can promise to look at it, but
> I'm afraid I'm slowly drowning in my promises, and that's not good. So
> I'll take a look at it, but no deadlines please. :)

OK, this appears to have been easier than I thought. It seems like the
functionality is already in Litmus, but simply not exposed in Litmus
admin UI. With just two SQL queries I have just created a new group
called 'LibreOffice product administrators' and associated it with
LibreOffice product. As a member of that group, I can now manage
testcases for LibreOffice product, and I am NOT able to edit users.
Hooray! \o/

Furthermore, when I'm a member of both 'LibreOffice Product
Administrators' and 'Litmus Test Run/Test Day Administrators', I can
create testdays too, without still being able to edit users.

Folks, can you check and confirm that this particular problem is really
solved? :)

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] Creating test cases for Litmus server

[Rimas Kudelis]

Hi all and sorry for a bit late reply,

2011.11.04 08:56, Yifan Jiang rašė:
> On Thu, Nov 03, 2011 at 05:32:03PM +0100, Petr Mladek wrote:
>> On Wed, 2011-11-02 at 14:32 +0800, Yifan Jiang wrote:
>>> IMHO we may make the access more open at least with the problems resolved:
>>>
>>> 1. At the moment, the only user group can edit testcases is the
>>> Litmus Super Admin, which has an access to manage everything including
>>> other people's account. AFAIK, we had a particular Test run Admin group
>>> designed for test case editing but it didn't work properly currently :(

Well, it's obvious that we need more groups than folks from Mozilla did.
I'm not sure though whether or not it's hard to implement (without
knowing Perl). I guess it shouldn't be. I can promise to look at it, but
I'm afraid I'm slowly drowning in my promises, and that's not good. So
I'll take a look at it, but no deadlines please. :)

>>>
>>> 2. I am not quite sure if we have a backup/version control in
>>> Litmus, so it would be better to update/remove cases with cautious.

No, I don't think there's any internal backup or version control
mechanism in Litmus. However, the server admins have set up daily
backups of the machine Litmus runs on, and that includes databases, so
we do have external backups I think.

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 problem in Chrome and IE.

[Rimas Kudelis]

2011.11.03 06:16, Yifan Jiang rašė:
> Hi Rimas,
>
> Would you help to look a bit of this bug found by occasion, though I am not
> sure if someone else also meets the same problems. The bug may cause most of
> IE and Chrome users cannot filter test cases with usually used UI.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=42541
>
> It just reminds me to think about the new layout of test case selection box we
> did last week, which might be related?

That was a pure css change. I don't see how it could be related.
However, as I mentioned before, I updated Litmus from upstream last
weak. That could be related.

I'll take a look at this problem later.

> Thank you for your time and I appreciate your help :)

You're welcome. :)

Regards,
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/