Kohei Yoshida <[EMAIL PROTECTED]> writes: > 1) The use of "product" and "non-product" terms seems unclear to me. > What do they mean exactly? > Hi Kohei,
a "product" version is one that has .pro suffix at the output trees (that's the default case). A "non-product" has no such suffix, and gets enabled via --enable-dbgutil at the configure line. We should rather advertise this a bit more, because people then get assertions if they break stuff horribly. ;-) > 2) IMO, requiring that the developer of the cws make the binary install > set available to the QA personnel has the following downside. > > On Linux platform, there is an issue of ABI compatibility due to gcc > versioning as well as system library dependencies. When I build on my > machine, I do build using gcc 4.1.0 and make use of external system > libraries. This means that, even if I am able to provide an > installation set for the QA personnel by uploading it to an FTP/Web > server, my install set may not run on QA person's (Linux) machine. > > To me, it is just as well workable (or better?) to check the integrity > of a cws at source code level, and have both the developer and the QA > build the same cws on both ends. I'm personally not seeing any > advantage of requiring the developer to build and provide the binary > install sets for QA, especially on Linux platform. > Yep, sounds reasonable. Would need some kind of automatism on our side, to enable more people to trigger builds. But that appears to be just another case for a (specialized) buildbot... Cheers, -- Thorsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
