
Wine Staging - ivank
https://wine-staging.com/
======
haddr
Wine is hell of a project. Having all those windows programs running on
linux/os x is really a huge achievement. I know that there is still a way to
go, but I really admire this herculean effort put into this project.

~~~
jpolitz
I'm always really impressed when things just work in Wine. I started using
YNAB this year and sure enough, it worked in Wine _with Dropbox integration_.
Pretty cool.

------
ianlevesque
Interesting project, it's almost like they searched through the WineHQ bug
tracker for unmerged fixes and made a huge branch with all of them. There are
certainly a lot of fixes that never make it to mainline Wine. The handful I've
been watching have gone nearly 5 years without any meaningful progress past
the initial patch. Occasionally someone will comment that the issue still
affects them. I'm not sure what the solution is, it's an unpaid project.

~~~
ZenoArrow
> "There are certainly a lot of fixes that never make it to mainline Wine."

Out of interest, why is that?

~~~
IshKebab
Lack of manpower. Improving, merging and testing a fix isn't zero-effort.

~~~
stuaxo
Alexandre Juliarde keeps a very high quality threshold for patches, which
makes sense as it's such a complicated project.

This can make the conversations quite interesting from the outside if you're
into this sort of thing.

------
0x0
Tracking fixes as .patch files in a git repository is.... an interesting way
to go about things.

~~~
roblabla
Not the first or only project to do this. Spigot, a fork of the CraftBukkit
minecraft server, uses a similar approach [0]. It allows to easily collaborate
with the upstream project (Just apply the feature's patch on current master).

[0] :
[https://hub.spigotmc.org/stash/projects/SPIGOT/repos/spigot/...](https://hub.spigotmc.org/stash/projects/SPIGOT/repos/spigot/browse)

~~~
0x0
Wouldn't it be better to just keep the changes in a branch in a fork off of
the upstream master branch? I would think that git would do a better job at
re-applying to newer releases (i.e. merging from upstream master) than what
patch(1) can do?

~~~
btown
This makes me think that automatic rebasing and test running as a service
would be an interesting product. Continuous integration of upstream changes
into your possibly proprietary downstream fork (for features or ports), with
Travis running each time.... You could avoid the problem of divergent forks!

~~~
viraptor
This is possibly the hardest version control problem I ever ran into.
Especially in projects which have a large number of changes upstream (100+
commits daily), I've only seen bad and worse solutions.

The bad one is trying to follow upstream on each commit, notifying you every
time some patch either doesn't work or doesn't merge anymore so you have to
fix it manually. This still doesn't stop the cases where the patch in itself
works, but doesn't make sense in the project anymore (some code moved around,
tests still pass, but the functionality is not reachable). You also need a
fair bit of architecture to test each of your patches with on each upstream
change.

The worse solution is taking a few days off every time a bigger release is out
and porting all patches. It saves on the continuous testing infrastructure,
but takes unknown amount of time and you may discover some functionality
simply cannot be migrated anymore. You're also likely to introduce many more
bugs with rushed development.

I've been through planning something like this on a number of projects before.
It's a lot of effort and it should be avoided as much as possible.

I think the product you describe could be actually a really good idea, but a
lot of it would have to deal with as clever annotations as possible - what
broke, when did it work the last time, who's responsible for porting, what
functionality does it provide, is it critical/optional, etc.

------
dingdingdang
I wonder what it would take to create/put-together a minimal window manager
and stripped down version of Linux wired to run Windows software as its
default mode or purpose. Would it rival ReactOS or is Wine simply too unstable
to truly serve as a "whole" OS?

~~~
bkeroack
Google "Lindows". A company tried to do exactly this circa 2001.

~~~
icebraining
It came with the added fun of having Microsoft sue them, just to have the
court say that "Windows" in the OS context is not a defensible trademark!

~~~
marrs
At which point MS settled out of court and kept Lindows in business for many
years to come.

------
shmerl
It's quite useful. I mostly use Wine staging instead of regular Wine. For
instance support for PulseAudio is nice to have. Stock Wine still doesn't have
it for some reason. And some other such things.

~~~
leni536
Pulseaudio support is definitely nice. I use stock wine and it's the main
reason I use alsa. The alsa sink of pulse and wine don't run well together for
some reason.

------
geuis
Curious, why does the link show as green on HN?

~~~
viraptor
See
[https://news.ycombinator.com/item?id=10223645](https://news.ycombinator.com/item?id=10223645)
(first link submitted from that domain)

------
metasean
For those who are wondering what exactly "a special wine version" is, it isn't
some new version of the drink, it is "a free and open source compatibility
layer software application that aims to allow applications designed for
Microsoft Windows to run on Unix-like operating systems". "Wine" stands for
"Wine Is Not an Emulator".

[https://en.wikipedia.org/wiki/Wine_%28software%29#Pipelight....](https://en.wikipedia.org/wiki/Wine_%28software%29#Pipelight.2Fwine-
compholio)

------
helb
Gentoo users: there's an USE flag for that ;) [[https://github.com/wine-
compholio/wine-staging/wiki/Installa...](https://github.com/wine-
compholio/wine-staging/wiki/Installation#-gentoo-portage)]

------
jarnix
The url of the link seems incorrect :
[https://news.ycombinator.com/from?site=wine-
staging.com](https://news.ycombinator.com/from?site=wine-staging.com)

~~~
viraptor
See
[https://news.ycombinator.com/item?id=10223645](https://news.ycombinator.com/item?id=10223645)
(click the name, not the domain name)

~~~
jarnix
ok thank you for the answer and explanation :)

------
jd3
This is awesome! building wine in pkgsrc is broken for me at the moment (clang
problems), so having a working/up to date wine build on OS X is great!

~~~
k8tte
brew install wine --devel

or

brew install wine --HEAD

~~~
jd3
a good point. I used to use homebrew but I've dedicated my time pkgsrc
proselytization, so I don't have homebrew installed anymore. I have a
fontforge patch that I need to submit upstream, and I think I just need to
install a newer gcc to get the builds to pass with pkgsrc. In the mean time I
haven't tried an i686 build, which in theory should work..

------
tomphoolery
What is the origin of "compholio"? I chuckled when I saw that for some reason.

~~~
striking
It's a person's internet handle
([http://www.compholio.com/](http://www.compholio.com/)) who wrote custom
patches for Wine that were popular before they were incorporated into the
mainline project... and not a thinly veiled Beavis and Butthead reference.

------
rottyguy
How does Wine, Mono, and Microsoft open source .Net play out?

~~~
viraptor
[http://wiki.winehq.org/Mono](http://wiki.winehq.org/Mono)

"For Wine releases 1.5.3 and later, the Wine Mono package is recommended. For
earlier versions, an official Windows release of Mono 2.10 is recommended.

Wine 1.5.6 will install Wine Mono automatically as needed."

"If you need to use Microsoft's implementation of the .NET framework, the
Microsoft runtimes can partly run on Wine."

------
resca79
In the 90 ages, as linux user, I tried many times to use it, with not great
result. But now with the virtualization I think that it lost its traction.

------
kazinator
> _Please note that our Wine Staging repository does not contain the full Wine
> source, which would be very intransparent for our users and developers.
> Instead we 're providing Wine Staging as a patchset which has to be applied
> on top of the corresponding upstream Wine version. _

Translation: we can't figure out how to use git, to _actually_ make a
transparent development stream that users can just pull: and check out to an
arbitrary commit, etc. "Let's try this without the last three commits ... git
checkout HEAD^^^ ... done".

