Slashdot Mirror
Wine Project Frustration and Forking
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 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.
you should probably look into using X-render, which is designed for this (check cairo for instance)
...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.
Check out ioquake3.org for a great, free, First-Person Shooter engine!
Not necessarily commenting this particular case, just wondering in general...
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?
"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.
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?
Lurking at the bottom of the gravity well, getting old
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?
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
Progressivism (aka US 'Liberalism'): Ideas so good they need a police/surveillance-state to enforce.
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.
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.
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.
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.
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?
If you can read this you've gone too far.
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.
Why would a drunk man try to eat wine with a fork? Shouldn't he be fairly good at drinking wine correctly?
XP, however, is a no-longer-moving target. Useful, that.
http://rocknerd.co.uk
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.
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.
IANAL but write like a drunk one.
What the heck is it doing in Ubuntu?
IANAL but write like a drunk one.
So you're happy to have something like the Gnome session manager issues http://np237.livejournal.com/22014.html?thread=113662?
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.
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".
IANAL but write like a drunk one.
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.
Yes, but, Win32 is soon to be deprecated, making Wine only good for supporting legacy apps.
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).
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.
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.
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.
I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
Err...
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?
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 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.
"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".
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?
Well, I was thinking to not to enter inside this discussion, but... just to be precise :
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