TED],
[EMAIL PROTECTED]
Subject: Re: Road to 0.9
03/21/02
03:37
On Thursday 21 March 2002 02:21, you wrote:
> This looks awesome. I can set up a machine that tests the Office 2000
> apps on a daily basis with this.
>
> I'm wondering about your failstrings though. Will wine with no
> debugmsg's print that line? Won't it just print
> "Seg Fault Occurred" ?
>
At
>
> >Michael Cardenas
>
> ><[EMAIL PROTECTED]>
> >ndows.com>
On Wednesday 20 March 2002 15:04, you wrote:
> --- Francois Gouget <[EMAIL PROTECTED]> wrote:
> > On Wed, 20 Mar 2002, Yven Leist wrote:
> > > On Tuesday 19 March 2002 23:47, Michael Cardenas
> > wrote:
> > > > Can you pick up wine and compile it on a
[...]
> >I think that doing it each time A
On Wednesday 20 March 2002 18:56, you wrote:
> Well, that's great. If you do write the script, please post it here for
> others to use. If I write it, I'll do the same.
>
something like this might be enough:
#!/bin/bash
WINECVS="/usr/src/wine"
CONFOPTS="--prefix=/usr"
WINEOPTS=""
TESTAPPS="app1
This looks awesome. I can set up a machine that tests the Office 2000
apps on a daily basis with this.
I'm wondering about your failstrings though. Will wine with no
debugmsg's print that line? Won't it just print
"Seg Fault Occurred" ?
Yven Leist wrote:
>On Wednesday 20 March 2002 18:56, you
Well, that's great. If you do write the script, please post it here for
others to use. If I write it, I'll do the same.
Yven Leist wrote:
>On Wednesday 20 March 2002 02:12, you wrote:
>
>>The problem with only testing releases is that so many patches go into a
>>release, that you won't know wha
On Wednesday 20 March 2002 02:12, you wrote:
> The problem with only testing releases is that so many patches go into a
> release, that you won't know what patch broke your app.
>
> I think the real problem is, what would your cron job do after the "wine
> {my app}" stage?
>
> how about doing a
>
> Yven, could you put information about the application
> to the Application Database
> (http://wine.codeweavers.com/appdb/)?
> It would be also great if you could maintain
> information about these applications there, put nice
> screenshots, detailed description etc. This won't take
> a lot of yo
--- Francois Gouget <[EMAIL PROTECTED]> wrote:
> On Wed, 20 Mar 2002, Yven Leist wrote:
>
> > On Tuesday 19 March 2002 23:47, Michael Cardenas
> wrote:
> > > Can you pick up wine and compile it on a
> daily/weekly basis and let us
> > > know when/if your apps break?
> > >
> > Yes, definitely. I
Francois Gouget wrote:
>On Tue, 19 Mar 2002, Michael Cardenas wrote:
>
>The problem is that if the application does not crash it is likely to
>stay up indefinitely waiting for you to do something...
> Rather than automating the testing, it may be better to automate the
>process of updating
On Tue, 19 Mar 2002, Michael Cardenas wrote:
> The problem with only testing releases is that so many patches go into a
> release, that you won't know what patch broke your app.
Well, you only have about two weeks worth of patches to check. It's
already better than the current situation where
The problem with only testing releases is that so many patches go into a
release, that you won't know what patch broke your app.
I think the real problem is, what would your cron job do after the "wine
{my app}" stage?
how about doing a
"wine {my app} > myapp.log && tail -f myapp.log | grep '
Can you pick up wine and compile it on a daily/weekly basis and let us
know when/if your apps break?
Yven Leist wrote:
>On Tuesday 19 March 2002 16:14, James Hatheway wrote:
>
>>>C. Testing apps? I have no real idea what you mean.
>>>
>>Sorry, I guess I should have been more clear, I just typed
><[EMAIL PROTECTED]>
>ndows.com> cc:
>
> Sent by:Subject: Re: Road to 0.9
>
On Tuesday 19 March 2002 16:14, James Hatheway wrote:
> > C. Testing apps? I have no real idea what you mean.
>
> Sorry, I guess I should have been more clear, I just typed in
> word for word my brief shorthand notes :)
>
> Basically, the idea that we had was the concept of getting users
> to volu
Eric Pouech <[EMAIL PROTECTED]> writes:
> and you can tell which fields are valid from the protocol version
> number I assume
The missing fields are filled with zero so we shouldn't even need
that.
> another point: as of today, at startup, the link to wineserver
> isn't done when the protocol v
> It's OK to add fields to existing requests, this doesn't break
> backwards compatibility. In fact that's one of the reasons for the
> fixed request size.
and you can tell which fields are valid from the protocol version
number I assume
another point: as of today, at startup, the link to wines
On Tue, Mar 19, 2002 at 10:16:12AM -0800, Michael Cardenas wrote:
>
>
> Yeah, I wanted to ask Alexandre at the conference how regression testing
> is a requirement. We need some specific numbers here. How many tests
> does he expect us to have? 10? 100?
I think we decided on a stable framewor
On Tue, 19 Mar 2002, Andriy Palamarchuk wrote:
> --- James Hatheway <[EMAIL PROTECTED]> wrote:
> > For Wine 0.9
> > =
> > * Dll seperation (being able to build on windows
> > being a "Wish") -
> >Dimi, Patrick, Steven, Alexandre, Scott
> > * Address Space Seperation - Alexandre
> > *
On Tue, 2002-03-19 at 12:57, Dimitrie O. Paun wrote:
> On March 19, 2002 12:48 pm, Andreas Mohr wrote:
> >
> > > The point is not to freeze the protocol completely, it will clearly
> > > continue to evolve even after 1.0. The idea is that once the protocol
> > > is declared frozen all future chan
On Tue, 2002-03-19 at 12:15, Michael Cardenas wrote:
>
>
> I think this will really bring us a long way to having a stable wine.
>
> Does anyone besides lawson have a pet application that they use all the
> time?
FWIW, Just about every FoxPro v5 or v6 -based app that I try behaves the
same.
Eric Pouech <[EMAIL PROTECTED]> writes:
> that's why I think we should clearly look at it now... what bugs me
> is the server request which only partially implement a feature so,
> if we freeze them now, we'll have to add another request, which will
> be a subset of the existing one in order to
I think this will really bring us a long way to having a stable wine.
Does anyone besides lawson have a pet application that they use all the
time?
Any volunteers?
James Hatheway wrote:
>>C. Testing apps? I have no real idea what you mean.
>>
>
>Sorry, I guess I should have been more clear,
Yeah, I wanted to ask Alexandre at the conference how regression testing
is a requirement. We need some specific numbers here. How many tests
does he expect us to have? 10? 100?
James Hatheway wrote:
>>>* Regression Testing - Francois, Andridy, Patrick,
>>>Dimi, Andi, Steven
>>>
>>Hmm, Regre
On March 19, 2002 12:48 pm, Andreas Mohr wrote:
>
> > The point is not to freeze the protocol completely, it will clearly
> > continue to evolve even after 1.0. The idea is that once the protocol
> > is declared frozen all future changes are done in a way that preserves
> > backwards compatibilit
On Tue, Mar 19, 2002 at 09:22:42AM -0800, Alexandre Julliard wrote:
> Andreas Mohr <[EMAIL PROTECTED]> writes:
>
> > In fact I raised my eyebrows on that statement of him, too.
> >
> > There's probably a lot of NT object stuff that's not 150% implemented yet,
> > I think.
> > And if the wineserv
Andreas Mohr <[EMAIL PROTECTED]> writes:
> In fact I raised my eyebrows on that statement of him, too.
>
> There's probably a lot of NT object stuff that's not 150% implemented yet,
> I think.
> And if the wineserver protocol isn't independent from such changes
> (I dunno about that), then it ce
On Tue, Mar 19, 2002 at 10:09:59AM -0500, James Hatheway wrote:
> > > * Wine Server Protocols (DONE)
> > it this really done ? I still have some enhancements
>
> I think you better send an email to Alexandre then, because he said at the
> conference that "it (Wineserver protocol) is basically fi
The specific goal was to clone Lawson 50 times,
and have each clone pick up an application.
On Tue, 2002-03-19 at 09:14, James Hatheway wrote:
> > C. Testing apps? I have no real idea what you mean.
>
> Sorry, I guess I should have been more clear, I just typed in
> word for word my brief shor
> C. Testing apps? I have no real idea what you mean.
Sorry, I guess I should have been more clear, I just typed in
word for word my brief shorthand notes :)
Basically, the idea that we had was the concept of getting users
to volunteer to "own" an app, ie. responsible for yelling when
we break
> > * Regression Testing - Francois, Andridy, Patrick,
> > Dimi, Andi, Steven
>
> Hmm, Regression Tests development will never finish.
> Can you define any specific goal for the regression
> tests you want to accomplish for 0.9?
I believe the goal from Alexandre was that he just wanted
the frame
> > * Wine Server Protocols (DONE)
> it this really done ? I still have some enhancements
I think you better send an email to Alexandre then, because he said at the
conference that "it (Wineserver protocol) is basically finished, we just
need to formally freeze it" (or something like that, that
--- James Hatheway <[EMAIL PROTECTED]> wrote:
> For Wine 0.9
> =
> * Dll seperation (being able to build on windows
> being a "Wish") -
>Dimi, Patrick, Steven, Alexandre, Scott
> * Address Space Seperation - Alexandre
> * Window Management - Ulrich, Mike, Alexandre
> * Wine Server Pro
James Hatheway wrote:
> Hi everyone,
[Snip]
>
>
> The other keypoint that was brought up was that: we need to drive
users in and make it easy
> for them to help with (A) Docs, (B) Bugs, and (C) Testing apps
>
>
> -James
>
As a _not_to_bright_ user of wine I would like to comment on the
> * Wine Server Protocols (DONE)
it this really done ? I still have some enhancements
- one has already be sent for improving toolhelp process snapshots
(btw, Alexandre didn't commit it yet, even if two versions of it
have been provided - the second by Andi -. Is this related ?)
- CreateProce
Hi everyone,
I just got back from sunny San Diego last night to not-so-sunny
Ottawa, where I seem to have been just in time to catch a snow
storm, lucky me!
As I said I would do at the conference, I am posting notes on the
road to Wine 0.9 (tasks that Alexandre requires to consider WINE
at the 0
37 matches
Mail list logo
