Re: [Libreoffice-qa] installing 400rc2 parallel on Windows - no way to choose extensions ?

[Andras Timar]

Hi,

On Sun, Jan 27, 2013 at 10:59 PM, V Stuart Foote  wrote:
> Andras,
>
> So as per the  Installing_in_parallel Wiki
> 
> to install a parallel instance, should we be setting a WRITEREGSITRY=0 when
> doing the command line /A administrative installation?

Administrative installation just extracts the embedded CAB file onto
the disk in the right folder structure. It does not write anything to
registry. WRITEREGISTRY property has no effect.

>
> And other than adjusting the "*UserInstallation=*" location of the
> program\bootstrap.ini file so as to not clobber the existing user
> profile--the administrative install becomes the working "parallel"
> installation?   Does the system default language become the language of the
> administrative install?  Or does it always remain 1033, en-US?

AFAIK default language selection happens at first start.

>
> Couldn't LibreOffice program features and alternate languages be configured
> and applied against the administrative install using a .MST transform file?
> And how complicated would that have to be to end up with a usable alternate
> installation--not needing to run the recast .MSI located in the
> administrative install's folder.
>

If I understand correctly, you would like to test custom
installations, where not all features are present, parallel. I don't
know, how to do that right. One option is to manually delete files
that belong to a given feature. I don't know how to manipulate
administrative images with MST files.

Best regards,
Andras
___
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] Stagnant NEEDINFO bugs

[bfo]

Hi!
My proposal:

e) a reminder at major version + automated closing of bug report after first
major.maintenance version if a reminder is last comment (which means no
activity)

This will give bugs cleaning every 6 months. Not a bad deal...
Most of bugs in NEEDINFO state are dead ends. Reporters in general think
that people who triage are LO experts in every way. A reminder text should
convince them, that the easier STR the better. Even very complicated issue
can be reproduced with a "download'n'run" test case attached . BTW: I really
liked graphics made by one reporter in bug
https://bugs.freedesktop.org/show_bug.cgi?id=51162.
IMHO all this should include also UNCONFIRMED bugs (many are dead ends too). 
I see bug reporting in this project not like "file and forget" process.
Reminder text should encourage the reporter to get involved a little bit
more, as he is an expert about reported bug, at least confirming it with
latest major version.
Also having a subpage for dealing with UNCONFIRMED or NEEDINFO bugs in
Bugzilla would make life easier.
Such page is available for instance in bmo (bugzilla.mozilla.org). 
Link: https://bugzilla.mozilla.org/page.cgi?id=triage_reports.html. 
Source is available at:
http://bzr.mozilla.org/bmo/4.0/annotate/head:/extensions/BMO/template/en/default/pages/triage_reports.html.tmpl
In short (their implementation):
- Show UNCONFIRMED bugs with: [Product] [Component]
- Comment:
-- where the last commenter: is the reporter, does not have canconfirm, is
[set user]
-- where the last comment is older than: 30/60/90 days, one year, the date
[set date]
I played with it for a while and it is very friendly, especially  for
unexperienced Bugzilla users.
In our version this should support UNCONFIRMED and NEEDINFO statuses and
maybe reminder IDs, to browse the bugs before the next step (if one is
concerned that important issues will be closed).
It would be a great companion for triage marathons.
Best regards.
P.S.
Everything has to be done to not repeat last incident with 3 or 4 messages
added to selected issues.  This was PITA for everyone.




--
View this message in context: 
http://nabble.documentfoundation.org/Libreoffice-qa-Stagnant-NEEDINFO-bugs-tp4032113p4032419.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] installing 400rc2 parallel on Windows - no way to choose extensions ?

[V Stuart Foote]

Andras,

So as per the  Installing_in_parallel Wiki

 
to install a parallel instance, should we be setting a WRITEREGSITRY=0 when
doing the command line /A administrative installation? 

And other than adjusting the "*UserInstallation=*" location of the
program\bootstrap.ini file so as to not clobber the existing user
profile--the administrative install becomes the working "parallel"
installation?   Does the system default language become the language of the
administrative install?  Or does it always remain 1033, en-US?

Couldn't LibreOffice program features and alternate languages be configured
and applied against the administrative install using a .MST transform file? 
And how complicated would that have to be to end up with a usable alternate
installation--not needing to run the recast .MSI located in the
administrative install's folder.

Stuart



--
View this message in context: 
http://nabble.documentfoundation.org/Libreoffice-qa-installing-400rc2-parallel-on-Windows-no-way-to-choose-extensions-tp4032127p4032414.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] installing 400rc2 parallel on Windows - no way to choose extensions ?

[Rainer Bielefeld]

Andras Timar schrieb:


You can install LibreOffice with that .msi. It works the same as the original.



Hi András,

I tried with one of my 4.1.0.0 server installations on WIN:

1. launched
   master~2013-01-24_22.52.49_LibO-Dev_4.1.0.0.alpha0_Win_x86.msi
2. Custom Installation
3. Unselected Writer (and saw BASE unexpectedly unselected)
4. Continued "Installation"
   No effect nowhere, this build and also my normal 4.0.0.2 rc
   worked with Writer as expected

Best Regards


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

Re: [Libreoffice-qa] installing 400rc2 parallel on Windows - no way to choose extensions ?

[Andras Timar]

Hi Rainer,

On Sun, Jan 27, 2013 at 3:12 PM, Rainer Bielefeld
 wrote:
> Andras Timar schrieb:
>
>
>> Yes, it is. With msiexec /a you convert the install kit from one
>> format to another. It is not an installation
>
>
>
> Hi,
>
> Yes, but I wonder what can be done with the .msi above the program folder? I
> am pretty sure that I was involved in a discussion concerning reasons of
> that .msi, but I forgot all results.
>

You can install LibreOffice with that .msi. It works the same as the original.

Best regards,
Andras
___
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] installing 400rc2 parallel on Windows - no way to choose extensions ?

[Rainer Bielefeld]

Andras Timar schrieb:


Yes, it is. With msiexec /a you convert the install kit from one
format to another. It is not an installation



Hi,

Yes, but I wonder what can be done with the .msi above the program 
folder? I am pretty sure that I was involved in a discussion concerning 
reasons of that .msi, but I forgot all results.


CU

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] installing 400rc2 parallel on Windows - no way to choose extensions ?

[Andras Timar]

Hi Cor,

On Sun, Jan 27, 2013 at 12:14 AM, Cor Nouws  wrote:
> Hi,
>
> As not regular Windows user, I hit a problem with installing 400rc2.
> I use parallel installation (1)
>
> After  " msiexec /a LibreOffice_4.0.0.2_Win_x81.msi  "
> I can give the path, but do not have the option to choose which extensions
> (e.g. language packs) will be installed.
> Is that regular, expected, behaviour?
>

Yes, it is. With msiexec /a you convert the install kit from one
format to another. It is not an installation, just an extraction of
the single msi file.

Cheers,
Andras
___
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] Stagnant NEEDINFO bugs

[Rainer Bielefeld]

Joel Madero schrieb:

Hi Joel,

thank you for opening this discussion with your thoughts and suggestions.

To avoid misunderstandings: my critics at current plans does not mean 
that I do not want any automated mass cleanups. I would appreciate to 
get rid of lots of hopeless reports with few "costs".


Although I believe we could solve some part of the problem if we would 
invest the time discussing here into bug reviews, it might be useful to 
do some very careful preparation, so that in future such mass closes can 
be done effectively and with few preparation, because the work already 
has been done here.


Some thoughts (I'm still sorting and prioritizing)

I) Such an action should avoid collateral damages as effective as 
possible. A promising approach might be to find an effective query with 
good accuracy for hopeless Bug reports where we can expect that there 
will be no useful reaction from reporter, AND where we can be sure that 
the NEEDINFO is appropriate and not only caused by laziness of reviewer 
At least I can say for me that sometimes I am interested and tough and I 
find a real bug even with a very rare report. And sometimes I try to get 
a better bug description because I want to  save some work. I will not 
forget these Bugs, they are in my hold-file, but if I saw a low 
priority, it might take a year or so until I get back to the bug. And 
this might cause unnecessary work for other reviewers, may be hundreds 
invest half a minute, see that someone is involved, leave again, and so 
we loose some hors every year in such 1 bug.


II) Such a mass close should really terminate any action on a closed bug 
(except reporter redelivers useful info). The last mass close in August 
2012 also closed lots of appropriate enhancement requests. We should 
avoid such a mistake in future.


III) I prefer to close Bugs immediately with a very polite text 
encouraging the reporter to reopen the bug if he can contribute more 
detailed and precise due to 
. I am pretty sure that 
those who would have improved their bug description after a "first 
strike" will understand our reasons and simply reopen the Bug with 
better info. And for the other ones the first and second strike would be 
wasted energy.


IV) We need a very polite and encouraging text for first strike bug 
closing.


V) Remaining concerns
We can be as careful as possible, it's inevitable that we will close 
some bugs reported from real experts with appropriate info, but only the 
bad luck that the of us who reviewed was expert for something else. That 
makes us looking like idiots.



My method of resolution:
I will start with a suggestion for a query with reasoning why I believe 
that that should be done that way soon, and then we can integrate more 
proposals for optimization step by step.


We will see to where that leads, and the rating how nearby the optimum 
that is at least for me is decisive what of Joels suggesteions might be 
the best.


CU

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] Stagnant NEEDINFO bugs

[Rob Snelders]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The option from Marc looks good to me.

But do you look at the length that a bug is in NEEDINFO or the time
from the last post in the bug?

- --
Greetings,
Rob Snelders

Op 27-01-13 09:45, Marc Par￩ schreef:
> Hi Joel,
> 
> If you are asking our opinion on these ...
> 
> Le 2013-01-26 17:22, Joel Madero a ￩crit :
>> Hi All,
>> 
>> During our last QA call we came up with a plan for NEEDINFO bugs
>> that have been stagnant for 6+ months. I've decided to remove
>> this from the minutes because there are some concerns about the
>> agreement that was made. It was requested that we have a
>> discussion through a thread about what we should do about these
>> bugs.
>> 
>> Let's try to keep this thread moving and organized so we can make
>> a decision once and for all. Goal should be to minimize flare ups
>> from users while keeping in mind that our long term QA goal is to
>> get FDO organized, accurate and under control.
>> 
>> With that, I'll let the thread move forward :-D
>> 
>> Options: (feel free to add)
>> 
>> a) Leave them alone, accept that most will just sit in NEEDINFO
>> forever
>> 
>> b) Automate a reminder for these bugs and leave it at that, if
>> it doesn't lead to anything, so be it, leave the bugs alone
>> 
>> c) a reminder + automated closing of bug after some period of
>> time
>> 
>> d) a "3 strikes" type system - send one reminder, a month later
>> send a second with a warning the bug will be closed, then close
>> the bug
>> 
>> 
>> These are the options that come to mind.
>> 
>> Best Regards, Joel
>> 
>> P.S. Florian - please hold off on writing something about our
>> previous agreement until we reach some consensus here.
> 
> +1 for d) BUT make it a real "3 strikes". one reminder, a month
> later send another reminder, a month later send the last reminder
> with a warning that the bug will be closed in one month.
> 
> The 3-strikes concept is understandable to most people and I
> believe the submitter would be more understanding if the bug were
> closed. It also gives more than an abundant amount of time to fill
> out the missing details of the bug -- from start to end would take
> 4 months. This would hopefully quiet the noise from disgruntled
> submitters and allow QA people enough time to get to them if they
> find some of them important enough for a closer look. Hopefully
> most of these would be taken care in shorter amount of time.
> 
> 
> Cheers,
> 
> Marc
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRBOnzAAoJEGs78UIq7mKy/ggH/34SMLbRKCijHdyNtmHZRLS1
IfbW/1t/g4QEKAmEDWLlngDR40CHa2dsaDysGKTjlGtT635nE2wysLSSvHdfXdKt
es2NiP5a2219hgEtCkDJDOZyTEukTBfx13QtUegJ1/RyCJcJMzOCXu/02a6enymV
QwB/sXWFclQVpFMzfhcyDSzkIrK2j4XmY+3G2I4hBsKoGl2Gt/CCLNJZnNzcqiLC
ZfLxEY2tbRPiGZwNpu70ITCB4e18XqmuPSy7/0cOn6mO16j9ncvDA+ND4yZQvxhm
PoAw2n+WtvL+5IBP6NRMFa4HIxhwNWoF4XUZWDvjtSL+5Zq+Sje0gwyGWFFnJl0=
=ur84
-END PGP SIGNATURE-
___
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] Stagnant NEEDINFO bugs

[Marc Paré]

Hi Joel,

If you are asking our opinion on these ...

Le 2013-01-26 17:22, Joel Madero a écrit :

Hi All,

During our last QA call we came up with a plan for NEEDINFO bugs that
have been stagnant for 6+ months. I've decided to remove this from the
minutes because there are some concerns about the agreement that was
made. It was requested that we have a discussion through a thread about
what we should do about these bugs.

Let's try to keep this thread moving and organized so we can make a
decision once and for all. Goal should be to minimize flare ups from
users while keeping in mind that our long term QA goal is to get FDO
organized, accurate and under control.

With that, I'll let the thread move forward :-D

Options: (feel free to add)

a) Leave them alone, accept that most will just sit in NEEDINFO forever

b) Automate a reminder for these bugs and leave it at that, if it
doesn't lead to anything, so be it, leave the bugs alone

c) a reminder + automated closing of bug after some period of time

d) a "3 strikes" type system - send one reminder, a month later send a
second with a warning the bug will be closed, then close the bug


These are the options that come to mind.

Best Regards,
Joel

P.S. Florian - please hold off on writing something about our previous
agreement until we reach some consensus here.


+1 for d) BUT make it a real "3 strikes". one reminder, a month later 
send another reminder, a month later send the last reminder with a 
warning that the bug will be closed in one month.


The 3-strikes concept is understandable to most people and I believe the 
submitter would be more understanding if the bug were closed. It also 
gives more than an abundant amount of time to fill out the missing 
details of the bug -- from start to end would take 4 months. This would 
hopefully quiet the noise from disgruntled submitters and allow QA 
people enough time to get to them if they find some of them important 
enough for a closer look. Hopefully most of these would be taken care in 
shorter amount of time.



Cheers,

Marc

--
Marc Paré
m...@marcpare.com
http://www.parEntreprise.com
parEntreprise.com Supports OpenDocument Formats (ODF)
parEntreprise.com Supports http://www.LibreOffice.org

___
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/