Re: Governance revisited (Wineconf report)
From: Kai Blin [EMAIL PROTECTED] On Saturday 23 September 2006 10:32, Scott Ritchie wrote: Frankly, all we really need is for Alexandre to write a 10-second reply to wine-devel for each patch he rejects. On WineConf, we decided against this. That would still slow down the overall patch submission speed. Consider you have a patch that's just fine, but before you sent that, I sent in ten patches with C++ style comments. Alexandre would now have to reply to ten patches with No C++ style comments before processing your patch. Everybody reading wine-patches could point out what was wrong with my patches. You must be kidding. Even in your somewhat convoluted example, it would be fine to receive just a single notification No C++ style comments and I really wouldn't care if the notification came from Alexandre or from someone else on wine-patches. The reality is that a lot of patches (I haven't kept a precise count, but I estimate about a third of my own patches) are dropped silently, without any feedback at all. I have absolutely no problem with a strict patch acceptance policy, designed to keep the Wine quality high. Alexandre is amazingly smart and when he tells me why a certain patch was rejected I'll usually agree with him and even if I don't agree, I have enough confidence in him to accept his judgement. But having your patches dropped silently is pretty annoying. The usual response from the core Wine developers is well, just resubmit. I fail to see how this helps Alexandres productivity (or my own for that matter). If patches weren't dropped silently the sequence of events would be: 1) Submit patch 2) Alexandre looks at patch 3) Alexandre writes 10-second rejection reply With the resubmit: 1) Submit patch 2) Alexandre looks at patch 3) Wait a week 4) Resubmit patch 5) Alexandre looks at patch again 6) Alexandre writes 10-second rejection reply Seems to me this incurs extra work for Alexandre (number 5). The patch processes isn't very transparant. For example, I submitted a patch on 20 June 2006 to dlls/kernel/heap.c (www.winehq.org seems to be unreachable for me at the moment so I can't give a URL to the message) to fix a problem with the heap on Win64. This patch was silently dropped. On July 21 a change very similar to what I submitted was committed but not attributed to me. Now, either the commit was not based on my patch (in which case someone else spent another 2-3 days (it was one of those problems where a chain of out-of-buffer memory writes take place and you have to work your way up the chain to find the root cause) on tracking down an already known problem for which a fix was already available) or it was based on my patch (in which case my patch shouldn't have been dropped and I should have been given credit). Like I said before, I have a lot of respect for Alexandres technical abilities. But when I read comments in the Wineconf report about git: Developers might not like it, but Alexandre does so it's a success (did I mention I dislike git also???) and the inability of the Wine community to set up a patch management system (so patches won't disappear into the big void) because Alexandre refuses to use it if it won't work in Emacs I'm starting to wonder if people realise that the developers don't work for Alexandre. He's a great Benovelent Dictator on technical issues, but in my opinion only a Dictator on patch process management. Ge van Geldorp.
Re: Governance revisited
Hiji [EMAIL PROTECTED] wrote: - Original Message From: Mike McCormack [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: wine-devel@winehq.org; Marcus Meissner [EMAIL PROTECTED] Sent: Friday, September 22, 2006 11:42:36 PM Subject: Re: Governance revisited The current process is crippling this project, limiting the developer base and reducing community value. Without some healthy dissent it will never change and get better. I am a friend of change, a true believer in the process of continuous improvement. I believe one day, the WIne project will value my contribution - even in dissent. We value your contribution, however it's even more valuable to have developers that listen to feedback and fix their broken patches rather than just complaining loudly. Since you know better, how about maintaining your own Wine tree and showing us how it's done? Mike I intentionally left Mike's answer and the mail he were answering to. I absolutely don't understand why you addressed your message to him. [skipped] I think this team has done an incredible job with Wine - heck I've made it a point to stop by the CodeWeavers booth the last two year at LinuxWorld to say how much I love the work you guys do (sometimes, I'm the only one there). However, I can't help but believe that this project can evolve MUCH faster and better to gain the respect that it deserves. Everyone who complaints about problems with patch acceptance policy seem to claim that, but my impression is that complaints are going from technically incompetent people, who just feels that the process can be improved, but can't explain it in developer's language (i.e. in technical words) how. -- Dmitry.
Re: Please create wine-msxml and wine-setupapi components in bugzilla
Louis Lenders wrote: I propose adding categories for msxml and setupapi now. Here are bugzilla queries that find quite a few bugs that are candidates for moving into those categories: Good idea. In case someone is going to add these catagories, please also add catagories for comctl32 and msvcrt. Regards Louis I will add these categories to bugzilla as soon as I can but unfortunatly bugzilla and the AppDB and the main site are down since at least 9:00 AM MST -- Tony Lambregts
Re: Governance revisited (Wineconf report)
Vitaliy Margolen wrote: The next question is how long does someone wait till resorting to Bugzilla. Depending on the criteria it could generate a fair bit of -several days :) As in if some one wants to fix something, they should either provide a test (best choice) or open bug and describe the problem, and the resolution. It seems a fairly short time, especially if there is no feedback to say that it is rejected. Thre is another aspect to this, what we are saying is that some developers are able to write good code and won't need to resort to Bugzilla and other developers just won't cut it and Bugzilla is the way for them. I think the discussion on mentoring and developing the WineHQ compilant skills of developers is a more positive way forward. noise in the database with a lot of patches that would normally be This will not be noise but _correct_ use of bug database. Making good bug report is really helpful and 1/2 of the resolution. I was thinking here of the 4,000 patches we have had since March this year and how many would be added to Bugzilla. I expect that a fair few hundred or more would be in this category. accepted after a couple of goes. Who is responsible for clearing the bug report after acceptance? Unless you are actually actively pushing Of course ultimately bug submitter would be the right person to test if bug is still present in new version and act upon it. If this process is being directed at hackers who can't get patches accepted, they probably won't be on the list for long enough to test the patch as they probably will leave. the patch for acceptance, the submitter of a patch to Bugzilla would probably be unaware that it had been accepted. They don't have to. All they need is update Wine to new version whenever it's released. You misunderstood me here, but I think the answer is that the person who make the patch to resolve a Bug report will close the Bug. Vitaliy Jeff
Server instability warning
Hi Folks, The server crashed early yesterday evening, and again sometime over the night. It's a new server - and in fact, I think it's the new 'new' server - seems like it always takes a while to get a server stabilized). Jeremy Newman is coming back from England today, and I prefer to leave these sort of repairs to him, otherwise he grouses at me (rightly, I might add :-/). So it's back up now, but I'm not sure for how long that will be true. Sorry for the hassle; if it gets worse this afternoon before Jer gets back, I may break down and start dissecting it. Cheers, Jeremy
Re: ALSA implementation
James Courtier-Dutton wrote: The technically best solution is for the application to do the resampling before passing it to the sound card, so any effort to do it in the sound drivers is always going to be sub-optimal, with sound quality suffering. I still fail to see how that's the case for Wine, specifically. Doing the resampling in software in ALSA is surely just as good as doing the same resampling in software in Wine, right? I will document the constraints when I get a moment. Cool ;-).
Re: Governance revisited (Wineconf report)
Andreas Mohr wrote: Hi, On Wed, Sep 20, 2006 at 08:52:45PM -0600, Vitaliy Margolen wrote: Dr J A Gow wrote: How to capture these 'lost' contributions is a difficult issue. Maybe a centralized repository for patches could be maintained separate from the main Wine tree and with a very loose method of acceptance (maybe just ensure that it is clearly indicated what the patch is for and what version it can be applied to). This way it would be very easy for a contributor to place a patch somewhere where it is easily accessed by the community. A developer with more time who is interested in it may pick it up and clean it up for inclusion in the tree, but at least the patch is available for others to use, saving re-invention of the wheel. Why reinvent the wheel? If such people can spend their time chasing down the problem and developing a fix for it, they sure can open a bug in bugzilla, describe theproblem and attach a patch they made. How more simple can it be? No patches lost, no extra places to look for. And all the information describing the problem. Everything in one place. And exactly this information should probably be stated in the wine-patches subscription welcome mail. If for some reason the Wine patches you submit fail to get applied, then we'd appreciate you taking the effort of submitting your current patch as a new item at bugzilla to help us track your work properly until it's fully applied. As alternative to bugzilla we have this section in the wiki. http://wiki.winehq.org/InterestingPatches This has several hac^H^H^Hpatches that I found uesfull and have used over time. I particularly like the Mouse Hack patch http://wiki.winehq.org/PatchMouseHack The thing is that if a patch is useful it will have a life of its own and I am glad that I have an easy way of getting to them when I want to try them. Or, for improved visibility, even state this in the footer of every wine-patches mail sent (probably bad idea, though). Oh, and a DNS alias (or preferrably forwarder) bugzilla.winehq.org might be useful (after all it's quite common to have that site name, see e.g. bugzilla.kernel.org or bugzilla.mozilla.org etc.). Yes please.. -- Tony Lambregts
Re: my dsound/winealsa hacks
Am Samstag 23 September 2006 10:57 schrieb Tomas Carnecky: .. another small update, now tries to create the buffer size as close as possible to what the app requested. The whole patch is available at the same URL, I also created a patch of only ./dlls/winmm/winealsa/audio.c to make it easier to read the patch, the patch is here: http://dbservice.com/ftpdir/tom/alsa-audio.patch Just asking, would it work if you just make sure that the created buffer is bigger than the requested buffer? pgpK0hOkjxRbZ.pgp Description: PGP signature
Re: Governance revisited (Wineconf report)
Scott Ritchie wrote: On Sat, 2006-09-23 at 11:24 +0200, Kai Blin wrote: On Saturday 23 September 2006 10:32, Scott Ritchie wrote: Frankly, all we really need is for Alexandre to write a 10-second reply to wine-devel for each patch he rejects. On WineConf, we decided against this. That would still slow down the overall patch submission speed. Consider you have a patch that's just fine, but before you sent that, I sent in ten patches with C++ style comments. Alexandre would now have to reply to ten patches with No C++ style comments before processing your patch. Everybody reading wine-patches could point out what was wrong with my patches. Now, we agreed to try something different, two things actually. The first thing is the ambassador thing Steve and a couple of other people mentioned before. New contributors would be contacted by someone who would explain the way wine works to them. Secondly, we wanted to make a standard practice of what Mike's been doing for MSI patches. A developer proficient in a certain area of wine will reply to all the patches for his area, do a review and also makes sure they don't disappear into the void. Well, as long as SOMEONE writes the 10-second reply, I suppose it doesn't matter. But until we appoint the equivalent of Mike and MSI for every part of Wine, Alexandre ends up being the default person to do it. Thanks, Scott Ritchie Well, the way it works at present, nobody is obliged to write a 10 second reply and often don't. There has to be feedback to keep the process moving. I don't receive it and patches languish unapplied, delaying me considerably on tackling new work as I wait for acceptance before proceeding. Jeff Latimer
Re: Governance revisited (Wineconf report)
From: Kai Blin [EMAIL PROTECTED] On Saturday 23 September 2006 10:32, Scott Ritchie wrote: Frankly, all we really need is for Alexandre to write a 10-second reply to wine-devel for each patch he rejects. On WineConf, we decided against this. That would still slow down the overall patch submission speed. Consider you have a patch that's just fine, but before you sent that, I sent in ten patches with C++ style comments. Alexandre would now have to reply to ten patches with No C++ style comments before processing your patch. Everybody reading wine-patches could point out what was wrong with my patches. How about emacs macros that would send Patch rejected or Patch under consideration to wine-patches or wine-devel ? This would get rid of the feeling that patches are dropping into a black hole while only costing Alexandre a fraction of a second per patch.
Re: Governance revisited
On Saturday 23 September 2006 18:10, Hiji wrote: I think Bob, Jim and co. were very diplomatic in their recommendations, and I firmly believe that they symbolize the opinions of a much larger group of people. I don't think they've overstepped their boundaries at all, have complained or rushed-in to proclaim that they are know-it-alls. What they do realize is that the process can be improved and have tried to provide recommendations. I'm also very suprised that they have been accused of trolling when I didn't see it that way at all - I think someone who was complaining or trolling because their patches never/ rarely make it in would be MUCH less constructive. You guys, you don't have to be on the defensive because Bob, Jim, and co. are attacking you. Well, I just fail to see some of the points. Robert Lunnon complains there is no appeal process about Wine patches. This is true. But most other successful OSS projects out there do the same. I've never seen this sort of stuff come up on samba-technical. Why is it a problem in Wine? My way or the highway is an accepted gouvernance model in OSS. Besides, at WineConf we had a consent to keep it that way. To be frank, I didn't understand what Jim White's point was. Watching and being on this list for a few years now, it's no secret that this topic has come up over and over again - clearly, they aren't the only ones feeling this way and the problem persists. We've seen MANY discouraged developers leave because of situations like this, and I believe this hurts the project. Can you point out a couple of those? People who send some good patches that didn't make it in and who left again? Yeah, the team can say hey, we have no problem with it, but I think that's only because those who disagree have been scared away. As far as the recommendation to fork the tree, I wouldn't be suprised if that happens because it's already happened once before - of course, relations between this team and with Transgaming aren't all that great; so, I doubt they would want to share their development process. That fork was on a licensing issue. If you have a couple of hours to waste, it's a fun read. It had nothing to do with policy though. We're comparing apples and oranges here. I think this team has done an incredible job with Wine - heck I've made it a point to stop by the CodeWeavers booth the last two year at LinuxWorld to say how much I love the work you guys do (sometimes, I'm the only one there). However, I can't help but believe that this project can evolve MUCH faster and better to gain the respect that it deserves. I think the bigger issue that keeps developers away is: It's damn hard, and the Win32 API sucks. :) But that might be my personal opinion. I've been using Wine for a little over 2 years now (it's the first app I've ever installed on Linux, and its what kept me on Linux), but from a user's perspective, I have seen very little progress (and in some cases, steps backwards.) Now that really can't be. I couldn't play most of my games in Wine two years ago, and now I can play most of them. If you don't call that progress, what else do you want? And frankly said, it really sucks to hear that the developers here don't place user needs/ value higher on their priority list. Granted, Wine is free software, and I could off and do my own thing, but speaking merely from a personal satisfaction perspective, when I develop something, what really makes me happy is knowing that the person using my app REALLY enjoys and makes use of it. That's why it's always high on my priority list. If I don't have that going for me, I have no reason to develop the app. Let me answer this from my own perspective. As you can see in my signature, wine isn't the only FOSS project I'm working on. In fact, I only got started with Wine development because I was accepted into the Google Summer of Code 2005, so I was paid to work on Wine. I worked on an obscure area of Wine, and I so far heard from one user who seems to need this. I sent a fix for his problem, but I didn't hear back from him. So obviously my personal satisfaction comes from getting my personnal test applications to work. (And the times I got paid for this, it was a job.) Now, while I don't think most wine developers have this background, I figure most of them work on a certain area to scratch an itch they're having, I wonder what's wrong about this policy. I just want to close with this: I'm not trolling (the team should know this because I've been on the list for awhile) and I certainly don't think that anyone else here has trolled around this thread. You're not trolling, but you are very vague. Cheers, Kai -- Kai Blin, kai Dot blin At gmail Dot com WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgprdnAfaLFPf.pgp Description: PGP signature
Re: Call for Installer Bugs...
Dan Kegel wrote: (see http://bugs.winehq.org/buglist.cgi?product=Winecomponent=wine-msikeywords_type=allwordskeywords=downloadbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED for list) I have an installer bug in the 'zilla, I'd like to see whether it's on your list. Can't though, clicking the URL above gives: } Net Reset Error } } The document contains no data. } } The link to the site was dropped unexpectedly while } negotiating a connection or transferring data. Aye? PS. 'zilla sucks. With Trac, you could have specified the parameters used above in a report, and just linked to that. Like for example this: http://trac.edgewall.org/report/2 :-)
Re: my dsound/winealsa hacks
Tomas Carnecky wrote: James Courtier-Dutton wrote: I have place some documentation on the ALSA wiki site: https://bugtrack.alsa-project.org/wiki/wikka.php?wakka=ALSAresampler It tries to explain the constraints that the current ALSA resampler works under. You might like to read it as I think it will have impact on your plans. Thanks. One question though, if the app in in blocking mode and requests the said two periods, will alsa wait until the hardware has processed three 48000Hz-periods and then copy the two 44100Hz-periods to the application (because: 3 periods at 48000Hz 2*1024 frames at 44100Hz)? DirectSound doesn't know anything about periods, the windows application operates on bytes rather than frames or periods. So whether I'd have to wait for two or three periods wouldn't matter. The important thing is that I get X bytes in the right format to pass that back to the application. tom Maybe the ALSA terminology needs to be clarified. A frame is equivalent of one sample being played, irrespective of the number of channels or the about of bits. e.g. 1 frame of a Stereo 48khz 16bit PCM stream is 4 bytes. 1 frame of a 5.1 48khz 16bit PCM stream is 12 bytes. A period is the amount of frames in between each hardware interrupt. The poll() will return once a period. The buffer is a ring buffer. The buffer size always has to be greater than one period size. Commonly this is 2*period size, but some hardware can do 8 periods per buffer. It is also possible for the buffer size to not be an integer multiple of the period size. Now, if the hardware has been set to 48000Hz , 2 periods, of 1024 frames each, making a buffer size of 2048 frames. The hardware will interrupt 2 times per buffer. The application 44100Hz will also have 2 periods of 940 frames. ALSA will endeavor to keep the buffer as full as possible. Once the first period has been played, the third is transfered into the space the first one occupied while the second period is being played. (normal ring buffer behaviour). So, once a period has been transfered to the sound card hardware, it cannot be modified, even though the sound card has not yet played it from the DACs. As Direct Sound does not know anything about periods, I don't really know how you will be able to get it to work well with ALSA. I expect that some sort of double buffer will be required. Does Direct Sound have a concept of position of the ADC, and also a concept of where in the buffer it is sensible to fill with new samples? James
RE: Governance revisited (Wineconf report)
Robert Lunnon [EMAIL PROTECTED] wrote: On community, the wine project doesn't represent a community in the sense that Wine has an altruistic purpose to provide value to that community - It doesn't do that because the wine developer base doesn't measure important to Wine users and set policy to provide that value. This means Wine isn't a particularly good Product. Wine is a developers play-thing, Crossover is a Product ! Considering that CrossOver does pay the bill for some part and the major driving force behind Wine is and has been for a long time Codeweavers, no matter if you like it or not, I feel that a Wine with a much more loose acceptance policy but without the Codeweavers support it has now would be not half as far as it is. It would contain all sorts of hacks and workarounds for specific applications but be basically an unmaintainable beast and much further from providing a proper basic infrastructure with COM/DCOM and MSI support (to name some examples) as it should be done rather than as it might just barely work for some popular applications. A project driven mostly by users most likely is focusing on providing fast fixes that make a specific application work, while Alexandre is specifically trying to make sure that there is a clean (both technically and legally) infrastructure on which one can build for years to come. And which by coincidence will deliver a very good platform to build CrossOver from. It does mean that you can't expect it to immediately deliver support for all the apps you and many others might like but on the other hand it will mean that once new MS technologies get used more widespread it is much easier if not only possible then, to add them and provide faster support for newer apps. For some part it does boil down to I want to have fun now vs I want to have a technically sound infrastructure that can stand some time. In that sense Wine as is is maybe not a product in the sense of our fast and trigger happy marketing world but it is certainly a product in the sense of engineering and even more so than CrossOver. But then you pay something for CrossOver and not for Wine so maybe that is also why Wine can't and shouldn't really be a product in the sense of marketing. And as with all OpenSource projects, those that provide the most support in terms of code submissions, testing and documentation get to say the most and I think it has been clear that most of them are quite content if not happy with the modus operandi. Of course Alexandre can be a pain sometimes but he has been always with a reason as far as I can tell. Rolf Kalbermatter
Re: Whither msxml?
Hi our msxml idl flles are not in sync with psdk idl files. especially it still doesnot have SAX defines. And XML DSO definitions. (this is a bit compilicated). As msxml.idl includes xmldso.idl in PSDK headers. And msxml2.idl defines them in the idl file itself. As there are some incompatibilities with msxml2 and msxml3 (esp guids) But in the wine implementation, Mike wnet for a simplified approach with the msxml idl implementation. To reuse msxml.idl functionality in msxml2.idl, by including it. But we should not do that, if we want to support older versions of msxml. We should redo the idl's first inorder, to get msxml implemented correctly. Thanks, VJ On 9/23/06, Dan Kegel [EMAIL PROTECTED] wrote: For the past two years, I've helped UCLA's cs130 by pointing them at an area of Wine that needs improvement and helping them get patches submitted. For Winter 2007, I'm considering having them focus on msxml3. So I'm starting to look at bugzilla (see my previous message) and dig up demo apps and articles that might help us understand where wine's msxml needs to go. Man, oh, man are there a lot of pages about msxml out there. If anyone has tips on sore spots with Wine's msxml, please let me know. A few random notes: MSDN on msxml: http://windowssdk.msdn.microsoft.com/en-us/library/ms763742.aspx I see the spec file for msxml3 has a bunch of stubbed ordinals. Anyone know what they are? Can Wine handle the msxml3 jumpstart demo app from year 2000 yet? http://msdn.microsoft.com/library/en-us/dnmsxml/html/sax2jumpstart.asp Or the msxsl.exe wrapper app? http://www.microsoft.com/downloads/details.aspx?familyid=2fb55371-c94e-4373-b0e9-db4816552e41displaylang=en Programming The SAX2 3.0 Using MSXML (examples in vb6) http://xml.sys-con.com/read/40210.htm MSXML, It's Not Just for VB Programmers Anymore (examples in perl) http://www.perl.com/pub/a/2001/04/17/msxml.html Python XML http://safari.oreilly.com/0596001282 Here's a page that seems to show how to use msxsl and explains differences between msxml3 and msxml4: http://www.perfectxml.com/articles/xml/XSLTInMSXML.asp msxml3 examples: http://www.perfectxml.com/articles/xml/msxml30.asp A C++ Template Wrapper for the XML SAX API http://www.ddj.com/showArticle.jhtml?articleID=184401778 etc. etc. - Dan
AW: Call for Installer Bugs...
HelloThere are Bugs in Corel Draw:CorelDRAW 10: Bug #5801I know that CorelDRAW 11 installation fails at start but have not a version so cannot provide a bug report.CorelDRAW 12 is already reportedOffice 2003 installation fails on 0.9.21SimCity 4 needs special interaction to get it running: http://www.holarse-linuxgaming.de/h2006/space/SimCity+4Also a securom issue.Roland- Ursprüngliche Mail Von: Dan Kegel [EMAIL PROTECTED]An: "wine-devel@winehq.org" wine-devel@winehq.orgGesendet: Freitag, den 22. September 2006, 19:11:04 UhrBetreff: Call for Installer Bugs...Lots of progress has been made in fixing installer bugs lately,but there are probably many such bugs hiding in plain view still.It would be very helpful if people could look for bugs which:a) appear to be MSI or setupapi related, andb) occur in freely downloadable executables (e.g. trial versions)c) aren't already in bugzilla(seehttp://bugs.winehq.org/buglist.cgi?product=Winecomponent=wine-msikeywords_type=allwordskeywords=downloadbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDfor list)and file reports as appropriate at http://bugs.winehq.org.Thanks!- Dan
Re: LOSTWAGES: WWN 292 320 updates
On 23/09/06, Mirek [EMAIL PROTECTED] wrote: I also changed what benchmarks I had running at this years WineConf 3DMark2000, 3DMark2001SE and 3DMark2003... I have 3DMark2006 running and its beautiful, well beauty is in the eye of the beholder All of the test run in all three of the benchmarks to completion and there is only two test out of all test that have minor problems, and Henri has one of the test fixed in his tree. Can you post how i can get sources from his tree? The 3th and 4th 3DMark03 tests should pretty much work with current git, actually. The 4th test has some minor issues, afaik because of the wrong sampler types being bound. If there are other issues, those are separate bugs, and should probably be reported on bugzilla.
Re: RFC: wine ASIO driver available for testing
Jim White wrote: Eric Pouech wrote: I'm afraid submission (or integration in the Wine tree) will be problematic ASIO interface is copyrighted, and you need to sign an agreement to Steinberg for using the API. Are you sure about that? I see other GPL software using ASIO, like SndOBJ: http://music.nuim.ie//musictec/SndObj/main.html yes, check Steinberg's website IANAL, but including derivative work of a copyrighted API will not be possible. Then how did Wine get started? by using public information from Microsoft (and we're still are) A+
RE: Governance revisited
Jim White wrote: CodeWeavers Wine version is full of patches that Alexandre won't accept for WineHQ. Obvious proof that the Alexandre's policy isn't the only way to make a Wine that people value. In fact it proves that the WineHQ's patch process is not good enough to make Wine that people will pay for, while CodeWeavers' is. And that is wrong? Wine being Open Source that everybody can download I'm not sure how you would get many people to pay for it. Packaging alone won't be a good business model because there are many Linux distributors who will and do that too for no additional cost. Many more leave than stay. And your rudeness just helps that to happen. In case you didn't notice, your entire post was signal free. If Mike is trolling, you've been hooked. I agree with you that Vitaly's post wat unnecessarily rude and harsh, especially considering that Bob did submit a bunch of patches no matter if they were accepted into Wine or not. Rolf Kalbermatter
some wineconference pictures
Hi, Some Wine conference pictures from David and myself: http://gallery.kuschelt.net/main.php?g2_view=core.ShowItemg2_itemId=100617 Ciao, Marcus
Re: AW: Call for Installer Bugs...
Roland Kaeser wrote: Hello There are Bugs in Corel Draw: CorelDRAW 10: Bug #5801 http://bugs.winehq.org/show_bug.cgi?id=5801 I know that CorelDRAW 11 installation fails at start but have not a version so cannot provide a bug report. CorelDRAW 12 is already reported Office 2003 installation fails on 0.9.21 SimCity 4 needs special interaction to get it running: http://www.holarse-linuxgaming.de/h2006/space/SimCity+4 Also a securom issue. Roland Try reading Dan's email again. I've quoted below for you: - Ursprüngliche Mail Von: Dan Kegel [EMAIL PROTECTED] An: wine-devel@winehq.org wine-devel@winehq.org Gesendet: Freitag, den 22. September 2006, 19:11:04 Uhr Betreff: Call for Installer Bugs... Lots of progress has been made in fixing installer bugs lately, but there are probably many such bugs hiding in plain view still. It would be very helpful if people could look for bugs which: a) appear to be MSI or setupapi related, and b) occur in freely downloadable executables (e.g. trial versions) c) aren't already in bugzilla (see http://bugs.winehq.org/buglist.cgi?product=Winecomponent=wine-msikeywords_type=allwordskeywords=downloadbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED http://bugs.winehq.org/buglist.cgi?product=Winecomponent=wine-msikeywords_type=allwordskeywords=downloadbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED for list) and file reports as appropriate at http://bugs.winehq.org. Thanks! - Dan -- Rob Shearman
Re: my dsound/winealsa hacks
James Courtier-Dutton wrote: As Direct Sound does not know anything about periods, I don't really know how you will be able to get it to work well with ALSA. I expect that some sort of double buffer will be required. Does Direct Sound have a concept of position of the ADC, and also a concept of where in the buffer it is sensible to fill with new samples? When the application creates a buffer, it passes a structure to CreateSoundBuffer() that describes what kind of sound the buffer will contain, and the data include: - format (PCM/ALAW/ULAW etc) - number of channels - bits per sample - rate (Hz) and - size of the buffer it wants, in bytes The application can use Lock() to request s pointer to a buffer where it can write X bytes of sound data to, once it has written the data, it calls Unlock() and then DirectSound passes the data to the soundcard. World of Warcraft calls Lock to get a pointer where it can fill 4096 bytes (regardless of how big the period is, because DirectSound doesn't know about periods), writes the sound to the buffer and calls Unlock(), I'm using the async handler that invokes a function that reads the data from the intermediary buffer and passes it to the alsa). And yes, the app can call GetCurrentPosition() to find out the 'Play' and 'Write' positions in the buffer, play is where the soundcard is at the moment (eg. the position where I will read the data from and pass it to alsa), write is where the app can write the data to, currently I'm using 'playpos+period'. I haven't implemented the DirectSoundCapture, but I guess that it will work the same: the app calls Lock() and when the call returns it will receive a pointer to a buffer where X bytes of the captured data is, so if the app wants 4096 bytes, I'll have to wait until alsa has returned Y periods (where frames_to_bytes(Y) X) and then return to the app. I'm sorry, I didn't explain myself clearly in the previous mail :-/ tom
Re: Governance revisited
Jim White wrote: The whole quality and hack language is a red herring. To see that it is selective and subjective, just look at the code, try xrender.c for example. The difference is that presumably the person who submitted that code demonstrated that they understood the problem that they were trying to solve and convinced Alexandre that fixing it without hacks would lead to other problems or take months to code. At least one person has mentioned that there is no right of appeal, but there is - you can reply to Alexandre's rejection comment by doing the above. Another way of demonstrating that you understand the problem is to demonstrate that you understand the code by submitting patches to it, fixing smaller and easier to solve bugs. Steven cited the business at Wineconf of Alexandre never being proved wrong on a technical matter. Another straw man. The part of Alexandre's patch process that is the root of this conflict between Wine development-focused developers vs. Wine user-focused developers is that which consists of style and aesthetic considerations. CodeWeavers Wine version is full of patches that Alexandre won't accept for WineHQ. Obvious proof that the Alexandre's policy isn't the only way to make a Wine that people value. In fact it proves that the WineHQ's patch process is not good enough to make Wine that people will pay for, while CodeWeavers' is. I'm not sure I understand what point you are trying to make here. We at CodeWeavers have to retest each hack before each release to make sure that it still works and whether it is still necessary. We have a set of applications that we guarantee to support for each release, whereas there are no such requirements for a WineHQ release. This happens because we want to reduce the number of conflicts when we merge from WineHQ, but people probably wouldn't do this in Wine, since we generally only hear from users of certain applications when the applications don't work. -- Rob Shearman
Re: Governance revisited (Wineconf report)
Robert Lunnon wrote: 2. Adapt the patch acceptance process to create a right of appeal where a patch can be proven to be within the Patch Acceptance policy. Appeal should be independent of and binding on Alexandre - this eliminates one-to-one arguments about patch acceptability while still providing good excellent control. It will also have the effect of reducing Alexandres workload. I think this process would be completely redundant, so can you give an example of the patches that would meet the Patch Acceptance policy but have been rejected by Alexandre? BTW, you already have a right to appeal - it's a message to wine-devel with a well-reasoned argument. -- Rob Shearman
Re: Please create wine-msxml and wine-setupapi components in bugzilla
On 9/23/06, Tony Lambregts [EMAIL PROTECTED] wrote: I will add these categories to bugzilla as soon as I can but unfortunatly bugzilla and the AppDB and the main site are down since at least 9:00 AM MST Can you also add an 'installer' keyword? This would be helpful in keeping track of all installer bugs, whether they use msi, setupapi, advpack, etc. Thanks, James Hawkins
Re: Please create wine-msxml and wine-setupapi components in bugzilla
Tony Lambregts wrote: Louis Lenders wrote: I propose adding categories for msxml and setupapi now. Here are bugzilla queries that find quite a few bugs that are candidates for moving into those categories: Good idea. In case someone is going to add these catagories, please also add catagories for comctl32 and msvcrt. Regards Louis I will add these categories to bugzilla as soon as I can but unfortunatly bugzilla and the AppDB and the main site are down since at least 9:00 AM MST -- I have added these components http://bugs.winehq.org/describecomponents.cgi?product=Wine I just wanted to point out that we have a component wine-gui that is kind of a catch all that seems to include bugs in richedit, ddraw, comctrl, rebar and x11. I believe it would be a good thing if someone could do some janitorial on this to sort them out into there proper components. http://bugs.winehq.org/buglist.cgi?component=wine-guibug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED -- Tony Lambregts
Re: Governance revisited (Wineconf report)
On Saturday 23 September 2006 11:39, Steven Edwards wrote: As it stands right now the only reason technically good patches have been rejected is due to concerns over reverse engineering in another project. I don't see the difference between rejection and I won't put this in yet because I want to wait and see if X happens where X is something that might take I long time. This has been known to happen. In a couple of cases I (or somebody working for me) have had this response after going through extensive discussion about how a thing should be done and then doing it that way. Essentially, sometimes Alexandre has ideas about how something should be done but is unwilling to commit. Sometimes he will have a suggestion as to how something should be done and then change his mind later (reflecting the reality that nobody is right *all* of the time). The developers have the right to disagree and we do quite often. However we have mob rule with a benevolent despot and none of us really like to work any other way. If the project demographics change and the developers decide they don't like the system then, once again, we would change. The present system is self-reinforcing since people who run into significant problems will slow down on (or cease) their contributions. Things would be much better if there were a system in place that ensured every patch that didn't get in resulted in feedback. Right now it seems only a tiny fraction of patches that don't go in result in feedback. Contributors shouldn't feel like they have to go around begging for feedback every time a patch is not applied. Having a suitable system in place would also prevent the oops, missed that one, please resubmit situation. As things stand it actually involves less effort per patch to maintain a separate branch than to go through the begging-for-feedback process. Our governance is ultimately that Alexandre rules at the consent of the governed and while it can suck to be in the minority of mob rule from time to time, the mob agrees to keep Alexandre as the benevolent dictator for life. I for one hope this never changes as it seems to be the best system for making stable FOSS software. Yes, kind of. It would suck to establish a full-scale bureaucracy that might actually slow things down. On the other hand there seems to be a culture here that there is only One True Answer to every problem - in reality two people may disagree about the way a thing should be done and both be equally right. etc. As a Wine developer I do not develop for the users. I develop for my own needs and really don't care what the users have to say other than how it relates to my job. Bob and I are in somewhat different situations, given that we are developing for customers and both have customers using Winelib apps. I *was* also making some contributions for non work-related stuff but don't do that anymore, in large part because it's such a PITA to do so. I suspect there is also a significant difference between contributions extending Winelib functionality and contributions on Win32 compatibility. For Winelib functionality there is often a larger design element involved than Win32 were you are just trying to find the best way to implement the same functionality Windows has. -- Troy Rollo - [EMAIL PROTECTED]
Re: Governance revisited (Wineconf report)
On Saturday 23 September 2006 19:24, Kai Blin wrote: On WineConf, we decided against this. That would still slow down the overall patch submission speed. Consider you have a patch that's just fine, but before you sent that, I sent in ten patches with C++ style comments. Alexandre would now have to reply to ten patches with No C++ style comments before processing your patch. Everybody reading wine-patches could point out what was wrong with my patches. All this points to is a need to automate - sending this reply should be a one-click action. In fact this particular one (and no doubt many others) could be done by a reply-bot. Other things that could be done by a reply-bot: unacceptable patch format no patch found in message missing ChangeLog Perhaps a reply-bot should send out a copy of the guidelines the first time a new contributor submits something to wine-patches (or even to existing contributors when there have been changes to the guidelines). -- Troy Rollo - [EMAIL PROTECTED]
Re: Please create wine-msxml and wine-setupapi components in bugzilla
James Hawkins wrote: On 9/23/06, Tony Lambregts [EMAIL PROTECTED] wrote: I will add these categories to bugzilla as soon as I can but unfortunatly bugzilla and the AppDB and the main site are down since at least 9:00 AM MST Can you also add an 'installer' keyword? This would be helpful in keeping track of all installer bugs, whether they use msi, setupapi, advpack, etc. Thanks, James Hawkins Done. -- Tony Lambregts
Re: Governance revisited
On Sun, 2006-09-24 at 12:36 +0900, Dmitry Timoshkov wrote: Everyone who complaints about problems with patch acceptance policy seem to claim that, but my impression is that complaints are going from technically incompetent people, who just feels that the process can be improved, but can't explain it in developer's language (i.e. in technical words) how. One thing to be careful about is the ever growing trend of forming a very tightly coupled in-group. It is very easy to happen: most top developers work for the same company, they are extremely competent, and have the technical argument on their side. It is way too easy to feel righteous. This is a big problem, as it elevates the (already high) barrier to entry to a dangerous altitude. And the feedback is positive, as people are being put off, the in-group grows tighter, etc. The net is littered with amazingly smart and competent teams that killed projects via this process: *BSD, XFree86, etc. The human aspect of engineering a lively community is still a black art, so we have to tread carefully. Now, for the problem at hand: I think people's intuition that something is off has a seed of truth. And I find it difficult to say that because I think Alexandre does an amazing job. He is probably by far the person that had the largest (positive) influence on me from a professional perspective. To my mind, Alexandre is the Roger Federer and Michael Schumacher of software development. He is never wrong. And paradoxically, I think this is part of the problem. He is just too good for mere mortals. And I think a lot of folks get discouraged because it is just too much work to reach Alexandre's standards. This is even more difficult when you have to guess Alexandre's ideas about how you should properly solve the problem :) IOW, I think we're missing on an important human aspect of development: the need to compete, and show that you can do it better than the other guy. I always found it interesting on LKML, how Linus lets in sometimes dubious code, and that results in an effervescence of work! It's like bad stuff motivates people to show that things can be done better. I think Tom Tromey is onto something: http://tromey.com/blog/?p=252 So, what is the solution? Let in crappy code? Certainly not. And in all honesty, how can we ask Alexandre to let in stuff that he know sucks? I can appreciate how silly and difficult that would be. Bottom line, I don't know. At most I can say that sometimes I wish Alexandre would be a bit more impulsive, and just let (a selected few) things in that people want. Maybe this way we generate more excitement, and the tiny bit of quality drop we pay with would be worth it. YMMV :) -- Dimi Paun [EMAIL PROTECTED] Lattica, Inc.
Re: Governance revisited
On Monday 25 September 2006 13:16, Dimi Paun wrote: On Sun, 2006-09-24 at 12:36 +0900, Dmitry Timoshkov wrote: Everyone who complaints about problems with patch acceptance policy seem to claim that, but my impression is that complaints are going from technically incompetent people, who just feels that the process can be improved, but can't explain it in developer's language (i.e. in technical words) how. One thing to be careful about is the ever growing trend of forming a very tightly coupled in-group. It is very easy to happen: most top developers work for the same company, they are extremely competent, and have the technical argument on their side. Is it, or is it that the culture attracts yes men? Considering the text you quoted, who would want to work for CodeWeavers if they do differ in opinion (or, quite frankly, even if they don't)? People are more likely to go where they will be appreciated. We know we're right, because we're all very clever and we all agree. It is way too easy to feel righteous. The text you quoted exhibits far more serious problems than that. This is a big problem, as it elevates the (already high) barrier to entry to a dangerous altitude. And the feedback is positive, as people are being put off, the in-group grows tighter, etc. Indeed. Consider again the paragraph you quoted. Not only is it ad-hominem, it is a classic example of forestalling disagreement. Don't speak up to disagree or you'll be labelled incompetent. The accusation is far more likely to be more an indication of the maturity of its maker rather than a reflection of truth. If I say I've been coding since I was 14 (in those days home computers had less than 1% penetration in Australia), in assembly language since shortly after that and raw machine code not long after, having memorised the instruction set, then was widely recognised as the most capable Comp Sci student at the top university for Computer Science in the state, and that I only employ people who are proven geniuses, would it make a difference? While true, it's all irrelevant to the argument at hand. The accusation made above is also irrelevant. There is a valid point being made here - the black hole of patch submission *is* turning away developers. As one anecdote, one person currently on my staff - and note above - tried submitting patches to Wine in a personal capacity and would most likely still be submitting patches, but found the problems being discussed rendered it not worth his effort. I don't have to walk very far to find somebody else with the same opinion of Wine. The present system turns people off even before you've had time to learn whether they are capable or not. To my mind, Alexandre is the Roger Federer and Michael Schumacher of software development. He is never wrong. Everybody is wrong sometimes, although I have noticed that when somebody gets a sufficiently high reputation people stop noticing when they do get things wrong. I say this from the perspective of somebody who is sometimes in the situation of being the person with that reputation. As an example I have had people say to me it's easy to speak up when you get everything right, to which I have responded that I do get things wrong, you just don't notice when I do. Actually, some people arguing in support of the status quo have pointed out that Alexandre sometimes accepts things he previously rejected after an argument being made successfully in favour of a change - in such a case if we are calling things black-and-white wrong or right, then either the first decision or the revised one must be wrong. A rejection cannot be an incontrovertible sign of the wrongness of the contribution. Of course making an argument in favour of a particular contribution is somewhat challenging, if not impossible, when you're not being told why Alexandre perceives his solution to be better, which seems to be most of the time. Often the difference may be a mere matter of style - Alexandre seems to be more comfortable with copy-and-paste coding than I am, for example - but if it's more than a matter of style the rejection of the patch should give the reason. It saves no time to require people to chase up Alexandre for reasons unless by saving time you mean the person doesn't bother and so the change never gets in. This is even more difficult when you have to guess Alexandre's ideas about how you should properly solve the problem :) Actually, this is probably 90%+ of the problem. If patch submission weren't a black hole in which it either gets through or you have to go begging for feedback like an errant schoolboy, you wouldn't see nearly the volume of complaints you do. Worse are the times when you spend considerable time reworking a patch to his specifications and he still won't let it in. One of my staff had this problem, and the answer from Alexandre was that he wasn't going to let *anything* in covering that
Governance revisited
-- Forwarded message --From: Steven Edwards [EMAIL PROTECTED]Date: Sep 25, 2006 1:27 AM Subject: Re: Governance revisitedTo: Troy Rollo [EMAIL PROTECTED]On 9/25/06, Troy Rollo [EMAIL PROTECTED] wrote: The present system turns people off even before you've had time to learnwhether they are capable or not.Which is why we want to have the ambassadors project to help new people in to wine. The thinking goes that if we have some people to help hold the hands of new developers and the developers that are defacto maintainers of a certain section of code will respond to patches as they seem them, this will free julliard from having to answer every single patch with a reply. Now in the case of Ge where he was patching core functions of ntdll,kernel32,wineserver,etc I guess it would still fall to julliard to reply personally but in the case of other modules the experts in that area should take a step up and monitor wine-patches and say what patch X.Y.Z sucks and julliard most likely will not merge it.-- Steven EdwardsThere is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo -- Steven EdwardsThere is one thing stronger than all the armies in the world, and that is an idea whose time has come. - Victor Hugo
Re: Governance revisited
On Monday 25 September 2006 15:27, Steven Edwards wrote: Which is why we want to have the ambassadors project to help new people in to wine. ... if... the developers that are defacto maintainers of a certain section of code will respond to patches as they seem them... the experts in that area should take a step up and monitor wine-patches and say what patch X.Y.Zsucks and julliard most likely will not merge it.this will free julliard from having to answer every single patch with a reply. So when it comes to code, everything must be done exactly the right way, but when it comes to process defects, we're happy to hack around them? :-) Presumably nobody who's gratuitously abusive would be counted among those experts since it's not helpful to get feedback from somebody who's in a truckload of filters. Now in the case of Ge where he was patching core functions of ntdll,kernel32,wineserver,etc I guess it would still fall to julliard to reply personally but in the case of other modules It's also remains a haphazard process where things can (and so will) fall through the cracks. -- Troy Rollo - [EMAIL PROTECTED]
