Re: proposal for testing procedure of future LyX releases

2006-05-09 Thread Jean-Marc Lasgouttes
Uwe == Uwe Stöhr [EMAIL PROTECTED] writes: Uwe Personally I use a test procedure for every new release of my Uwe LyXWinInstaller. Derived from this here's my proposal for new Uwe releases of LyX: This would be very nice indeed. JMarc

Re: proposal for testing procedure of future LyX releases

2006-05-09 Thread Lars Gullik Bjønnes
[EMAIL PROTECTED] writes: | On Sun, 7 May 2006, [UTF-8] Uwe Stöhr wrote: | | This email is a proposal for a new test procedure of LyX releases. | | In consequence of this I propose to create a testing procedure | LyX-releases to avoid regressions and new introduced bugs. | | This makes a

Re: proposal for testing procedure of future LyX releases

2006-05-09 Thread christian . ridderstrom
On Tue, 9 May 2006, Uwe Stöhr wrote: [EMAIL PROTECTED] wrote: I think it's probably unrealistic to create and maintain a big archive with all of this. However, I'm sure few of you will be surprised when I'm now going to suggest how we partially use the wiki for helping with this. So

Re: proposal for testing procedure of future LyX releases

2006-05-09 Thread christian . ridderstrom
On Tue, 9 May 2006, Uwe Stöhr wrote: We could have automated tests but many things must be tested manually. For example my math manual is build upon sequences to create a formula, e.g. the sequence: A_u uparrow ^2 should create an A with the subscript u and the superscript 2. To have a

Re: proposal for testing procedure of future LyX releases

2006-05-09 Thread christian . ridderstrom
On 9 May 2006, Lars Gullik Bjønnes wrote: When it comes to testing I will also put forward my meager attempt on beginnging to create test cases (please expand on them and create new ones). So far only for a few helper functions, but we should be able to do it for larger subsystems as well.

Re: proposal for testing procedure of future LyX releases

2006-05-09 Thread Jean-Marc Lasgouttes
> "Uwe" == Uwe Stöhr <[EMAIL PROTECTED]> writes: Uwe> Personally I use a test procedure for every new release of my Uwe> LyXWinInstaller. Derived from this here's my proposal for new Uwe> releases of LyX: This would be very nice indeed. JMarc

Re: proposal for testing procedure of future LyX releases

2006-05-09 Thread Lars Gullik Bjønnes
[EMAIL PROTECTED] writes: | On Sun, 7 May 2006, [UTF-8] Uwe Stöhr wrote: | | > This email is a proposal for a new test procedure of LyX releases. | > | > In consequence of this I propose to create a testing procedure | > LyX-releases to avoid regressions and new introduced bugs. | | This

Re: proposal for testing procedure of future LyX releases

2006-05-09 Thread christian . ridderstrom
On Tue, 9 May 2006, Uwe Stöhr wrote: > [EMAIL PROTECTED] wrote: > > > I think it's probably unrealistic to create and maintain a big archive > > with all of this. However, I'm sure few of you will be surprised when I'm > > now going to suggest how we partially use the wiki for helping with this.

Re: proposal for testing procedure of future LyX releases

2006-05-09 Thread christian . ridderstrom
On Tue, 9 May 2006, Uwe Stöhr wrote: > We could have automated tests but many things must be tested manually. > For example my math manual is build upon sequences to create a formula, > e.g. the sequence: > A_u uparrow ^2 > should create an "A" with the subscript "u" and the superscript "2". To

Re: proposal for testing procedure of future LyX releases

2006-05-09 Thread christian . ridderstrom
On 9 May 2006, Lars Gullik Bjønnes wrote: > When it comes to testing I will also put forward my meager attempt on > beginnging to create test cases (please expand on them and create new > ones). > > So far only for a few helper functions, but we should be able to do it > for larger subsystems as

Re: proposal for testing procedure of future LyX releases

2006-05-08 Thread christian . ridderstrom
On Sun, 7 May 2006, [UTF-8] Uwe Stöhr wrote: This email is a proposal for a new test procedure of LyX releases. In consequence of this I propose to create a testing procedure LyX-releases to avoid regressions and new introduced bugs. This makes a lot of sense to me. What John wrote about

Re: proposal for testing procedure of future LyX releases

2006-05-08 Thread Uwe Stöhr
[EMAIL PROTECTED] wrote: I think it's probably unrealistic to create and maintain a big archive with all of this. However, I'm sure few of you will be surprised when I'm now going to suggest how we partially use the wiki for helping with this. So here's one possible approach: ... If this

Re: proposal for testing procedure of future LyX releases

2006-05-08 Thread christian . ridderstrom
On Sun, 7 May 2006, [UTF-8] Uwe Stöhr wrote: > This email is a proposal for a new test procedure of LyX releases. > > In consequence of this I propose to create a testing procedure > LyX-releases to avoid regressions and new introduced bugs. This makes a lot of sense to me. What John wrote

Re: proposal for testing procedure of future LyX releases

2006-05-08 Thread Uwe Stöhr
[EMAIL PROTECTED] wrote: I think it's probably unrealistic to create and maintain a big archive with all of this. However, I'm sure few of you will be surprised when I'm now going to suggest how we partially use the wiki for helping with this. So here's one possible approach: > > ... If this

proposal for testing procedure of future LyX releases

2006-05-07 Thread Uwe Stöhr
This email is a proposal for a new test procedure of LyX releases. I started to use LyX when LyX 1.2 came out. While working with it I started to write my math manual which was not finished when LyX 1.3 was released. I reworked my document to cover the new features of lyX 1.3 and discovered

Re: proposal for testing procedure of future LyX releases

2006-05-07 Thread John Levon
On Sun, May 07, 2006 at 05:00:23PM +0200, Uwe Stöhr wrote: Personally I use a test procedure for every new release of my LyXWinInstaller. Derived from this here's my proposal for new releases of LyX: Some time ago I started a lyx-tests CVS repository for precisely this regression-testing

Re: proposal for testing procedure of future LyX releases

2006-05-07 Thread Michael Gerz
John Levon wrote: - Test scrolling and editing (copy/paste, etc.) with a long and big document like a PHD thesis. I believe we knew about all the problems here, but released anyway. Yes, that was definitely the problem. We locked ourself by a code freeze period that started too early

Re: proposal for testing procedure of future LyX releases

2006-05-07 Thread John Levon
On Sun, May 07, 2006 at 06:04:13PM +0200, Michael Gerz wrote: Yes, that was definitely the problem. We locked ourself by a code freeze period that started too early (and lasted too long). No, that wasn't the problem, it was too much changes allowed at once, rather than small simple

proposal for testing procedure of future LyX releases

2006-05-07 Thread Uwe Stöhr
This email is a proposal for a new test procedure of LyX releases. I started to use LyX when LyX 1.2 came out. While working with it I started to write my math manual which was not finished when LyX 1.3 was released. I reworked my document to cover the new features of lyX 1.3 and discovered

Re: proposal for testing procedure of future LyX releases

2006-05-07 Thread John Levon
On Sun, May 07, 2006 at 05:00:23PM +0200, Uwe Stöhr wrote: > Personally I use a test procedure for every new release of my > LyXWinInstaller. Derived from this here's my proposal for new releases > of LyX: Some time ago I started a lyx-tests CVS repository for precisely this regression-testing

Re: proposal for testing procedure of future LyX releases

2006-05-07 Thread Michael Gerz
John Levon wrote: - Test scrolling and editing (copy/paste, etc.) with a long and big document like a PHD thesis. I believe we knew about all the problems here, but released anyway. Yes, that was definitely the problem. We locked ourself by a code freeze period that started too early

Re: proposal for testing procedure of future LyX releases

2006-05-07 Thread John Levon
On Sun, May 07, 2006 at 06:04:13PM +0200, Michael Gerz wrote: > Yes, that was definitely the problem. We locked ourself by a code freeze > period that started too early (and lasted too long). No, that wasn't the problem, it was too much changes allowed at once, rather than small simple