Re: Additional languages for buildbots

2013-08-14 Thread Herbert Duerr

On 13.08.2013 20:28, Andrew Rist wrote:

On 8/13/2013 1:18 AM, Herbert Duerr wrote:

Last week we ran out of space on the Windows buildbot. When Andrew
cleaned things out they started working again. With the additional
languages we are stressing it a bit more now though.

Actually, the situation is not too bad - the disk space issue is under
control now and we have space for languages as they become available.


That's great news, thanks!


The snapshot tag is currently only moved sporadically so spending time
in setting up new snapshot buildbots for e.g. Linux is an arguable
investment.

We are waiting on the CentOS bot to set up the Linux 32 snapshot build.
I'm also about to look at the ubuntu bots - now that they're back on ,
it would be good to have them running through correctly.


Yes, bots based on the older CentOS would generate binaries that are 
consumable directly by most other Linux systems. The current Ubuntu 12.4 
(for Linux32) and even Ubuntu 10.4 (for Linux64) create a base line that 
is quite high.



For most cases the already existing nightly builds are better.

This is something we need to resolve (by making the bot builds better,
of course) I think the CentOS bot will help us move in that direction.


Agreed. If we want it also to help translators by providing all 
available translations then upping the snapshot frequency (e.g. 
biweekly) would help too.


Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Lending a Hand

2013-08-14 Thread Robin Molnar
Hello,

I'm Robin, I do QA and is good to be here. Thus, I look forward to our
working together on this great product.

Have a great day!

R.

-- 
Robintel BMS
www.robintel.ro


Re: [RELEASE]: preparation for AOO 4.0.1

2013-08-14 Thread Jürgen Schmidt
On 8/13/13 6:55 PM, Ricardo Berlasso wrote:
> 2013/8/13 Fernando Cassia 
> 
>> On Tue, Aug 13, 2013 at 12:24 PM, Jürgen Schmidt 
>> wrote:
>>> But if
>>> we change it it annoys potentially other users. The question is what
>>> would be the correct and most often wanted default.
>>
>> What is the purpose of showing margins, and by extension, seeing text
>> smaller, (less zoom level)?. Is there any data the user can put on
>> Margins? change the margin colors? put pictures in margins?. In short:
>> what use is there for margins taking a sizeable portion of the screen
>> size?
>>
> 
> 
> I do not see those margin you talk about and for a good reason: I never use
> maximized windows. I hate maximized windows. Other people love maximized
> windows, of course, but many of us just hate them: how do you count how
> many people is on each camp?
> 
> Default values are an important discussion point and I started a couple of
> threads about defaults in the past, but defaults are also an incredible
> difficult question where almost all possible answers are at the same time
> wrong and right for someone.
> 
> I propose to start (again) a discussion about default values, but not now:
> let's concentrate on 4.0.1.

please start a new thread for this topic. It's a feature/enhancement
discussion and doesn't belong to the topic of this thread

Thanks

Juergen


> 
> Regards
> Ricardo
> 
> 
> 
>>
>> I'm not saying we should NOT show margings, after all, in "Optimal
>> width", a portion of the margins is seen, but not 50-100 pixels of
>> them, on every side.
>>
>> I'm not even saying the view with margins is wrong, maybe someone
>> wants to look at the "bigger picture". But for TYPING text, "optimal
>> width" is the best. So, again, why isn't that option the default?.
>>
>> Maybe the UX guys can comment?. And yes, I'd love to see a survey. And
>> even better, some telemetry (like Firefox' ) about how many users,
>> when typing or browsing text documents, end up viewing the document in
>> "optimize width" mode).
>>
>> Thanks for taking the time to answer, btw. Appreciate it.
>> Best regards,
>>
>> FC
>> --
>> During times of Universal Deceit, telling the truth becomes a
>> revolutionary act
>> - George Orwell
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: dev-h...@openoffice.apache.org
>>
>>
> 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



[RELEASE]: propose translation deadline for AOO 4.0.1

2013-08-14 Thread Jürgen Schmidt
Hi,

it seems that besides new languages some communities are working on
fixes/improvements of the existing translation which is fine for me.

To coordinate this work with the rest I would like to propose a general
translation deadline for new languages as well as updates of existing ones.

I propose September 6th, 2013 - 12:00 UTC at noon

Please take this date into account of any translation related planning.
Changes after this date won't make it into AOO 4.0.1 and the earlier you
have finished the work the better it is and you will have more time for
testing and potential further fixes.

The general workflow is to create an issue, assign it to me and request
the showstopper flag. When the translation is ready put a comment in the
issue to signal that it can be integrated.


Thanks
Juergen

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [Pootle] about translating AOOE site

2013-08-14 Thread Roberto Galoppini
2013/8/13 janI 

> On 12 August 2013 23:47, Ricardo Berlasso  wrote:
>
> > 2013/8/12 janI 
> >
> > > On 12 August 2013 11:11, janI  wrote:
> > >
> > > >
> > > >
> > > >
> > > > On 12 August 2013 11:01, Raphael Bircher  wrote:
> > > >
> > > >> Am 12.08.13 10:56, schrieb janI:
> > > >>
> > > >>  On 12 August 2013 10:48, Roberto Galoppini <
> > > roberto.galopp...@gmail.com>
> > > >>> **wrote:
> > > >>>
> > > >>>  Could we create a pootle project on translate.apache.org to
> upload
> > >  AOOE PO
> > >  files and get them translated?
> > > 
> > >   I have the karma to do that, but sorry for my lack of knowledge,
> > what
> > > >>> is
> > > >>> AOOE compared to AOO ?
> > > >>>
> > > >> Apache OpenOffice Extension Website?!
> > > >
> > > >
> > > > that was too simple, why did I not see that.
> > > >
> > >
> > > Project is created, so as soon as I get the files I will put them on
> the
> > > vm. After the initial load anybody can download them, and users can
> > upload
> > > changes.
> > >
> >
> >
> > Great!
> >
> > Just a small comment: there is a typo on the project name: there is a
> > missing i between the f and the c: it says "Apache OpenOffce Extensions".
> >
>
> corrected (not by me someone was faster).
>
> I am still waiting for the initial batch of po files, you cannot load the
> primary set yourself.
>

Thanks Jan,

 We are now cleaning up PO files that actually contain thousands of Drupal
strings, I'll be back to yo with an English, German and French versions in
few days. If it works fine we'll be able to add the Polish version right
away.

Roberto


> In general we need .pot (po template files for en-US), these act as
> template files for all languages.
>
> Furthermore an administrator (e.g. me) needs to activate new languages,
> currently no languages are active.
>
> rgds
> jan I.
>
> >
> > Regards
> > Ricardo
> >
> >
> >
> >
> > >
> > > rgds
> > > jan I.
> > >
> > > >
> > > > thx.
> > > > rgds
> > > > jan I.
> > > >
> > > >>
> > > >>
> > > >>> If you make the po files available to me, I can do it relative
> fast.
> > > >>>
> > > >>> rgds
> > > >>> jan I.
> > > >>>
> > > >>>
> > > >>>  Roberto
> > > 
> > > 
> > > >>
> > > >>
> > >
> --**--**-
> > > >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.**apache.org<
> > > dev-unsubscr...@openoffice.apache.org>
> > > >> For additional commands, e-mail: dev-h...@openoffice.apache.org
> > > >>
> > > >>
> > > >
> > >
> >
>


Debian Build Scripts

2013-08-14 Thread Mike Dupont
Hi there,
I am looking for the debian source packages and or debian/rules for
apache open office, can anyone give me some pointers?
mike

-- 
James Michael DuPont
Member of Free Libre Open Source Software Kosova http://flossk.org
Saving wikipedia(tm) articles from deletion http://SpeedyDeletion.wikia.com
Contributor FOSM, the CC-BY-SA map of the world http://fosm.org
Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3
Free Software Foundation Europe Fellow http://fsfe.org/support/?h4ck3rm1k3

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Debian Build Scripts

2013-08-14 Thread Herbert Duerr

On 14.08.2013 12:57, Mike Dupont wrote:

I am looking for the debian source packages and or debian/rules for
apache open office, can anyone give me some pointers?


AOO creates its Debian packages using EPM [1] when the configure option 
--with-package-format="deb" is given to the AOO build. They are 
assembled when AOO builds its main/postprocess module using some perl 
scripts in main/solenv/bin/


[1] http://www.msweet.org/projects.php?Z2

Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Debian Build Scripts

2013-08-14 Thread Mike Dupont
Thank you, that is what I was looking for!
mike

On Wed, Aug 14, 2013 at 6:28 AM, Herbert Duerr  wrote:
> On 14.08.2013 12:57, Mike Dupont wrote:
>>
>> I am looking for the debian source packages and or debian/rules for
>> apache open office, can anyone give me some pointers?
>
>
> AOO creates its Debian packages using EPM [1] when the configure option
> --with-package-format="deb" is given to the AOO build. They are assembled
> when AOO builds its main/postprocess module using some perl scripts in
> main/solenv/bin/
>
> [1] http://www.msweet.org/projects.php?Z2
>
> Herbert
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>



-- 
James Michael DuPont
Member of Free Libre Open Source Software Kosova http://flossk.org
Saving wikipedia(tm) articles from deletion http://SpeedyDeletion.wikia.com
Contributor FOSM, the CC-BY-SA map of the world http://fosm.org
Mozilla Rep https://reps.mozilla.org/u/h4ck3rm1k3
Free Software Foundation Europe Fellow http://fsfe.org/support/?h4ck3rm1k3

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: unexpected behavior from configure -- new env script not generated

2013-08-14 Thread Andre Fischer

On 13.08.2013 23:02, Kay Schenk wrote:

On Tue, Aug 13, 2013 at 12:16 PM, janI  wrote:


On 13 August 2013 21:03, Kay Schenk  wrote:


Yesterday, I did a dmake clean to start over with my build, and then
proceded with autoconf and configure. I had chagned my ant version a

while

back and this was reflected in my configure call. Much to my surprise,

the

old ant version seemed to be "stuck' in configure's brain, and it took

me a

while to track this down and just delete my existing shell environment
script. Then the configure worked as expected. This was the ONLY change

in

my configure params

Any guesses as to the cause of this?
* Is this a problem with *my* system autoconf or configure ?
* is this how things normally work and we should document this in the

build
I have had similar problems a couple of times.

I used to have "source LinuxX86-64Env.Set.sh" in .bashrc, meaning
environment was set when I ran configure.

After having a couple of strange problem (in my case with epm), I took
"source..." out of .bashrc, so securing that I run configure without the
AOO environment, since then I have not had problems.

Due to my genLang tests, I do configure a couple of times pr week (to test
my build changes).

hope it helps.
rgds
jan I.

instructions ?


  got around it by just deleting my *.sh file and then running configure
again. If I knew more about autoconf, I could just put some code in that to
delete it.  Configure is supposed to create the environment -- part of the
AC_OUTPUT I think, so this is why I asked about this.  In my case, my *.sh
is not getting overwritten but seemingly reused. 


Deleting the *.sh file when running configure would not have the desired 
effect.  The problem is not that the file exists but that it has been 
run prior to calling configure.  Run configure in a 'clean' shell and 
you should have no problems.


-Andre






I'm looking at configure.in etc but since I'm not an autoconf guru,

well,

what to do.

--



-

MzK

Success is falling nine times and getting up ten."
  -- Jon Bon Jovi







-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: unexpected behavior from configure -- new env script not generated

2013-08-14 Thread Oliver-Rainer Wittmann

Hi,

On 14.08.2013 14:28, Andre Fischer wrote:

On 13.08.2013 23:02, Kay Schenk wrote:

On Tue, Aug 13, 2013 at 12:16 PM, janI  wrote:


On 13 August 2013 21:03, Kay Schenk  wrote:


Yesterday, I did a dmake clean to start over with my build, and then
proceded with autoconf and configure. I had chagned my ant version a

while

back and this was reflected in my configure call. Much to my surprise,

the

old ant version seemed to be "stuck' in configure's brain, and it took

me a

while to track this down and just delete my existing shell environment
script. Then the configure worked as expected. This was the ONLY change

in

my configure params

Any guesses as to the cause of this?
* Is this a problem with *my* system autoconf or configure ?
* is this how things normally work and we should document this in the

build
I have had similar problems a couple of times.

I used to have "source LinuxX86-64Env.Set.sh" in .bashrc, meaning
environment was set when I ran configure.

After having a couple of strange problem (in my case with epm), I took
"source..." out of .bashrc, so securing that I run configure without the
AOO environment, since then I have not had problems.

Due to my genLang tests, I do configure a couple of times pr week (to
test
my build changes).

hope it helps.
rgds
jan I.

instructions ?


  got around it by just deleting my *.sh file and then running configure
again. If I knew more about autoconf, I could just put some code in
that to
delete it.  Configure is supposed to create the environment -- part of
the
AC_OUTPUT I think, so this is why I asked about this.  In my case, my
*.sh
is not getting overwritten but seemingly reused. 


Deleting the *.sh file when running configure would not have the desired
effect.  The problem is not that the file exists but that it has been
run prior to calling configure.  Run configure in a 'clean' shell and
you should have no problems.



This is my experience, too.
Esp. under Linux I always start with a new shell, when I want to 
configure my AOO build environment.


Best regards, Oliver.




I'm looking at configure.in etc but since I'm not an autoconf guru,

well,

what to do.

--



-


MzK

Success is falling nine times and getting up ten."
  -- Jon Bon Jovi







-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



[Website]

2013-08-14 Thread Lynda Martin
IHAVE USED O O PREVIOUSLY. However the app has disappeared and I can not access 
OO to write a letter. Can I re-install the short cut to my desk top? I have 
tried with no good results.

Ben Martinph. 619-993-5797lovesport...@gmail.com


I have down loaded 4.0 and  have W-8



Sent from Windows Mail

Re: unexpected behavior from configure -- new env script not generated

2013-08-14 Thread Kay Schenk
On Wed, Aug 14, 2013 at 5:28 AM, Andre Fischer  wrote:

> On 13.08.2013 23:02, Kay Schenk wrote:
>
>> On Tue, Aug 13, 2013 at 12:16 PM, janI  wrote:
>>
>>  On 13 August 2013 21:03, Kay Schenk  wrote:
>>>
>>>  Yesterday, I did a dmake clean to start over with my build, and then
 proceded with autoconf and configure. I had chagned my ant version a

>>> while
>>>
 back and this was reflected in my configure call. Much to my surprise,

>>> the
>>>
 old ant version seemed to be "stuck' in configure's brain, and it took

>>> me a
>>>
 while to track this down and just delete my existing shell environment
 script. Then the configure worked as expected. This was the ONLY change

>>> in
>>>
 my configure params

 Any guesses as to the cause of this?
 * Is this a problem with *my* system autoconf or configure ?
 * is this how things normally work and we should document this in the

>>> build
>>> I have had similar problems a couple of times.
>>>
>>> I used to have "source LinuxX86-64Env.Set.sh" in .bashrc, meaning
>>> environment was set when I ran configure.
>>>
>>> After having a couple of strange problem (in my case with epm), I took
>>> "source..." out of .bashrc, so securing that I run configure without the
>>> AOO environment, since then I have not had problems.
>>>
>>> Due to my genLang tests, I do configure a couple of times pr week (to
>>> test
>>> my build changes).
>>>
>>> hope it helps.
>>> rgds
>>> jan I.
>>>
>>> instructions ?
>>>
>>>got around it by just deleting my *.sh file and then running configure
>> again. If I knew more about autoconf, I could just put some code in that
>> to
>> delete it.  Configure is supposed to create the environment -- part of the
>> AC_OUTPUT I think, so this is why I asked about this.  In my case, my *.sh
>> is not getting overwritten but seemingly reused. 
>>
>
> Deleting the *.sh file when running configure would not have the desired
> effect.  The problem is not that the file exists but that it has been run
> prior to calling configure.  Run configure in a 'clean' shell and you
> should have no problems.
>
> -Andre


h...well OK I see what you're saying. I may have gotten some steps
mixed up.  I will try this again with a  config change and see what
happens. Thanks. I'm farily certain I hadn't sourced the shell env script
before I did this.



>
>
>>
>>
>>  I'm looking at configure.in etc but since I'm not an autoconf guru,

>>> well,
>>>
 what to do.

 --


  --**--**
>>> --**---
>>>
 MzK

 Success is falling nine times and getting up ten."
   -- Jon Bon Jovi


>>
>>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
-
MzK

Success is falling nine times and getting up ten."
 -- Jon Bon Jovi


Re: [Website]

2013-08-14 Thread Rob Weir
On Wed, Aug 14, 2013 at 11:19 AM, Lynda Martin  wrote:
> IHAVE USED O O PREVIOUSLY. However the app has disappeared and I can not 
> access OO to write a letter. Can I re-install the short cut to my desk top? I 
> have tried with no good results.
>
> Ben Martinph. 619-993-5797lovesport...@gmail.com
>
>
> I have down loaded 4.0 and  have W-8
>

Hi Lynda,

>From the Windows 8 "Start" screen type "OpenOffice".  That will filter
your installed apps to show only the OpenOffice ones.  You can then
launch the app you want.  Or you can right click on the app and pick
"Pin to Taskbar" to make it more convenient to launch in the future.

Regards,

-Rob

>
>
> Sent from Windows Mail

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Some thoughts on quality

2013-08-14 Thread Rob Weir
We're working now on AOO 4.0.1, to fix defects in AOO 4.0.0.  The fact
that we're doing this, and their are no arguments against it, shows
that we value quality.   I'd like to take this a step further, and see
what we can learn from the defects in AOO 4.0.0 and what we can do
going forward to improve.

Quality, in the end, is a process, not a state of grace.  We improve
by working smarter, not working harder.  The goal should be to learn
and improve, as individuals and as a community.

Every regression that made it into 4.0.0 was added there by a
programmer.  And the defect went undetected by testers.  This is not
to blame.  It just means that we're all human.  We know that.  We all
make mistakes.  I make mistakes.  A quality process is not about
becoming perfect, but about acknowledging that we make mistakes and
that certain formal and informal practices are needed to prevent and
detect these mistakes.

But enough about generalities.  I'm hoping you'll join with me in
examining the 32 confirmed 4.0.0 regression defects and answering a
few questions:

1) What caused the bug?   What was the "root cause"?  Note:
"programmer error" is not really a cause.  We should ask what caused
the error.

2) What can we do to prevent bugs like this from being checked in?

3) Why wasn't the bug found during testing?  Was it not covered by any
existing test case?  Was a test case run but the defect was not
recognized?  Was the defect introduced into the software after the
tests had already been executed?

4) What can we do to ensure that bugs like this are caught during testing?

So 2 basic questions -- what went wrong and how can we prevent it in
the future, looked at from perspective of programmers and testers.  If
we can keep these questions in mind, and try to answer them, we may be
able to find some patterns that can lead to some process changes for
AOO 4.1.

You can find the 4.0.0 regressions in Bugzilla here:

https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=400_regressions&sharer_id=248521&list_id=80834


Regards,

-Rob

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



[BUILD] Linux32 snapshot configure

2013-08-14 Thread Andrew Rist
Here is the current configure statement for the Linux32 bot - is this 
correct, and what changes would make it better?


./configure \
--with-jdk-home="/usr/lib/jvm/java-6-openjdk" \
   --with-epm-url="http://www.msweet.org/files/project2/epm-3.7-source.tar.gz
   " \
   
--with-dmake-url="http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.tar.bz2";
   \
--enable-verbose \
--without-stlport \
--enable-category-b \
--enable-opengl \
--enable-dbus \
--enable-gstreamer \
 --with-package-format="installed rpm deb" \
 --enable-bundled-dictionaries \
 --with-lang="ast cs de el en-GB en-US es fi fr gd gl hu it
   ja km ko nl pl pt pt-BR ru sk sl ta zh-CN zh-TW ca eu he hi id lt sv
   th tr " \
--with-vendor="Apache OpenOffice buildbot" \
--with-build-version="%(today)s-Rev.%(got_revision)s" \




Re: Some thoughts on quality

2013-08-14 Thread Rob Weir
I apologize in advance if my note was note clear.  I'm not at all
interested in off-the-cuff opinions.  We all have our opinions.  But
I'm only interested in fact-based analysis of the actual regressions
reported in BZ.   Specifically:  what caused the actually defects that
ended up in 4.0.0 and what could have been done to prevent it.
General recommendations, like "more time", not backed by specific
analysis, are not very useful.  And remember, there will never be
enough time to improve quality with a suboptimal process.  The goal
should be (IMHO) to improve the process, i.e., work smarter, not
harder.

Regards,

-Rob

On Wed, Aug 14, 2013 at 12:59 PM, Rob Weir  wrote:
> We're working now on AOO 4.0.1, to fix defects in AOO 4.0.0.  The fact
> that we're doing this, and their are no arguments against it, shows
> that we value quality.   I'd like to take this a step further, and see
> what we can learn from the defects in AOO 4.0.0 and what we can do
> going forward to improve.
>
> Quality, in the end, is a process, not a state of grace.  We improve
> by working smarter, not working harder.  The goal should be to learn
> and improve, as individuals and as a community.
>
> Every regression that made it into 4.0.0 was added there by a
> programmer.  And the defect went undetected by testers.  This is not
> to blame.  It just means that we're all human.  We know that.  We all
> make mistakes.  I make mistakes.  A quality process is not about
> becoming perfect, but about acknowledging that we make mistakes and
> that certain formal and informal practices are needed to prevent and
> detect these mistakes.
>
> But enough about generalities.  I'm hoping you'll join with me in
> examining the 32 confirmed 4.0.0 regression defects and answering a
> few questions:
>
> 1) What caused the bug?   What was the "root cause"?  Note:
> "programmer error" is not really a cause.  We should ask what caused
> the error.
>
> 2) What can we do to prevent bugs like this from being checked in?
>
> 3) Why wasn't the bug found during testing?  Was it not covered by any
> existing test case?  Was a test case run but the defect was not
> recognized?  Was the defect introduced into the software after the
> tests had already been executed?
>
> 4) What can we do to ensure that bugs like this are caught during testing?
>
> So 2 basic questions -- what went wrong and how can we prevent it in
> the future, looked at from perspective of programmers and testers.  If
> we can keep these questions in mind, and try to answer them, we may be
> able to find some patterns that can lead to some process changes for
> AOO 4.1.
>
> You can find the 4.0.0 regressions in Bugzilla here:
>
> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=400_regressions&sharer_id=248521&list_id=80834
>
>
> Regards,
>
> -Rob

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Some thoughts on quality

2013-08-14 Thread Rob Weir
On Wed, Aug 14, 2013 at 1:36 PM, Edwin Sharp  wrote:
> Dear Rob
> The 4.0 release was too ambitious - we should advance in smaller steps.
> Nothing compares to general public testing - betas and release candidates 
> should not be avoided.
> TestLink cases should be less comprehesive (in terms of feature coverage) and 
> more stress testing oriented.

The number to consider here is how many defects were found and fixed
during the 4.0.0 testing, before the general public users had access?
I assume it was quite substantial.  If so, the TestLink usage was
effective.  In other words, we might have found fewer bugs without
using it.

This is important to keep in mind:  we want to prevent or find more
bugs, but we're not starting from zero. We're starting from a process
that does a lot of things right.

I like the idea of a public beta.  But consider the numbers.  The 40
or so regressions that were reported came from an install base (based
on download figures since 4.0.0 was released) of around 3 million
users.  Realistically, can we expect anywhere near that number in a
public beta?  Or is it more likely that a beta program has 10,000
users or fewer?  I don't know the answer here.   But certainly a
well-publicized and used beta will find more than a beta used by just
a few hundred users.

Regards,

-Rob


> Regards,
> Edwin
>
> On Wed, Aug 14, 2013, at 19:59, Rob Weir wrote:
>> We're working now on AOO 4.0.1, to fix defects in AOO 4.0.0.  The fact
>> that we're doing this, and their are no arguments against it, shows
>> that we value quality.   I'd like to take this a step further, and see
>> what we can learn from the defects in AOO 4.0.0 and what we can do
>> going forward to improve.
>>
>> Quality, in the end, is a process, not a state of grace.  We improve
>> by working smarter, not working harder.  The goal should be to learn
>> and improve, as individuals and as a community.
>>
>> Every regression that made it into 4.0.0 was added there by a
>> programmer.  And the defect went undetected by testers.  This is not
>> to blame.  It just means that we're all human.  We know that.  We all
>> make mistakes.  I make mistakes.  A quality process is not about
>> becoming perfect, but about acknowledging that we make mistakes and
>> that certain formal and informal practices are needed to prevent and
>> detect these mistakes.
>>
>> But enough about generalities.  I'm hoping you'll join with me in
>> examining the 32 confirmed 4.0.0 regression defects and answering a
>> few questions:
>>
>> 1) What caused the bug?   What was the "root cause"?  Note:
>> "programmer error" is not really a cause.  We should ask what caused
>> the error.
>>
>> 2) What can we do to prevent bugs like this from being checked in?
>>
>> 3) Why wasn't the bug found during testing?  Was it not covered by any
>> existing test case?  Was a test case run but the defect was not
>> recognized?  Was the defect introduced into the software after the
>> tests had already been executed?
>>
>> 4) What can we do to ensure that bugs like this are caught during testing?
>>
>> So 2 basic questions -- what went wrong and how can we prevent it in
>> the future, looked at from perspective of programmers and testers.  If
>> we can keep these questions in mind, and try to answer them, we may be
>> able to find some patterns that can lead to some process changes for
>> AOO 4.1.
>>
>> You can find the 4.0.0 regressions in Bugzilla here:
>>
>> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=400_regressions&sharer_id=248521&list_id=80834
>>
>>
>> Regards,
>>
>> -Rob
>>
>> -
>> To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: qa-h...@openoffice.apache.org
>>
>
> -
> To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: qa-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Some thoughts on quality

2013-08-14 Thread Rob Weir
On Wed, Aug 14, 2013 at 1:55 PM, janI  wrote:
> On 14 August 2013 19:36, Edwin Sharp  wrote:
>
>> Dear Rob
>> The 4.0 release was too ambitious - we should advance in smaller steps.
>> Nothing compares to general public testing - betas and release candidates
>> should not be avoided.
>> TestLink cases should be less comprehesive (in terms of feature coverage)
>> and more stress testing oriented.
>> Regards,
>> Edwin
>>
>> On Wed, Aug 14, 2013, at 19:59, Rob Weir wrote:
>> > We're working now on AOO 4.0.1, to fix defects in AOO 4.0.0.  The fact
>> > that we're doing this, and their are no arguments against it, shows
>> > that we value quality.   I'd like to take this a step further, and see
>> > what we can learn from the defects in AOO 4.0.0 and what we can do
>> > going forward to improve.
>> >
>> > Quality, in the end, is a process, not a state of grace.  We improve
>> > by working smarter, not working harder.  The goal should be to learn
>> > and improve, as individuals and as a community.
>> >
>> > Every regression that made it into 4.0.0 was added there by a
>> > programmer.  And the defect went undetected by testers.  This is not
>> > to blame.  It just means that we're all human.  We know that.  We all
>> > make mistakes.  I make mistakes.  A quality process is not about
>> > becoming perfect, but about acknowledging that we make mistakes and
>> > that certain formal and informal practices are needed to prevent and
>> > detect these mistakes.
>> >
>> > But enough about generalities.  I'm hoping you'll join with me in
>> > examining the 32 confirmed 4.0.0 regression defects and answering a
>> > few questions:
>> >
>> > 1) What caused the bug?   What was the "root cause"?  Note:
>> > "programmer error" is not really a cause.  We should ask what caused
>> > the error.
>> >
>> > 2) What can we do to prevent bugs like this from being checked in?
>> >
>> > 3) Why wasn't the bug found during testing?  Was it not covered by any
>> > existing test case?  Was a test case run but the defect was not
>> > recognized?  Was the defect introduced into the software after the
>> > tests had already been executed?
>> >
>> > 4) What can we do to ensure that bugs like this are caught during
>> testing?
>> >
>> > So 2 basic questions -- what went wrong and how can we prevent it in
>> > the future, looked at from perspective of programmers and testers.  If
>> > we can keep these questions in mind, and try to answer them, we may be
>> > able to find some patterns that can lead to some process changes for
>> > AOO 4.1.
>> >
>> > You can find the 4.0.0 regressions in Bugzilla here:
>> >
>> >
>> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=400_regressions&sharer_id=248521&list_id=80834
>> >
>> >
>> > Regards,
>> >
>> > -Rob
>>
>
> I strongly believe that one of the things that went wrong is our limited
> possibility to retest (due to resources), when I look at our current manual

I wonder about that as well.  That's one reason it would be good to
know how many of the confirmed regressions were introduced late in the
release process, and thus missed coverage in our full test pass.

> testcases, a lot of those could be automated, e.g. with a simple UI macro,
> that would enable us to run these test cases with every build. It may sound
> like a dream but where I come from, we did that every night, and it caught
> a lot of regression bugs and sideeffects.
>

This begs the question:  Is the functionality of the regressions
covered by our test cases?  Or are they covered but we didn't execute
them?  Or we executed them but didn't recognize the defect?  I don't
know (yet).

> A simple start, if to request that every bug fix, is issued with at least
> one test case (automated or manual).
>

Often there is, though this information lives in Bugzilla.  One thing
we did on another (non open source) project is to mark defects in our
bugtracking system that should become test cases.   Not every bug did
that.  For example, a defect report to update a mispelling in the UI
would not lead to a new test case.  But many would.

Regards,

-Rob

> rgds
> jan I.
>
>
>> >
>> > -
>> > To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
>> > For additional commands, e-mail: qa-h...@openoffice.apache.org
>> >
>>
>> -
>> To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
>> For additional commands, e-mail: qa-h...@openoffice.apache.org
>>
>>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Some thoughts on quality

2013-08-14 Thread Raphael Bircher

Am 14.08.13 20:21, schrieb Rob Weir:

On Wed, Aug 14, 2013 at 1:36 PM, Edwin Sharp  wrote:

Dear Rob
The 4.0 release was too ambitious - we should advance in smaller steps.
Nothing compares to general public testing - betas and release candidates 
should not be avoided.
TestLink cases should be less comprehesive (in terms of feature coverage) and 
more stress testing oriented.

The number to consider here is how many defects were found and fixed
during the 4.0.0 testing, before the general public users had access?
I assume it was quite substantial.  If so, the TestLink usage was
effective.  In other words, we might have found fewer bugs without
using it.

This is important to keep in mind:  we want to prevent or find more
bugs, but we're not starting from zero. We're starting from a process
that does a lot of things right.

I like the idea of a public beta.  But consider the numbers.  The 40
or so regressions that were reported came from an install base (based
on download figures since 4.0.0 was released) of around 3 million
users.  Realistically, can we expect anywhere near that number in a
public beta?  Or is it more likely that a beta program has 10,000
users or fewer?  I don't know the answer here.   But certainly a
well-publicized and used beta will find more than a beta used by just
a few hundred users.
The public beta is from my point of view realy important. Even you have 
only 10'000 Downloads of a beta, you have normaly verry experianced 
Users there, like power users from Companies. They provide realy valua 
feedback. So from my point of view, this is one of the moast important 
changes we have to do. For all Feature release a beta version. And don't 
forget, people are realy happy to do beta tests. but many of them are 
maybe not willing to follow a mailing list.


Greetings Raphael


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



[Extensions website] Timeline don't work

2013-08-14 Thread FR web forum
Hello list,
For the last 3 recents OXT, timeline don't work:
http://extensions.openoffice.org/en/search?query=&sort_by=created&sort_order=DESC
Download numbers seems to be not tracked.
If you jump to SF.net, you got an error:
The "/17434" file could not be found or is not available.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



4.0.1_release_blocker requested: [Bug 123038] Update bundled dictionaries for OpenOffice 4.0.1

2013-08-14 Thread bugzilla
Andrea Pescetti  has asked  for 4.0.1_release_blocker:
Bug 123038: Update bundled dictionaries for OpenOffice 4.0.1
https://issues.apache.org/ooo/show_bug.cgi?id=123038


--- Additional Comments from Andrea Pescetti 
Bundled dictionaries listed in
main/extensions.lst
should be updated for OpenOffice 4.0.1.

This is an umbrella issue that will depend on other issues for the individual
languages.

Assigning to myself; I expect this to be done in the same timeframe for l10n
updates (suggested: 6 September), so that volunteers can test localization and
dictionaries at the same time.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Some thoughts on quality

2013-08-14 Thread Hagar Delest

Le 14/08/2013 21:01, Raphael Bircher a écrit :


I like the idea of a public beta.  But consider the numbers.  The 40
or so regressions that were reported came from an install base (based
on download figures since 4.0.0 was released) of around 3 million
users.  Realistically, can we expect anywhere near that number in a
public beta?  Or is it more likely that a beta program has 10,000
users or fewer?  I don't know the answer here.   But certainly a
well-publicized and used beta will find more than a beta used by just
a few hundred users.

The public beta is from my point of view realy important. Even you have only 
10'000 Downloads of a beta, you have normaly verry experianced Users there, 
like power users from Companies. They provide realy valua feedback. So from my 
point of view, this is one of the moast important changes we have to do. For 
all Feature release a beta version. And don't forget, people are realy happy to 
do beta tests. but many of them are maybe not willing to follow a mailing list.


+1.
OOo used to have RC versions strongly advertised, it could go up to 6 RC before 
going final and it was very useful to spot the main bugs.

Hagar

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Some thoughts on quality

2013-08-14 Thread Hagar Delest

Le 14/08/2013 21:29, Hagar Delest a écrit :

Le 14/08/2013 21:01, Raphael Bircher a écrit :


I like the idea of a public beta.  But consider the numbers.  The 40
or so regressions that were reported came from an install base (based
on download figures since 4.0.0 was released) of around 3 million
users.  Realistically, can we expect anywhere near that number in a
public beta?  Or is it more likely that a beta program has 10,000
users or fewer?  I don't know the answer here.   But certainly a
well-publicized and used beta will find more than a beta used by just
a few hundred users.

The public beta is from my point of view realy important. Even you have only 
10'000 Downloads of a beta, you have normaly verry experianced Users there, 
like power users from Companies. They provide realy valua feedback. So from my 
point of view, this is one of the moast important changes we have to do. For 
all Feature release a beta version. And don't forget, people are realy happy to 
do beta tests. but many of them are maybe not willing to follow a mailing list.


+1.
OOo used to have RC versions strongly advertised, it could go up to 6 RC before 
going final and it was very useful to spot the main bugs.


And I forgot: the 2 main bugs (slow saving in MS Office formats and the Calc 
display issue under Windows) were reported in the forum only 2 days and 5 days 
after the release! and we have had many topics for both afterward. A RC would 
have clearly spared the hassle.

See:
http://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=63082
http://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=63161

Hagar

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Some thoughts on quality

2013-08-14 Thread Marcus (OOo)

Am 08/14/2013 09:01 PM, schrieb Raphael Bircher:

Am 14.08.13 20:21, schrieb Rob Weir:

On Wed, Aug 14, 2013 at 1:36 PM, Edwin Sharp  wrote:

Dear Rob
The 4.0 release was too ambitious - we should advance in smaller steps.
Nothing compares to general public testing - betas and release
candidates should not be avoided.
TestLink cases should be less comprehesive (in terms of feature
coverage) and more stress testing oriented.

The number to consider here is how many defects were found and fixed
during the 4.0.0 testing, before the general public users had access?
I assume it was quite substantial. If so, the TestLink usage was
effective. In other words, we might have found fewer bugs without
using it.


In general, my feeling is that it's too early to do a retrospective and 
ask "what was good, what needs to be improved?" (to say it with SCRUM 
words ;-) ) Just after the first major release.


We should look on the BZ query you have mentioned and see if there is 
one or more hotspots that should be improved fast. That's it.



This is important to keep in mind: we want to prevent or find more
bugs, but we're not starting from zero. We're starting from a process
that does a lot of things right.

I like the idea of a public beta. But consider the numbers. The 40
or so regressions that were reported came from an install base (based
on download figures since 4.0.0 was released) of around 3 million
users. Realistically, can we expect anywhere near that number in a
public beta? Or is it more likely that a beta program has 10,000
users or fewer? I don't know the answer here. But certainly a
well-publicized and used beta will find more than a beta used by just
a few hundred users.

The public beta is from my point of view realy important. Even you have
only 10'000 Downloads of a beta, you have normaly verry experianced
Users there, like power users from Companies. They provide realy valua
feedback. So from my point of view, this is one of the moast important
changes we have to do. For all Feature release a beta version. And don't
forget, people are realy happy to do beta tests. but many of them are
maybe not willing to follow a mailing list.


A public beta release is of course not the golden solution but could 
activate some power users that give us the feedback we want and need.


So, +1 for going this way.

After the 4.1 release is done we can see if this was much better - and 
ask ourself why? :-)


Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [Website]

2013-08-14 Thread Marcus (OOo)

Since a few weeks we get mails with just "[Website]" as subject.

Just one word is not really meaningful to classify the mail content on 
the first view. So, I'm wondering from where they come from and how to 
improve this?


Marcus

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Some thoughts on quality

2013-08-14 Thread Rob Weir
On Wed, Aug 14, 2013 at 3:33 PM, Hagar Delest  wrote:
> Le 14/08/2013 21:29, Hagar Delest a écrit :
>
>> Le 14/08/2013 21:01, Raphael Bircher a écrit :
>>
 I like the idea of a public beta.  But consider the numbers.  The 40
 or so regressions that were reported came from an install base (based
 on download figures since 4.0.0 was released) of around 3 million
 users.  Realistically, can we expect anywhere near that number in a
 public beta?  Or is it more likely that a beta program has 10,000
 users or fewer?  I don't know the answer here.   But certainly a
 well-publicized and used beta will find more than a beta used by just
 a few hundred users.
>>>
>>> The public beta is from my point of view realy important. Even you have
>>> only 10'000 Downloads of a beta, you have normaly verry experianced Users
>>> there, like power users from Companies. They provide realy valua feedback.
>>> So from my point of view, this is one of the moast important changes we have
>>> to do. For all Feature release a beta version. And don't forget, people are
>>> realy happy to do beta tests. but many of them are maybe not willing to
>>> follow a mailing list.
>>
>>
>> +1.
>> OOo used to have RC versions strongly advertised, it could go up to 6 RC
>> before going final and it was very useful to spot the main bugs.
>>
> And I forgot: the 2 main bugs (slow saving in MS Office formats and the Calc
> display issue under Windows) were reported in the forum only 2 days and 5
> days after the release! and we have had many topics for both afterward. A RC
> would have clearly spared the hassle.
>
> See:
> http://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=63082
> http://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=63161
>


Maybe we need to call an earlier build the "RC" so it will get more
attention?   We had a complete test build that we were testing for
over a month.  But maybe it is ignored unless we call it an "RC"?  In
other words, there were many opportunities for users to help try 4.0
before it was released, but maybe there opportunities were not well
known.

-Rob

>
> Hagar
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Some thoughts on quality

2013-08-14 Thread Hagar Delest

Le 14/08/2013 21:37, Marcus (OOo) a écrit :

In general, my feeling is that it's too early to do a retrospective and ask "what 
was good, what needs to be improved?" (to say it with SCRUM words ;-) ) Just after 
the first major release.

Well, I visit forums and contribute since OOo 2.0 and it's the first time we 
(volunteers in forums) advise to downgrade so often, even for a major upgrade 
(because of the slow saving time and the Calc display issue mainly).
So there has been clearly a quality issue.

About test case, it's strange that the 2 bugs above were not seen.

Hagar

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Some thoughts on quality

2013-08-14 Thread Marcus (OOo)

Am 08/14/2013 09:39 PM, schrieb Rob Weir:

On Wed, Aug 14, 2013 at 3:33 PM, Hagar Delest  wrote:

Le 14/08/2013 21:29, Hagar Delest a écrit :


Le 14/08/2013 21:01, Raphael Bircher a écrit :


I like the idea of a public beta.  But consider the numbers.  The 40
or so regressions that were reported came from an install base (based
on download figures since 4.0.0 was released) of around 3 million
users.  Realistically, can we expect anywhere near that number in a
public beta?  Or is it more likely that a beta program has 10,000
users or fewer?  I don't know the answer here.   But certainly a
well-publicized and used beta will find more than a beta used by just
a few hundred users.


The public beta is from my point of view realy important. Even you have
only 10'000 Downloads of a beta, you have normaly verry experianced Users
there, like power users from Companies. They provide realy valua feedback.
So from my point of view, this is one of the moast important changes we have
to do. For all Feature release a beta version. And don't forget, people are
realy happy to do beta tests. but many of them are maybe not willing to
follow a mailing list.



+1.
OOo used to have RC versions strongly advertised, it could go up to 6 RC
before going final and it was very useful to spot the main bugs.


And I forgot: the 2 main bugs (slow saving in MS Office formats and the Calc
display issue under Windows) were reported in the forum only 2 days and 5
days after the release! and we have had many topics for both afterward. A RC
would have clearly spared the hassle.

See:
http://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=63082
http://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=63161




Maybe we need to call an earlier build the "RC" so it will get more
attention?   We had a complete test build that we were testing for
over a month.  But maybe it is ignored unless we call it an "RC"?  In
other words, there were many opportunities for users to help try 4.0
before it was released, but maybe there opportunities were not well
known.


Déjà vu ;-)

I remember that we had the same problem in the old project.

Call it "Developer Snapshot" and you will have a few hundreads downloads 
with respective number of feedback. But call it (and announce it!) with 
a name that sounds more familar (like Early Access, Preview, Beta, RC) 
then we had much more. So, going public more early should bring us a 
higher number of feedback.


Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Some thoughts on quality

2013-08-14 Thread Rob Weir
On Wed, Aug 14, 2013 at 3:37 PM, Marcus (OOo)  wrote:
> Am 08/14/2013 09:01 PM, schrieb Raphael Bircher:
>
>> Am 14.08.13 20:21, schrieb Rob Weir:
>>>
>>> On Wed, Aug 14, 2013 at 1:36 PM, Edwin Sharp  wrote:

 Dear Rob
 The 4.0 release was too ambitious - we should advance in smaller steps.
 Nothing compares to general public testing - betas and release
 candidates should not be avoided.
 TestLink cases should be less comprehesive (in terms of feature
 coverage) and more stress testing oriented.
>>>
>>> The number to consider here is how many defects were found and fixed
>>> during the 4.0.0 testing, before the general public users had access?
>>> I assume it was quite substantial. If so, the TestLink usage was
>>> effective. In other words, we might have found fewer bugs without
>>> using it.
>
>
> In general, my feeling is that it's too early to do a retrospective and ask
> "what was good, what needs to be improved?" (to say it with SCRUM words ;-)
> ) Just after the first major release.
>

Memories are still fresh and programmers are looking at the relevant
code.  This is the best time to answer these questions.

> We should look on the BZ query you have mentioned and see if there is one or
> more hotspots that should be improved fast. That's it.
>

That would be fine.  I'm not suggesting anything radical.  Gradual,
but constant improvements are the way to high quality.


>
>>> This is important to keep in mind: we want to prevent or find more
>>> bugs, but we're not starting from zero. We're starting from a process
>>> that does a lot of things right.
>>>
>>> I like the idea of a public beta. But consider the numbers. The 40
>>> or so regressions that were reported came from an install base (based
>>> on download figures since 4.0.0 was released) of around 3 million
>>> users. Realistically, can we expect anywhere near that number in a
>>> public beta? Or is it more likely that a beta program has 10,000
>>> users or fewer? I don't know the answer here. But certainly a
>>> well-publicized and used beta will find more than a beta used by just
>>> a few hundred users.
>>
>> The public beta is from my point of view realy important. Even you have
>> only 10'000 Downloads of a beta, you have normaly verry experianced
>> Users there, like power users from Companies. They provide realy valua
>> feedback. So from my point of view, this is one of the moast important
>> changes we have to do. For all Feature release a beta version. And don't
>> forget, people are realy happy to do beta tests. but many of them are
>> maybe not willing to follow a mailing list.
>
>
> A public beta release is of course not the golden solution but could
> activate some power users that give us the feedback we want and need.
>
> So, +1 for going this way.
>
> After the 4.1 release is done we can see if this was much better - and ask
> ourself why? :-)
>

But several of the bugs in 4.0.0 should never have made it to even a
beta.  For example, the very slow saving in Excel format.  What
happened there?

Sure, this could be fixed later in the process, in a beta, or in a
4.0.1 as we're doing now.  But this really should have been detected
and fixed much earlier in the process.

What are betas good for?  Betas are good for expanding the set of
configurations. Platforms, languages, extensions, etc.But the
informal "tests" done by real users tend to be shallow.  Also, we have
no way of determining what the test coverage is.  In particular we
have no basis for telling the difference between the coverage of a 2
week beta versus a 4 week beta.  But with out formal test cases we can
easily look at how many test cases were executed. We could even look
at code coverage if we wanted to.

Maybe if there was a way to record what features beta testers were
using...   Or even have a little survey where they report what
platform they ran on, etc.

But very slow saving to XLS files?  A defect like that should have
been caught by us before a beta and before a RC.  We shouldn't expect
to find bugs like that in a beta.

Finally, I think we can all point to a similar open source project
that has numerous betas, but still suffers from poor quality.  So a
public beta, by itself, is not sufficient.  We need some upstream
improvements as well, I think.  But we should do a beta as well.  But
aim to have the highest quality beta we can, right?

Regards,

-Rob



> Marcus
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Some thoughts on quality

2013-08-14 Thread Marcus (OOo)

Am 08/14/2013 09:50 PM, schrieb Hagar Delest:

Le 14/08/2013 21:37, Marcus (OOo) a écrit :

In general, my feeling is that it's too early to do a retrospective
and ask "what was good, what needs to be improved?" (to say it with
SCRUM words ;-) ) Just after the first major release.

Well, I visit forums and contribute since OOo 2.0 and it's the first
time we (volunteers in forums) advise to downgrade so often, even for a
major upgrade (because of the slow saving time and the Calc display
issue mainly).
So there has been clearly a quality issue.


Sure, I don't want to deny this.

However, IMHO it's too early to look at the big picture and try to find 
the black spots.



About test case, it's strange that the 2 bugs above were not seen.


That seems indeen one hotspot I mentioned.

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Some thoughts on quality

2013-08-14 Thread Hagar Delest

Le 14/08/2013 21:39, Rob Weir a écrit :

Maybe we need to call an earlier build the "RC" so it will get more
attention?   We had a complete test build that we were testing for
over a month.  But maybe it is ignored unless we call it an "RC"?  In
other words, there were many opportunities for users to help try 4.0
before it was released, but maybe there opportunities were not well
known.


I think that it was too difficult to get to the dev versions and it was too 
much complicated. There was no clear link to download a dev version (I had to 
rely on the url in the messages from the dev list).

What I see (from a standard user point of view) for a RC:
- When a dev version is almost done, rename it RC and make it known (blog and 
we would relay the announcement in the forums of course)
- Have a link visible under the main download button of the download page 
(perhaps a similar button as a dedicated entry)
- Make that RC installable in parallel with a stable version
- No file association allowed for that RC by design

The wiki page for the dev builds were too complicated and sounded to much beta 
to make the users confident in using them (when they managed to get on that 
page!).

Hagar

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



4.0.1_release_blocker requested: [Bug 122881] OpenOffice Application icon invisible

2013-08-14 Thread bugzilla
Raphael Bircher  has asked  for 4.0.1_release_blocker:
Bug 122881: OpenOffice Application icon invisible
https://issues.apache.org/ooo/show_bug.cgi?id=122881


--- Additional Comments from Raphael Bircher 
Ask for Release Blocker

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [Website]

2013-08-14 Thread Rob Weir
On Wed, Aug 14, 2013 at 3:37 PM, Marcus (OOo)  wrote:
> Since a few weeks we get mails with just "[Website]" as subject.
>
> Just one word is not really meaningful to classify the mail content on the
> first view. So, I'm wondering from where they come from and how to improve
> this?
>

These probably come from the contact page:

http://www.openoffice.org/contact_us.html

See:  For problems with the www.openoffice.org website, please contact
us via Development mailing list.

That page covers contacts for reporting bugs, website and wiki
problems, press, etc.   But the very first link on the page is for
support.  I assume it requires an advanced degree in psychology to
understand why someone would skip over that link and go to another.

-Rob


> Marcus
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Some thoughts on quality

2013-08-14 Thread Marcus (OOo)

Am 08/14/2013 09:58 PM, schrieb Rob Weir:

On Wed, Aug 14, 2013 at 3:37 PM, Marcus (OOo)  wrote:

Am 08/14/2013 09:01 PM, schrieb Raphael Bircher:


Am 14.08.13 20:21, schrieb Rob Weir:


On Wed, Aug 14, 2013 at 1:36 PM, Edwin Sharp  wrote:


Dear Rob
The 4.0 release was too ambitious - we should advance in smaller steps.
Nothing compares to general public testing - betas and release
candidates should not be avoided.
TestLink cases should be less comprehesive (in terms of feature
coverage) and more stress testing oriented.


The number to consider here is how many defects were found and fixed
during the 4.0.0 testing, before the general public users had access?
I assume it was quite substantial. If so, the TestLink usage was
effective. In other words, we might have found fewer bugs without
using it.



In general, my feeling is that it's too early to do a retrospective and ask
"what was good, what needs to be improved?" (to say it with SCRUM words ;-)
) Just after the first major release.



Memories are still fresh and programmers are looking at the relevant
code.  This is the best time to answer these questions.


We should look on the BZ query you have mentioned and see if there is one or
more hotspots that should be improved fast. That's it.



That would be fine.  I'm not suggesting anything radical.  Gradual,
but constant improvements are the way to high quality.


Then this should be sufficiant IMHO.


This is important to keep in mind: we want to prevent or find more
bugs, but we're not starting from zero. We're starting from a process
that does a lot of things right.

I like the idea of a public beta. But consider the numbers. The 40
or so regressions that were reported came from an install base (based
on download figures since 4.0.0 was released) of around 3 million
users. Realistically, can we expect anywhere near that number in a
public beta? Or is it more likely that a beta program has 10,000
users or fewer? I don't know the answer here. But certainly a
well-publicized and used beta will find more than a beta used by just
a few hundred users.


The public beta is from my point of view realy important. Even you have
only 10'000 Downloads of a beta, you have normaly verry experianced
Users there, like power users from Companies. They provide realy valua
feedback. So from my point of view, this is one of the moast important
changes we have to do. For all Feature release a beta version. And don't
forget, people are realy happy to do beta tests. but many of them are
maybe not willing to follow a mailing list.



A public beta release is of course not the golden solution but could
activate some power users that give us the feedback we want and need.

So, +1 for going this way.

After the 4.1 release is done we can see if this was much better - and ask
ourself why? :-)



But several of the bugs in 4.0.0 should never have made it to even a
beta.  For example, the very slow saving in Excel format.  What
happened there?

Sure, this could be fixed later in the process, in a beta, or in a
4.0.1 as we're doing now.  But this really should have been detected
and fixed much earlier in the process.

What are betas good for?  Betas are good for expanding the set of
configurations. Platforms, languages, extensions, etc.But the
informal "tests" done by real users tend to be shallow.  Also, we have
no way of determining what the test coverage is.  In particular we
have no basis for telling the difference between the coverage of a 2
week beta versus a 4 week beta.  But with out formal test cases we can
easily look at how many test cases were executed. We could even look
at code coverage if we wanted to.

Maybe if there was a way to record what features beta testers were
using...   Or even have a little survey where they report what
platform they ran on, etc.

But very slow saving to XLS files?  A defect like that should have
been caught by us before a beta and before a RC.  We shouldn't expect
to find bugs like that in a beta.


Of course. I've said nothing different. ;-)


Finally, I think we can all point to a similar open source project
that has numerous betas, but still suffers from poor quality.  So a
public beta, by itself, is not sufficient.  We need some upstream
improvements as well, I think.  But we should do a beta as well.  But
aim to have the highest quality beta we can, right?


Sure, the XLS bug has nothing to with "this wouldn't happen with a 
Beta". As I answered to Hagar this is one hotspot that should be looked 
at closer.


Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Some thoughts on quality

2013-08-14 Thread Marcus (OOo)

Am 08/14/2013 10:05 PM, schrieb Hagar Delest:

Le 14/08/2013 21:39, Rob Weir a écrit :

Maybe we need to call an earlier build the "RC" so it will get more
attention? We had a complete test build that we were testing for
over a month. But maybe it is ignored unless we call it an "RC"? In
other words, there were many opportunities for users to help try 4.0
before it was released, but maybe there opportunities were not well
known.


I think that it was too difficult to get to the dev versions and it was
too much complicated. There was no clear link to download a dev version
(I had to rely on the url in the messages from the dev list).


This was intended.

We hadn't published the dev builds via Apache or SF mirrors but only on 
2 people accounts. Apache policy says it's not allowed to publish them 
for a wider audience to save the servers from a high traffic load. It's 
the job of the mirrors to handle this.



What I see (from a standard user point of view) for a RC:
- When a dev version is almost done, rename it RC and make it known
(blog and we would relay the announcement in the forums of course)
- Have a link visible under the main download button of the download


Both can be done, depending where the install files are located.


page (perhaps a similar button as a dedicated entry)
- Make that RC installable in parallel with a stable version
- No file association allowed for that RC by design


IMHO the last both points doesn't apply to a RC [1] as it wouldn't be a 
RC anymore. One of the RC attributes is to change it into the final 
release with, e.g., just a file name change. But this has to be done 
without any code changes. Otherwise you have to change code parts, build 
again, test again, ... ;-)


But a Beta release could go this separated way.


The wiki page for the dev builds were too complicated and sounded to
much beta to make the users confident in using them (when they managed
to get on that page!).


Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Some thoughts on quality

2013-08-14 Thread Marcus (OOo)

Am 08/14/2013 10:24 PM, schrieb Marcus (OOo):

Am 08/14/2013 10:05 PM, schrieb Hagar Delest:

Le 14/08/2013 21:39, Rob Weir a écrit :

Maybe we need to call an earlier build the "RC" so it will get more
attention? We had a complete test build that we were testing for
over a month. But maybe it is ignored unless we call it an "RC"? In
other words, there were many opportunities for users to help try 4.0
before it was released, but maybe there opportunities were not well
known.


I think that it was too difficult to get to the dev versions and it was
too much complicated. There was no clear link to download a dev version
(I had to rely on the url in the messages from the dev list).


This was intended.

We hadn't published the dev builds via Apache or SF mirrors but only on
2 people accounts. Apache policy says it's not allowed to publish them
for a wider audience to save the servers from a high traffic load. It's
the job of the mirrors to handle this.


What I see (from a standard user point of view) for a RC:
- When a dev version is almost done, rename it RC and make it known
(blog and we would relay the announcement in the forums of course)
- Have a link visible under the main download button of the download


Both can be done, depending where the install files are located.


page (perhaps a similar button as a dedicated entry)
- Make that RC installable in parallel with a stable version
- No file association allowed for that RC by design


IMHO the last both points doesn't apply to a RC [1] as it wouldn't be a
RC anymore. One of the RC attributes is to change it into the final
release with, e.g., just a file name change. But this has to be done
without any code changes. Otherwise you have to change code parts, build
again, test again, ... ;-)

But a Beta release could go this separated way.


The wiki page for the dev builds were too complicated and sounded to
much beta to make the users confident in using them (when they managed
to get on that page!).


Marcus


Sorry, forgot the link:

[1] 
http://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Some thoughts on quality

2013-08-14 Thread David Gerard
On 14 August 2013 20:39, Rob Weir  wrote:


> Maybe we need to call an earlier build the "RC" so it will get more
> attention?   We had a complete test build that we were testing for
> over a month.  But maybe it is ignored unless we call it an "RC"?  In
> other words, there were many opportunities for users to help try 4.0
> before it was released, but maybe there opportunities were not well
> known.
>


It basically wasn't publicised. I knew about it because I actually went
looking for it (goal: to put an image on the Wikipedia article of the 4.0
sidebar). It took a bit of ferreting about to find the prereleases. I've
followed the list all this year, so I knew (a) it existed (b) what to ask
about; the percentage of AOO users on the dev list is all but invisible.

Suggestion 1: note prereleases on the blog and in the social media channels.

Suggestion 2: do an RC for 4.0.1 as well. Even if you don't think there's a
need to, and fully expect the RC to be byte-for-byte identical to the final
release, people will appreciate being asked.

The Cathedral and the Bazaar still applies. "Release early, release often."
You could have had six months' intense testing from users who were
seriously interested.


- d.


Re: [Website]

2013-08-14 Thread Marcus (OOo)

Am 08/14/2013 10:11 PM, schrieb Rob Weir:

On Wed, Aug 14, 2013 at 3:37 PM, Marcus (OOo)  wrote:

Since a few weeks we get mails with just "[Website]" as subject.

Just one word is not really meaningful to classify the mail content on the
first view. So, I'm wondering from where they come from and how to improve
this?



These probably come from the contact page:

http://www.openoffice.org/contact_us.html


ah, thanks.


See:  For problems with the www.openoffice.org website, please contact
us via Development mailing list.

That page covers contacts for reporting bugs, website and wiki
problems, press, etc.   But the very first link on the page is for
support.  I assume it requires an advanced degree in psychology to
understand why someone would skip over that link and go to another.


Yes, especially because the hint with the dev@ link is one of the last 
options. So, it doesn't make sense to exchange it with others in the 
section as this would just move the problem to the l10n@ or bz@ mailing 
list.


OK, seems to be the last remaining 2.5% that never can be improved.

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [Website]

2013-08-14 Thread Marcus (OOo)

Am 08/14/2013 10:32 PM, schrieb Marcus (OOo):

Am 08/14/2013 10:11 PM, schrieb Rob Weir:

On Wed, Aug 14, 2013 at 3:37 PM, Marcus (OOo)
wrote:

Since a few weeks we get mails with just "[Website]" as subject.

Just one word is not really meaningful to classify the mail content
on the
first view. So, I'm wondering from where they come from and how to
improve
this?



These probably come from the contact page:

http://www.openoffice.org/contact_us.html


ah, thanks.


See: For problems with the www.openoffice.org website, please contact
us via Development mailing list.

That page covers contacts for reporting bugs, website and wiki
problems, press, etc. But the very first link on the page is for
support. I assume it requires an advanced degree in psychology to
understand why someone would skip over that link and go to another.


Yes, especially because the hint with the dev@ link is one of the last
options. So, it doesn't make sense to exchange it with others in the
section as this would just move the problem to the l10n@ or bz@ mailing
list.

OK, seems to be the last remaining 2.5% that never can be improved.


Proposal:

Exchange the predefined mail subject (e.g. "[Website]") with a more 
speaking wording like:


"I want to report a problem with the OpenOffice website"
"I want to report a problem with the OpenOffice BugZilla"
"I want to report a problem with the OpenOffice Wiki"
"I want to report a problem with the Pootle translation service"

Maybe this will make it a bit more obvious for the user that her/his 
mail doesn't fit to the topic and could lead to think twice before 
hitting on [Send].


Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Some thoughts on quality

2013-08-14 Thread Rob Weir
On Wed, Aug 14, 2013 at 4:24 PM, Marcus (OOo)  wrote:
> Am 08/14/2013 10:05 PM, schrieb Hagar Delest:
>
>> Le 14/08/2013 21:39, Rob Weir a écrit :
>>>
>>> Maybe we need to call an earlier build the "RC" so it will get more
>>> attention? We had a complete test build that we were testing for
>>> over a month. But maybe it is ignored unless we call it an "RC"? In
>>> other words, there were many opportunities for users to help try 4.0
>>> before it was released, but maybe there opportunities were not well
>>> known.
>>
>>
>> I think that it was too difficult to get to the dev versions and it was
>> too much complicated. There was no clear link to download a dev version
>> (I had to rely on the url in the messages from the dev list).
>
>
> This was intended.
>
> We hadn't published the dev builds via Apache or SF mirrors but only on 2
> people accounts. Apache policy says it's not allowed to publish them for a
> wider audience to save the servers from a high traffic load. It's the job of
> the mirrors to handle this.
>
>
>> What I see (from a standard user point of view) for a RC:
>> - When a dev version is almost done, rename it RC and make it known
>> (blog and we would relay the announcement in the forums of course)
>> - Have a link visible under the main download button of the download
>
>
> Both can be done, depending where the install files are located.
>
>
>> page (perhaps a similar button as a dedicated entry)
>> - Make that RC installable in parallel with a stable version
>> - No file association allowed for that RC by design
>
>
> IMHO the last both points doesn't apply to a RC [1] as it wouldn't be a RC
> anymore. One of the RC attributes is to change it into the final release
> with, e.g., just a file name change. But this has to be done without any
> code changes. Otherwise you have to change code parts, build again, test
> again, ... ;-)
>
> But a Beta release could go this separated way.
>

Right.  A release is a release is a release.  The basic requirements
for every release still apply:

1) 3 PMC +1 votes
2) Must include source files
3) Digital signatures, hash files, etc.

But we can have a "beta release", that follows these rules, and it
would be acceptable.  We can then host on the mirrors, publicize, etc.

However, back to the original topic of this thread:   We should look
to see when the bugs we're fixing in 4.0.1 were added to the code.
Not to blame or make anyone feel bad.  But to understand.  If these
were late bugs then an earlier beta would not have found them.

-Rob

>
>> The wiki page for the dev builds were too complicated and sounded to
>> much beta to make the users confident in using them (when they managed
>> to get on that page!).
>
>
> Marcus
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: [Extensions website] Timeline don't work

2013-08-14 Thread Roberto Galoppini
2013/8/14 FR web forum 

> Hello list,
> For the last 3 recents OXT, timeline don't work:
>
> http://extensions.openoffice.org/en/search?query=&sort_by=created&sort_order=DESC
> Download numbers seems to be not tracked.
>


Actually the timeline works only for extensions hosted on the Extensions
website. The reason is that we do not have any stats info for extensions
served by third parties' sites, and those are indicated as "Not tracked".

we might want to eliminate the "Timeline" for those extensions in the
future, though.

Roberto


> If you jump to SF.net, you got an error:
> The "/17434" file could not be found or is not available.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


Re: Some thoughts on quality

2013-08-14 Thread sebb
On 14 August 2013 23:10, Rob Weir  wrote:
> On Wed, Aug 14, 2013 at 4:24 PM, Marcus (OOo)  wrote:
>> Am 08/14/2013 10:05 PM, schrieb Hagar Delest:
>>
>>> Le 14/08/2013 21:39, Rob Weir a écrit :

 Maybe we need to call an earlier build the "RC" so it will get more
 attention? We had a complete test build that we were testing for
 over a month. But maybe it is ignored unless we call it an "RC"? In
 other words, there were many opportunities for users to help try 4.0
 before it was released, but maybe there opportunities were not well
 known.
>>>
>>>
>>> I think that it was too difficult to get to the dev versions and it was
>>> too much complicated. There was no clear link to download a dev version
>>> (I had to rely on the url in the messages from the dev list).
>>
>>
>> This was intended.
>>
>> We hadn't published the dev builds via Apache or SF mirrors but only on 2
>> people accounts. Apache policy says it's not allowed to publish them for a
>> wider audience to save the servers from a high traffic load. It's the job of
>> the mirrors to handle this.
>>
>>
>>> What I see (from a standard user point of view) for a RC:
>>> - When a dev version is almost done, rename it RC and make it known
>>> (blog and we would relay the announcement in the forums of course)
>>> - Have a link visible under the main download button of the download
>>
>>
>> Both can be done, depending where the install files are located.
>>
>>
>>> page (perhaps a similar button as a dedicated entry)
>>> - Make that RC installable in parallel with a stable version
>>> - No file association allowed for that RC by design
>>
>>
>> IMHO the last both points doesn't apply to a RC [1] as it wouldn't be a RC
>> anymore. One of the RC attributes is to change it into the final release
>> with, e.g., just a file name change. But this has to be done without any
>> code changes. Otherwise you have to change code parts, build again, test
>> again, ... ;-)
>>
>> But a Beta release could go this separated way.
>>
>
> Right.  A release is a release is a release.  The basic requirements
> for every release still apply:
>
> 1) 3 PMC +1 votes
> 2) Must include source files
> 3) Digital signatures, hash files, etc.
>
> But we can have a "beta release", that follows these rules, and it
> would be acceptable.  We can then host on the mirrors, publicize, etc.

There would likely be some restrictions on how many extra downloads
are permitted.
For example, the ASF mirrors probably could not cope with a set of
betas of all the languages for all the OSes in addition to the current
GA release.

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Some thoughts on quality

2013-08-14 Thread Kay Schenk
On Wed, Aug 14, 2013 at 12:51 PM, Marcus (OOo)  wrote:

> Am 08/14/2013 09:39 PM, schrieb Rob Weir:
>
>  On Wed, Aug 14, 2013 at 3:33 PM, Hagar 
> Delest>
>>  wrote:
>>
>>> Le 14/08/2013 21:29, Hagar Delest a écrit :
>>>
>>>  Le 14/08/2013 21:01, Raphael Bircher a écrit :

  I like the idea of a public beta.  But consider the numbers.  The 40
>> or so regressions that were reported came from an install base (based
>> on download figures since 4.0.0 was released) of around 3 million
>> users.  Realistically, can we expect anywhere near that number in a
>> public beta?  Or is it more likely that a beta program has 10,000
>> users or fewer?  I don't know the answer here.   But certainly a
>> well-publicized and used beta will find more than a beta used by just
>> a few hundred users.
>>
>
> The public beta is from my point of view realy important. Even you have
> only 10'000 Downloads of a beta, you have normaly verry experianced
> Users
> there, like power users from Companies. They provide realy valua
> feedback.
> So from my point of view, this is one of the moast important changes
> we have
> to do. For all Feature release a beta version. And don't forget,
> people are
> realy happy to do beta tests. but many of them are maybe not willing to
> follow a mailing list.
>


 +1.
 OOo used to have RC versions strongly advertised, it could go up to 6 RC
 before going final and it was very useful to spot the main bugs.

  And I forgot: the 2 main bugs (slow saving in MS Office formats and
>>> the Calc
>>> display issue under Windows) were reported in the forum only 2 days and 5
>>> days after the release! and we have had many topics for both afterward.
>>> A RC
>>> would have clearly spared the hassle.
>>>
>>> See:
>>> http://forum.openoffice.org/**en/forum/viewtopic.php?f=9&t=**63082
>>> http://forum.openoffice.org/**en/forum/viewtopic.php?f=9&t=**63161
>>>
>>>
>>
>> Maybe we need to call an earlier build the "RC" so it will get more
>> attention?   We had a complete test build that we were testing for
>> over a month.  But maybe it is ignored unless we call it an "RC"?  In
>> other words, there were many opportunities for users to help try 4.0
>> before it was released, but maybe there opportunities were not well
>> known.
>>
>
> Déjà vu ;-)
>
> I remember that we had the same problem in the old project.
>
> Call it "Developer Snapshot" and you will have a few hundreads downloads
> with respective number of feedback. But call it (and announce it!) with a
> name that sounds more familar (like Early Access, Preview, Beta, RC) then
> we had much more. So, going public more early should bring us a higher
> number of feedback.
>
> Marcus


If this would help, then we should do it. Hopefully this will get users'
attention more.



>
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@openoffice.**apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org
>
>


-- 
-
MzK

"When in doubt, cop an attitude."
-- Cat laws


Re: [BUILD] Linux32 snapshot configure

2013-08-14 Thread Kay Schenk
On Wed, Aug 14, 2013 at 10:29 AM, Andrew Rist wrote:

> Here is the current configure statement for the Linux32 bot - is this
> correct, and what changes would make it better?
>
> ./configure \
> --with-jdk-home="/usr/lib/jvm/**java-6-openjdk" \
>--with-epm-url="http://www.**msweet.org/files/project2/epm-**
> 3.7-source.tar.gz
>" \
>--with-dmake-url="http://**dmake.apache-extras.org.**
> codespot.com/files/dmake-4.12.**tar.bz2
> "
>\
> --enable-verbose \
> --without-stlport \
> --enable-category-b \
> --enable-opengl \
> --enable-dbus \
> --enable-gstreamer \
>  --with-package-format="**installed rpm deb" \
>  --enable-bundled-dictionaries \
>  --with-lang="ast cs de el en-GB en-US es fi fr gd gl hu it
>ja km ko nl pl pt pt-BR ru sk sl ta zh-CN zh-TW ca eu he hi id lt sv
>th tr " \
> --with-vendor="Apache OpenOffice buildbot" \
> --with-build-version="%(today)**s-Rev.%(got_revision)s" \
>
>
>
OK, I'm not exactly sure why you're asking this -- I have meant to take a
look at the build logs for the current instance since it has been failing,
but no time yet -- but are you referring to the existing Linux 32 bot with
your question or the newly proposed one?

We have discussed using java 7 instead of 6. My recent build went fine but
of course not thoroughly tested many aspects. Please --

--enable-verbose

-- 
-
MzK

"When in doubt, cop an attitude."
-- Cat laws