On 1/8/07, Bill Medland billmedland@shaw.ca wrote:
Bill Medland (billmedland@shaw.ca) Add tests structure to odbccp32
You need to add tests for this patch to be accepted. Also, you've labeled the test suite 'error'. How many functions in odbccp32 are you planning on testing in this file? I see only SQLInstallerError and SQLPostInstallerError in the spec file, which is not enough to warrant a whole test file. Please read other test files to get a better of idea what needs to happen with these tests.
On Mon, 2007-08-01 at 12:11 -0600, James Hawkins wrote:
On 1/8/07, Bill Medland billmedland@shaw.ca wrote:
Bill Medland (billmedland@shaw.ca) Add tests structure to odbccp32
You need to add tests for this patch to be accepted. Also, you've labeled the test suite 'error'. How many functions in odbccp32 are you planning on testing in this file? I see only SQLInstallerError and SQLPostInstallerError in the spec file, which is not enough to warrant a whole test file. Please read other test files to get a better of idea what needs to happen with these tests.
Why?? I was trying to make things easier for Alexandre. If I write any tests in the patch then I need to write the code to ensure that we actually pass those tests (which we don't because we don't actually really do anything yet and then the patch ends up doing all three things; adding testing, adding the error reporting and then adding the actual function that I want to get working). My aim is: + to submit one trivial patch which adds testing; a no-brainer + to submit the code for the error stack and SQLInstallerError (so that when I add the function I want I will be able to do the error reporting straight off instead of the usual hack of "I'll do the error reporting when I get around to it in another two years time" + to submit the code for SQLGetInstalledDrivers (which is what I actually want to get done).
And why can't I have error.c? The purpose of error.c is to contain the tests of the error handling, as you surmised, so I feel that I named it well. That is two functions, as you surmised. However they constitute a well-defined subsystem of the dll so why should they not be in a separate file? How many tests? Well, to start with I envisage about 10. However as I said I believe that the measure is not the length; it is the modularity.
On 1/8/07, Bill Medland billmedland@shaw.ca wrote:
On Mon, 2007-08-01 at 12:11 -0600, James Hawkins wrote:
On 1/8/07, Bill Medland billmedland@shaw.ca wrote:
Bill Medland (billmedland@shaw.ca) Add tests structure to odbccp32
You need to add tests for this patch to be accepted. Also, you've labeled the test suite 'error'. How many functions in odbccp32 are you planning on testing in this file? I see only SQLInstallerError and SQLPostInstallerError in the spec file, which is not enough to warrant a whole test file. Please read other test files to get a better of idea what needs to happen with these tests.
Why??
What's the point of adding code that does absolutely nothing? In an open source project, there's no guarantee that you'll come back and finish what you started, though there are several other reasons why this is not allowed.
I was trying to make things easier for Alexandre. If I write any tests in the patch then I need to write the code to ensure that we actually pass those tests (which we don't because we don't actually really do anything yet and then the patch ends up doing all three things; adding testing, adding the error reporting and then adding the actual function that I want to get working).
That is what todo_wine is for. It sounds like you need to read the developer documentation at http://winehq.org/site/docs/winedev-guide/index
My aim is:
- to submit one trivial patch which adds testing; a no-brainer
- to submit the code for the error stack and SQLInstallerError (so that
when I add the function I want I will be able to do the error reporting straight off instead of the usual hack of "I'll do the error reporting when I get around to it in another two years time"
- to submit the code for SQLGetInstalledDrivers (which is what I
actually want to get done).
And why can't I have error.c? The purpose of error.c is to contain the tests of the error handling, as you surmised, so I feel that I named it well. That is two functions, as you surmised. However they constitute a well-defined subsystem of the dll so why should they not be in a separate file?
Two functions is definitely not a well-defined subsystem. They are helper functions and they don't need their own test file.
How many tests? Well, to start with I envisage about 10. However as I said I believe that the measure is not the length; it is the modularity.
Ten tests is fine, but like I said, they don't need a separate file.
On Mon, 2007-08-01 at 12:38 -0600, James Hawkins wrote:
On 1/8/07, Bill Medland billmedland@shaw.ca wrote:
On Mon, 2007-08-01 at 12:11 -0600, James Hawkins wrote:
On 1/8/07, Bill Medland billmedland@shaw.ca wrote:
Bill Medland (billmedland@shaw.ca) Add tests structure to odbccp32
You need to add tests for this patch to be accepted. Also, you've labeled the test suite 'error'. How many functions in odbccp32 are you planning on testing in this file? I see only SQLInstallerError and SQLPostInstallerError in the spec file, which is not enough to warrant a whole test file. Please read other test files to get a better of idea what needs to happen with these tests.
Why??
What's the point of adding code that does absolutely nothing? In an open source project, there's no guarantee that you'll come back and finish what you started, though there are several other reasons why this is not allowed.
I was trying to make things easier for Alexandre. If I write any tests in the patch then I need to write the code to ensure that we actually pass those tests (which we don't because we don't actually really do anything yet and then the patch ends up doing all three things; adding testing, adding the error reporting and then adding the actual function that I want to get working).
That is what todo_wine is for. It sounds like you need to read the developer documentation at http://winehq.org/site/docs/winedev-guide/index
My aim is:
- to submit one trivial patch which adds testing; a no-brainer
- to submit the code for the error stack and SQLInstallerError (so that
when I add the function I want I will be able to do the error reporting straight off instead of the usual hack of "I'll do the error reporting when I get around to it in another two years time"
- to submit the code for SQLGetInstalledDrivers (which is what I
actually want to get done).
And why can't I have error.c? The purpose of error.c is to contain the tests of the error handling, as you surmised, so I feel that I named it well. That is two functions, as you surmised. However they constitute a well-defined subsystem of the dll so why should they not be in a separate file?
Two functions is definitely not a well-defined subsystem. They are helper functions and they don't need their own test file.
How many tests? Well, to start with I envisage about 10. However as I said I believe that the measure is not the length; it is the modularity.
Ten tests is fine, but like I said, they don't need a separate file.
Ah, heck. I submit one patch and get the usual deathly silence as to whether it has been rejected outright or whether it is being put to one side for a few days.
So I try splitting it up so that Alexandre's decisionmaking is easier
And this is what I get for it.
I have better things to do with my time.
I will stop trying to simplify things.
If Alexandre wants to accept the version I submitted on Friday, fine. If not then it;s no sking off my nose.
Bye
(Yes, I am upset)
On 1/8/07, Bill Medland billmedland@shaw.ca wrote:
On Mon, 2007-08-01 at 12:38 -0600, James Hawkins wrote:
On 1/8/07, Bill Medland billmedland@shaw.ca wrote:
On Mon, 2007-08-01 at 12:11 -0600, James Hawkins wrote:
On 1/8/07, Bill Medland billmedland@shaw.ca wrote:
Bill Medland (billmedland@shaw.ca) Add tests structure to odbccp32
You need to add tests for this patch to be accepted. Also, you've labeled the test suite 'error'. How many functions in odbccp32 are you planning on testing in this file? I see only SQLInstallerError and SQLPostInstallerError in the spec file, which is not enough to warrant a whole test file. Please read other test files to get a better of idea what needs to happen with these tests.
Why??
What's the point of adding code that does absolutely nothing? In an open source project, there's no guarantee that you'll come back and finish what you started, though there are several other reasons why this is not allowed.
I was trying to make things easier for Alexandre. If I write any tests in the patch then I need to write the code to ensure that we actually pass those tests (which we don't because we don't actually really do anything yet and then the patch ends up doing all three things; adding testing, adding the error reporting and then adding the actual function that I want to get working).
That is what todo_wine is for. It sounds like you need to read the developer documentation at http://winehq.org/site/docs/winedev-guide/index
My aim is:
- to submit one trivial patch which adds testing; a no-brainer
- to submit the code for the error stack and SQLInstallerError (so that
when I add the function I want I will be able to do the error reporting straight off instead of the usual hack of "I'll do the error reporting when I get around to it in another two years time"
- to submit the code for SQLGetInstalledDrivers (which is what I
actually want to get done).
And why can't I have error.c? The purpose of error.c is to contain the tests of the error handling, as you surmised, so I feel that I named it well. That is two functions, as you surmised. However they constitute a well-defined subsystem of the dll so why should they not be in a separate file?
Two functions is definitely not a well-defined subsystem. They are helper functions and they don't need their own test file.
How many tests? Well, to start with I envisage about 10. However as I said I believe that the measure is not the length; it is the modularity.
Ten tests is fine, but like I said, they don't need a separate file.
Ah, heck. I submit one patch and get the usual deathly silence as to whether it has been rejected outright or whether it is being put to one side for a few days.
So I try splitting it up so that Alexandre's decisionmaking is easier
And this is what I get for it.
I have better things to do with my time.
I will stop trying to simplify things.
If Alexandre wants to accept the version I submitted on Friday, fine. If not then it;s no sking off my nose.
Bye
(Yes, I am upset)
It's not really worth getting upset about. Developer's patches get rejected sometimes...it happens. That's a good thing though, as it keeps the Wine code base free of hacks and bad code. The best thing you can do is to be flexible and take the advice of fellow developers. As a community, it's up to everyone to comment on patches coming in and do a pre-screen to lighten the load on Alexandre. I know that he won't accept this patch as it is, so I gave you advice on how to make it acceptable.
-
Bill Medland -
James Hawkins