Re: bricscad goes native
On 05/26/2010 12:17 AM, Dmitry Timoshkov wrote: > Scott Ritchie wrote: > >> I believe a reasonable alternative is to communicate directly with the >> distro Wine packager and have them test your app against whatever >> version of Wine they plan on shipping. That way you don't miss out on >> good changes in Wine either. > > That's unreasonable to put the testing burden of a commercial application > to a 3rd party that's not a part of QA or a support team. Obviosuly you can't > test all the aspects of the application, or even don't know how to do that, > or testing requires additional data or tools. > The idea is for the distro to become part of the QA process itself. By being forward about what version of Wine to ship (eg only the stable releases) the vendor can greatly narrow their testing focus. If multiple distros are using the same stable Wine version, that testing burden gets shared -- assuming the vendor even cares about more than a couple distros. This is, of course, assuming it's reasonable to stick to Wine's stable releases. That's only useful if they're relatively frequent - a year and a half was a bit too much time. I'm also, of course, assuming a distro that actively cares about Wine enough to devote some sort of QA resources towards it. Thanks, Scott Ritchie
Re: bricscad goes native
On Wed, May 26, 2010 at 6:44 AM, Scott Ritchie wrote: > On 05/25/2010 11:39 AM, Dan Kegel wrote: >> On Tue, May 25, 2010 at 10:58 AM, Avery Pennarun wrote: In either case, you probably want to bundle the Wine runtime with the app rather than trying to run against whatever Wine the user has. >>> >>> I guess this is because wine is such a moving target? It seems a >>> shame to bundle a copy of wine with every single app, although I can >>> definitely see how commercial products would want to do that to >>> improve repeatability. One would hope that all the automated testing >>> wine is doing lately would reduce the need for this kind of thing >>> eventually. >> >> Commercial apps should continue bundling their own wine no matter >> what we do, I think. It'll be a while before they can count >> on everyone already having a wine installed that can handle their app. >> And security concerns might prevent wine from being installed by default >> on some distros. >> >> > > I believe a reasonable alternative is to communicate directly with the > distro Wine packager and have them test your app against whatever > version of Wine they plan on shipping. That way you don't miss out on > good changes in Wine either. > > In essence, you come to me with your app, have me verify the packaging > and put it in the archive (or store if it's a paid app), and have it > depend on the system Wine. Then I check it against every Wine version > that gets into an official Ubuntu release. > > Thanks, > Scott Ritchie They'd have to contact 300+ Linux distributions every +/- 6 months to ensure their application works on every version of every distribution - and that's only if every user uses the single Wine version that the distribution version originally shipped with. Maybe each distribution should instead adhere to LSB standards and pre-install the Autopackage/Zeroinstall runtimes which would allow third parties to package their own stuff and have it work out of the box on every distribution? Zeroinstall for example lets you parallel install several versions of the same package - so you could have a Wine version for a specific Winelib application and another Wine version for every other application. Thank you Damjan Jovanovic
Re: bricscad goes native
Scott Ritchie wrote: > I believe a reasonable alternative is to communicate directly with the > distro Wine packager and have them test your app against whatever > version of Wine they plan on shipping. That way you don't miss out on > good changes in Wine either. That's unreasonable to put the testing burden of a commercial application to a 3rd party that's not a part of QA or a support team. Obviosuly you can't test all the aspects of the application, or even don't know how to do that, or testing requires additional data or tools. -- Dmitry.
Re: bricscad goes native
On 05/25/2010 11:39 AM, Dan Kegel wrote: > On Tue, May 25, 2010 at 10:58 AM, Avery Pennarun wrote: >>> In either case, you probably want to bundle the Wine runtime >>> with the app rather than trying to run against whatever Wine >>> the user has. >> >> I guess this is because wine is such a moving target? It seems a >> shame to bundle a copy of wine with every single app, although I can >> definitely see how commercial products would want to do that to >> improve repeatability. One would hope that all the automated testing >> wine is doing lately would reduce the need for this kind of thing >> eventually. > > Commercial apps should continue bundling their own wine no matter > what we do, I think. It'll be a while before they can count > on everyone already having a wine installed that can handle their app. > And security concerns might prevent wine from being installed by default > on some distros. > > I believe a reasonable alternative is to communicate directly with the distro Wine packager and have them test your app against whatever version of Wine they plan on shipping. That way you don't miss out on good changes in Wine either. In essence, you come to me with your app, have me verify the packaging and put it in the archive (or store if it's a paid app), and have it depend on the system Wine. Then I check it against every Wine version that gets into an official Ubuntu release. Thanks, Scott Ritchie
Re: bricscad goes native
On Tue, May 25, 2010 at 10:58 AM, Avery Pennarun wrote: >> In either case, you probably want to bundle the Wine runtime >> with the app rather than trying to run against whatever Wine >> the user has. > > I guess this is because wine is such a moving target? It seems a > shame to bundle a copy of wine with every single app, although I can > definitely see how commercial products would want to do that to > improve repeatability. One would hope that all the automated testing > wine is doing lately would reduce the need for this kind of thing > eventually. Commercial apps should continue bundling their own wine no matter what we do, I think. It'll be a while before they can count on everyone already having a wine installed that can handle their app. And security concerns might prevent wine from being installed by default on some distros.
Re: bricscad goes native
On Tue, May 25, 2010 at 1:47 PM, Dan Kegel wrote: > On Tue, May 25, 2010 at 10:21 AM, Avery Pennarun wrote: the winelib version was quite a flop too many problems >>> >>> Indeed. One should never release naked winelib apps. >>> Instead, one should bundle the windows version >>> with a private copy of Wine, like Picasa (and >>> now at least one other app) have done. >> >> Why is that better? What's the point of winelib then? > > Winelib is mostly useful when recompiling a windows app to > run on a non-x86 platform (where win32 compilers aren't available). Ah, that makes sense. > In either case, you probably want to bundle the Wine runtime > with the app rather than trying to run against whatever Wine > the user has. I guess this is because wine is such a moving target? It seems a shame to bundle a copy of wine with every single app, although I can definitely see how commercial products would want to do that to improve repeatability. One would hope that all the automated testing wine is doing lately would reduce the need for this kind of thing eventually. Thanks, Avery
Re: bricscad goes native
On Tue, May 25, 2010 at 10:21 AM, Avery Pennarun wrote: >>> the winelib version was quite a flop too many problems >> >> Indeed. One should never release naked winelib apps. >> Instead, one should bundle the windows version >> with a private copy of Wine, like Picasa (and >> now at least one other app) have done. > > Why is that better? What's the point of winelib then? Winelib is mostly useful when recompiling a windows app to run on a non-x86 platform (where win32 compilers aren't available). You could also use it to build a linux plugin for a windows app running on Wine. In either case, you probably want to bundle the Wine runtime with the app rather than trying to run against whatever Wine the user has. - Dan
Re: bricscad goes native
On Mon, May 24, 2010 at 6:46 PM, Dan Kegel wrote: > Max wrote: >> the winelib version was quite a flop too many problems > > Indeed. One should never release naked winelib apps. > Instead, one should bundle the windows version > with a private copy of Wine, like Picasa (and > now at least one other app) have done. Why is that better? What's the point of winelib then? Thanks, Avery
Re: bricscad goes native
Max wrote: > the winelib version was quite a flop too many problems Indeed. One should never release naked winelib apps. Instead, one should bundle the windows version with a private copy of Wine, like Picasa (and now at least one other app) have done.
Re: bricscad goes native
Il 24/05/2010 02:39, Dan Kegel ha scritto: I've long predicted that companies might use Wine for a while to ship Linux-compatible products, and later switch to a native build once they know they have users. Well, now we have at least one example of this: Bricscad (see http://www.bricsys.com ). This is a *good* thing, and validates somewhat the idea that Wine is a catalyst to enable a global shift from Windows to Linux. mh... I'm following bricscad development and I'd say that the winelib version was quite a flop too many problems and didn't have the expected success. The linux native version is (imho) a courageus effort of Bricsys team to give Linux something that was missing since too long time :-) Pity for the choice of wxwidgets, indeed it's becoming too old style, imho, and the portability level isn't that easy. Ciao Max
bricscad goes native
I've long predicted that companies might use Wine for a while to ship Linux-compatible products, and later switch to a native build once they know they have users. Well, now we have at least one example of this: Bricscad (see http://www.bricsys.com ). This is a *good* thing, and validates somewhat the idea that Wine is a catalyst to enable a global shift from Windows to Linux.
