Forgot your password?
typodupeerror
Wine Software Linux

Wine Project Frustration and Forking 470

Posted by kdawson
from the new-bottles dept.
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?"
This discussion has been archived. No new comments can be posted.

Wine Project Frustration and Forking

Comments Filter:
  • When? (Score:5, Insightful)

    by LeafOnTheWind (1066228) on Monday May 25, 2009 @02:03AM (#28080463)

    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.

    • Re:When? (Score:5, Insightful)

      by soren202 (1477905) on Monday May 25, 2009 @02:15AM (#28080517)

      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.

      • Re:When? (Score:5, Insightful)

        by Martin Blank (154261) on Monday May 25, 2009 @02:44AM (#28080643) Journal

        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.)

  • by influenza (138942) on Monday May 25, 2009 @02:03AM (#28080469)

    Maybe if there is a fork, it can be White Wine and the original can be Red Wine.

    And then if they merge back together, it'll be a blush!

  • by QuantumG (50515) * <qg@biodome.org> on Monday May 25, 2009 @02:08AM (#28080485) Homepage Journal

    Just submit your patches and do any fix ups that they request.. if you submit too much, they won't review it at all.. so don't do that!

    After that, if they don't want your code, it's their loss. The great thing about git hosted projects is that anyone can merge in your changes with ease. In the case of WINE, the best way to get your patches noticed is to say FIXES [APP NAME] in the subject line and actually address a real bug witnessed in a real program that people actually use.

    Other than that, hey, welcome to the politics of open source development.

    • by Anonymous Coward on Monday May 25, 2009 @02:25AM (#28080559)

      After that, if they don't want your code, it's their loss.
      Wrong. The loss is just as much yours and the users'. If I was an evil M$ overlord, I would definitely attempt to mess up projects like wine, and the easiest way to do this is to find that key people on whom everything relies and try to influence those in the wrong direction. Seen from this viewpoint, it is easy to see the loss is not "theirs" at all. And even if this is not the case, the point is the same.

      • Re: (Score:3, Funny)

        by daveime (1253762)

        3 ... 2 ... 1 .... for the M$ WINE Poisoning Conspiracy Theories.

        Who killed WINE ? It was Steve Ballmer, in Seattle, with the poison ... or possibly with a chair.

    • by Sun (104778) <shachar@shemesh.biz> on Monday May 25, 2009 @04:03AM (#28080941) Homepage

      Just submit your patches and do any fix ups that they request

      The problem is that Alexandre Juliard, the project's dictator, often rejects patches with reasons that contain no useful feedback except the patronizing statement "you can do better", or "it's not right".

      I've had a patch I wrote for moving the wineserver code to epoll rejects because "it was not pretty". Michael Mccormak then made two more attempts at a rewrite that were rejected for precisely the same reason. In the end (several months later), Alexandre wrote his own version. At the time people explained this behavior to me as "wineserver is something he is very sensitive about".

      Several years later I wrote a patch to something to do with the Window reordering being ignored (with no error message) in some cases. It is a pretty unbelievable piece of Windows mislogic, so I wrote a test case to prove this is, indeed, the behavior on Windows. The test case was rejected because it was not pretty enough. When I asked for more specific feedback, Alexandre responded with "If I can think of better ways to do it, so can you".

      A project with as many contributers as Wine should have room for more than one programming styles than one. I thought it was only me for a while, but if it made it to slashdot, obviously it's not.

      Shachar

      • by rtfa-troll (1340807) on Monday May 25, 2009 @04:16AM (#28080985)

        Reading the bug (yes; I know; but I'm the RTFA troll. I'm allowed to do that) it seems that the issue is that this would be better not in Wine core, but in a DLL. So it's not being accepted because it doesn't need to be. Did I misunderstand?

        • Re: (Score:3, Informative)

          by AndrewFenn (1449703)

          I've submitted many patches to wine and Alex has always given me good feedback. Without a link to the parent's patches so we can judge for ourselves I would have to say that what Sun is saying is false.

          There's a couple of reasons why patches get rejected:
          - The code style doesn't match what's in the file
          - No test cases are submitted with a function implementation
          - The patche's test cases fail on windows

          I am subscribed to the mailing list and often see people get frustrated that they have to do more work then

          • by jotaeleemeese (303437) on Monday May 25, 2009 @07:36AM (#28081699) Homepage Journal

            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".

          • by Haeleth (414428) on Monday May 25, 2009 @08:41AM (#28082023) Journal

            In the case of Sun's patch it sounds like "not pretty" means he either did something like put in C++ style comments or didn't match the coding standard on the file he was editing.

            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: (Score:3, Insightful)

            by DrgnDancer (137700)

            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 abou

        • by kestasjk (933987) * on Monday May 25, 2009 @06:55AM (#28081541) Homepage
          My code is flawless; if it gets rejected it's time to fork.
    • Problem is ego, the bigger they are, the harder....they don't listen!
      If someone at the top management of this project were to get their heads out of their asses,
      and realize that WINE is the only thing stopping many from switching from Windows to Linux,
      they might make a serious mental note to include certain fixed as critical on their to do list!

      WINE is the only thing that makes a windows app work on linux, so why not make it
      as best as you can, because the higher the people coming over because WINE lest them

  • by Anonymous Coward on Monday May 25, 2009 @02:08AM (#28080487)

    Massimo Del Fedele seems to be working towards a solution [winehq.org]. Which of the devs is calling for this fork on the mailing list?

  • DIB engine (Score:3, Insightful)

    by sxpert (139117) on Monday May 25, 2009 @02:08AM (#28080491)

    you should probably look into using X-render, which is designed for this (check cairo for instance)

  • by Anonymous Coward on Monday May 25, 2009 @02:11AM (#28080501)

    As someone who have been following the wine developer list for a couple of years now, I think this post is more likely to be written up by a disgruntled user rather than a disgruntled "core developer" :p

    That said, to get a patch accepted in wine can be somewhat frustrating. Which is good on the one hand, as bad patches are unlikely to get in, but on the other hand it's also kind of detrimental for new developers to just have their patches dropped without a comment. Which happens from time to time. :p

    • by lorenzo.boccaccia (1263310) on Monday May 25, 2009 @02:47AM (#28080657)
      doubly so, and even of the DIB feature page it's written in e really explicit manner that:

      Note: The difficulty in this task is more integration with the current Wine codebase in an incremental and non-intrusive manner. Wine needs infrastructure for the DIB engine so that graphics operations without DIB support can fall back to X11.

      A patch that dumps an entire DIB engine somewhere in the Wine tree is unlikely to be accepted (that has already happened!). It needs to be added in an incremental manner, without breaking working functionality.
      • by Elektroschock (659467) on Monday May 25, 2009 @04:50AM (#28081099)

        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: (Score:3, Funny)

        by Petersko (564140)
        "A patch that dumps an entire DIB engine somewhere in the Wine tree is unlikely to be accepted (that has already happened!). It needs to be added in an incremental manner, without breaking working functionality."

        I flashed back to evolution arguments when I read that.

        "Hey, here's an eye!"

        ... "That's far too complicated to put in all at once."

        "Well, okay. Here's a single photosensitive cell."

        ... "What am I gonna do with that?"
  • by YokoZar (1232202) on Monday May 25, 2009 @02:13AM (#28080513)
    This is all exaggeration by the submitter. At worst, I'll be integrating the DIB engine at the packaging level rather than getting Wine pure from upstream. No one in the Wine project has threatened a fork, not even Chris Howe.
  • by Roman Mamedov (793802) on Monday May 25, 2009 @02:25AM (#28080555) Homepage
    Another long-standing issue is "Bug 6971: Mouse "escapes" window or is confined to an area in the full screen program [winehq.org]", which affects A LOT of games out there.

    The developers in charge insists that it could only be fixed by making changes in the code all the way down to X.org layers and perhaps even in the kernel mouse handling. However, this is demonstrably false, because: A) there is no such issue in Wine's fork Cedega; and B) some "outside" developers pointed out that there is a way to deal with this problem without asking for personal favors from X.org and the Linux kernel, 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.

    The bug was reported almost three years ago, and it's almost like it's kept "in" on purpose, so that Wine never works properly with many games, and so that users will always have a need for the proprietary Crossover Games product.
    • by YokoZar (1232202) on Monday May 25, 2009 @02:28AM (#28080577)

      Another long-standing issue is "Bug 6971: Mouse "escapes" window or is confined to an area in the full screen program [winehq.org]", which affects A LOT of games out there. The developers in charge insists that it could only be fixed by making changes in the code all the way down to X.org layers and perhaps even in the kernel mouse handling. However, this is demonstrably false, because: A) there is no such issue in Wine's fork Cedega; and B) some "outside" developers pointed out that there is a way to deal with this problem without asking for personal favors from X.org and the Linux kernel, 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. The bug was reported almost three years ago, and it's almost like it's kept "in" on purpose, so that Wine never works properly with many games, and so that users will always have a need for the proprietary Crossover Games product.

      XInput 2 is coming to the next X Release, and the support for relative mouse movements means that this bug will be fixed "the right way" shortly thereafter. There are already Wine devs testing out the latest X alphas to make sure XInput2 does what we need.

    • Re: (Score:3, Informative)

      a way to deal with this problem without asking for personal favors from X.org and the Linux kernel, namely, to use the DGA subsystem [winehq.org] to achieve the required mouse behavior

      DGA sucks. It's a painful kludge. When you use DGA, you are asking both X and the kernel to stand back and respect your right to draw whatever you like on the framebuffer. This is a hell of a lot harder than it sounds, and is just simply fail in modern setups.

    • Re: (Score:3, Insightful)

      by FooBarWidget (556006)

      "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

      • Re: (Score:3, Informative)

        by Roman Mamedov (793802)

        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.

        Please read the fine bugreport comment thread [winehq.org].

        DGA shared memory video was deprecated because it required superuser privileges (essentially it mapped the video memory into application memory space, so that a game could draw stuff at the fastest possible speed, provided that the window was completely uncovered). In essence, it was useless for security r

  • Look deeper (Score:5, Informative)

    by msclrhd (1211086) on Monday May 25, 2009 @02:32AM (#28080595)

    While I can understand the frustration, and sympathise with Chris, this is only part of the story:
    1. Massimo has been invited to the IRC to discuss the architecture with Alexandre, but hasn't;
    2. Conversely, Alexandre hasn't commented on any of the DIB threads - but other people (such as Roderick Colenbrander) have made comments summarising what Alexandre has been saying on IRC;
    3. One of the reasons that Alexandre doesn't like the design is that it is a mix of 3 architectural designs;
    4. Massimo's engine does not currently pass all the Wine tests (a requirement to get in) -- but is getting there;
    5. A recent report from Steve Edwards says that, yes the DIB engine is faster, but it has rendering glitches.

    Massimo's work is great, but even if it had Alexandre's approval needs more work. It's like rewriting Firefox's CSS support to allow for CSS3, but regressing on the Acid2 tests and not rendering pages correctly.

    Getting code into Wine is difficult. I know because some of my stuff took 5 attempts to get in. When it did get in, the code was a lot better for it.

    Wine has a quality bar that is required for code to be committed. This especially goes for something that is at the core of the project (which in this case is the gdi32 code, but also applies to DirectX and other areas).

    Is Wine perfect? No. but a fork here will not help.

  • by Time Doctor (79352) <zjs@zacharyjackslater.com> on Monday May 25, 2009 @02:40AM (#28080623) Homepage Journal

    ...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.

    • by Late Adopter (1492849) on Monday May 25, 2009 @03:26AM (#28080791)
      Some of us, when we write software, want to be able to distribute it such that it runs on all 3 platforms "our of the box".

      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.
    • by NormalVisual (565491) on Monday May 25, 2009 @03:26AM (#28080797)
      Do not buy Windows products if you want to see them in Linux.

      That's easy to say, but computers are a tool to be used as a means to an end, and that's how most people use them. If I'm a graphic professional, I'm not going to boycott Adobe just because Photoshop isn't available on Linux. There are some great OSS solutions out there, and there are thousands of programmers that bust their ass every day to write and improve them, but the fact of the matter is that all that effort doesn't matter when someone has a need, and there's not a Linux solution that meets that need but there is one for Windows. It doesn't help when the OSS community refuses to listen to them and attempts to tell them otherwise (i.e. "GIMP is just as good as Photoshop!"). Given that, really the best you can hope for is that the person will run their Windows software under WINE instead of just discarding Linux altogether and using Windows itself. Most people don't care about what operating system they use - they just want to get their work done.

      Learn from the unions, buy software made for Linux native if you want more of it.

      As long as the general viewpoint of the Linux community diametrically opposes that of the majority of commercial software vendors, you're not going to see any appreciable amount of native software for general sale. Most commercial software houses of any size are extremely loathe to release source for their products, and I'd bet that the majority of Linux users aren't going to be interested in purchasing a product that doesn't abide by their political views by including source code or otherwise abiding by the GPL. Not to mention the support headaches the software houses would have owing to the huge number of widely disparate distros out there ("is that config file in /etc/network/interfaces or /etc/sysconfig/network-scripts?").

      Don't get me wrong - I have several Linux boxes here at home, one hosted in a data center several states away, and I work exclusively on Linux machines at my job. It's not that I don't like Linux. It's just that there's going to have to be a lot more that happens in the Linux world for it to get traction on the desktop, and thus to become more attractive for vendors regarding native implementations. Hopefully the recent licensing changes in Qt will grease the rails a bit.
      • by ArsenneLupin (766289) on Monday May 25, 2009 @05:43AM (#28081297)

        Most commercial software houses of any size are extremely loathe to release source for their products,

        If that is the case, why then are they then so eagerly giving out a license to legally decompile their program?

        Indeed, in the European Union, according to articles 5.3 and 6 of the European "copyright" directive of May 14th 1991 [europa.eu], it is allowable to reverse engineer a program in circumstances where this is necessary to achieve interoperability.

        Right now, decompilation is a pretty rare occurrence due to lack of appropriate tools, but this is changing...

        • It's hard enough to translate source code from one language to another and end up with a maintainable code base, and there you have all comments, high level control structures, classes, and templates or macros intact. Decompilation, even if you reverse-engineer the low level control structures and detect unrolled loops and other optimizations, doesn't leave you with something that you can take forward long term... and I don't see that changing.

        • Re: (Score:3, Interesting)

          by drinkypoo (153816)

          If that is the case, why then are they then so eagerly giving out a license to legally decompile their program?

          That is a disingenuous or ignorant statement. Reverse engineering is not restricted to decompiling.

      • by gbarules2999 (1440265) on Monday May 25, 2009 @10:16AM (#28082921)

        the majority of Linux users aren't going to be interested in purchasing a product that doesn't abide by their political views by including source code or otherwise abiding by the GPL.

        Bullshit.

        Imagine the uptick in sales for Photoshop if Linux took it in. Sure, you'd have maybe, what, FIVE nerds yelling frantically into their monitors "Its teh not free softwarez" but then you'd get well, well over that in sales.

        This stigma that the Linux community doesn't like anything that's not free has to go. We're all using nVidia drivers, and we all have those non-free blogs installed right next to our kernels. Let's get it on, people.

    • Re: (Score:3, Informative)

      by IntlHarvester (11985) *

      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.

      Small Businesses are almost the worst place to convert to Linux, because they largely depend on the millions of vertical/custom Windows applications out there. Most of these applications aren't actively developed and aren't portable anyway. (VB, etc.)

      In fact, the only place worse that Small Business for Linux marketshare gains would be Home users. Poor hardware compatibility, still no software. And for your mom, it's just a slow, brown clone of Windows.

      That is why I propose that Linux should focus on the sm

      • Re: (Score:3, Funny)

        by Opportunist (166417)

        For my dad (an avoved computer illiterate, with no intention to learn more than the absolute bare minimum), KDE 4.0 is a sleek looking "new and better Windows" that doesn't pester him with crazy popups (no AV suit, and adblocker installed) while he does "his stuff" (read email).

        Whether Linux is an alternative in the home user market depends on a few things. Most of all, on what they want to do. If their goal is reading email, using IM, browsing the net and doing essentially what a fair lot of the "older gen

    • Re: (Score:3, Insightful)

      by cyber-vandal (148830)

      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 Phot

  • About forking (Score:5, Insightful)

    by Masa (74401) on Monday May 25, 2009 @02:41AM (#28080629) Journal
    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?
    • by ArsenneLupin (766289) on Monday May 25, 2009 @05:45AM (#28081307)

      Are we just afraid of negative feedback from anti-forking people?

      Or maybe we are afraid of some knifing (backstabbing) by the pro-knife people?

  • MS Office support (Score:4, Interesting)

    by Britz (170620) on Monday May 25, 2009 @02:45AM (#28080653) Homepage

    In the blog post the project lead is talking about working on better MS Office support. I would love that. Especially MS Office 2007 SP2.
    Add a little Samba gui integration into Ubuntu (share folders and drives point and click) and I am ready to roll out Linux in my companies. Seriously. Myself I have been a Debian desktop user since Slink.

  • by VincenzoRomano (881055) on Monday May 25, 2009 @03:30AM (#28080815) Homepage Journal
    If a popular FOSS project like Firefox can have a 10+ years bug on the core HTML rendering [mozilla.org], why should we be picky on a 7+ years old on a less popular application? The bottom line is: none has (enough) interest in it.
  • by TopSpin (753) * on Monday May 25, 2009 @03:41AM (#28080851) Journal

    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?

  • by BlueStrat (756137) on Monday May 25, 2009 @04:28AM (#28081019)

    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

  • Microsoft sabotage? (Score:4, Informative)

    by w0mprat (1317953) on Monday May 25, 2009 @04:41AM (#28081065)
    I was going to make some joke about how Microsoft is hiring stooges to sabotage Wine, then I realised how plausible it is sounding.
  • by jeremy_white (598942) * on Monday May 25, 2009 @12:14PM (#28084429) Homepage

    I find this story spin deeply offensive and highly misleading.

    Let's start at the bottom, because that's the one that offends me so mightily. My blog is pointed to, with a caption 'adverse commercial agenda'. In that self same blog post, I refer to the energy we put into the DIB engine - I paid Huw to work on the DIB engine for six months. In fact, CodeWeavers has had the highly unenviable job of doing the long, hard dirty jobs that no one else wants to do, because they're not fun. (Can you say "COM", boys and girls). CodeWeavers contributes all of its patches to Wine first, and if you look at the top contributors to the Wine project throughout its lifetime, you will find a stunning number of CodeWeavers people. I find it personally insulting to the many people at CodeWeavers that have worked so very hard on Wine, often for very little pay, to imply that we have an evil agenda. We don't. We do want to make a living. We do put our customers ahead of shills on mailing lists. We do sometimes focus on making CrossOver better for specific tasks, but at all times our core mission remains making Wine better.

    The proposed 'wonder' patch is based upon solid work by Jesse Allen, along with some of the work we paid Huw to do. And, in fact, it does some nifty things, because the author went after the fun cool part of the task, and ignored the long, hard, nasty part of the task. Indeed, the author repeatedly refuses to consider Alexandre's requirements for doing it right. Max has not 'satisfied all requirements set'. In fact, if you read this post [winehq.org], you'll see that Max has no interest in implementing the DIB Engine in the fashion that Alexandre has requested - it's too much work.

    Wine has come a long way in the past 8-10 years - anyone who has used Wine lately can tell you how amazing it is becoming. This is largely driven by the ever increasing standard that Alexandre is using - the bar for patches, particularly against stable and well tested code - is becoming very high. This is a Good Thing (TM).

    And finally, up to the top, this phrase is troubling: 'the dissatisfaction of core developers with the arbitrary project governance'. Once a year, the core Wine developers get together at WineConf [winehq.org]. We often have a topic called 'Wine governance', where we have great fun lampooning Alexandre. (He certainly is terse, and can be incredibly maddening). But the overwhelming and unanimous consensus, year over year, is that he does a damn fine job and that the Wine project is lucky to have him.

    Change that to be 'the dissatisfaction of a bunch of vocal people on the mailing list, who don't really understand the technical issues at hand, but think they're missing out on a cool shiny' and now you have an accurate statement.

    Cheers,

    Jeremy

    • by jeremy_white (598942) * on Monday May 25, 2009 @01:12PM (#28085125) Homepage

      One clarification: in my last paragraph, I implied that I was upset with people on the Wine mailing list. That was poorly written on my part; my anger is almost entirely directed at the original poster. Max has written some nifty code. Alexandre won't take it, for reasons that most folks are clear on. So folks are working to find ways to make that code available for folks to try. That's all good; it in fact makes good pressure for getting it done 'right', and makes it a great tool to test the usefulness of a DIB engine. So it's all good, and healthy, and for this to somehow be spun up the way it was really bugged me.

      Cheers,
      Jeremy

    • by MicioMax (1562083) on Monday May 25, 2009 @06:46PM (#28088539)
      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

The person who's taking you to lunch has no intention of paying.

Working...