As the Summer Of Code begins and new blood joins us all at once, I thought it'd be a good time to open a discussion on how we are doing as a project.
Questions to consider:
* Is Wine improving or is the regression rate matching the improvement rate?
* Are we producing a quality product, from the perspective of non-technical end users? (I appreciate this isn't a goal for everyone)
* Are we turning away potential developers for any reason? Could we do more to attract new hackers?
* Are the projects fundamental processes serving us well?
* Any other thoughts for improvement?
In case it's not clear, I'm talking about the project as a community adventure here rather than technical aspects of the codebase.
From my own perspective I think Wine is doing better than ever before.
What prompted this email is the realisation that in the past few days I've used Wine nearly every day to run a variety of apps - from games to utilities - and it's succeeded with every single one. Not always perfect but always good enough. I am no longer surprised when Wine runs an app correctly as I was when I first came to the project, these days I nearly take it for granted. Though this may be due to having developed a feel for what will work and what won't :)
So clearly we're doing something right ... I also think we are doing OK with attracting and keeping new hackers. The influx of new Direct3D talent lately is fabulous for instance. The experiences of our SoC students will be useful in assessing how to improve the learning curve and we need to tap this resource better than we did last year.
In other words, I think we're doing pretty well. I feel more positive about the project that I have done for a long time. It seems like as Win32 stagnated and slowed down over the past 6 years we've been able to turn the tide and add our own code faster than Microsoft can, which is the tipping point.
So areas for improvement?
* We seem to be doing very well in recruiting hackers who work on one particular DLL or area and solidly improve that, but a less well when it comes to 'general purpose' hackers who just take random apps and make them work.
It might just be that I'm out of touch but I don't see as much patch traffic these days along the lines of "This patch set fixes XYZ app" followed by 6 patches to 6 different DLLs. Discussion on IRC/wine-devel is
* No clear roadmap to 1.0 - for 0.9 we had Dimis TODO list and it was quite satisfying to see them go green as tasks were completed. I guess we have a 1.0 TODO list too but I never see any updates to it :(
* Integration with other projects is still a weak area. Desktop/kernel/X integration could all use some work. I know I know, I'm guilty in not doing my bit here too .... maybe I will find my hack-fu returning sometime soon and work on the fullscreen patch again :)
* App specific patches. Well I don't expect policy here to change anytime soon but extreme cases like the WoW VMA layout problem which affects tons of users do highlight the issue.
* A few random things I already got into arguments about (forums, libwine api etc) :)
What do you guys think?
thanks -mike
Mike Hearn wrote:
- Are we turning away potential developers for any reason? Could we do more to attract new hackers?
Yes. The attitude on wine-devel could be appreciative of the progress that Darwine has made and the hard work its developers rather than disdain. That way developers working on Wine for Mac OS X might be more inclined to focus their activity on Wine for Intel Mac OS X here.
I only speak for myself, so I don't know whether the developers feel that way. But I do know I set up Darwine because of the antagonistic and dismissive tone here when I tried to discuss Darwin & Mac OS X development ideas.
In fact we just happened to be discussing this very topic the day I found out about the SF CCA (Ken Thomases patch meant I had to attend to a bit of admin):
Jim White wrote:
Alexandre Julliard wrote:
Jim White jim@pagesmiths.com writes:
It was trying to discuss things like PPC emulation and Quartz display on wine-devel that led to the creation of the Darwine list. Obviously wine-devel has plenty of traffic on it already, and certainly doesn't need to deal with topics that are not cross-platform. And while Darwine is not a fork, we certainly have concerns that are not identical with Wine's.
I don't see why that would be the case, good MacOS support is certainly one of Wine's goals. I think you should really consider becoming real members of the Wine community instead of remaining in your own private community; otherwise the Mac port will always be a second-class citizen in the Wine world, and I don't think anybody wants that.
Mac OS X did not get the respect you describe from the Wine (or any Windows community) B.I. (Before Intel).
Refer to the wine-devel archives for 2002 if you want gory details on why Darwine was established.
And I repeat, Darwine is not and has never been a fork of Wine. The only code we maintain is stuff that either hasn't yet made it into WineHQ CVS or never will.
Darwine is a "private community"? "Second-class citizen in the Wine world"? Uh, yeah. I'm really feeling the love here.
I posted last week that Darwine got first place in the SF CCA awards, an event that involved the casting of more than 250,000 votes. A surprising result considering Darwine doesn't support end users and doesn't have anything for them to run. But it happened, and like the CCA contest rules said, the prize is getting to feel proud and brag a little.
Was there a single warm fuzzy from anyone on this list? No. Fortunately we get them from Macfolk on a regular basis.
Did it get mentioned in Wine Weekly? Nope. And we know it got out before the deadline since the Google Picassa posting on the next day got plenty of ink.
Oh, wait. The award *did* get mentioned in Wine Weekly issue #311. Hmmm, except that not only is Darwine not in the subject line, it isn't mentioned at all. There is some whining that Wine didn't win though. Thanks guys.
http://www.winehq.org/?issue=311#SourceForge%20Community%20Choice%20Awards
The reason that Darwine won the award is because a *lot* of people want to run Windows applications on Mac OS X. In fact you're lucky most of them have PowerPC Macs. Otherwise WineHQ would get overwhelmed by the horde when something ships.
Lest you think I'm complaining here, I'm not. As Alexandre said, no one wants the Mac port to be anything other than first class. Darwine exists because wine-devel is uninviting to Mac OS X developers. I'm suggesting that more honey and less vinegar is in order.
I think WineHQ should set up a wine-macosx list. It worked for me.
Jim White
On Mon, 29 May 2006 23:47:26 -0700, Jim White wrote:
But I do know I set up Darwine because of the antagonistic and dismissive tone here when I tried to discuss Darwin & Mac OS X development ideas.
I have yet to see anybody give Emmanuel and the other Darwine developers anything but respect. The "dismissive tone" you received are because you are not a developer and like most open source projects, Wine has a simple currency -> those who do the work get the respect.
Tell people they should work on a port to a platform they don't use and you'll be told to do the work yourself. Dismissive? Maybe. Unexpected? I'd hope not.
Darwine is a "private community"? "Second-class citizen in the Wine world"? Uh, yeah. I'm really feeling the love here.
You've misinterpreted a statement of fact as some kind of insult. Work that doesn't take place on wine-devel is invisible to most Wine developers, it's as simple as that.
Oh, wait. The award *did* get mentioned in Wine Weekly issue #311. Hmmm, except that not only is Darwine not in the subject line, it isn't mentioned at all. There is some whining that Wine didn't win though. Thanks guys.
Look, there are various reasons why some developers - and it seems maybe Marcus is in that group - are uncertain as to whether a Mac port is a good thing. This has been explained to you before. So why do you act shocked when an individual is "unsure whether to be happy or sad" over the news?
Lest you think I'm complaining here, I'm not.
You clearly are complaining, there's no other way to describe it.
-mike
Mike Hearn wrote:
Tell people they should work on a port to a platform they don't use and you'll be told to do the work yourself. Dismissive? Maybe. Unexpected? I'd hope not.
I never told anyone they should work on anything. I've got an idea for a processor emulation technique to enable Intel Windows applications to run on PowerPC Mac OS X with high efficiency. My project plan to use Intel Darwin to port Wine (one of the necessary steps) has worked out beautifully. Did you notice it won the 2006 Sourceforge Community Choice Awards in the Desktop Environment category?
I'm looking forward to Wine for Intel Mac OS X development moving to WineHQ so Darwine's focus can return to the interesting part.
Lest you think I'm complaining here, I'm not.
You clearly are complaining, there's no other way to describe it.
Actually the only complaint I've made has been about you. I appreciate you making it clear to everyone who's got the attitude problem here.
Jim White wrote in Darwine on 2006-05-24:
Jeremy White wrote:
Speaking of a better way...is there any reason we couldn't shift the bulk of this development work over to WineHQ and to the Wine develoment mailing lists? That's where we do all of our work.
... Of course, then you'll be subject to Alexandre's oppresive regime :-/.
I don't have a problem with Alexandre. It's guys like Mike Hearn that give me heartburn...
While I realize it was a long email, it's clear you got to the end. The point of the email was to make a suggestion for action at WineHQ, creating a wine-macosx mailing list, having provided a sound justification for it.
Jim
Jim White wrote:
Jim White wrote in Darwine on 2006-05-24:
Jeremy White wrote:
Speaking of a better way...is there any reason we couldn't shift the bulk of this development work over to WineHQ and to the Wine develoment mailing lists? That's where we do all of our work.
... Of course, then you'll be subject to Alexandre's oppresive regime :-/.
I don't have a problem with Alexandre. It's guys like Mike Hearn that give me heartburn...
While I realize it was a long email, it's clear you got to the end. The point of the email was to make a suggestion for action at WineHQ, creating a wine-macosx mailing list, having provided a sound justification for it.
I wouldn't object to a mailing list, but I would really like to see the Darwine developers using wine-devel for discussing all wine-connected development.
P.S. Don't let the opinions of one person put you off wine-devel. As Alexandre as tried to make clear in the past, they don't represent the opinions of the majority of the people active on wine-devel.
On 5/30/06, Jim White jim@pagesmiths.com wrote:
Was there a single warm fuzzy from anyone on this list? No. Fortunately we get them from Macfolk on a regular basis.
Press/news announcements almost never garner warm fuzzies on the devel list. That's not to say they're not appreciated; I think a lot of people in the community genuinely like to hear such things. It's okay, don't worry. It's takes a while to realize that silence on this list doesn't imply apathy, rather it usually means tacit improval. For example, see the recent LJ article I sent a message to the list about.
Did it get mentioned in Wine Weekly? Nope. And we know it got out before the deadline since the Google Picassa posting on the next day got plenty of ink.
Right.. you noticed that Dan and I both noticed it before you. So to a lot of developers that wasn't news. That's ok.
Oh, wait. The award *did* get mentioned in Wine Weekly issue #311. Hmmm, except that not only is Darwine not in the subject line, it isn't mentioned at all. There is some whining that Wine didn't win though. Thanks guys.
I've been nothing but supportive of Darwine in everything I've written. I'd like to think WWN provides the biggest window into the Wine development process of anything else the project does. The rest of the world not on wine-devel knows more about Wine through WWN than any other way. I'm fairly confident when I say that every Wine developer would like to see Wine runnng on Mac OS X. It's certainly my personal view, so that's the one that goes into WWN. I regularly browse the Darwine mailing list and you may have seen threads from there appear in WWN. Did you by any chance read this section of WWN from last month? http://www.winehq.org/?issue=311#News:%20Windows%20on%20Macintels
Now, as far as not feeling the love, I'd strongly encourage as many Darwine developers as possible to attend Wineconf in September. I know last year I personally invited Pierre.
Anyway, don't take code criticism too personally on wine-devel. I really don't understand why you think the whole community is against you when I think the whole community is on your side. (Anyone want to prove me wrong?)
-Brian
Brian Vincent wrote:
... Now, as far as not feeling the love, I'd strongly encourage as many Darwine developers as possible to attend Wineconf in September. I know last year I personally invited Pierre.
Huh? Why is WineConf private? Shouldn't a conference for an Open Source project like Wine be open to all people interested in attending, instead of needing invitations?
Darwine is open to everyone who wants to join. Currently 280 subscribe to darwine-devel and no one is ever refused.
But seriously. Jeremy and Mike both ask what to do to get more developers to participate at WineHQ. I explain what needs to be done and still I get no expression of support.
I get a lot of people I'm telling me I'm wrong to feel how I feel. What's the point of that?
I have no way of knowing specifically why Wine for Mac OS X developers focus their activity at Darwine rather than WineHQ. All I can relate is my experience.
All I did was create a mailing list. I'm pretty sure that would work for WineHQ too.
Maybe call it wine-macos instead of wine-macosx so it doesn't become dated when Apple revs the name.
And maybe I've been being too subtle for the rough & tumble of wine-devel. I'd be surprised if much developer activity took place on wine-macos.
If you set it up, they will come.
Jim
Huh? Why is WineConf private? Shouldn't a conference for an Open Source project like Wine be open to all people interested in attending, instead of needing invitations?
Just for the record, WineConf is now and always has been a) Open to all b) Free of charge c) Focused on Wine developers and it has clearly been advertised and described as such through the years.
A personal invitation may have been extended to someone out of concern that they weren't subscribed to wine-devel, but no one need be invited to come.
Cheers,
Jeremy
Jeremy White wrote:
Huh? Why is WineConf private? Shouldn't a conference for an Open Source project like Wine be open to all people interested in attending, instead of needing invitations?
Just for the record, WineConf is now and always has been a) Open to all b) Free of charge c) Focused on Wine developers and it has clearly been advertised and described as such through the years.
A personal invitation may have been extended to someone out of concern that they weren't subscribed to wine-devel, but no one need be invited to come.
Geez. Clearly I am being too subtle. Guess I needed to add a ;-) rather than my Rodney Dangerfield "But seriously".
So why are you not supporting setting up a wine-macos(x) list @ WineHQ?
Jim
Jim White wrote:
So why are you not supporting setting up a wine-macos(x) list @ WineHQ?
Jim
Hi, I'm just a user, but may I suggest because : - Wine for Mac OS X has basically the same relation to Wine for Linux as Wine for Solaris and Wine for *BSD have, and these don't have special mailing lists (AFAIK) - the special components needed for OS X (graphics, audio) should be treated the same as any of these components for Linux (for audio : alsa, oss) - The traffic on Darwine-devel is quite low, why divide? - and anyway in a few months I'm sure there will be more developers and users of Wine on Mac than on Linux so we'd better consolidate in one place.
(I'm not even saying that the principal contributer/sponsor of Wine for Linux, CodeWeavers, is, I believe, also the main worker on Wine for Mac OS X at the moment)
Just my 2 euro cents
Geez. Clearly I am being too subtle. Guess I needed to add a ;-) rather than my Rodney Dangerfield "But seriously".
Um, yes. I took it as an accusation of an event I have helped to plan, not as a jest.
So why are you not supporting setting up a wine-macos(x) list @ WineHQ?
Hmm. I feel that you are putting words in my mouth. I told you in a private email that I did not know whether it was a good idea or not, although I did say I felt strongly it should be users only.
I was hoping you would propose it in a clean email thread so that subject, and that subject alone, could be discussed and debated.
So, yes, I am not actively supporting it, but I'm not actively against it either.
Cheers,
Jeremy
On Tue, 30 May 2006, Jim White wrote: [...]
So why are you not supporting setting up a wine-macos(x) list @ WineHQ?
I think the goal is to bring the Wine on Intel Macs development efforts into the mainline.
That means committing the Audio driver into the main tree (done), doing the same for the Quartz driver as soon as possible, and extends to the communication channels. Wine developpers normally subscribe to wine-devel so that's where Wine on Intel Macs discussions should take place. Otherwise, whether they take place on darwine-devel or wine-macosx@winehq won't make a difference (except we could end up with development discussions being fragmented into three mailing lists instead of only two).
Now there could be an argument for creating a separate wine-macosx list if traffic on it or wine-devel was unbearably high but I don't think we're there yet, so it's better to keep everything in one place.
On Tuesday 30 May 2006 01:17, Mike Hearn wrote:
As the Summer Of Code begins and new blood joins us all at once, I thought it'd be a good time to open a discussion on how we are doing as a project.
Questions to consider:
Is Wine improving or is the regression rate matching the improvement rate?
Are we producing a quality product, from the perspective of non-technical end users? (I appreciate this isn't a goal for everyone)
Are we turning away potential developers for any reason? Could we do more to attract new hackers?
Are the projects fundamental processes serving us well?
Any other thoughts for improvement?
Well, winecfg need more improvements to be really usable (ie. understandable) by a non-technical end user. Anyway we need to improve wine base installation: users should not have to always use winecfg to configure wine, many things must be detected at installation/runtime
We must work on (free/gnome/kde) desktop integration too
For developers, i think we miss (in wiki): - wine developer begining HowTo - wine comiting process (explaining why AJ never respond when patches are refused :p ) - simili-doxygen APIs (to found what is implemented/how/where some docs, and status)
In case it's not clear, I'm talking about the project as a community adventure here rather than technical aspects of the codebase.
From my own perspective I think Wine is doing better than ever before.
What prompted this email is the realisation that in the past few days I've used Wine nearly every day to run a variety of apps - from games to utilities - and it's succeeded with every single one. Not always perfect but always good enough. I am no longer surprised when Wine runs an app correctly as I was when I first came to the project, these days I nearly take it for granted. Though this may be due to having developed a feel for what will work and what won't :)
So clearly we're doing something right ... I also think we are doing OK with attracting and keeping new hackers. The influx of new Direct3D talent lately is fabulous for instance. The experiences of our SoC students will be useful in assessing how to improve the learning curve and we need to tap this resource better than we did last year.
In other words, I think we're doing pretty well. I feel more positive about the project that I have done for a long time. It seems like as Win32 stagnated and slowed down over the past 6 years we've been able to turn the tide and add our own code faster than Microsoft can, which is the tipping point.
So areas for improvement?
We seem to be doing very well in recruiting hackers who work on one particular DLL or area and solidly improve that, but a less well when it comes to 'general purpose' hackers who just take random apps and make them work.
It might just be that I'm out of touch but I don't see as much patch traffic these days along the lines of "This patch set fixes XYZ app" followed by 6 patches to 6 different DLLs. Discussion on IRC/wine-devel is
No clear roadmap to 1.0 - for 0.9 we had Dimis TODO list and it was quite satisfying to see them go green as tasks were completed. I guess we have a 1.0 TODO list too but I never see any updates to it :(
If you are speaking about wine-bugs task list, i think the wiki is more appropriate for that. It will be cool to have a time-line roadmap as trac (http://www.edgewall.com/trac/)
- Integration with other projects is still a weak area. Desktop/kernel/X integration could all use some work. I know I know, I'm guilty in not doing my bit here too .... maybe I will find my hack-fu returning sometime soon and work on the fullscreen patch again :)
:)
- App specific patches. Well I don't expect policy here to change anytime soon but extreme cases like the WoW VMA layout problem which affects tons of users do highlight the issue.
For WoW the problem is really on WoW code. Proposed patch (who try to adapt VM layout) only works for part of users. I don't understand how blizzard made to handle their memory that way
- A few random things I already got into arguments about (forums, libwine api etc) :)
What do you guys think?
thanks -mike
Regards, Raphael
Got a reply from somebody who would rather remain anonymous:
---------------------------------------------------------------------
This may be just me, but the learning curve is probably much more steep for a "general purpose" hacker than for a particular dll. I have some apps I'd like to get working, but I find that the underlying problems tend to take a long time to find, and when I do find them they tend to fall into one of these categories: -relatively simple to hack around, but difficult to really fix -involves implementing or fixing something that's way beyond my skills -it's unclear how to properly fix the problem
None of those result in a patch. Usually they only will only result in a bug report or (if it's something the developers are aware of) nothing at all. On the other hand, I'm not really interested in working on a particular dll; I just want my apps to run correctly on wine with as little kludging around things as possible.
---------------------------------------------------------------------
... which is certainly true, it has a steep learning curve. But I think we need more people doing such things :/
thanks -mike
"Mike Hearn" mike@plan99.net wrote:
Got a reply from somebody who would rather remain anonymous:
This may be just me, but the learning curve is probably much more steep for a "general purpose" hacker than for a particular dll. I have some apps I'd like to get working, but I find that the underlying problems tend to take a long time to find, and when I do find them they tend to fall into one of these categories: -relatively simple to hack around, but difficult to really fix -involves implementing or fixing something that's way beyond my skills -it's unclear how to properly fix the problem
None of those result in a patch. Usually they only will only result in a bug report or (if it's something the developers are aware of) nothing at all. On the other hand, I'm not really interested in working on a particular dll; I just want my apps to run correctly on wine with as little kludging around things as possible.
... which is certainly true, it has a steep learning curve. But I think we need more people doing such things :/
I can't believe that writing a good test case showing the bug and adding it to the Wine test harness is such hard thing to do for a good Windows developer who already knows what he expects from a particular Win32 API. Once the test is in the Wine tree that becomes *much* easier to pinpoint the bug and decide what is the real fix for it.
On 5/30/06, Dmitry Timoshkov dmitry@codeweavers.com wrote:
I can't believe that writing a good test case showing the bug and adding it to the Wine test harness is such hard thing to do for a good Windows developer who already knows what he expects from a particular Win32 API.
But most developers who come to Wine are not Windows developers, they are Linux developers who want to run an app or game. Often finding the bug is much harder than fixing it these days. It takes practice to learn how to read a relay trace or debug a mysterious crash.
There is documentation showing how to do this with examples but I guess it could go further.
Once the test is in the Wine tree that becomes *much* easier to pinpoint the bug and decide what is the real fix for it.
Yes, sometimes. Some things are hard to show with unit tests. Consider the case of "I run my game and the audio glitches". It turned out that for some people that was due to scheduling problems and a fix is to use POSIX capabilities to add SetThreadPriority support to the wineserver. For somebody new to Wine that would be a very difficult problem to track down and fix, and hard to unit test.
I agree that proving a problem using a test is a good way to start for many bugs however, especially message related ones.
thanks -mike
"Mike Hearn" mike@plan99.net wrote:
But most developers who come to Wine are not Windows developers, they are Linux developers who want to run an app or game. Often finding the bug is much harder than fixing it these days. It takes practice to learn how to read a relay trace or debug a mysterious crash.
I've quoted the whole e-mail, and it implied that the bug already has been found but a real fix was not clear.
Is Wine improving or is the regression rate matching the improvement rate?
Are we producing a quality product, from the perspective of non-technical end users? (I appreciate this isn't a goal for everyone)
Note that I intend to make another big push for the use of CxTest shortly so that we can start to build application level regression tests, and hopefully start making application level claims of reliability.
(Today, I believe that Alexandre formally guarantees that Solitaire will work, but I believe that's about it <grin>).
I had hoped to have regular application testing be on the 1.0 list.
On a side note, there is something that worries me a bit. Specifically, it appears that we have a dirty secret about the regression tests - that they only work reliably on Alexandre's machine. Is that true? Shouldn't we do something about that? Or am I on crack, and lots of people run all the tests cleanly every day...
Cheers,
Jeremy
Jeremy White wrote:
On a side note, there is something that worries me a bit. Specifically, it appears that we have a dirty secret about the regression tests - that they only work reliably on Alexandre's machine. Is that true? Shouldn't we do something about that? Or am I on crack, and lots of people run all the tests cleanly every day...
Hi Jeremy,
No crack: you can see the variation graphically. Because bug 3666[1] has become stale, I sent a winetest report[2] from an SMP machine to demonstrate problems running Wine on the terminal server at our office: a Dual AMD Opteron with Fedora Core 5 x86 (32-bit software only). Then, I sent another report from a single CPU machine. The former report had many more failures.
[1] http://bugs.winehq.org/show_bug.cgi?id=3666 [2] http://test.winehq.org/data/200605161000/#Wine
(Later, I suppose should run the tests on the same machine with an SMP kernel and a normal kernel.)
Andrew
On 5/29/06, Mike Hearn mike@plan99.net wrote:
- Is Wine improving or is the regression rate matching the improvement rate?
It's hard for me to answer this question, because I don't regularly run many apps with Wine, but it seems like we've had reports of a lot of regressions lately. A bigger issue is how we should deal with regressions. Most of the bug reports we get are of the type, "This app used to work, now it doesn't..." and we have to ask the reporter to run a regression test. I know these tests are crucial, but they take a long time and many users don't bother going through that process. Even more integration with the AppDB might help with this process. Ideally we would like to inform the user of a "Last known working release", which would be the Wine release that worked with this app. Looking at a sample AppDB entry, I guess this would be the Testing Results->Wine Version->Runs? field. If the 'regression' keyword is provided for a bug, and the bug is linked with an app in the AppDB, we could provide the "Last known working release" info to the tester, so they know where to start testing.
- Are we turning away potential developers for any reason? Could we do more to attract new hackers?
It seems a lot of developers are frustrated by our development model (one pathway to commit) and by the amount of effort it takes to get a patch committed. I say too bad for them. We have a great devel model that substantially reduces the amount of bugs and bad code getting into CVS.
- Any other thoughts for improvement?
One of my biggest concerns about the wine development process is lack of direction. A lot of the experienced devels know what they plan to do on an individual level, but it's hard for people new to wine to grasp the whole picture of what needs to be worked on. We have TODO lists, 1.0 goals, and janitorial tasks etc., but sometimes those items lack meaning, even to me. I really enjoy reading KDE's feature plan page [1]. They list in detail what exactly needs to be implemented/fixed. One could say that we have a different development model, in that our goal is to get application x, y, and z to work, but that model is inefficient, and we usually don't work that way anyway. There are features that are missing, important bugs that need to be fixed, and it would be great if we could all take the time to list somewhere, probably on a wiki page, the most important things that need to be implemented/fixed. On a larger scale than individual bugs and features, we could also list dlls that need more attention than others, e.g., ole32.dll is more critical than cards.dll. As Dmitry pointed out, test cases are very important to the devel process, and typically they aren't very difficult to write. Maybe we could have a list of areas that need more testing.
Looking at wiki.winehq.org, I don't see anything that shouts out, "Hey! New to Wine development? Check this page out." I'd like to see a one-stop shop that eases a new developer into the process. We could point them to the devel documentation, provide some beginner tips, and show some areas of Wine that they can work on to dip their toes in the water (Janitorial, tests, etc). I'm sure there are lots of new developers that decide they want to work on Wine, stop by, and leave because they have no idea where to start. Granted they should put more effort into it, but it wouldn't hurt to cater to these new developers. We can always use more devels, right?
[1] http://developer.kde.org/development-versions/kde-4.0-features.html
* James Hawkins truiken@gmail.com [30/05/06, 18:32:37]:
- Are we turning away potential developers for any reason? Could we do more to attract new hackers?
It seems a lot of developers are frustrated by our development model (one pathway to commit) and by the amount of effort it takes to get a patch committed. I say too bad for them. We have a great devel model that substantially reduces the amount of bugs and bad code getting into CVS.
I agree here. The effort to figure out how to do the patches correctly is pretty high, and you need a lot of frustration tolerance at first. I'm not sure if I would have stayed around if it wasn't for Summer of Code 2005. Once you get past this, and figured out how to write your code so Alexandre will commit it, development is quite fun. I also agree that the whole process improves code quality. It still is hard in to get started. Unfortunately I don't really know how this can be changed.
I think that the effort by some of the more experienced coders to provide feedback to patches already helps a lot.
Cheers, Kai
On Wednesday 31 May 2006 12:43, Kai Blin wrote:
that the whole process improves code quality. It still is hard in to get started. Unfortunately I don't really know how this can be changed.
I think we could focus more on the motivation aspects of becoming a Wine developer. Yes, you need specific technical skills but you also have to align with Wine's goals before you are willing to make an enduring effort. And it apparently also takes courage to invest in Wine, because of what Microsoft could do to hamper Wine.
So if we can convince more people of the usefulness and legality of Wine we will attract more skilled developers. For example, we should stress the fact that Wine is a net gain for open source if it allows a user to switch from Windows to Linux, even though the program running on Wine is "proprietary Windows bloatware".
We should even stress that Wine is a *temporary* solution in many scenario's, Wine is not a threat to a native ports! If Wine brings users to Linux it actually helps create a user base that in turn justifies the additional cost of a native port.
At the same time we should think of exciting new possibilities that an open source implementation of the Windows API brings to the table.
-Hans
On Wed, 31 May 2006 14:57:06 +0200, Hans Leidekker wrote:
At the same time we should think of exciting new possibilities that an open source implementation of the Windows API brings to the table.
At past WineConfs the possibility of reaching out to Windows developers was raised, by making it easier for Windows guys to use our code. For instance if they have built their app on an API but need a bugfix or feature Wine is the obvious candidate but right now we make it hard for them to do that. We're very Linux/UNIX centric (eg build system ...)
thanks
Mike Hearn wrote:
As the Summer Of Code begins and new blood joins us all at once, I thought it'd be a good time to open a discussion on how we are doing as a project.
Questions to consider:
- Is Wine improving or is the regression rate matching the improvement rate?
Since I have Administrated both the AppDB and Bugzilla for quite a while I would say that this is about even with regressions keeping pace with improvements. What seems to be improving is the rate at which the regressions are caught and fixed.
Catching regressions early is critical to fixing them and the faster release cycle helps but only if the user upgrades in a timely fashion.
Some programs have been Rock Solid for years (eg: SimCity 3000) while others are are not. Myst worked for years and then fell victim the Windows Management rewrite and I have just recently been able to run it again but it is still very unstable.
Over All I am seeing a lot more activity in bugzilla [1] since we went to 0.9.0 as I am sure most of you are aware. Some may call it a flood but over all I think this has been a good thing. The real downside to this is that it takes a lot more of my time to go through each email and see if I can assist and that the proper bug links are in place.
[1] 501 in Apr 2005 1492 in Apr 2006
610 in May 2005 1174 in May 2006
- Are we producing a quality product, from the perspective of non-technical end users? (I appreciate this isn't a goal for everyone)
Going to winecfg has made the product more user friendly but we are still seem to be a long way away from "It Just Works" in a lot of cases.
In the interm I believe the AppDB has helped a lot. I think that the work that we have put into it has paid off fairly well to a point. So far we have added:
- Applications Maintantainers that can modify application entries on an App by App basis.
- Notification emails so that people (Administrators, Maintainers and Monitors) kept up to date on changes to applications.
- Bug links to track bugs affecting an application.
- Test results to track how well an application runs on a Wine version. and help spot regressions
- Lots of small improvements.
Lots of thanks to Chris Morgan and Johnathan Ernst and everyone else that submited patches to get it to its current state.
However there are a number of things that are needed still.
- We need a general search page.
- It would be nice to have the ability for people to have classes of rights so that they can add/change/delete certain fields IE: "Application Description" without having to become a maintainer or administrator.
There is a todo list here as well. http://wiki.winehq.org/AppdbInfo
If anyone has experience with PHP or wants to gain some, there is a real need for your help.
- A newsgroup set up that works the same as bugs so that anyone can see the notifications generated by the AppDB.
I asked Jeremy Newman for this before but I don't think that I explained the need for it very well. (trying again)
- More Maintainers
If you have an app that you run on a regular basis please consider becomeing a maintainer for that app.
- More Administrators
The Application Queue is not being processed in a timely fashion.
For myself I am busy with my day job, working on upgrading bugzilla, and burnt out/frustrated trying to keep up with Application submitions (I am too soft hearted to reject some submittions that probably should be rejected). Keeping up with the Application Queue is a tough job (for me at least, at this time) and at this point just reviewing some of the submittions makes my head hurt.
Alexander Nicolaysen Sørnes and KillerTux have picked up some of the slack but I think we could use some more help.
This job is time consuming, tedious, thankless and does not come with a paycheck. It requires attention to detail and is a position of trust and responsability. On the plus side it does NOT require any programming skills. So... if this sounds like something you would like to do please send an email to appdb@winehq.org explaining why you you think you would be a good AppDB Administrator. (The guys in the white coats will be around ASAP)
Thanks
--
Tony Lambregts.
Hi,
Tony Lambregts wrote:
In the interm I believe the AppDB has helped a lot. I think that the work that we have put into it has paid off fairly well to a point. So far we have added:
- Applications Maintantainers that can modify application entries on
an App by App basis.
- Notification emails so that people (Administrators, Maintainers and
Monitors) kept up to date on changes to applications.
Bug links to track bugs affecting an application.
Test results to track how well an application runs on a Wine
version. and help spot regressions
- Lots of small improvements.
Lots of thanks to Chris Morgan and Johnathan Ernst and everyone else that submited patches to get it to its current state.
However there are a number of things that are needed still.
We need a general search page.
It would be nice to have the ability for people to have classes of
rights so that they can add/change/delete certain fields IE: "Application Description" without having to become a maintainer or administrator.
There is a todo list here as well. http://wiki.winehq.org/AppdbInfo
If anyone has experience with PHP or wants to gain some, there is a real need for your help.
- A newsgroup set up that works the same as bugs so that anyone can
see the notifications generated by the AppDB.
I asked Jeremy Newman for this before but I don't think that I explained the need for it very well. (trying again)
The AppDB is a great idea, but why is it so poorly integrated in the main page? The same question goes to the Bugtracker and the Wiki where the situation is even worse. On most web pages you have a navigation bar which remains the same as long as you are on the same page. But if you enter the AppDB or the Bugtracker you have the feeling that you are on an entirely new page which only have a link back to the main page and a similar design. If you enter one of the wiki pages the situation is even worse because it does not even have a link to the main page in the navigation bar. Is this a design decision or is it just the lack of time which prevents IMHO proper integration?
Another thing I'd like to be changed is the "Paid Support" Link. Now it leads you direct to the codeweavers homepage. Well I'd not expect such a behaviour from a menu link. I would propose it to change it so that it opens a new window with the codeweavers page (ok I know that some people don't like that) or to make a new page under "Paid support" which contains the link to codeweavers (and perhaps others, if existent)
I'm a PHP and C/C++ coder and I thought about working on the todo list but I don't like the idea of starting to work on something which won't satisfy me in the end. I don't even care what you think about me or my ideas. There are other projects which needs to be worked on, too. Don't get me wrong, wine is a super project and I use it daily to run my favorite instant messenger, but I think the climate is a bit cold for my taste. I thought a while whether to send the email here or to /dev/null, but I thought I should inform you what I don't like ;)
Greetings KGJ
On 6/1/06, KGJ WOLFProductions@gmx.de wrote:
Hi,
The AppDB is a great idea, but why is it so poorly integrated in the main page? The same question goes to the Bugtracker and the Wiki where the situation is even worse. On most web pages you have a navigation bar which remains the same as long as you are on the same page. But if you enter the AppDB or the Bugtracker you have the feeling that you are on an entirely new page which only have a link back to the main page and a similar design. If you enter one of the wiki pages the situation is even worse because it does not even have a link to the main page in the navigation bar. Is this a design decision or is it just the lack of time which prevents IMHO proper integration?
I have to agree here that this sucks. I have been looking at doing something about this for a while. I have looked at making patches that woud fix up Wine HQ, AppDB and Bugzilla but I am lost with changing the wiki. The change I propose would add links for the four sites that we have to each site. IE:
Wine HQ menu Main Site Home AppDB Home Bugzilla Home Wiki Home.
I am still working on the upgrade to 2.20 for bugzilla and I think I am close to having it finished but I do not want to have a repeat of the last upgrade, so I am a little gun shy. Once that is in I can make it a priority to get those changes in.
Also as I have said I have a lot of problems changing the wiki. Maybe Dimi could give me some pointers. (please).
--
Tony Lambregts
KGJ WOLFProductions@gmx.de wrote:
The AppDB is a great idea, but why is it so poorly integrated in the main page? The same question goes to the Bugtracker and the Wiki where the situation is even worse. On most web pages you have a navigation bar which remains the same as long as you are on the same page. But if you enter the AppDB or the Bugtracker you have the feeling that you are on an entirely new page which only have a link back to the main page and a similar design. If you enter one of the wiki pages the situation is even worse because it does not even have a link to the main page in the navigation bar. Is this a design decision or is it just the lack of time which prevents IMHO proper integration?
There's so many pages, I think it's utopia to create a common menu for all of them.
But perhaps the menu could have an integrated navigation bar added.
Example.
On the main page: +====== | WineHQ | > Wiki | > AppDB | > Issue Tracker
After clicking "Wiki": +====== | WineHQ | > Wiki | > Categories | > All pages | > Recent changes
Sort of a menu + navigation bar + automatic-folder-of-unused-menu-items-thingy...
Tony Lambregts wrote:
The Application Queue is not being processed in a timely fashion.
For myself I am busy with my day job, working on upgrading bugzilla, and burnt out/frustrated trying to keep up with Application submitions (I am too soft hearted to reject some submittions that probably should be rejected). Keeping up with the Application Queue is a tough job (for me at least, at this time) and at this point just reviewing some of the submittions makes my head hurt.
Once I get some free time, I'd like to get acquainted with the AppDB code and help out in the PHP department, specifically making it easier for maintainers to do stuff without having to go through the moderation queue.
Too bad that the queues are filling up, unfortunately I don't have the time or energy to help with that right now. I think the system needs a shift towards less stuff ending up there in the first place, right?
Speaking from the viewpoint of a new wine developer, the major hurdle, in my view, to contributing to wine is the lack of comments in the code, and the lack of whitespace. Wine is complicated enough, and the lack of comments in the code makes it more difficult. When trying to trace existing code to see how things work, there are very few comments to go off of. This hinders things, especially when trying to understand things that don't have any documentation written for them. Parts of wine might have one or two comments spread throughout the page, if you don't count the copywright info at the top of the page.
On Fri, Jun 02, 2006 at 08:25:42PM +0900, Mike McCormack wrote:
lack of comments in the code
+1, I think it's horrifying.
void the_function_that_adds_one_to_i(int i) { /* this adds one to i */ i = i + 1;
/* this returns i to the caller */ return i; }
There's a bug in this code, let's try this:
/* change by Huw Davies 02-Jun-2006, to fix the return type of the function */ int the_function_that_adds_one_to_i(int i) { /* this adds one to i */ i = i + 1;
/* this returns i to the caller */ return i; }
That's so much better ;-) Huw.
Huw Davies wrote:
There's a bug in this code, let's try this:
/* change by Huw Davies 02-Jun-2006, to fix the return type of the function */ int the_function_that_adds_one_to_i(int i) { /* this adds one to i */ i = i + 1;
/* this returns i to the caller */ return i;}
That's so much better ;-) Huw.
ARRRRRRRG! This whole thing is just a bullshit strawman. The real complaint about the lack of comments is not this kind of trivial comment, but more like:
/* the_function_that_adds_one_to_i - return 1+value This function is necessary because of a compiler bug in FooC 0.8, wherein just incrementing the loop variable in WinGenCryptokeyAllHailBillOurDarkLord will generate incorrect code. */ int the_function_that_adds_one_to_i(int i) { /* this adds one to i */ i = i + 1;
/* this returns i to the caller */ return i; }
There is precious little "Why" in the comments of a lot of projects - Why does this function exist, why would I call it, why does it return what it does, etc.
BS comments like those within the function don't help, obviously - but sometimes a comment block describing WHY a given chunk of code does what it does would be nice.
David D. Hagood wrote:
ARRRRRRRG! This whole thing is just a bullshit strawman.
Indeed.
However my strawman demonstrates that it's difficult to enforce code commenting, as you'll just end up with a bunch of bs.
You also can't comment somebody else's code properly, obvious things don't need commenting, and non-obvious things either have a comment, or you won't see them.
You can't force other people to add comments, and you can't add them for yourself. So if you like comments, you can jump up and down and say there should be more, but that changes nothing.
My pet hate comments are stuff like:
/* My tests reveal that it's done this way */
ofcourse, those tests aren't in the test suite.
/* FIXME: this is broken */
With no explanation of why.
/* go forward in the array */ i--;
Then you've got the whole issue of maintaining the comments in synchronization with the code.
If what you really want is code that's easier to understand we're better off scrapping all comments, then enforcing good coding style, so that the code is readable without comments. If the functions are kept small, things are well named, and the complexity confined (eg. no 7 level indent), you'll be able to understand the code without the auth
If you need to comment your code so others can understand it, it's probably badly structured and unclear.
Mike
If what you really want is code that's easier to understand we're better off scrapping all comments, then enforcing good coding style, so that the code is readable without comments. If the functions are kept small, things are well named, and the complexity confined (eg. no 7 level indent), you'll be able to understand the code without the auth
If you need to comment your code so others can understand it, it's probably badly structured and unclear.
I think that above argument, and the gripe about: i++; /* increment i */ are both overrated and overused to get away with laziness and to excuse a lack of discipline that would create better code.
Yes, obviously written code to perform an obvious function needs few, if any, comments. And I think I would agree that the Wine server is commented about right; it is, imho, a beautiful piece of code.
But there are plenty of places in Wine where the code does something screwball or out of the ordinary (hell, the API itself is screwball), and those places deserve more comments.
I think David hit the nail on the head. I don't need a comment to tell me what the code is doing, I agree that the code itself is more clear. I need a comment to tell me why the @#$ you decided to do that.
And the problem is that that prevailing attitude discourages people from being thoughtful about where a comment *would* do some good.
I'd far rather discard a bunch of /* increment i */ comments but still have some comments as to an authors state of mind than have no comments at all (what we have now).
But that's too bad, because Alexandre feels exactly the opposite; and so long as he's in charge (and I very much want him to continue being in charge), that's the way it's gonna be.
@#$!@$@#$ Wine Maintainer...
<grin>
Cheers,
Jeremy
Am Freitag, den 02.06.2006, 08:03 -0500 schrieb Jeremy White:
But there are plenty of places in Wine where the code does something screwball or out of the ordinary (hell, the API itself is screwball), and those places deserve more comments.
IMHO, more comment's help to teach someone, who read the code, what a Function does. Many of my Patches add the missing WineAPI - Documentation, but the overall API Documentation - Status is still to low.
We can of course add the same Type of documentation for internal Functions. Example: http://source.winehq.org/source/dlls/winspool.drv/info.c#L214
Another big Place to teach someone what a Function does, are the regression tests.
We are missing a lot of tests.
Example: After a comment by Alexandre about my recent patch, i read again our WineAPI-Guide and MSDN. Both document's say the same, but our implementation is different. The affected Function is called only 3 times in our regression tests (WideCharToMultiByte).
On Fri, 02 Jun 2006 08:03:46 -0500, Jeremy White wrote:
And I think I would agree that the Wine server is commented about right; it is, imho, a beautiful piece of code.
+1 to that. I reckon I didn't really grok in that deep-down-in-your-soul way what "good coding style" is until I took time to study the wineserver.
That said, some parts of it could use a tad more explanation. The reader will know that files are opened for clients by the wineserver due to POSIX locking semantics ..... but not any more detail than that.
How on earth does the blocking/sync/wait infrastructure in the server work? What is an "in flight" fd? When I started it was black magic.
It also has a bunch of comments like this:
/* initialize the structure for a newly allocated thread */ inline static void init_thread_structure( struct thread *thread )
;)
That said, I could not have written the wineserver, so my comments should be taken for what they're worth (not much)!
thanks -mike
Mike McCormack wrote:
/* My tests reveal that it's done this way */ /* FIXME: this is broken */ /* go forward in the array */
Then you've got the whole issue of maintaining the comments in synchronization with the code.
You've gravely misunderstood what good code commenting is?
Good comments tell what the _purpose_ of a block of code or a whole function is. The purpose of comments is to let strangers get approximately acquainted with how the code works in abstract, what the call structure is, etc. - NOT to document what individual lines of code do.
Comments that simply state what the code right in front of you effectively does are of course useless. That goes both for dumb oneline comments like the ones you stated earlier, but also for comments that just describe what effects come from nesting a block of code like this and that.
If what you really want is code that's easier to understand we're better off scrapping all comments, then enforcing good coding style, so that the code is readable without comments.
You're missing the point.
If the functions are kept small, things are well named, and the complexity confined (eg. no 7 level indent), you'll be able to understand the code without the auth
Sure, that would help with understanding the call structure. But your angle of attack is utopian, since making up function names perfect enough to convey all needed information in the context of all callers, and always structuring code perfectly - especially when the code has to work exactly like Windows code - is practically impossible. And getting everybody to do it is even worse.
Teaching people to write good comments is infinitely easier - it's a simple case of banging 'em on the head and forcing them to write a comment every time they've done a piece of code that they know required cunning skill for whatever reason. You may need to perfect the english phrasing from some of the foreigners around here once they learn to actually write the comments, but that's a minor nit.
Molle Bestefich wrote:
Sure, that would help with understanding the call structure. But your angle of attack is utopian, since making up function names perfect enough to convey all needed information in the context of all callers, and always structuring code perfectly - especially when the code has to work exactly like Windows code - is practically impossible. And getting everybody to do it is even worse.
Teaching people to write good comments is infinitely easier - it's a simple case of banging 'em on the head and forcing them to write a comment every time they've done a piece of code that they know required cunning skill for whatever reason. You may need to perfect the english phrasing from some of the foreigners around here once they learn to actually write the comments, but that's a minor nit.
Teaching people to write well structured code is definitely much harder, as sloppy programmers can be easily trained to write better comments about their badly structured code.
Add all the great comments you like, but you still actually have to read the code and understand it to figure out how to fix it.
So, IMO, you're better off striving for the Utopian goal of well structured code that trying to make everybody understand what your reason or intention was when you were writing the code, as in the end you must understand the code and all it's subtleties anyway.
Mike
Mike McCormack wrote:
Add all the great comments you like, but you still actually have to read the code and understand it to figure out how to fix it.
Often the goal is not to fix it, the goal is to understand it in order to fix something else.
So, IMO, you're better off striving for the Utopian goal of well structured code that trying to make everybody understand what your reason or intention was when you were writing the code, as in the end you must understand the code and all it's subtleties anyway.
As per above, often you're trying to figure out the big picture, not fix the particular function you're looking at.
Increasing the speed of that process would be truly great.
"Molle Bestefich" molle.bestefich@gmail.com wrote:
Teaching people to write good comments is infinitely easier - it's a simple case of banging 'em on the head and forcing them to write a comment every time they've done a piece of code that they know required cunning skill for whatever reason. You may need to perfect the english phrasing from some of the foreigners around here once they learn to actually write the comments, but that's a minor nit.
Teaching people to write good comments is definitely much easier than writing real code.
grep McCormack documentation/ChangeLog.ALPHA | wc -l 1084
grep McCormack ChangeLog | wc -l 220
grep Bestefich documentation/ChangeLog.ALPHA | wc -l 0
grep Bestefich ChangeLog | wc -l 0
grep Bestefich documentation/ChangeLog.ALPHA | wc -l 0
grep Bestefich ChangeLog | wc -l 0
And this is exactly the kind of comment and attitude that pushes people away from being Wine developers.
This was a thread that asked the question: What would get more developers interested in Wine?
A number of people said: "The code is too hard to read because it's completely unmovitated and uncommented."
Dismissing their input because they've never contributed code is exactly the wrong approach; if we're talking about getting new developers, then their impressions are particularly valuable.
With that said, and all joking aside, I have never seen Alexandre reject a patch with comments or strip a single comment out.
To get material comments in the code would require the imposition of a kind of standard that is far beyond anything we could reasonably expect. Heck, we can't even standardize indenting or do away with those abominable K&R style brack placements <g>.
I just hope that the bulk of the anti comment pogrom is mostly posturing and jest (which is what I suspect), and that folks do try to comment tricky and inobvious bits.
Cheers,
Jeremy
K&R style brack placements
was what i was referring to when I commented about coding style. They are an eyesore and make things difficult to read.
A number of people said: "The code is too hard to read because it's completely unmovitated and uncommented."
Especially the code that is responded to as , I know it's a mess to look at, but I didn't write it.
These portions of code could use a comment or two to explain what is going on, not every line, but explain what happens in that chunk of code.
From: Jeremy White jwhite@codeweavers.com To: Dmitry Timoshkov dmitry@codeweavers.com CC: Mike McCormack mike@codeweavers.com, wine-devel@winehq.org Subject: Re: How are we doing? Date: Fri, 02 Jun 2006 11:24:06 -0500
grep Bestefich documentation/ChangeLog.ALPHA | wc -l 0
grep Bestefich ChangeLog | wc -l 0
And this is exactly the kind of comment and attitude that pushes people away from being Wine developers.
This was a thread that asked the question: What would get more developers interested in Wine?
A number of people said: "The code is too hard to read because it's completely unmovitated and uncommented."
Dismissing their input because they've never contributed code is exactly the wrong approach; if we're talking about getting new developers, then their impressions are particularly valuable.
With that said, and all joking aside, I have never seen Alexandre reject a patch with comments or strip a single comment out.
To get material comments in the code would require the imposition of a kind of standard that is far beyond anything we could reasonably expect. Heck, we can't even standardize indenting or do away with those abominable K&R style brack placements <g>.
I just hope that the bulk of the anti comment pogrom is mostly posturing and jest (which is what I suspect), and that folks do try to comment tricky and inobvious bits.
Cheers,
Jeremy
EA Durbin wrote:
K&R style brack placements
was what i was referring to when I commented about coding style. They are an eyesore and make things difficult to read.
Oh, NO NO NO. K&R style IS the one and only true pure C style. As mutch as GNU did good work for OSS they did very wrong with the GNU coding standard. Especialy with the placement of the braces. Just read the Chapter 3 "Placing Braces" from the Linux Kernel CodingStyle. I quote: "Also, note that this brace-placement also minimizes the number of empty (or almost empty) lines, without any loss of readability. Thus, as the supply of new-lines on your screen is not a renewable resource (think 25-line terminal screens here), you have more empty lines to put comments on." ^^^ See more place for comments and we all agreed that more comments are good!
bye michael
P.S.: Let the flame war begin. ;)
A number of people said: "The code is too hard to read because it's completely unmovitated and uncommented."
"Michael" == Michael Stefaniuc mstefani@redhat.com writes:
Michael> P.S.: Let the flame war begin. ;)
Isn't it already raginh ;-)
From the viewpoint of a new developer (Summer of Code), having a few
"The purpose of this function" comments would have been / still would be very useful!
It's painfully having to figure out what exactly a function does, that calls five other functions that you have to look into, which each call another cryptically named function.
Also, sometimes it's not obvious why a function is called. A comment like "Call funcResetStatusVariables because the above code triggers a redraw which can break them" would save a new developer twenty minutes of "But why update them THERE?! Does my code have to do that?".
--Matt
Matt Finnicum wrote:
Also, sometimes it's not obvious why a function is called. A comment like "Call funcResetStatusVariables because the above code triggers a redraw which can break them" would save a new developer twenty minutes of "But why update them THERE?! Does my code have to do that?".
We seem to have a policy of not accepting comments in exisiting code. If I add comments to existing code that clear up a mystery I have found they are nicely deleted. A pity as the comments would help me next time I am in the area if no one else.
Jeff
On Sat, 03 Jun 2006 12:03:21 +1000, Jeff Latimer wrote:
We seem to have a policy of not accepting comments in exisiting code.
We do? I seem to recall having comment patches accepted before. Albiet a long time ago.
If I add comments to existing code that clear up a mystery I have found they are nicely deleted. A pity as the comments would help me next time I am in the area if no one else.
Hmm, well that should be changed if so! I can agree that some parts of Wine are painfully obscure. I've learned most of what I know about how Wine works by asking questions here and on IRC. Hopefully the developer guide expansion I worked on a while ago covers a lot of the more exotic topics.
thanks -mike
"Jeremy White" jwhite@codeweavers.com wrote:
grep Bestefich documentation/ChangeLog.ALPHA | wc -l 0
grep Bestefich ChangeLog | wc -l 0
And this is exactly the kind of comment and attitude that pushes people away from being Wine developers.
This was a thread that asked the question: What would get more developers interested in Wine?
A number of people said: "The code is too hard to read because it's completely unmovitated and uncommented."
Dismissing their input because they've never contributed code is exactly the wrong approach; if we're talking about getting new developers, then their impressions are particularly valuable.
I'd suggest to return and carefully reread the whole paragraph I've quoted and replied to. It has nothing to do with a constructive talk about commenting the code, instead it's full of insults and hits. I'm not even talking about using the word "foreigners" for the contributors to the open source international project. I'd call the foreigners that kind of people who sends messages like the one I replied to, clearly that people absolutely don't understand what they are talking about.
I apologize for my harsh wording, but I just can't stay aside when I see accusations like that one. When people are interested to contribute code they ask *technical* questions.
I'd suggest to return and carefully reread the whole paragraph I've quoted and replied to. It has nothing to do with a constructive talk about commenting the code, instead it's full of insults and hits. I'm not even talking about using the word "foreigners" for the contributors to the open source international project. I'd call the foreigners that kind of people who sends messages like the one I replied to, clearly that people absolutely don't understand what they are talking about.
I apologize for my harsh wording, but I just can't stay aside when I see accusations like that one. When people are interested to contribute code they ask *technical* questions.
Fair enough; I did reread that paragraph, and I can see a case for you being offended.
I don't think it was meant that way; I think it was more of a canonical rant, but it was nevertheless a poor choice of words.
But I don't know Molle, and I do know you, so I feel more comfortable yelling at you. Sorry :-/.
Cheers,
Jeremy
Dmitry Timoshkov wrote:
I'd suggest to return and carefully reread the whole paragraph I've quoted and replied to. It has nothing to do with a constructive talk about commenting the code, instead it's full of insults and hits.
It has everything to do with a constructive talk about comments.
I strongly disagreed with Mike at the time, and I told him so. It never induces a nice and fuzzy feeling to be told by someone else that they think you're very wrong, but I was in no way imposing insults or hits.
If I wanted to insult someone, I'd say: "Dmitry, go see the doctor about that layer of dirt you have between your eyes and your brain that is grossly obscuring your view on anything I say."
Honestly, I think that you just don't like me and that's why you comprehend everything I write in an extremely prejudicious, negative manner.
That's fine, you do that. But reading people's attitude from a simple email is tough to get right (as you've clearly shown). Therefore it would make me very happy if you could keep your very wrong conception of my attitude and person to yourself. Thank you.
I'm not even talking about using the word "foreigners" for the contributors to the open source international project.
Apologies if that was insulting, perhaps I was too short on words. I meant "speakers of english where that language is not their first language / mother's tongue", not necessarily foreigners in relation to whatever country it was that you thought I meant.
I'm not even sure what you're accusing me of (racism?), but I hope that was better?
I'd call the foreigners that kind of people who sends messages like the one I replied to, clearly that people absolutely don't understand what they are talking about.
Don't make such accusations without backing it up with some proof. You might have a point, who knows, but if you just shout out rants like the above, you're going to present yourself as just being full of BS.
I apologize for my harsh wording, but I just can't stay aside when I see accusations like that one.
I think you're the one who's full of accusations.
When people are interested to contribute code they ask *technical* questions.
What exactly is that supposed to mean?
Jeremy White wrote:
Fair enough; I did reread that paragraph, and I can see a case for you being offended.
I still don't see it, so if anyone could enlighten me, that would be nice.
Just making guesses, is it this?: | You may need to perfect the english phrasing from | some of the foreigners around here once they learn | to actually write the comments, but that's a minor nit.
That could be interpreted as "only native english speakers know how to write good comments". I didn't think about it that way, because that's so utterly absurd that it would never occur to me. Obviously (to me), _that_ wasn't what I meant. What I meant by "they" was "everyone".
Apologies for the unthoughtful wording above, if that indeed was your problem (Dmitry).
I don't think it was meant that way; I think it was more of a canonical rant, but it was nevertheless a poor choice of words.
Perhaps it was too canonical. I felt that Mike's upfront and total dismissal of the request for useful comments with a simple joke was uncalled for. Sorry about that.
But I don't know Molle, and I do know you, so I feel more comfortable yelling at you. Sorry :-/.
Don't be sorry, you were just being fair - Dmitry is the one who's ranting and accusing here.
* Molle Bestefich molle.bestefich@gmail.com [05/06/06, 15:21:08]:
I'm not going to try and answer all of these questions, but this one I think I can answer.
Honestly, I think that you just don't like me and that's why you comprehend everything I write in an extremely prejudicious, negative manner.
How many FOSS projects have you interacted with? Did it occur to you that as identities on the internet can or cannot be what or who they appear to be (I think the quote to that is "On the internet, noone knows you're a dog"), you need to base your trust and respect for people on something else? In most FOSS projecs I know, it's contributed source code.
The reply you got from Dmitry was an open source classic. I've seen a couple of people getting that kind of reply, including me. It's not really meant as harsh as it looks, it's more a way of saying "I know <developer> because he contributed a lot of code, you didn't, so I don't know if I can trust you or if you just want to troll". If your changelog entries reach a significant number, noone will think you are a troll. You still might have some clashes with people having a different opinion, but you'll also be a developer, so people can look at your code to decide if they want to trust you or not. This is just how FOSS development works, and I've yet to see a successful project taking a radically different approach here.
Cheers, Kai
Since my previous posting(s) were poorly written (and/or misconceived), I'd like to try and explain my point again.
Some coders think: "If it was hard to write it should be hard to understand, so that when people finally get it, they'll be amazed at how clever I am."
Writing good comments can IMHO be achieved by urging developers to: * abandon above selfish line of thought * document interesting/curly hacks and complex code structure
Hope I did better this time.
Mike McCormack wrote:
If what you really want is code that's easier to understand we're better off scrapping all comments...
And we can encourage safe driving by removing airbags and seatbelts, and installing big shiny sharp metal spikes on the steering wheel, and executing anybody who has an accident and survives.
Code CANNOT explain "why" - there simply is no way to encode that into the source EXCEPT comments. The solution is to review code and to reject patches that contain "Fixme - this is busted" without a more detailed explanation.
There is precious little "Why" in the comments of a lot of projects - Why does this function exist, why would I call it, why does it return what it does, etc.
BS comments like those within the function don't help, obviously - but sometimes a comment block describing WHY a given chunk of code does what it does would be nice.
Exactly my point.
As in the case of wine, you must try to figure out what a block of code does, then that block of code calls existing wine functions that you've never seen before in your life. So then you have to trace that back to find out what the already implemented function does, and look through the code to it, because there is no documentation for it either, then it calls another function, so go ahead and trace back through the code for it too to find out what it does. Kind of like why i switched to gentoo, I didn't like the rpm dependency hell of fedora, and this is eerily similar. As a new developer, one is not familiar with all of the functions being used in wine, a block of comment explaining what a function does would be nice, instead of having to trace back through various parts of wine code, just to find out what one function is doing.
On Fri, Jun 02, 2006 at 07:27:18AM -0500, EA Durbin wrote:
There is precious little "Why" in the comments of a lot of projects - Why does this function exist, why would I call it, why does it return what it does, etc.
BS comments like those within the function don't help, obviously - but sometimes a comment block describing WHY a given chunk of code does what it does would be nice.
Exactly my point.
As in the case of wine, you must try to figure out what a block of code does, then that block of code calls existing wine functions that you've never seen before in your life. So then you have to trace that back to find out what the already implemented function does, and look through the code to it, because there is no documentation for it either, then it calls another function, so go ahead and trace back through the code for it too to find out what it does. Kind of like why i switched to gentoo, I didn't like the rpm dependency hell of fedora, and this is eerily similar. As a new developer, one is not familiar with all of the functions being used in wine, a block of comment explaining what a function does would be nice, instead of having to trace back through various parts of wine code, just to find out what one function is doing.
If you find something missing, patches or even comments pointing to such problems are welcome.
Ciao, Marcus
Friday, June 2, 2006, 6:27:18 AM, EA Durbin wrote:
There is precious little "Why" in the comments of a lot of projects - Why does this function exist, why would I call it, why does it return what it does, etc.
BS comments like those within the function don't help, obviously - but sometimes a comment block describing WHY a given chunk of code does what it does would be nice.
I don't see any problems here. If anyone needs to know _why_ some function does X - they should look on msdn. Also it would really help look at the patch itself that _does_ explain what the patch is for. And might even link to the bug #.
BTW Alexandre, can we preserve references to bug numbers in patch comments? That would be an ultimate explanation to what most questionable code does.
Exactly my point.
As in the case of wine, you must try to figure out what a block of code does, then that block of code calls existing wine functions that you've never seen before in your life. So then you have to trace that back to find out what the already implemented function does, and look through the code to it, because there is no documentation for it either, then it calls another function, so go ahead and trace back through the code for it too to find out
And how that would be different from reading comments to each function? Or do you expect to have description of what each function with variation of the any other function can do?
Vitaliy
On 6/3/06, Vitaliy Margolen wine-devel@kievinfo.com wrote:
I don't see any problems here. If anyone needs to know _why_ some function does X - they should look on msdn. Also it would really help look at the patch itself that _does_ explain what the patch is for. And might even link to the bug #.
I think it's good to have seperate documentation to msdn. MSDN has a lot of inaccurate information and regularly discards information about older functions. What better place to put this seperate information, provided it is not too wordy, than in the source code?
n0dalus.
Vitaliy Margolen schrieb:
Friday, June 2, 2006, 6:27:18 AM, EA Durbin wrote:
There is precious little "Why" in the comments of a lot of projects - Why does this function exist, why would I call it, why does it return what it does, etc.
BS comments like those within the function don't help, obviously - but sometimes a comment block describing WHY a given chunk of code does what it does would be nice.
I don't see any problems here. If anyone needs to know _why_ some function does X - they should look on msdn.
Only that there is no guarantee that the information in MSDN will stay forever ;)
BTW Alexandre, can we preserve references to bug numbers in patch comments?
Indeed that would be nice.
Peter Beutner p.beutner@gmx.net writes:
BTW Alexandre, can we preserve references to bug numbers in patch comments?
Indeed that would be nice.
I'm not opposed to having bug number in the comments, but it has to be in addition to a proper explanation; the log must be understandable on its own without making reference to an external database.
On Friday, June 02, 2006 07:25, Mike McCormack wrote:
lack of comments in the code
+1, I think it's horrifying.
void the_function_that_adds_one_to_i(int i) { /* this adds one to i */ i = i + 1;
/* this returns i to the caller */ return i;}
Horrifying, yes :)
Mike
Particularly horrifying is the return i in a void function! Is there a test for what native does in this case?
- Neil
On Fri, 02 Jun 2006 12:33:03 +0100, Robert Shearman wrote:
The lack of comments in your email is more horrifying.
Haha :)
Maybe we should have a new janitorial task "comment code", or maybe Alexandre should reject patches that don't have enough comments?
The problem I think is that because MSDN basically describes what the code is meant to do, developers familiar with that area end up perceiving it all as "obvious". I know this was an issue with the old DCOM code, and it took a long time before I really understood what it was doing. I think the new code is a lot better commented which is nice. Plus we have in depth explanations of DCOM in the developer guide now.
The other issue is that Wine is an extremely opaque codebase *unless* you know operating system design inside out, in which case it's often self explanatory. Most people don't, and this surfaces as "I wish it had more comments". Well, yeah ....
thanks -mike
Am Dienstag, den 30.05.2006, 00:17 +0100 schrieb Mike Hearn:
Thanks a lot for starting this. As I'm connected with wine about a Year now, I give my comments / feeling here. (It's large, but i'm unable to Split ...)
Questions to consider:
- Is Wine improving or is the regression rate matching the improvement rate?
Depends on the Area, and how the Wine improvements are validated by regression Tests. We have hundreds of Tests failing on various Windows Systems, and this is really bad. Many reasons for the regression rate is the fact, that we have no regression tests at all for many Functions.
- Are we producing a quality product, from the perspective of non-technical end users? (I appreciate this isn't a goal for everyone)
It seems, that we produce a quality product, when an a widely used, previously untested Application works 'out of the box', but IMHO, we fail, because we have lot's of bugs (and regressions: missing tests) that stay unfixed for a long time. Can we get an overview with "new bugs" / "still existing bugs" / "closed bugs" per month from bugzilla (without duplicates)?
- Are we turning away potential developers for any reason? Could we do more to attract new hackers?
I was starting with wine, because i want to get my Lexmark X5130 working on Linux and my Idea was: Use the Windows-Driver with wine. When I started development with winspool, we had only 2 regression-tests.
It was very hard to get the first Patch accepted: I needed to learn, how windows works in this area, how CVS works and what was expected from a fine Patch. I read a lot of Documentation (wine-dev-guide, wine-wiki.org, winehq.org, MSDN and the Wine-source), got a lot of hints on wine-devel and finally my first Patch was accepted. (Great to be a Member of such a large Project.)
During the Time, things changed and I get confused more and more times about "special Developers" and "other Developers", as well as "special Patches" and "other Patches". (It's also Possible, that i did not see the big differences before).
I aware of the fact, that some Developer earn there Money when working on Wine, working on a special project with a Company behind them (wine on macos / Codeweavers as example) or others stay already a long time with Wine and all of the resulting special Patches are handled a bit different.
Some Examples from my point of View: EnumMonitors (Test + Implementation) needed a long Time: - I created, tested and send a Patch - No commit, and no comments for my Patch for almost two weeks - I ask for comments and got one Hint from one Person. - Updating, testing and resending the Patch - next week waiting again without a reaction. - Asking for comments: One Hint from a different Person - loop again > 5 times I was frustrated that it need so many loops from the first Patch for the tests upto the commit of the last Patch for the Implementation due to the fact, that I got only one Hint after every Update. One Hint was changing NO_ERROR to ERROR_SUCCESS. Another Example was to split the ANSI-Implementation and the UNICODE-Implementation (together ~11kb)in two Patches.
Here a Code-Review that I did: 1: http://www.winehq.org/pipermail/wine-devel/2006-February/045163.html 2: http://www.winehq.org/pipermail/wine-devel/2006-March/045278.html
A Test from Stefan Dösinger: http://www.winehq.org/pipermail/wine-cvs/2006-April/022105.html
I have no Idea about d3d, but the test-style is very Strange. Various tests in this Style (I created the Line-Wrap) : + /* Check the results */ + if( !comparefloat(out[0].x, 128.0 ) || + !comparefloat(out[0].y, 128.0 ) || + !comparefloat(out[0].z, 0.0 ) || + !comparefloat(out[0].rhw, 1.0 )) + { + todo_wine ok(FALSE, "Output 0 vertex is (%f , %f , %f , %f)\n", out[0].x, out[0].y, out[0].z, out[0].rhw); + } + else + { + todo_wine ok(TRUE, "Output 0 vertex is (%f , %f , %f , %f)\n", out[0].x, out[0].y, out[0].z, out[0].rhw); + } + I wanted to comment the patch, but it was already in the Tree. My only Idea is: "special Patch": @codeweavers.com
Big Patches went into the tree:
Juan Lang: crypt32: Implement CryptBinaryToStringA and CryptStringToBinaryA.
When I saw the big Patch, i wanted to ask to split this in seperate Patches: 1x Header-Changes 2x Testcase (2 tested Functions -> 2 Patches) 2x Implementation ( 2 Functions) However, the Big patch was already in the Tree: http://www.winehq.org/pipermail/wine-cvs/2006-May/023291.html
My only Idea is: "special Patch": SoC
Problem with this Patch: Functions not Present every crypt32.dll
Emmanuel Maillard: winecoreaudio: Initial Audio Driver for Mac OS X I saw the Patch and asked about the Project: Merge all sound-driver to "dlls/wineaudio.drv" Reaction: Resend a Day later after a comment from Alexandre and in the Tree the next commit-day: http://www.winehq.org/pipermail/wine-cvs/2006-May/023277.html
This Patch needed a bunch of fixes, done by Alexandre another day later: http://www.winehq.org/pipermail/wine-cvs/2006-May/023295.html
IMHO, every other Patch with a bunch of warnings will never pass. My Idea for this "special Patch" (wine-macos)
Is the Project for a single "wineaudio.drv" dead?
- Are the projects fundamental processes serving us well?
- Any other thoughts for improvement?
In case it's not clear, I'm talking about the project as a community adventure here rather than technical aspects of the codebase.
- A Mentor for a new wine - developer, that tries to Guide the "new blood" a bit. (Vitaliy Margolen did a lot for me by commenting my Patches, when I started dev. for wine. Many Thanks!) - Merge the Coding Hints from wine-wiki.org, wiki.wine.org and wine-dev-guide - Wine Roadmap: Update the ToDo-List for 1.0 and Create a ToDo-List for post-1.0 - "Contributing to Wine" is really large and complex. I would suggest a small Welcome-Page that has: - Importand Headlines from the actual Page, - an invitation to join wine-devel and say Hello, I'm new on wine, - Link: "More Details for Developer" - Link: "More Details on Documentation and Localization" - Link: "More Details on Translations" - Link: "More Details on Application testing" - Link: "More Details on Artwork" - The Wine Party Found. The Links go to something that we have now in "Contributing to Wine" It's IMHO important, that the user does not need to scroll the Welcome-Page
With the Welcome-Page and a Mentor, we should get more developer to wine.
The other Side is the limited Bandwidth of Alexandre. For the Direct3D - Group, it's great, that they manage to test the Patches even if they sometimes fail (the double code-move)
We need more Groups like this. The Group from Dan Kegel, wo worked on richedit, was great.
It might help, that we state in the Patch, on which machines / OS the Patch was tested and which other Persons tested the Patch also.
- No clear roadmap to 1.0 - for 0.9 we had Dimis TODO list and it was quite satisfying to see them go green as tasks were completed. I guess we have a 1.0 TODO list too but I never see any updates to it :(
Yep.
- A few random things I already got into arguments about (forums, libwine api etc) :)
- The number failures on Windows for our regression Tests must go down fast
- We need more Regression tests
- Maybe use parts of the SoC - Money, that Google give to the Project as Bounty for special Bugs (2398 OpenGL in a window or DSOUND-Buffer underrun as examples) or start a small "Wine Winter-of-Code"
Detlef Riekenberg wine.dev@web.de writes:
During the Time, things changed and I get confused more and more times about "special Developers" and "other Developers", as well as "special Patches" and "other Patches". (It's also Possible, that i did not see the big differences before).
There's no such thing as special developer vs. other developer, it's more like a linear scale based on trust: the more I trust a developer the easiest it is for him to get his patches committed. The only way to earn trust points is by submitting consistently good patches.
That doesn't mean you can't get stuff in if you aren't trusted, but it means it will require extra scrutiny, which is why it's very important at the beginning to send small patches that are easy to review. Once you have earned enough trust you can get away with being a bit more sloppy (but not too much, or you'll lose trust points again ;-)
Am Donnerstag, den 01.06.2006, 11:45 +0200 schrieb Alexandre Julliard:
During the Time, things changed and I get confused more and more times about "special Developers" and "other Developers", as well as "special Patches" and "other Patches". (It's also Possible, that i did not see the big differences before).
There's no such thing as special developer vs. other developer, it's more like a linear scale based on trust:
Just a different wording for the same thing. :-) It's the Only way, how it can work. Not only here for accepting Patches, but everywhere for everything in the World.
the more I trust a developer the easiest it is for him to get his patches committed. The only way to earn trust points is by submitting consistently good patches.
IMHO, modify trust points according the recent coding Area from a Developer can improve the quality of the committed Patches a little bit.
To pick up my last Message, Stefan does a great Job for ddraw/dx. The trust for him is so high, that he was hired by Codeweavers. The quoted Patch was IMHO an unusual Coding-Area for him, because it was his first Patch for the regression tests. Another Example is the Testcase for GetPrinter by Dmitry Timoshkov (14. April). I'm working on winspool about a Year now and the Patch from Dmitry was the first one from him in the Area of winspool and winspool/tests for that time. The first view was enough for me to know, that this Test will produce a lot of failures and was never tested on any win9x-system, but is was already in the tree.
I asked Markus for renaming sane.gs to winesane.ds and gphoto.gs to winegphoto.ds as well as wine-devel, Emmanuel Millard, Robert Reif and Ken Thomases to use dlls/winmm/winecoreaudio.drv as a starting point for dlls/wineaudio.drv. Both Patches where resend a day after my questions, but without any changes in this area (Over 100k of code). During my re-reading of the winecoreaudio-Patch yesterday, I missed the Part for winecfg/audio.c to extend sAudioDrivers with "coreaudio", but Robert has already send a message about this topic.
That doesn't mean you can't get stuff in if you aren't trusted, but it means it will require extra scrutiny, which is why it's very important at the beginning to send small patches that are easy to review. Once you have earned enough trust you can get away with being a bit more sloppy (but not too much, or you'll lose trust points again ;-)
Another statement that we can use for the wine-dev-guide. Thanks
* Detlef Riekenberg wine.dev@web.de [01/06/06, 01:15:28]:
Big Patches went into the tree:
Juan Lang: crypt32: Implement CryptBinaryToStringA and CryptStringToBinaryA.
When I saw the big Patch, i wanted to ask to split this in seperate Patches: 1x Header-Changes 2x Testcase (2 tested Functions -> 2 Patches) 2x Implementation ( 2 Functions) However, the Big patch was already in the Tree: http://www.winehq.org/pipermail/wine-cvs/2006-May/023291.html
My only Idea is: "special Patch": SoC
The only connection with SoC this patch has is that it's using the base64 encoder/decoder I wrote for Summer of Code 2005.
Besides, it took me unitl about november to finally get my SoC patches with major functionality in, so SoC students certainly don't have any bonus.
Cheers, Kai
Any status on what projects have been approved and who is going to work on which project for this years SoC.
--- Vijay
On 6/1/06, Kai Blin blin@gmx.net wrote:
- Detlef Riekenberg wine.dev@web.de [01/06/06, 01:15:28]:
Big Patches went into the tree:
Juan Lang: crypt32: Implement CryptBinaryToStringA and CryptStringToBinaryA.
When I saw the big Patch, i wanted to ask to split this in seperate Patches: 1x Header-Changes 2x Testcase (2 tested Functions -> 2 Patches) 2x Implementation ( 2 Functions) However, the Big patch was already in the Tree: http://www.winehq.org/pipermail/wine-cvs/2006-May/023291.html
My only Idea is: "special Patch": SoC
The only connection with SoC this patch has is that it's using the base64 encoder/decoder I wrote for Summer of Code 2005.
Besides, it took me unitl about november to finally get my SoC patches with major functionality in, so SoC students certainly don't have any bonus.
Cheers, Kai
-- Kai Blin, (blin at gmx dot net) Quit worrying about your health. It'll go away. -- Robert Orben
I will be working on riched20 for SoC - Initially I'll be working on some unimplemented messages and styles, and then I'll be working on some of the missing COM interfaces.
Details are at http://wiki.winehq.org/MatthewFinnicum
--Matt
On 6/1/06, Vijay Kiran Kamuju infyquest@gmail.com wrote:
Any status on what projects have been approved and who is going to work on which project for this years SoC.
On Thu, Jun 01, 2006 at 03:21:52PM -0400, Vijay Kiran Kamuju wrote:
Any status on what projects have been approved and who is going to work on which project for this years SoC.
They are listed here: http://code.google.com/soc/wine/about.html
Ciao, Marcus
-
Alexandre Julliard -
Andrew Ziem -
Brian Vincent -
David D. Hagood -
Detlef Riekenberg -
Dmitry Timoshkov -
EA Durbin -
Francois Gouget -
Hans Leidekker -
Huw Davies -
James Hawkins -
Jeff Latimer -
Jeremy White -
Jeremy White -
Jim White -
Kai Blin -
KGJ -
Marcus Meissner -
Marcus Meissner -
Matt Finnicum -
Michael Stefaniuc -
Mike Hearn -
Mike McCormack -
Molle Bestefich -
n0dalus -
Neil Skrypuch -
Peter Beutner -
Raphael -
Robert Shearman -
Sylvain OBEGI -
Tony Lambregts -
Uwe Bonnes -
Vijay Kiran Kamuju -
Vitaliy Margolen