Hello everybody.
I know this is user forum - but I also know that developers "lurks" in here from time to time. So I would like to ask... what do you (developers) think is the biggest issue in wine development? Is it money? How much would wine development process speed up if Codewavers would start selling... let say, 10 times more licenses for Crossover then they sell now? Would it be a dramatic speed up (by that I mean for example - MS is presenting "DirectX15" in January and we have 90% of it implemented in wine in March or April), or Windos API is so messed up, that even having 1000 programmers wouldn't help that much?
I'm asking because I'm curious.
Thanks in advance for the answers.
Hypothetical question - for the devs...
-
James McKenzie
Hypothetical question - for the devs...
James_Huk wrote:
or 1000 developers might not improve things, and may make matters
worse. What we do need is 'clean' coders that are persistant and
willing to work on a problem until it is properly fixed. We are loosing
some good coders because of 'real life' or the fact that their coding
has to go through a lot of testing and review before it is accepted. We
do tend to rely on a core bunch of coders (not all of them work for
CodeWeavers) to get much of the coding done for this project.
minor but important code segment for the riched20.dll file. I started
with code created by someone else and have worked through most, but not
all, of the concerns. I will continue to work on this until it is
either finished or I'm not here anymore. That is called persistence.
Some folks will pick up a project, work on it for a while and then put
it back down. Unfortunately, some of these attempts do not have full
documentation and thus are very hard to figure out what was done and why
it was that way.
I'm a big stickler for code documentation, for this very reason. I work
on stuff everyday and sometimes I have to revisit fixes made three
months ago and it takes me most of a day to figure out what I was doing,
and I document like a fiend. I feel sorry for those who pick up a chunk
of code and then have to figure out what was going on, with absolutely
no documentation. It's ok to remove it when submitting to Alexandre,
but when you are working on it, document, document, document. That way
if you have to leave the project or someone else picks up your work,
they don't have to spend days looking up documentation or trying to
figure out what you were doing...
James McKenzie
More support by CodeWeavers is a good thing. However, adding 10, 100,Hello everybody.
I know this is user forum - but I also know that developers "lurks" in here from time to time. So I would like to ask... what do you (developers) think is the biggest issue in wine development? Is it money? How much would wine development process speed up if Codewavers would start selling... let say, 10 times more licenses for Crossover then they sell now? Would it be a dramatic speed up (by that I mean for example - MS is presenting "DirectX15" in January and we have 90% of it implemented in wine in March or April), or Windos API is so messed up, that even having 1000 programmers wouldn't help that much?
or 1000 developers might not improve things, and may make matters
worse. What we do need is 'clean' coders that are persistant and
willing to work on a problem until it is properly fixed. We are loosing
some good coders because of 'real life' or the fact that their coding
has to go through a lot of testing and review before it is accepted. We
do tend to rely on a core bunch of coders (not all of them work for
CodeWeavers) to get much of the coding done for this project.
I'll give you an example. I've been working with Dylan Smith on oneI'm asking because I'm curious.
minor but important code segment for the riched20.dll file. I started
with code created by someone else and have worked through most, but not
all, of the concerns. I will continue to work on this until it is
either finished or I'm not here anymore. That is called persistence.
Some folks will pick up a project, work on it for a while and then put
it back down. Unfortunately, some of these attempts do not have full
documentation and thus are very hard to figure out what was done and why
it was that way.
I'm a big stickler for code documentation, for this very reason. I work
on stuff everyday and sometimes I have to revisit fixes made three
months ago and it takes me most of a day to figure out what I was doing,
and I document like a fiend. I feel sorry for those who pick up a chunk
of code and then have to figure out what was going on, with absolutely
no documentation. It's ok to remove it when submitting to Alexandre,
but when you are working on it, document, document, document. That way
if you have to leave the project or someone else picks up your work,
they don't have to spend days looking up documentation or trying to
figure out what you were doing...
James McKenzie
Over the years Wine has made great progress.
Lot of developers us to just do what ever would make X application work. Introduction of the no hacks rule has improved wine 10 fold.
The Introduction of test cases having to exist to prove functions operation also has improved wine.
Really some James McKenzie gets close to is that some of Wine issues these days is not coders. Its lack of pro documentation writers to be able to help coders who cannot document well. Ie not everyone can document simple fact of the matter yet they might be brilliant at finding solutions. Then there are the people who can document but can only barely code who fear joining the project out of fear of screwing up.
How we address this. No clear idea.
The issue is not as simple as more coders. More coders help. More documentation writers at this stage would give some large boosts. Also more testers who do report and work hand and hand with developers help.
As I say there is something that everyone can do in wine that help progress.
Basically more of all classes of people with critical on documentation writers at this time. Too many of one class really don't get us very far. Instead lead to many wasted man hours.
Lot of developers us to just do what ever would make X application work. Introduction of the no hacks rule has improved wine 10 fold.
The Introduction of test cases having to exist to prove functions operation also has improved wine.
Really some James McKenzie gets close to is that some of Wine issues these days is not coders. Its lack of pro documentation writers to be able to help coders who cannot document well. Ie not everyone can document simple fact of the matter yet they might be brilliant at finding solutions. Then there are the people who can document but can only barely code who fear joining the project out of fear of screwing up.
How we address this. No clear idea.
The issue is not as simple as more coders. More coders help. More documentation writers at this stage would give some large boosts. Also more testers who do report and work hand and hand with developers help.
As I say there is something that everyone can do in wine that help progress.
Basically more of all classes of people with critical on documentation writers at this time. Too many of one class really don't get us very far. Instead lead to many wasted man hours.
theres problems with Documentation... like myself, I have some coding skill, but not to the level to help much on Wine (yet... still learning stuff, which is why I play around making Wineskin as a hobby), but documentation I am good at.. I do not like making anything without it being well documented. The problem I have with volunteering to help in documentation is that... without some of the coding knowledge or understanding the code, its very difficult to be able to document things correctly. I'd be afraid of not being able to be thorough enough in documentation simply because I do not understand it good enough to be thorough. Mistakes in documentation can often cause more problems than lack of documentation.oiaohm wrote: Really some James McKenzie gets close to is that some of Wine issues these days is not coders. Its lack of pro documentation writers to be able to help coders who cannot document well. Ie not everyone can document simple fact of the matter yet they might be brilliant at finding solutions. Then there are the people who can document but can only barely code who fear joining the project out of fear of screwing up.
How we address this. No clear idea.
The issue is not as simple as more coders. More coders help. More documentation writers at this stage would give some large boosts. Also more testers who do report and work hand and hand with developers help.
As I say there is something that everyone can do in wine that help progress.
Basically more of all classes of people with critical on documentation writers at this time. Too many of one class really don't get us very far. Instead lead to many wasted man hours.
Maybe if all the coders could have some guide lines written up of specifics they have to document (even very crudely), then someone better at making easily understood documentation could re-write it... but the re-writer would have to be able to understand what it was in the first place.
doh123 Notice the way I wrote this. Not you reading the code to work out what it does. We are lacking a way to assign a person like you to a coder with a documentation issue. Both of you work as one. You ask coder about the code them you write the documentation then you send documentation to coder for approval of course this might take many cycles the first time.Its lack of pro documentation writers to be able to help coders who cannot document well.
Along the way starters out at coding get to know a section of wine and the coder with poor documentation skill might improve that. Ie win win. Of course some people will never be able to document well. Just the way it is some areas might have to be teams for ever.
Yes it would be a more relaxed way for some new coders to enter.
Anyone who is good at documentation and poor tech skill with lots of time doing it. Comes to learn creating documentation is never a solo effort. Its always has to be a shared process. Even between developers keeping documentation in a common style helps for developers switching between sections.
Yes what I am suggesting is a way to address some poorly documented sections. Also it could be minor annoyance if wine ever grows a documentation quality group. Ie a group who job is to find sections of code with poor documentation and question developer who did not document about it. Don't know if this would be the next level in quality control evolution of wine.
