[Wine] Installing The Witcher, GOG edition

Frédéric Delanoy frederic.delanoy at gmail.com
Thu Dec 19 19:22:01 CST 2013

On Wed, Dec 18, 2013 at 4:00 PM, Martin Gregorie <martin at gregorie.org> wrote:
> On Wed, 2013-12-18 at 14:38 +0100, Hartmut Figge wrote:
>> Regarding regressions, i am compiling SeaMonkey, much more code than
>> wine, nearly daily. Unless there is a bustage. Currently there is one
>> since 5 days.
>I'm not as bothered if a developer build breaks or fails regression
>tests, though IMHO changes that do either shouldn't be committed, as I
>am if a release candidate gets published while its still failing
>regression tests.
>> Regressions do occur there and it takes time to fix them. And there is
>> the issue with using much of the code from Firefox and Thunderbird,
>> which changes often and has the tendency to damage SeaMonkey. Sigh.
> Indeed, but:
> (1) devs that commit code that breaks a compile or fails regression
> testing deserve a warning followed, if needed, by having their commit
> privileges revoked. Yes, I know they may be volunteers, but does any
> project need devs that make such gross mistakes

Checking for regressions for every commit, given the amount of work
needed, isn't feasible: there are a lot of windows programs in
existence, so regressions inevitably happen... you can't test them all
for every commit, and it can be very difficult to automate, if
possible at all.

There are a lot of unit tests in the code though, which are run for
every commit. And FYI non-compiling code isn't committed...
And only the project leader has commit rights.

Kicking developers out for every regression... If one would do what you
suggest, I guess you would be the only Wine developer remaining?!?
Good way to kill a project...

When regressions are reported (http://bugs.winehq.org), they are
usually fixed quickly, especially when they are reported quickly after
they appear.

Remember 1.7.x series are *development* releases... regressions can
happen e.g. when someone adds a new dll: some programs which would
work previously because they workaround the missing DLL might not work
when that (stub) DLL is added.

If you want to avoid regressions at all costs, stay with stable branch
(1.6.x). Use development versions at your own risk.

> (2) publishing a version that fails regression or has incomplete changes
> testing is a really good way to destroy its reputation. Gnome 3 anybody?

IIRC the issues with Gnome 3 was released as a stable version with a
lot of bugs. Wine development releases ARE NOT stable versions.

>> In wine itself i had the luck to meet regressions very seldom. And
>> regressions *are* fixed. See the release notes of wine-1.6.1 from Alexandre.
> I've regularly seen apps that initially ran OK gradually develop runtime
> faults and eventually stop running altogether. My apps weren't changing
> at all, but the current Wine version certainly was.

Nobody forces you to upgrade your Wine version. You can keep an old
Wine version for some apps, and even distinct versions on the same
system (as a developer, this shouldn't be difficult for you).

Moreover, if you find a regression, please report it on
http://bugs.winehq.org/. Not everybody runs the same applications as
you do, again checking every app in existence is just unrealistic.

>That certainly looks
> like a failing in the regression test system to me: I don't tolerate
> that in my own code, so why should I put up with it from others?

>> Maybe there exists a lack of developers and likely they are all
>> volunteers which cannot be forced.
> As I said above, volunteer dev or not, does any project need devs that
> don't follow the project standards and procedures?
> Martin

It seems you don't know much about Wine development procedures, if at
all. Please inquire about them before criticizing so harshly.
They do exist, and are very much enforced. Look e.g. on the wiki for more

Feel free to suggest improvements on Wine development
standards/procedures on the wine-devel mailing list, or on IRC



More information about the wine-users mailing list