29 May
2006
29 May
'06
11:17 p.m.
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
30 May
30 May
6:47 a.m.
New subject: Set up wine-macosx? (Re: How are we doing?)
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(a)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
2:29 p.m.
New subject: Set up wine-macosx? (Re: How are we doing?)
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
3:12 p.m.
New subject: Set up wine-macosx? (Re: How are we doing?)
Mike Hearn wrote:
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:
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. Jeremy White wrote:
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
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... 
3:43 p.m.
New subject: Set up wine-macosx? (Re: How are we doing?)
Jim White wrote:
Jim White wrote in Darwine on 2006-05-24:
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.
--
Rob Shearman
Jeremy White wrote:
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.
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...
4:12 p.m.
New subject: Set up wine-macosx? (Re: How are we doing?)
On 5/30/06, Jim White <jim(a)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
5:44 p.m.
New subject: [Darwine] Set up wine-macosx? (Re: How are we doing?)
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
5:51 p.m.
New subject: [Darwine] Set up wine-macosx? (Re: How are we doing?)
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
6:12 p.m.
New subject: [Darwine] Set up wine-macosx? (Re: How are we doing?)
Jeremy White wrote:
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
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. 
6:22 p.m.
New subject: [Darwine] Set up wine-macosx? (Re: How are we doing?)
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
--
Sylvain OBEGI
6:35 p.m.
New subject: [Darwine] Set up wine-macosx? (Re: How are we doing?)
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
31 May
31 May
9:24 a.m.
New subject: [Darwine] Set up wine-macosx? (Re: How are we doing?)
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.
--
Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/
Hiroshima '45 - Czernobyl '86 - Windows '95
30 May
30 May
9:09 a.m.
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.
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/)
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.
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
1:57 p.m.
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
2:45 p.m.
"Mike Hearn" <mike(a)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.
--
Dmitry.
4 p.m.
On 5/30/06, Dmitry Timoshkov <dmitry(a)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
4:09 p.m.
"Mike Hearn" <mike(a)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.
--
Dmitry.
4:12 p.m.
* 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
31 May
31 May
12:12 a.m.
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
30 May
30 May
11:32 p.m.
On 5/29/06, Mike Hearn <mike(a)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
31 May
31 May
10:43 a.m.
* James Hawkins <truiken(a)gmail.com> [30/05/06, 18:32:37]:
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
--
Kai Blin, (blin at gmx dot net)
Quit worrying about your health. It'll go away.
-- Robert Orben
* 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. 
12:57 p.m.
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
2:37 p.m.
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
5:27 p.m.
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(a)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.
1 Jun
1 Jun
7:55 p.m.
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
8:13 p.m.
On 6/1/06, KGJ <WOLFProductions(a)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
9:08 p.m.
KGJ <WOLFProductions(a)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...
9:13 p.m.
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?
11:16 p.m.
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.
11:42 a.m.
On Fri, Jun 02, 2006 at 08:25:42PM +0900, Mike McCormack wrote:
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
huw(a)codeweavers.com
lack of
comments in the code
+1, I think it's horrifying. 
12:01 p.m.
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.
12:27 p.m.
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
1:03 p.m.
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
7:13 p.m.
New subject: How are we doing? (documentation + regression tests)
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).
--
By By ...
... Detlef
3 Jun
3 Jun
5:50 p.m.
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
2 Jun
2 Jun
1:03 p.m.
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.
2:10 p.m.
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
3:06 p.m.
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.
2:41 p.m.
"Molle Bestefich" <molle.bestefich(a)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
--
Dmitry.
4:24 p.m.
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
5:06 p.m.
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(a)codeweavers.com>
>To: Dmitry Timoshkov <dmitry(a)codeweavers.com>
>CC: Mike McCormack <mike(a)codeweavers.com>om>, wine-devel(a)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
>
>
7:25 p.m.
EA Durbin wrote:
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. ;)
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."
--
Michael Stefaniuc Tel.: +49-711-96437-199
Sr. Network Engineer Fax.: +49-711-96437-111
Red Hat GmbH Email: mstefani(a)redhat.com
Hauptstaetterstr. 58 http://www.redhat.de/
D-70178 Stuttgart
9:37 p.m.
>>>> "Michael" == Michael
Stefaniuc <mstefani(a)redhat.com> writes:
Michael> P.S.: Let the flame war begin. ;)
Isn't it already raginh ;-)
--
Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
3 Jun
3 Jun
1:42 a.m.
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
2:03 a.m.
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
5:54 p.m.
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
5:44 a.m.
"Jeremy White" <jwhite(a)codeweavers.com> 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. 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.
--
Dmitry.
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.
5 Jun
5 Jun
2:58 a.m.
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
1:21 p.m.
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.
7 Jun
7 Jun
7:43 a.m.
* Molle Bestefich <molle.bestefich(a)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
--
Kai Blin, (blin at gmx dot net)
Five bicycles make a volkswagen, seven make a truck.
-- Adolfo Guzman
14 Jun
14 Jun
1:55 p.m.
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.
2 Jun
2 Jun
2:02 p.m.
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.
12:27 p.m.
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.
12:36 p.m.
On Fri, Jun 02, 2006 at 07:27:18AM -0500, EA Durbin wrote:
If you find something missing, patches or even comments pointing to such
problems are welcome.
Ciao, Marcus
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. 
3 Jun
3 Jun
6:29 a.m.
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
7:34 a.m.
On 6/3/06, Vitaliy Margolen <wine-devel(a)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.
10:18 a.m.
Vitaliy Margolen schrieb:
Friday, June 2, 2006, 6:27:18 AM, EA Durbin wrote:
Only that there is no guarantee that the information
in MSDN will stay forever ;)
> 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. BTW Alexandre, can we preserve references to bug
numbers in patch comments?
Indeed that would be nice.
10:32 a.m.
Peter Beutner <p.beutner(a)gmx.net> writes:
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.
--
Alexandre Julliard
julliard(a)winehq.org
BTW Alexandre,
can we preserve references to bug numbers in patch comments?
Indeed that would be
nice. 
2 Jun
2 Jun
12:07 p.m.
On Friday, June 02, 2006 07:25, Mike McCormack wrote:
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
lack of comments in the code
+1, I think it's horrifying.
3 Jun
3 Jun
5:43 p.m.
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
31 May
31 May
11:15 p.m.
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"
--
By By ...
... Detlef
1 Jun
1 Jun
9:45 a.m.
Detlef Riekenberg <wine.dev(a)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 ;-)
--
Alexandre Julliard
julliard(a)winehq.org
5:40 p.m.
Am Donnerstag, den 01.06.2006, 11:45 +0200 schrieb Alexandre Julliard:
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.
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.
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
--
By By ...
... Detlef
7:12 p.m.
* Detlef Riekenberg <wine.dev(a)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
7:21 p.m.
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(a)gmx.net> wrote:
* Detlef Riekenberg <wine.dev(a)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
7:50 p.m.
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(a)gmail.com> wrote:
Any status on what projects have been approved and
who is going to work on which project for this years SoC.
8:39 p.m.
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
6550
days inactive
6566
days old
69 comments
34 participants
participants (34)
-
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