> Your argument for beta-testing is void, because, for a beta, I want
> to have the source available. Thus you distribute the source, 
> I compile, and get back to you with comment on behavior and code.
> Testing a black box is not a good testing for code!
> Dissiminating time-unlimited beta is not a good thing either!

Er... beta testing IS black-box testing.  Beta testing is done by 
end-users who volunteer to take an early release.  And in the 
commercial world even alpha [in-house] testing is done mainly by teams 
of testers who normally have very limited access to the source code 
(and probably wouldn't understand it anyway). Only unit testing and 
early integration testing is [supposed to be :) ] done by developers.

Admittedly, black-box testing often makes it harder for the developer 
to reproduce a reported bug, but at least the bugs are being found and 
(hopefully) reported.  Testing also tends to be less 'structured' which 
means the testers will be trying many scenarios that the developer 
would not necessarily consider when testing against their source code.

Black-box testing has been demonstrated to be a valid and worthwhile 
technique, but is not intended to be used exclusively.

By the way, I've been following all the discussion on this topic, and 
am enthusiastic about the future of SMSQ/E as long as the project is 
well managed.  I do however believe there is room for a limited amount 
of divergence of versions, to support different hardware platforms 
without having to stick to the Lowest Common Denominator approach, e.g. 
the FPU/No FPU situation.

Ian.

> -----Original Message-----
> From: jerome.grimbert 
> Sent: 26 March 2002 15:47
> To: ql-users
> Cc: jerome.grimbert
> Subject: Re: [ql-users] SMSQ/E license criticisms
> 
> 
> Dexter makes some magical things to make me read
> } Hi all,
> } 
> } I'm not saying anything here as personal opinion - I am 
> playing devil's 
> } advocate for the sake of creating a little controversy, which will 
> } hopefully result in some discussion. At the moment there is 
> too much 
> } agreement. :o)
> 
> Ok, let's see... It's just my point-of-view/feeling.
> 
> } The decision to have two official sellers of SMSQ/E is 
> flawed. It prevents 
> } growth to not have a clear way for additional people to 
> become resellers. 
> } If there isn't a way for people to become resellers, it's 
> also probably 
> } illegal. There should at least be a procedure for one 
> person in each 
> } country/territory to apply and be accepted as an official reseller.
> 
> That's easily answered by specifying either that:
>   - Reseller must be directly nominated by Tony Tebby.
>   - a would-be-Reseller must get clearance from the college 
> of actual Resellers.
>     the procedure for the college of Reseller is up to them. 
>     In case of conflict, the coordinator or Tony Tebby get 
> the final word.
> 
> } 
> } The decision to not allow any charging for sources is being 
> rationalised 
> } by you folks as a good thing (taxes, etc). It forces the 
> sources to be 
> } distributed by some free means only, ie the internet, and 
> prevents it 
> } being distributed by PB/shareware libraries unless they 
> make special 
> } arrangements. These arrangements more than double the 
> length of time it 
> } would take a recipient to get a copy of the sources.
> 
> Outdated argument, might has been valid ten years ago.
> Moreover, personnaly speaking, as I'm still the QLCF librarian, 
> French people could get free access to the sources from me the same
> way as they get access to the QLCF library (even more easily,
> because accessing the QLCF library required to be on the right list!).
> I would not have to make any change to my management for 
> these sources.
> } 
> } The decision to not allow distribution of binaries is very 
> restrictive to 
> } the point of being obstructive. I would propose the 
> refinement to the 
> } license, stating object code/binaries cannot be distributed 
> to the general 
> } public, and may only be shared at no cost for the purposes of beta 
> } testing, or for producing custom versions for specific 
> hardware. It would 
> } otherwise restrict development and, combined with the 
> clause mentioned 
> } above, testing, of the code.
> 
> The only way to force fancy developpers to share their code 
> is to forbid
> the distribution of binary. This way, code related to new hardware is
> forced to go back to the coordinator for inclusion in the main code.
> It is also the only means to have the reseller doing their work.
> Otherwise, Just Imagine: I make a custom version for some hardware,
> based on version 3.01. I distributed it worldwide. Then 
> official version
> move on up to 3.30 (with lot of nice enhancements), and either:
>  - I get hassle by my customers to update and either:
>     + I do it (and everybody is happy)
>     + I try to do it but fail du to a major incompatibility 
> in my old design,
>       and customers get stucks.
>     + I say 'f**k up', and customers get stucks.
>  - I cleverly disappeared or loose my code: customers get stucks! 
>      
> Whereas, if the reseller are responsible of the binary distribution,
>  I could have simply given to the coordinator the patched source code,
> and new improvements get available to my customer. The burden 
> of the price 
> is dealed by the reseller.
> What I'm not yet confortable with is the 'pay-me-option' for 
> my source if
> it is not free and how to keep the main distribution of source. There
> must be some priviledged people (with the relevant hardware 
> for test) which
> must be able to generate the binary and test it. But that's 
> the problem
> of the coordinator.
> 
> Your argument for beta-testing is void, because, for a beta, I want
> to have the source available. Thus you distribute the source, 
> I compile,
> and get back to you with comment on behavior and code.
> Testing a black box is not a good testing for code!
> Dissiminating time-unlimited beta is not a good thing either!
> 
> } 
> } If only the official tree can be sold, how does a hardware 
> manufacturer 
> } who produces a custom version of SMSQ/E for XXX hardware 
> include it in 
> } ROM? He can offer to make payment of a license fee, but under this 
> } license, it doesn't matter, it can't be distributed in 
> binary form, or for 
> } a fee. This removes any incentive for a developer to 
> actually adapt SMSQ 
> } to specific hardware, forcing us to stay with the hardware 
> we already 
> } have.
> 
> He should provide its sources to the coordinator, 
> Get the status of Reseller (see first point) or buy them the 
> needed binary
> for the customer or just refers its customer to the Resellers.
> 
> Just my opinion.
> 


Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

Reply via email to