Re: [dev] Specifications - summary suggestions ...

2006-11-13 Thread Michael Meeks
Hi Joerg, On Tue, 2006-11-07 at 12:40 +0100, Joerg Sievers wrote: + specifications are critical for (at a minimum): + file formats + complex / unfamiliar behaviours + behaviour changes affecting other's work (e.g. the automated gui testing is extremely dependent to the basics

Re: [dev] Specifications - summary suggestions ...

2006-11-07 Thread Joerg Sievers
Hi Michael, Michael Meeks wrote: + specifications are critical for (at a minimum): + file formats + complex / unfamiliar behaviours + behaviour changes affecting other's work (e.g. the automated gui testing is extremely dependent to the basics of OOo) * (Perhaps)

Re: [dev] Specifications - summary suggestions ...

2006-11-07 Thread Mathias Bauer
Niklas Nebel wrote: Kohei Yoshida wrote: On 11/3/06, Mathias Bauer [EMAIL PROTECTED] wrote: Let's put it that way: it should be possible to integrate something even if the original goal laid out in the spec wasn't reached but the result is good enough. Good enough means that we could live

Re: [dev] Specifications - summary suggestions ...

2006-11-06 Thread Niklas Nebel
Kohei Yoshida wrote: On 11/3/06, Mathias Bauer [EMAIL PROTECTED] wrote: Let's put it that way: it should be possible to integrate something even if the original goal laid out in the spec wasn't reached but the result is good enough. Good enough means that we could live with it even if nothing

Re: [dev] Specifications - summary suggestions ...

2006-11-06 Thread Kohei Yoshida
On 11/6/06, Niklas Nebel [EMAIL PROTECTED] wrote: Kohei Yoshida wrote: On 11/3/06, Mathias Bauer [EMAIL PROTECTED] wrote: Let's put it that way: it should be possible to integrate something even if the original goal laid out in the spec wasn't reached but the result is good enough. Good

Re: [dev] Specifications - summary suggestions ...

2006-11-05 Thread Kohei Yoshida
On 11/3/06, Mathias Bauer [EMAIL PROTECTED] wrote: Let's put it that way: it should be possible to integrate something even if the original goal laid out in the spec wasn't reached but the result is good enough. Good enough means that we could live with it even if nothing was changed until the

Re: [dev] test frameworks (was: [dev] Specifications - summary suggestions ...)

2006-11-05 Thread Thorsten Behrens
Frank Schönheit - Sun Microsystems Germany [EMAIL PROTECTED] writes: What are testshl2 and cppunit? (No, I don't want to google. I want the pointer to the Wiki page where you document their usage inside OOo :) Hi Frank, glad to tell _you_ something new. ;-) cppunit is a port of JUnit to

[dev] test frameworks (was: [dev] Specifications - summary suggestions ...)

2006-11-04 Thread Frank Schönheit - Sun Microsystems Germa ny
Hi Thorsten, well, there actually _are_ several test frameworks in place. From what you've probably in mind, testshl2 should come close. It's basically cppunit dressed up to work in OOo's build environment. See e.g. o3tl/qa/makefile.mk on how to employ it. Always learning something new ...

Re: [dev] Specifications - summary suggestions ...

2006-11-03 Thread Nikolai Pretzell
Hi Kohei, Kohei Yoshida wrote: Michael Meeks wrote: + The primary consumer of a finished spec. is QA If the developer is the same as the spec writer. Else the developer is as important a consumer as the QA. So, the language used in the spec should be oriented toward QA personnel

Re: [dev] Specifications - summary suggestions ...

2006-11-03 Thread Kohei Yoshida
So, the language used in the spec should be oriented toward QA personnel (i.e. less advertising or selling tone, but more technicality and correctness). A spec is a strictly technical document. Advertisement and selling has nothing to do with it. Yes, that was my understanding as well. But

Re: [dev] Specifications - summary suggestions ...

2006-11-03 Thread Kohei Yoshida
On 11/2/06, Michael Meeks [EMAIL PROTECTED] wrote: It seems there has been a wide-ranging debate on the spec. topic wrt. reducing potentially discouraging barriers to entry for community contributors. I tried to summarise where I -think- we're at, and then present some principles some

Re: [dev] Specifications - summary suggestions ...

2006-11-03 Thread Kohei Yoshida
On 11/3/06, Niklas Nebel [EMAIL PROTECTED] wrote: Kohei Yoshida wrote: Another point I want to mention is that, perhaps the UI design requirement at CWS integration time should be relaxed a bit. Instead of requiring UE approveal of the UI change at cws integration time, either QA or peer

Re: [dev] Specifications - summary suggestions ...

2006-11-03 Thread Mathias Bauer
Kohei Yoshida wrote: + UE - get involved before before the feature is implemented, or have some veto role Not sure how this works out for a feature that arrives complete, that is, for a feature that was originally external to OO.o (hence missed the initial discussion

Re: [dev] Specifications - summary suggestions ...

2006-11-03 Thread Mathias Bauer
Kohei Yoshida wrote: On 11/3/06, Niklas Nebel [EMAIL PROTECTED] wrote: Kohei Yoshida wrote: Another point I want to mention is that, perhaps the UI design requirement at CWS integration time should be relaxed a bit. Instead of requiring UE approveal of the UI change at cws integration

Re: [dev] Specifications - summary suggestions ...

2006-11-02 Thread Thorsten Behrens
Michael Meeks [EMAIL PROTECTED] writes: [excellent proposal for an enhanced spec process] + Unit Tests + we need a good, standard, very easy to use unit test framework, that can trivially be extended. Hi Michael, well, there actually _are_ several test frameworks in

Re: [dev] Specifications - summary suggestions ...

2006-11-02 Thread Andreas Martens
Hi Michael, I agree on many points: Michael Meeks wrote: [..] * Proposed new process Sorry, didn't find something new :-( [..] + New spec. process: + 'Wiki' based solution (for those that want it) This has been already accepted. + minimal data required for good QA