Sophie wrote:
>> Whether help content must be part of a feature CWS or
>> not should be seen in the general context of how we want to localize it.
>
> Not only, sometimes changes are not documented because the corresponding
> CWS has not been mark help relevant, having an issue in the CWS task
Jörg Jahnke wrote:
> Hi Mathias,
>
> Mathias Bauer schrieb:
> ...
>>
>> Currently the way how localizations get into OOo is very inefficient. At
>> some point in time a "deadline" is reached and a whole bunch of
>> localizable content is exported from the source tree and handed over.
>> Localize
Rene Engelhard wrote:
> Hi,
>
> On Wed, Sep 23, 2009 at 11:39:49AM +0200, Michael Stahl wrote:
>> or maybe we could simply have a "convenience" flag for configure like
>> --official-build, that would simply behave as if the set of necessary
>> non-default flags were given?
>
> That would need Su
Helge Delfs - Sun Germany - ham02 - Hamburg wrote:
> Hi,
>
> On 09/23/09 08:29, Mathias Bauer wrote:
>> Really, this part of the work is superfluous. IMHO tests that are known
>> to be broken in a particular milestone should be skipped in a CWS based
>> on it also. So if you get a "red" state, yo
Frank Schoenheit, Sun Microsystems Germany wrote:
> Hi Mathias,
>
>> Really, this part of the work is superfluous. IMHO tests that are known
>> to be broken in a particular milestone should be skipped in a CWS based
>> on it also.
>
> Don't think this is a good idea, since a test can be broken i
Rene Engelhard openoffice.org> writes:
> That would need Sun people actually touching configure when they
> change their defaults. [...]
Please read mst's mail again. Especially the last sentence. The problem is well-
known, we know how to fix it (by using configure for all build): the only
pro
Hi Rene,
> Last occurance of Sun not caring about configure at all
It would make discussions easier if you would learn to stick to facts,
and refrain from ungrounded accusations.
If we (Sun) would "not care about configure at all", there would be much
much more problems. Usually, whenever we cha
Hi,
On Wed, Sep 23, 2009 at 11:39:49AM +0200, Michael Stahl wrote:
> or maybe we could simply have a "convenience" flag for configure like
> --official-build, that would simply behave as if the set of necessary
> non-default flags were given?
That would need Sun people actually touching configure
On 09/23/09 11:17, Frank Schoenheit, Sun Microsystems Germany wrote:
Hi Stephan,
I think this point is moot. I strongly believe that tests that are
regularly run on all CWS must also be run on the MWS, and the MWS must
not be declared ready until all those test succeed.
I believe that, to
Hi Helge,
Helge Delfs a écrit :
Hi Sophie,
On 09/21/09 20:15, Sophie wrote:
- No documentation on the interaction between EIS and QUASTe (or I
didn't find it and yes I can write it by myself ;). There is still one
button that I don't understand in QUASTe that sound to have an impact on
EIS. Als
Hi Mathias, all,
Mathias Bauer a écrit :
Hi Sophie,
thank you for your comments. I'm glad to get feedback from "non code
hackers" also as I'm hoping to make life easier for them also.
Thanks :)
I will add your points to my list. Let me give some immediate answers to
some of your points. I wi
Caolán McNamara wrote:
> On Mon, 2009-09-21 at 20:15 +0200, Sophie wrote:
>> - Install sets by the bots are different from Sun builds that make some
>> automated tests failing (why the quickstarter is available on linux
>> builds? it took me some time to understand that I have to disable it first
Hi Stephan,
> I think this point is moot. I strongly believe that tests that are
> regularly run on all CWS must also be run on the MWS, and the MWS must
> not be declared ready until all those test succeed.
I believe that, too, but it's theory only. Pretty similar to the theory
that of cour
Hi Bjoern,
> If a test checks for 10 things at once and in an atomic operation it is broken
> by design anyway. That would need to be fixed thus eliminating the problem,
> IMHO.
This depends on the definition of "test", "test case", etc. - which
might yield a longer discussion than is really appr
Hi Mathias,
Mathias Bauer schrieb:
...
Currently the way how localizations get into OOo is very inefficient. At
some point in time a "deadline" is reached and a whole bunch of
localizable content is exported from the source tree and handed over.
Localizers do their work, send it back and have t
Frank Schoenheit sun.com> writes:
> Don't think this is a good idea, since a test can be broken in different
> ways. For instance, if your test checks 10 aspects, and one of them is
> broken in MWS, you still want to know if the other 9 are okay in your
> CWS. Otherwise, you'll notice a breakage
Hi Sophie,
On 09/21/09 20:15, Sophie wrote:
> - No documentation on the interaction between EIS and QUASTe (or I
> didn't find it and yes I can write it by myself ;). There is still one
> button that I don't understand in QUASTe that sound to have an impact on
> EIS. Also I'm not sure that what yo
On Sep 23, 2009, at 8:45 AM, Frank Schoenheit, Sun Microsystems
Germany wrote:
Hi Mathias,
Really, this part of the work is superfluous. IMHO tests that are
known
to be broken in a particular milestone should be skipped in a CWS
based
on it also.
Don't think this is a good idea, since a
Hi,
On 09/23/09 08:29, Mathias Bauer wrote:
> Really, this part of the work is superfluous. IMHO tests that are known
> to be broken in a particular milestone should be skipped in a CWS based
> on it also. So if you get a "red" state, you know that something is
> wrong without the necessity to bro
19 matches
Mail list logo