Wine Project Frustration and Forking 470
Elektroschock writes "Wine attempts to implement the Windows API layer on Linux. There are some limitations and an important one is the missing DIB engine, bug 421. Chris Howe comprehends the dissatisfaction of core developers with the arbitrary project governance: 'Sorry to sound like a stuck record but the Wine website still lists "write a DIB engine" as a requirement, and every time someone does, the patches disappear down a hole because they're "not right." Someone document what "would be right," or take "write a DIB engine" off the list. I'd love to have a go at documenting it myself, but I don't have the time to reverse engineer it from a few years' worth of rejected solutions.' The latest attempt of Massimo Del Fedel satisfied all requirements set previously for the long standing bug 421, and his optional engine seems to work fine by all Wine quality standards. He seems to be extraordinary stubborn and insusceptible to mobbing. Usually it is extremely frustrating for developers when the goalpost is constantly moved. When is the right time for project members to fork when their chief maintainer does not respond anymore or pursues an adverse commercial agenda?"
When? (Score:5, Insightful)
When is the right time for project members to fork when their chief maintainer does not respond anymore or pursues an adverse commercial agenda?
I think you may have your answer. If a couple people agree with you, why don't you draft an email to the project maintainer with your concerns and the signatures of the other people? If he doesn't answer or you're not satisfied with his answer, I think forking the project should definitely be on the table.
DIB engine (Score:3, Insightful)
you should probably look into using X-render, which is designed for this (check cairo for instance)
Re:When? (Score:5, Insightful)
To be honest, Forking is only really possible once enough of the right people get mad enough with the project, and, by that time, it's probably about time to fork anyway.
Take Amarok, for example. That situation practically begs for a fork, but it hasn't happened yet (AFAIK) because people aren't motivated or organized enough to bother with maintaining a new version, so the project remains unforked.
If you can get enough people organized enough to start and maintain a separate version, especially of something as large and difficult as WINE, that's probably reason enough to go forward.
What is more frustrating... (Score:5, Insightful)
...is that people continue to purchase software for Windows and waste their time attempting to make it run perfectly in Linux with a Windows API reimplementation, pretendulator, or whatever you want to call it.
I've been using Linux for 10 years now. During that time I've seen several small business that I've supported with purchases rise with Linux on the desktop and fall as the whims of Linux users move towards pretendulation of Windows software.
As long as it is acceptable to ship a product for Windows without seeing a drop-off in sales, people will continue to develop for Windows instead of Linux. Do not buy Windows products if you want to see them in Linux.
Learn from the unions, buy software made for Linux native if you want more of it. Continue to support businesses who do not support you and see desktop support for your operating system dwindle.
About forking (Score:5, Insightful)
Why is it that when someone is pondering on forking a project, quite often we see these questions asked? Is the OSS community so polite that we have to ask permission from peers to fork a project? Why not just fork it and see, if the project takes off? Or is it about insecurity? Are we just afraid of negative feedback from anti-forking people?
Re:When? (Score:5, Insightful)
Even then, maintaining momentum is of critical importance. When X.org forked from the XFree86 tree, a great deal happened very quickly. However, in the latter half of 2007, development stagnated, something that was mentioned on at least one mailing list (I can't find it now for some reason). IIRC, part of the reason was simply that not enough development time was being spent on it, because people had other things on their plates.
It made for some frustrating times for Fedora 9 users, as nVidia refused for a while to release a driver for beta version of X, and F9 was released in May 2008 without a proper release version of X.org, that project still being stuck at 1.4.99, with the 1.5.0 release not happening until September, by which time the Fedora 10 beta had already been released. F9's development plan had been built in part around the expected timing of the X.org 1.5 release expected in the very early months of 2008, and I'm sure that the failure to make that timing made for some interesting discussions inside of the Fedora camp.
I understand that the 1.5 release was an enormous undertaking as part of the attempt to get rid of cruft left over from so many years of legacy support, but it still illustrates the perils of dealing with a large, complex codebase, even with an enthusiastic community backing the fork, and even if it is the reference implementation.
(I should mention that I don't come from a coding background, but I've worked with enough programmers to understand the issues of code maintenance and enhancement. Even in a corporate environment with lots of money and people behind a project, schedules don't always stay put.)
Re:When? (Score:2, Insightful)
Sorry, there's been a lot of ire coming from users over the GUI, as well as lost functionality in a number of areas, from what I've seen on forums.
I haven't read up on it since, as I reverted to Amarok 1.4 a day or two after upgrading to Jaunty, so I suppose the analogy isn't as apt as I had originally thought it was.
Point still stands, however.
Re:Wine mouse bug kept unfixed (Score:3, Insightful)
"namely, to use the DGA subsystem [winehq.org] to achieve the required mouse behavior. But that's not going to be accepted either, because someone somewhere decided that DGA was "deprecated" and never mind that the deprecation was ONLY concerning its graphic component."
To use DGA? That's not an acceptable solution. Last time I've used DGA was in 2004, and it required the application (not just the X server) to run as root because it writes directly to the video hardware. If the app crashes, the video RAM is screwed and you have to reboot. I haven't seen anybody actually using DGA for many years now so there's a pretty big chance that the drivers don't support it. And nowadays we have OpenGL-composited desktops which might conflict with it.
Re:What is more frustrating... (Score:4, Insightful)
Yes, Java accomplishes that, and I use that solution sometimes. Qt is ok if you want to ship multiple binaries and installers. And of course a source distribution is great if you can do it. But having a native (in terms of no VM or interpreter) API available everywhere with no recompilation is also a useful tool.
I think the biggest problem with Wine is that Windows developers don't test in it. If you could get people thinking about Wine as a cheap way to achieve cross-platform compatibility, it would be much more useful.
Re:When? (Score:2, Insightful)
Anyone who designs something with vertical tabs should be killed!
You're doing it wrong (Score:5, Insightful)
Fork, then announce it on Slashdot. Or is it obvious that this wouldn't be taken seriously? Hmm. Think hard about why you feel that way. Seeking affirmation from John Q. Geek for your fork is not how this has been done. Perhaps there is a reason.
I imagine that from the perspective of the Wine developer community what you've just done is set the drama fan to 11 and fire a giant shit cannon at it. You playing politics by leveraging whatever pressure you can gin up. That behavior, by itself, puts me on whatever side of the fence you're not.
Fork. If anyone notices and follows then good for you. Otherwise STFU.
'Adverse commercial agenda'... How much thought did you put into those weasel words before you hit submit?
Re:No fork is gonna happen (Score:1, Insightful)
Which begs the question:
You obviously know what Slashdot is "up to" judging by your remark, and by the tone of said remark I doubt that you approve of the tactic...so why do you keep visiting here? You even have an account registered, wouldn't you be protesting more effectively by _not_ providing those invaluable "page hits" in the first place?
Slashdot MOTD Says It Well IMHO... (Score:3, Insightful)
I was going to post a comment about careful consideration before forking, but found the /. MOTD at the bottom of the page already did my work for me:
"Be sure to evaluate the bird-hand/bush ratio."
Strat
Re:The secret is to not care (Score:1, Insightful)
In my experience, you won't be a good leader without at least a minimum of social skills. Juliard doesn't seem to have any at all - the examples you're all posting are pretty sub par on the charisma scale even for us 'computer nerds'. I say fork the project, it'll be best for everyone.
I love Linux and all, blah, blah, blah (Score:1, Insightful)
Don't get me wrong, I love Linux more than my own mother, but Windows is where it's at baby.
I don't like Windows but it's great. You should try it. Really. Just bear in mind that I love Linux.
Honestly, Linux is great for the world, except there are just so many things it cannot do. Use Windows instead. Not that I am advocating Windows or anything, because Linux stuff is what I live for... except it's a million miles from being usable, even though it is very good. ...and so on.
God how I get sick of the slimy mess that keeps spewing out this double talk.
Re:Sounds a like a storm in a teacup (Score:3, Insightful)
Wine has a GIT repository and if package managers take the patch on board it is in, they are willing to do, now the warning was raised: don't do that because then we would have "invalid" bugs in bugzilla (that are not in the official release). So currently, very strange, all related bugs are discussed on the dib engine bug page and unlike the rest of wine bugs they actually get fixed. Everybody seems to be very enthusiatic about Max' work. So the natural next move is to get a "beer" project which is more contributor friendly.
Re:"disgruntled core developer"? (Score:4, Insightful)
Yes, this is why Max did follow the rules in a slavish manner. His engine is optional and needs to get activated, so it won't break anything and could also be removed if it was found obsolete. The typical contribution troll is that in technical discussions you always find reasons to reject a patch. What you should never do is to move the goal post. If Wine had a professional maintainer he would communicate what he wants and set realistic goals. Look at the history: Max does it. Someone tells him that Huw was supposed to work on that. And of course it is never perfect, so in the situation of dictatorial silence the palatines make up their own explanaitions.
Re:"disgruntled core developer"? (Score:2, Insightful)
This is a working DIB engine. It integrates with the GDI layer. It has been developed at length and passes all tests, if you read the bug there are some fairly fanatical testers reporting in on the build. Providing detailed bug reports. Most bugs have been fixed. There are two outstanding issues, one is a show stopper (mouse movement chews CPU on slow machines (oddly it sounds like there's knee point below which CPU is chewed and above which no noticeable CPU is used at all)) the other is the problem: Alexandre doesn't like it and wont say why. Given the latter, why bother fixing the former?
Re:What is more frustrating... (Score:5, Insightful)
Odd. I got the distinct impression that the GP was advocating that people spend their own money on software that was written to run natively on their OS of choice. That's your basic free market capitalism in a nutshell.
And yet, from this you manage to infer that the GP supports forcible state seizure of all privately owned property?
You took the words right out of my mouth.
Re:You're doing it wrong (Score:1, Insightful)
fake outrage aside, there _is_ a clear and present "adverse commercial agenda" in WINE;
Codeweavers (and by extension, most of the core WINE devs.) would probably go bankrupt if they allowed regular [free] WINE to gain feature and quality parity with Crossover...
Re:Look deeper (Score:2, Insightful)
1. Massimo has been invited to the IRC to discuss the architecture with Alexandre, but hasn't;
And this is the whole problem IMHO. It's easy to keep turning down attempts but it's time for Alexandre to elaborate on what *is* the right design.
Too much time has been wasted on discussions on IRC and the mailing list. We need a design document written by him before more time is wasted.
Re:When? (Score:3, Insightful)
Amarok 2 is still in development. Give it time. Report bugs. Submit code if you can.
Re:red and white wine? (Score:4, Insightful)
Why would a drunk man try to eat wine with a fork? Shouldn't he be fairly good at drinking wine correctly?
Re:What is more frustrating... (Score:3, Insightful)
In this world, I'd rather be a communist than a capitalist manager. Those commie leaders could run a country while wasting a lot less money than some of today's managers do while merely running a bank.
Re:The secret is to not care (Score:4, Insightful)
Re:The secret is to not care (Score:3, Insightful)
Seriously, Microsoft have got other things to do than worry about a tin-pot emulation project. .NET advances are good in themselves for the developers who use those technologies. Microsoft don't have to stop advancing the technology just because Mono needs to catch up. If they cared about Linux support, they'd release .NET for Linux, but the don't and neither do the vast majority of Windows developers.
You don't move versions by reducing functionality. (Score:4, Insightful)
It is unforgivable.
If drastic changes needed to be be made you should go as far as creating a new product, so people stick to the old one that works while devs polish the new product.
When I saw how incomplete and different v. 2 is from v. 1.4 I could simply not believe it.
No podcasts? No support for music players? (if there is any it isn't working) and a complete redesign of the user interface (a complete no,no when it comes to user interface design).
Sorry, I am very grateful for what has been provided before, but it would be a disservice to say that the new version is anything but something to be ashamed about in the planning of the transition and the execution.
A text book case of how *not* to transition to a new version of a product.
If it is still in development.... (Score:4, Insightful)
What the heck is it doing in Ubuntu?
Re:Just make the damn thing work (Score:2, Insightful)
So you're happy to have something like the Gnome session manager issues http://np237.livejournal.com/22014.html?thread=113662 [livejournal.com]?
I don't know how the Windows GDI and DDB/DIB logic work in great detail, nor do I understand how it is implemented in Wine or works with DirectX. What I do know is that doing something this big is extremely difficult to get right. You need a decent migration strategy and someone who understands the architecture (both how it currently works and how it is intended to work).
I suspect that there are interesting DIBDDB and DIBEngineWineX11X11 and DIBEngineWineD3DOpenGL issues that make it more of a challenge.
"Not pretty" is not technical critique. (Score:5, Insightful)
I would fire somebody telling me that is their reason not to accept some piece of code.
Why? Because that is a subjective judgement, and in big programming projects one should be as objective as possible. Oh yes, and because it says nothing about any perceived issues, so the person being judged has no way to "correct" the "problem".
Re:What is more frustrating... (Score:3, Insightful)
Most of the Windows software out there is not pre-packaged from major software houses but written by businesses in-house or a niche app that will never see a Linux version.
What should we tell them? "Switch to Linux - all you have to do is rewrite all your applications"? Why is it that Linux advocates repeatedly forget that the majority of Windows desktops are in the workplace and that interoperability with their business systems is essential if Linux is to make any inroads.
The barrier to entry is not Photoshop, it's not Office, it's something like Winscribe [winscribe.com] or some internal stock tracking system that the business depends on and will not be spending millions to rewrite.
Why is it that openness and interoperability is so important to the community until it comes to the huge amount of Win32 apps? Then loads of people start frothing at the mouth about how WINE will prevent developers from creating native Linux apps. Here's a clue. While virtually no-one uses Linux desktops there will be virtually no native Linux apps from the major houses. You want a market for the Linux desktop you give businesses the opportunity to move as seamlessly as possible to it - not place insurmountable obstacles in their way.
Re:If it is still in development.... (Score:4, Insightful)
That question could be applied to a lot of things, and not just the whole KDE4 mess. Xfce 2.6 should never have made it into Jaunty, with no menu editor and vertical panels totally broken.
I use Linux because, with a bit of hacking and some command-line wizardry, I can turn it into a better OS for my purposes than anything else. But I don't recommend it to anyone less geeky than myself. There's simply no way it's going to be a suitable platform for the average user, as long as upgrades routinely lead to major regressions.
Re:Seems to be a separation issue (Score:5, Insightful)
In which case, why was the reason for rejection not given as the concrete and rectifiable "wrong coding style"?
As it stands, "not pretty" could refer to just about anything. When I read that post I assumed it was referring to algorithmic elegance, not coding style. And that's the problem: the critique is so vague as to be utterly worthless.
Re:The secret is to not care (Score:2, Insightful)
Re:When? (Score:5, Insightful)
The real advantage will be after feature parity with 1.4. Amarok 2.x is far superior 'under the hood'.
Do you know what I liked most in Amarok? The UI. A playlist, a file browser to drag stuff from, and a play button. That's it. I don't need a more complicated UI. I don't want one. Now there's a button for Wikipedia?
Do I have to go back to XMMS just because everyone's so fucking Web 2.0 now? In fact, the whole KDE4 thing looks like they want to deliberately lose every user who wants a simple, clean, responsive, effective UI. They overhyped the API changes so much, they forgot about the users. Why do you force me to use Fluxbox? I've already given up on Azureus, they did the same thing with Vuze.
Fun fact: even Vista still has the classic UI.
Re:When? (Score:4, Insightful)
I don't understand this. I'm not to into the community for either project (I use Linux more for servers), but apparently KDE has done the same thing. If it's "still in development", why is it Amarok 2.0? Why isn't it Amarok 2.0.BETA1 or something? A .0 release is supposed to be (mostly) feature complete and (largely) bug free. Obviously bugs will still exist and features will be added (software is released by humans), but the big bugs are supposed to be out, and the features are supposed to be mostly where the spec document said they'd be. This sounds more like a development version of the code, akin to the odd number kernel minor revision numbers.
Re:Wine mouse bug kept unfixed (Score:5, Insightful)
And then a numbnut promptly crawls out of the woodwork to respond with "errr, but didn't you hear that DGA is obsolete because it allows apps to write directly to the framebuffer".
And mods happily mod it up to 5 Insightful, rather than 5 Funny (or -1 Reading Comprehension).
Re:You don't move versions by reducing functionali (Score:5, Insightful)
WTF? Did you not check the *rest* of KDE in the same timeframe? KDE 4.X is not feature-complete when compared to 3.5, nor even half as stable. They did a ground-up rewrite with a new version of Qt, taking advantage of all sorts of eye-candy that Qt 4 provided. The rewrite of the GUI under the release-early-release-often motto is exactly what the entire KDE culture was undergoing through that time.
Sure, I use it. I provide many bug reports. I ensure I enable the debugging stuff to help with said bug reports. But I sure as heck don't anticipate it being at the same level as the 3.5 version.
Now, if you simply want to disagree with the release-early-release-often manifesto, that's fine, that's your prerogative. But let's at least call it for what it is. It's not just Amarok, it's the entire KDE 4 movement.
Now, if *no one* transitioned to the new version, then we'd be stuck. Without those users testing, we'd simply never get to the next version.
Provide your feedback, but please be civil about it. If you don't like the new version, by all means, stick with the old version. No one is stopping you. It's not like you paid for this.
Re:Seems to be a separation issue (Score:1, Insightful)
You're both assuming, there's no link to Sun's patch which he could easily have given. All of you shouldn't be modded insightful, including Sun.
Re:Seems to be a separation issue (Score:3, Insightful)
Well operating on the assumption that Sun is not lying flat out (because why would he?), doesn't it seem that a comment like "You"re using C++ style comments and we'd prefer C style (or whatever style is preferred), can you change them?" would be more useful than "It's not pretty enough". Probably resulting in a corrected and resubmitted patch rather than a frustrated developer. I mean, that's a really specific and easy to fix problem. "Code style" is a bit more arbitrary, but assuming we're talking about numbers of spaces in indents, not "You didn't code it exactly the way I would have", it should still be pretty easy to fix.
I kind of doubt that anyone who takes to time to write and test a patch is going to be completely frustrated and quit over the ten minutes required to reformat a few comments or change a few indents.
Re:"disgruntled core developer"? (Score:3, Insightful)
Prime time TV in China beats both, bandwidth-wise.
But what do I care? My wine emulator is sold by a company named Microsoft - and they do a brilliant job running Windows software.
And with discussions like these, you wonder why Linux on Desktop isn't as popular as you'd want to?
Re:Seems to be a separation issue (Score:1, Insightful)
You've given two possible interpretations of what was meant, and someone else in this thread has suggested that it could be also be construed as a critique of algorithmic elegance. No doubt there are other interpretations. Perhaps when the code is printed in fixed-width font and layed on its side it didn't look enough like a mountain range.
If Sun, if I can infer from his e-mail address that this [winehq.org] is he, was unable to determine what was meant, I'd be willing to give him the benefit of the doubt. In any case, if a maintainer is willing to turn patches away, for the sake of spending an extra 2 or 3 minutes giving more constructive feedback, then what incentive is there to patch submitters to continue doing so. How long would it take, even just to type "Remove C++ style comments, fix coding style to match rest of file"?
Since you're only providing another anecdotal point of view, I fail to see how you can judge his comment to be false.
Re:The secret is to not care (Score:3, Insightful)
"Do you have any idea of the sheer volume of code that gets submitted to wine everyday? Of course rejections are going to be short and to the point."
"Short and to the point" would be understandable and probably preferable in almost all cases.
But I got the impression people where complaining the reasons given often where being "short and vague".
Re:No winelib in Picasa. Earth is native. Chill. (Score:3, Insightful)
Many developers get frustrated by Alexandre's relative lack of feedback, but imagine yourself in Alexandre's shoes; he would get overwhelmed if he held everybody's hands.
If the project has a choke point where one lead developer doesn't have enough time to properly review all patches coming through and reply with meaningful feedback (which is an important part of any code review), then it needs more people working on this, not just one.
Surely a project as old as Wine would have more experienced developers capable of handling this?
Re:Wow. What a load of crap. (Score:5, Insightful)
1) I asked *many*, but really *many* times to Alexandre, on mailing lists, on IRC and to many other people about what would be the "right" design for an engine, but *never* got an answer.
Well, to pe precise, I just got *one* people answering me kindly, and it was Dan Kegel, whom I thank very much for its support. I tried also to ask Huw both in irc AND by mail, but no answer at all, even not a simple "sorry, no time for that".
So, please, don't tell me that I didn't ask or I didn't want to follow the right way, that's plain wrong, and you'll see it if you loose some time reading *all* posts on wine-devel about.
2) My design started with Jesse's one, right, then tried to merge Huw's one, because somebody told me that Huw's was the "right accepptable" design.
After loosing some time on it, and "without any feedback" from Huw nor Alexandre, besides one laconic "I don't think a multi-author stuff is accepptable", and after loosing most of time to keep my ongoing driver in sync with wine, I had to give up with that solution and think about a new one.
The *only* people involved with former designs that spoke to me was Jesse Allen, and I appreciated that really. After the laconic comment above, I lost about one week splitting the engine by author's commits. That was a large work, because I rewrote most of the code, but, as that was the *only* comment got so far, I was hoping that doing so I could rise the hope to see the engine inside wine.
Keep in mind that also in previous works I DID KEEP the original copyrights inside code, even when there was just a code line from original author.
3) At the end, tired of having to loose 80% time to rebase the engine and 20% time to improve it, and after getting to the conclusion that Huw's approach wasn't the best one (also well explained in mailing lists), I decided to start over with a brand new design.
So, again, please don't tell me that I ignored the long, hard part of the job.
It I should say that all, your "long, hard part of the job" contained almost as many bugs as code lines.
So, please again, *before* look at code, *then* comment.
The only part I kept from original Huw's design is the line drawing functions, and also those hardly patched and corrected.
4) If you'd be honest, you'd have reported ALL the content of my "too much work" comments. Those were referred to "too much work in hopeless tasks", which was the true stuff.
I don't code for job, nor I want to do it. I code for fun, because I like Linux and I like wine.
I've made small contributions since many years. That said, I, and I guess I'm not alone, don't like to loose my time, even if it's for fun. If I make a patch which is rejected with a *good* reason, I can try to improve it and to repost it; if the patch gets rejected because "it's not right", "it's a pain to review", "it's too commented" (yep, I got also that one.....), I simply keep it on my tree and go on.
5) The DIB engine was an effort for a stuff I needed, and taken further because it seemed to me that many people were interested about. It's not a "wonder patch" (never said that, but, again, you should just read mailing lists...), it's not perfect, it's not complete.
But, it works. On most apps, and is passing all (well, all -1 because lack of time lately) tests of wine suite.
It makes some apps simply usable, point. It's not a code masterpiece, nor it wants to be.
it's fixing a long standing bug to some extent, and it will do it 100% given enough time.
It's an *unpaid* work of 1 people for some monthes. If I should value it's time on my current's job time, you'd be surprised by the amount.
6) I don't know much about Codeweavers, just that they offer good compatibility for many important apps, and I appreciate it... And I find it right that thay earn money on it. Opensource doesn't mean "for free", of course.
I don't even know if a DIB engine is embedded in crossover products, nor it's important to me.
NOR I hope about a fork of wine project. We've got enough forks on Linux/unix, sometimes that's good, most times it's a bad stuff, too many resources are lost on it.
Ciao Max