Oh great, now there is poison on slashdot: http://tech.slashdot.org/article.pl?sid=09/05/24/2044239 Let's not fork, shall we? Remco
2009/5/25 Remco <remco47(a)gmail.com>:
Oh great, now there is poison on slashdot:
http://tech.slashdot.org/article.pl?sid=09/05/24/2044239
Let's not fork, shall we?
Out of pure curiosity, does anyone know if this "Elektroschock" guy has a real name? Personally I don't see a lot of "dissatisfaction of core developers with the arbitrary project governance", but I guess it's been a while since we had a "real" Governance thread.
Hello, I'd like to ask why you can't include this engine until someone does it the "right" way? If it doesn't do anything until user will manually trigger it, it shouldn't do any harm. If it can't be possible, I can provide a script to automatically download WINE from git, apply DIB engine patches and compile, so maybe someone could post it on WINE website for really DIB-engine-curious users. 2009/5/25 Henri Verbeet <hverbeet(a)gmail.com>:
2009/5/25 Remco <remco47(a)gmail.com>:
Oh great, now there is poison on slashdot:
http://tech.slashdot.org/article.pl?sid=09/05/24/2044239
Let's not fork, shall we?
Out of pure curiosity, does anyone know if this "Elektroschock" guy has a real name? Personally I don't see a lot of "dissatisfaction of core developers with the arbitrary project governance", but I guess it's been a while since we had a "real" Governance thread.
Am Montag, 25. Mai 2009 15:47:30 schrieb Henri Verbeet:
2009/5/25 Remco <remco47(a)gmail.com>:
Oh great, now there is poison on slashdot:
http://tech.slashdot.org/article.pl?sid=09/05/24/2044239
Let's not fork, shall we?
Out of pure curiosity, does anyone know if this "Elektroschock" guy has a real name? He posted similar slashdot stories in the past: http://developers.slashdot.org/developers/07/10/08/0344231.shtml
Personally I don't see a lot of "dissatisfaction of core developers with the arbitrary project governance", but I guess it's been a while since we had a "real" Governance thread. I guess we had one on Sept. 27 or 28 2008. I guess the next one is not yet scheduled, but will be somewhen in the fall I guess.
On that subject, I think Dan Kegel's patchwatcher was a really, really good idea, and we should revive it. Not only to catch simple problems, but also to broaden the set of platforms patches are pre-tested before they are applied(/me thinks about different graphics drivers)
On Mon, May 25, 2009 at 1:24 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Am Montag, 25. Mai 2009 15:47:30 schrieb Henri Verbeet:
2009/5/25 Remco <remco47(a)gmail.com>:
Oh great, now there is poison on slashdot:
http://tech.slashdot.org/article.pl?sid=09/05/24/2044239
Let's not fork, shall we?
Out of pure curiosity, does anyone know if this "Elektroschock" guy has a real name? He posted similar slashdot stories in the past: http://developers.slashdot.org/developers/07/10/08/0344231.shtml
Personally I don't see a lot of "dissatisfaction of core developers with the arbitrary project governance", but I guess it's been a while since we had a "real" Governance thread. I guess we had one on Sept. 27 or 28 2008. I guess the next one is not yet scheduled, but will be somewhen in the fall I guess.
On that subject, I think Dan Kegel's patchwatcher was a really, really good idea, and we should revive it. Not only to catch simple problems, but also to broaden the set of platforms patches are pre-tested before they are applied(/me thinks about different graphics drivers)
Patchwatcher is coming back. Look for something from me in the next couple weeks either on wine-devel or in WWN.
On Mon, 25 May 2009, Stefan Dösinger wrote: [...]
On that subject, I think Dan Kegel's patchwatcher was a really, really good idea, and we should revive it. Not only to catch simple problems, but also to broaden the set of platforms patches are pre-tested before they are applied(/me thinks about different graphics drivers)
Agreed. I think it's one of the projects that has the most potential for helping Wine move faster. As usual it's probably best to start small even if it does not do all we would like at first. Then once the basics are in place, well tested and stable we can broaden the scope and think about the wilder reaches (testing on multiple platforms: FreeBSD and Solaris, automatic conformance test runs on multiple Windows versions, etc). But the first and most important step is to get things in place. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.
On Mon, May 25, 2009 at 9:47 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote:
2009/5/25 Remco <remco47(a)gmail.com>:
Oh great, now there is poison on slashdot:
http://tech.slashdot.org/article.pl?sid=09/05/24/2044239
Let's not fork, shall we?
Out of pure curiosity, does anyone know if this "Elektroschock" guy has a real name?
Not sure, but I see the second time around was a success for him.. First attempt on the subject : http://slashdot.org/firehose.pl?op=view&id=4193755 Tom -- http://www.wine-reviews.net/ http://bordeauxgroup.com/
Not sure, but I see the second time around was a success for him..
First attempt on the subject : http://slashdot.org/firehose.pl?op=view&id=4193755 <http://slashdot.org/firehose.pl?op=view&id=4193755>
Ah. I see; he apparently believes that CrossOver has a DIB Engine and we've been holding out all these years. That's why he decided we were evil. /me goes to review Huw's commits to find the one where he snuck a DIB Engine into CrossOver without my knowing it <grin>. Cheers, Jeremy
2009/5/25 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se>
Not sure, but I see the second time around was a success for him.
Let's not look to hard. He (or her) does have the right to having an opinion and going out of one's way finding out and posting here would only appear vindictive and fuel interest.
//Nicklas
I don't post on here very often, I don't even hang out in #winehq(-social) very often either, so my opinion may not be considered too important, but by just looking at the efforts of the Wine Project to address the DIB engine over the years, I feel disheartened by the lack of real progress. There have been patches regarding the DIB engine that goes all the way back to 2002 with TransGaming! But the implementations are always stonewalled and left to die over arbitrary architectural reasons. I say arbitrary because I don't have a clue what the spec is for this supposed architecture that the DIB engine is supposed to follow. Eventually, Bug #421 may just be like one of those 10-year-old bugs that live in the GNOME and Mozilla bugzillas, that are just left there because people don't care enough anymore to do anything about it. While it is true that the DIB engine isn't the One True Solution regarding compatibility with many Windows applications, it helps a lot with graphics-intensive ones. At this rate, the DIB engine will be reassigned to the 1.4.0 milestone because nobody will accept any implementation. And nobody say, "Patches welcome!" or "Patches accepted!" because there is proof to the contrary. The fact people say that is also a problem. A vast majority of people are not technically inclined to the level of being able to produce such things. Even people that subscribe to mailing lists like I do, are not capable of contributing like that. And really, code IS NOT the most valuable form of contribution for any project. If anything, it is of the LEAST value. Documentation, advice, testing, support people, moderators, infrastructure management, all these are MUCH more valuable than code or money. Now, this problem is not limited to the Wine Project. This problem is all over the open source world. It bugs me a lot when I get rebuffed because I'm not a programmer. Granted, most people that ask are whiny and demanding, and they get on people's nerves. But, people are generally happier with an explanation in a cordial manner. Being mean or sarcastic about it, or even asking for something they can't give is not a good way to go about it. But, I digress. The Wine Project is making great strides, and with the work the ReactOS Project is doing alongside them, the work is a lot more momentous than just a compatibility API/ABI layer for UNIX and Unix-like systems.
Nicklas Börjesson wrote:
Not sure, but I see the second time around was a success for him.
Let's not look to hard. He (or her) does have the right to having an opinion and going out of one's way finding out and posting here would only appear vindictive and fuel interest.
1. I don't feel like creating a /. account just to reply. 2. AJ has keep several bad patches from being applied to Wine since I've been here. Without this, we would have a project that supports a couple of programs real well and others would be complete garbage.. 3. There should be a code style and submission guidance document. Something that explains coding style (four spaces vice tabs) and comment style ('c' style vice C++/VC++/Java). It would also be nice to have a statement that a patch has to affect one and only one area or bug. Oh, fixes CANNOT break existing running programs, just to get your favorite running, if you want them accepted. Now with that being said, getting the DIB engine into Wine may take a lot of shoehorning and for AJ to look over all of the code and accept/reject it with good notes and reasons. "You can do better" is not, in my book, a good reason. "Your code is not up to our standards" is with a side comment of "look at what is accepted and what is peer-rejected before resubmission". Of course, AJ does take on projects that a coder just cannot make work within the standards. And this is a good thing. Sadly, Electroshock decided that he would take his toys and go play in another sandbox. And lastly, I think there is a site at repo.cz that has all of the unaccepted Wine code somewhere, that we all could look at and fix. James McKenzie
2009/5/26 James McKenzie <jjmckenzie51(a)earthlink.net>:
And lastly, I think there is a site at repo.cz that has all of the unaccepted Wine code somewhere, that we all could look at and fix.
James McKenzie
All of it, definitely not. Only some of it (unless there IS one I'm not aware of). It would be nice to have a repository of fixes that are still in queue/have been rejected. Some patches do indeed just disappear without any reason given, and the author never bothers to fix what could be just a minor inconvenience in it. Seen years old patches all of a sudden being fixed and resent in order to fix an application that would have been running long before then. It would probably be maintenance hell, though. Maybe patchwatcher could help? -- Adys
On Monday 25 May 2009 23:12:57 Remco wrote:
Oh great, now there is poison on slashdot:
http://tech.slashdot.org/article.pl?sid=09/05/24/2044239
Let's not fork, shall we?
Remco
I saw the article. Anybody who thinks a fork is a good idea is quite frankly an idiot. However they are free to have their own GIT repo and play in their own corner. At the end of the day anybody is able to write a patch and share it with whomever they like - it might even be extremely popular but that is no reason to spoil the main code base. Patching and compiling really is child's play - there is even automated scripts for Ubuntu so even your grandmother can do it. Stop whining and improve your code/design and try asking around for some help. On the subject of the DIB engine I think that the parties involved need to just cool down, remember that they are on the same team and calmly and rationally work out the (full!) requirements. I am not very well known to this list (but I hang in #winehq and -social quite a bit) so I'm not sure if I am right to submit my thoughts. Take whatever I have said wrong with a grain of salt. I love the Wine project and I hope to become a productive contributor eventually. Also take Slashdot with pinch... I mean BAG of salt.
2009/5/25 Remco <remco47(a)gmail.com>
Oh great, now there is poison on slashdot:
http://tech.slashdot.org/article.pl?sid=09/05/24/2044239
Let's not fork, shall we?
Remco
Well, this is awkward.
For the record: I didn't intend to ambush anyone on here with my frustrations, and I certainly wouldn't have chosen to publicise them via Slashdot. Such is the nature of public discourse, eh. I don't think forking's the answer (and I'm certainly not putting myself forward for that!) That said, there's only so long that the issues of a proper DIB engine can go unadressed, and I mean, it hasn't been addressed for some time, despite the efforts of several people, latterly Massimo, to provide at least proof of concept solutions. All that's really been agreed upon is that what's there now can't be tweaked over time to become the "right solution", but at the same time, it can't be replaced wholesale as that might cause regression. This would seem to be a logical impasse, and that's why it needs a decision made, I think. No one developer is going to be able to come out and write the roadmap for it, because it needs broad input from a lot of people, not just Alexandre. But certainly, as a starting point, if it's so trivial to reject something on the grounds that the architecture is WRONG it suggests that there is a solution out there that's RIGHT, it just needs to be documented. My intention was not to whine, (except that it's heartbreaking to see good code go to waste over and over again) nor was it my aim to throw stones, but to try and stimulate the required discussion. If this list isn't the place for that, then perhaps a section of the Wiki? Even just a timetable for when it might be discussed? (As in, by release x.x.x, the roadmap needs to have been agreed upon). -- Chris
2009/5/25 Remco <remco47(a)gmail.com>:
Oh great, now there is poison on slashdot:
http://tech.slashdot.org/article.pl?sid=09/05/24/2044239
Let's not fork, shall we?
From this post: "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."
The issue is that it doesn't match Wine's quality standards (for architecture). This Elektroschock guy is hilarious. What post did he use to demonstrate "the dissatisfaction of core developers with the arbitrary project governance"? http://www.winehq.org/pipermail/wine-devel/2009-May/075844.html Chris responding to Max responding to me. Who here is the "core developer"? Chris doesn't appear in the WhosWho page on the wiki, nor can I find his name in git log --author. That only leaves Max, who's best work continues to remain floating on bug page #421 without being committed. For what it's worth, I agree with Chris. Someone needs to document how the DIB engine architecture *should* work, and then Massimo and <insert next guy to pick up DIB engine should Max lose interest> will know how to proceed. I believe we're closer than we've ever been to having a fully-working DIB engine, and I'd love to see real effort made towards getting it upstream.
participants (15)
-
Ben Klein -
Chris Howe -
Daniel Devine -
Francois Gouget -
Henri Verbeet -
James McKenzie -
Jeremy White -
Jerome Leclanche -
King InuYasha -
Nicklas Börjesson -
Remco -
Stefan Dösinger -
Tom Wickline -
Tommy -
Zachary Goldberg