> B. Obtain commitments for work
> I would like to start having people indicate
> whether or not they are working or will be working on a
> task.
>
> For our part, CodeWeavers is going to volunteer to do the
> jobs no
> one else wants (like QA and documentation).
> Really we will,
> let me just twist a few more arms...<g>
[snip]
Personally I'm intrested in and are working on "meta-QA"
and "meta-documentation", but not some much actual QA
and actual documentation.
In other words to write tools like winapi_check and the
new not yet released winapi_test.
winapi_check have a lot of options that a turned off by default
since they produce to much output. Of course most reported
things are not actual bugs but potential bugs but there
is not possible for me to tell which is which, since it either
is to complicated or the information required is not possible
to get from the source even in theory.
One example of this is the signed/unsigned mismatch in over 200
Win16 API functions. In most of these cases it isn't a real bug
since the most significant bit in the 16-bit word is never used
and can never be set and thus can never be wrongly sign extended.
But there might be real bugs hidden in all these output,
they must _all_ be fixed in order to nail down the real ones.
Run "winapi_check --argument-kind=word,s_word" to see them.
There are also a lot of functions that lack prototypes,
which is bad for WineLib applications.
Run "winapi_check --headers" to see them.
What I'm trying to point out is that tools like winapi_check
is very useful in finding bugs actual or potential, bug actually
fixing them is very boring that why I haven't done it except
on to a small degree.
So if you assign somebody to do the boring work of fixing the potential
(in the prototype case always real) bugs reported by winapi_check
and in the future winapi_test. I'm prepare to help you by
implementing more checks. Feel free to suggest new ones.
Note, be very careful, do not trust the output of winapi_check,
in some case I might have made mistakes both logical and
implementation wise in some case whether it is bug or not
depend on the documentation of the function, so read it
_carefully_ before deciding whether winapi_check is correct or not.
But I probably needn't had to said that since that should be
obvious to all programmers.
In short, if you do QA, I will do meta-QA. :-)
> 4. After the requirements for release have been met,
> declare Wine ready for release.
> (is this point decided by consensus? Fiat by Alexandre?)
IMHO Alexandre decides. I'm not a believer in voting about it.
> * some kind of automated regression testing, at least for
> non-graphical APIs (Alexandre Julliard)
I have meantion earlier I'm working on a new project winapi_test
that does brute force testing of the API:s.
What it does is that is generates a Windows (WineLib) application
that can be compiled and run under both Wine and Windows and
produces logs that can be compared and bugs fixed.
Currently it only implements a NULL test where all functions
are called with all NULL arguments, but even this very simple
test have found a _lot_ of errors. I have already used it to
fix a few of them (already in the CVS).
> Not absolutely required for release IMHO:
>
> * Many sample applications compile and work with Winelib
> 'out of the
> box' (along the lines of the work that Francois Gouget
> is doing).
> (Jeremy White) (Okay, Marcus, I pushed it down to here,
> but I reserve the option to make this happen anyway <g>)
Personally I think it is very important, since I think a 1.0 will
make many companies start investigating whether a port of their
software is realistic or not.
