Patchwork (was Re: Governance revisited)

[Troy Rollo]

As I speculated, the reason the PPC64 Patchwork example was so out of date was 
that the PPC64 list had been folded into the vanilla PPC list, however the 
big problem right now is that Patchwork is "extra work" for maintainers, so 
right now they don't want to use it.

It ought to go without saying that a patch management system should make 
things *easier* for maintainers rather than harder(*). Ideally it should be 
easier to take a step using the patch management system that it is to take 
the same step without it. If there are places where taking the same step is 
harder or more time consuming in the patch management system, it should at 
least provide a clear down-the-track benefit to the maintainer to make it 
worth it to the maintainer to take that extra time.

The Patchwork maintainer is interested in improving it - particularly in ways 
that will make maintainers want to use it - so given that there is at least 
the beginnings of a project out there aimed at meeting the general 
requirements it makes some sense to put some effort into it.

Step 1 has to be to get a few members of that particular target group to 
document the procedures they go through to get a patch from the mailing list 
through to git and/or to some other state.

Jeremy - do you have any documentation for this from the last time you looked 
at implementing patch managemen, and if so is it up to date for Git?

(*) it should also make things easier for contributors, but maintainers are 
the critical pressure-point.
-- 
Troy Rollo - [EMAIL PROTECTED]

Re: Governance revisited (Wineconf report)

[Vincent Povirk]

I don't have any real reason to have a say in this (as someone who
hasn't successfully made any changes to the wine tree, for which I
blame my inability to contribute anything that belongs there rather
than any problems with the current system), but I was just thinking
that "Patch management system" and "Bugzilla" sound like similar
systems. Wine already has a bugzilla. I'd like to at least consider
how close it is to meeting the requirements.


- Submit a patch

Can do, as long as it has a bug.

- Specify a subsystem

Also possible, but the subsystem is specified in the bug.

- Keep track of its progress

Yes, but there may actually not be any progress.

- Resubmit after receiving feedback

Yep.

- Get an overview of patches in the queue

Uhh..I guess you could do some kind of search. You'd actually see bugs
that have patches, not the patches themselves.

- Apply a queued patch to my working copy

I don't know how this is supposed to work, even forgetting about
bugzilla for a moment.

- Provide feedback to others

Yep.

- Withdraw a patch

Uh huh.

Aside from the "working copy" thing, which I'm completely confused
about, you could keep track of "patch status" with keywords. Not
everyone would know how/want to maintain the keywords manually--you'd
need either an army of gnomes to patrol the bugzilla or an automated
system to attach the right keywords if you want to make things easy
for patch submitters, which it appears you do. A nice checkbox on the
attachment form saying something like "I believe this patch is ready
to be included in wine in its current form", only not as stupid, could
work (the rest has to be done by people who can handle keywords
damnit).

The other major problem is that not every patch goes with an existing
bug. Presumably, each patch IS meant to improve Wine somehow. I think
it could be made more convenient to submit a but report along with the
patch. Having the history of events related to the patch/issue in one
place (bugzilla) rather than two (bugzilla and the patch manager, or
bugzilla and the wine-patches/wine-devel mailing list archives as it
is now) could be convenient.

Or it could just add lots of unwanted clutter to bugzilla. I don't know.


In addition to the patch submitter requirements, subsystem maintainers would
probably like to be able to:
- Get an overview of patches relevant to their subsystem

Bugzilla queries take care of this.

- Recommend a patch for inclusion

Um..I guess you could use keywords for that too..


In addition to all of the above, I guess Alexandre would need to be able to:



- All from within emacs

I don't want to think about this anymore.

--
Vincent Povirk

Re: Governance revisited

[Tom Wickline]

On 9/25/06, jimtabor <[EMAIL PROTECTED]> wrote:


Every Wine developer needs to read this,
http://www.codeweavers.com/services/ and
http://www.codeweavers.com/services/wine .


What do these two pages have to do with Wine's Governance ?



It is your job to provide support for this product, I spend money and I
need help, where do
I go?


If you purchase CrossOver you will receive support, Wine is free
software and support is provided through users helping other users,
wine-users mailing list and #winehq on IRC



Are you going to piss me off by telling me to shut up and put up with
the poor support from
this mailing list?


Umm, NO! I'm going to tell you that you are a clueless troll who has
no idea what so ever what your spouting off about!



This project needs a course in technical sales support. Good idea for
the next WineConf!


Wine is free, so you get what you payed for. You are the one in need
of some serious help! And don't bother to tell us how to run our
conferences, we do a fine job on our own.


Tom

Re: Governance revisited

[Dmitry Timoshkov]

"jimtabor" <[EMAIL PROTECTED]> wrote:


> First, he doesn't represent Codeweavers on the wine-devel mailing
> list.  Second, there's nothing unprofessional about his actions.
>
Missed my point! If his address has "[EMAIL PROTECTED]", than yes, 
that person does represent that organization.


Then check the address first before attributing a message to some
organization.

(I'm writing most messages in this thread, and particularly the one you
have replied to from a different address, intentionally to disassociate
myself from a company, and represent my own opinion).

--
Dmitry.

Re: Governance revisited

[jimtabor]

Wow, just like that!

James Hawkins wrote:
>> It is shocking to most FOSS code writers that maybe this is a real,
>> truly, paid for project. "No! It can not be! I contribute to someones
>> profit? NOO~~~!".
>
The above is a famous quote I read from Linux Journal magazine.

>
> I am well aware that Codeweavers funds most of Wine development, and I
> appreciate every bit of support coming from them, but this project
> would continue even without their support.
>
> --
> James Hawkins
>
>> NO! You are WRONG, sir!
>> NOO~~~!
>
>
> P.S.  You should really calm down.  It's hard to take you seriously
> when you act immature.
>
I am calm, lol! immature? just a little! 8^D

So, after reading this ML for years and assessing.

Seriously, If I was a contractor representative researching code weavers 
ability to support their product, the last thing I would expect from any 
of their developers would be the lack of customer support and poor 
attitude on IRC. At lest if one of my employees does go out and join 
wine IRC, I would hope they will not get kicked or banned for asking to 
many questions. Understanding this, has made my mind up and forced to 
stop linux migration due to the lack of support and maturity of wine and 
code weavers. We do have contracts with Red Hat, SCO, Solaris, Raytheon,


Oh the shock of that, yes we are considering the use of wine for moving 
away from Microsoft windows. Wine was the stop gap in our mission to 
provide both Linux and Window applications in a real time environment. 
That M$ update thingy is a ass kicker on real time systems, that must 
operate 24/7. Having said that sorry I can't authorize any contracts

with code weavers.

Sorry, you just never know sometime,
James

Re: Governance revisited

[James Hawkins]

On 9/25/06, jimtabor <[EMAIL PROTECTED]> wrote:

James Hawkins wrote:
 > On 9/25/06, jimtabor <[EMAIL PROTECTED]> wrote:
 >
 >>
 >> Every Wine developer needs to read this,
 >> http://www.codeweavers.com/services/ and
 >> http://www.codeweavers.com/services/wine .
 >>
 >
 > I'm a Wine developer, and I don't work for codeweavers.  Why should I
 > read that?
 >
You don't need to.



Um...you just said "Every Wine developer needs to read this."


 >> It is your job to provide support for this product, I spend money and I
 >> need help, where do
 >> I go?
 >>
 >
 > It is not my job to provide support for this product.  Even if you're
 > referring to Dmitry and everyone else that works at Codeweavers,
 > you're still wrong.  This is the wine-devel mailing list, and has
 > nothing to do with Codeweavers.  You confuse Crossover Office and Wine
 > as being the same product/project.  Just because they work at
 > Codeweavers, can they not also work on Wine and not have affiliation
 > with Codeweavers?  Of course they can, as can anyone else who has a
 > real job outside of Wine.
 >

NO! You are WRONG, sir! ~and I quote from
http://www.codeweavers.com/services/

"Since 1999, CodeWeavers has been hiring the very best Wine developers.
Chief among these is Alexandre Julliard
, the long-time
maintainer of the Wine Project itself. In addition to Alexandre's
prodigious talents, we have consistently hired the very best Wine
resources, recruiting them literally worldwide."

Wine is CO as is CO is Wine! Wine is the heart of CO with out it CW
would not have a product. They get paid for working on Wine to support
CO. Don't you see that?!



You are severely confused.  Maybe you should take some time and read
up on what both Wine and Crossover Office are.  Wine is an open source
implementation of the Win32 API.  Crossover Office is a support
platform for running a very specific list of Windows application in
Unix.  The fact that Crossover is based on Wine doesn't mean that Wine
is Crossover.  Codeweavers employees take the time to contribute back
to Wine, when they very well could take their code and walk (even
though they do release the source to Crossover.)  Every Wine developer
that understands this, paid or not, appreciates the work of
Codeweavers developers, as they appreciate the work of other Wine
developers.


 > First, he doesn't represent Codeweavers on the wine-devel mailing
 > list.  Second, there's nothing unprofessional about his actions.
 >
Missed my point! If his address has "[EMAIL PROTECTED]", than yes,
that person does represent that organization.

This project is NOT LINUX or X11, it is a paid for add on to it.



Linus Torvalds is paid by OSDL.  Andrew Morton is paid by Google.
Many major companies (too many to list, but to name a few: IBM, Red
Hat, Novell) employ engineers to work on Linux.  Linux is not a
paid-for project?  Wine began in 1993 with no funding.  Wine
development continued unfunded till 1998, when Corel sponsored Wine
development.  Codeweavers began funding Wine development in 1998.
Linux started as a volunteer project, just like Wine.  Linux now has
paid engineers, just like Wine.  I don't see the distinction.


I pay good money for support and I expect to get it.



You pay Codeweavers, and you should expect support from them, and I
have no doubt that you get that support.  This is Wine, an open source
project.  No one here owes you anything, and that includes Codeweavers
developers.


It is shocking to most FOSS code writers that maybe this is a real,
truly, paid for project. "No! It can not be! I contribute to someones
profit? NOO~~~!".


I am well aware that Codeweavers funds most of Wine development, and I
appreciate every bit of support coming from them, but this project
would continue even without their support.

--
James Hawkins


NO! You are WRONG, sir!
NOO~~~!


P.S.  You should really calm down.  It's hard to take you seriously
when you act immature.

Re: Governance revisited

[jimtabor]

James Hawkins wrote:
> On 9/25/06, jimtabor <[EMAIL PROTECTED]> wrote:
>
>>
>> Every Wine developer needs to read this,
>> http://www.codeweavers.com/services/ and
>> http://www.codeweavers.com/services/wine .
>>
>
> I'm a Wine developer, and I don't work for codeweavers.  Why should I
> read that?
>
You don't need to.

>> It is your job to provide support for this product, I spend money and I
>> need help, where do
>> I go?
>>
>
> It is not my job to provide support for this product.  Even if you're
> referring to Dmitry and everyone else that works at Codeweavers,
> you're still wrong.  This is the wine-devel mailing list, and has
> nothing to do with Codeweavers.  You confuse Crossover Office and Wine
> as being the same product/project.  Just because they work at
> Codeweavers, can they not also work on Wine and not have affiliation
> with Codeweavers?  Of course they can, as can anyone else who has a
> real job outside of Wine.
>

NO! You are WRONG, sir! ~and I quote from 
http://www.codeweavers.com/services/


"Since 1999, CodeWeavers has been hiring the very best Wine developers. 
Chief among these is Alexandre Julliard 
, the long-time 
maintainer of the Wine Project itself. In addition to Alexandre's 
prodigious talents, we have consistently hired the very best Wine 
resources, recruiting them literally worldwide."


Wine is CO as is CO is Wine! Wine is the heart of CO with out it CW 
would not have a product. They get paid for working on Wine to support 
CO. Don't you see that?!


> First, he doesn't represent Codeweavers on the wine-devel mailing
> list.  Second, there's nothing unprofessional about his actions.
>
Missed my point! If his address has "[EMAIL PROTECTED]", than yes, 
that person does represent that organization.


This project is NOT LINUX or X11, it is a paid for add on to it. I pay 
good money for support and I expect to get it.


It is shocking to most FOSS code writers that maybe this is a real, 
truly, paid for project. "No! It can not be! I contribute to someones 
profit? NOO~~~!".


Thanks,
James

WineD3D: glBlend* fixes

[Roland Scheidegger]

> Roderick, Mesa calls the extension "GL_EXT_blend_minmax", and so does
> the spec. I don't know what exactly uses the min_max form. Is this a
> typo?
Apart from the blend_minmax typo, it appears to be me this patch has 
some other problems.


>> This patch changes the detection extension detection for
>> glBlendColor/glBlendEquation. The function glBlendColor is part of
>> OpenGL 1.1 and is supported on all OpenGL implementations.
No, it's not. Calls to it are ONLY legal on opengl up to 1.3 if either 
ARB_imaging or EXT_blend_color are supported (the spec says "Blend Color 
is an imaging subset feature, and is only allowed when the imaging 
subset is supported"). It is however part of OpenGL 1.4.
So, a really correct detection would be to check for ogl version 1.4, 
EXT_blend_color, ARB_imaging. Maybe the check for ARB_imaging could be 
omitted, but it is possible there are drivers out there which only 
announce support for ARB_imaging but not EXT_blend_color, according to 
www.delphi3d.net there are indeed some tnt2's out there which claim 
support for ARB_imaging but not EXT_blend_color - if I'd have to guess 
I'd suspect the call to glBlendColor results in a sw fallback.


>> Further glBlendEquation is part of GL_ARB_imaging aswell. For the
>> same reason GL_ARB_imaging can't be used to detect glBlendEquation.
>> This call isn't supported on all OpenGL implementations. Luckily it
>> is part of 'GL_EXT_blend_min_max' so that is used now.
This is not quite so simple. If OGL 1.4 is supported, or the version is 
lower but ARB_imaging itself is supported, all the blend function stuff 
from ARB_imaging is ok. If only either EXT_blend_minmax or 
EXT_blend_subtract is supported, then glBlendEquation is supported, but 
only different modes are valid (FUNC_ADD, MIN, MAX for EXT_blend_minmax, 
FUNC_ADD, FUNC_SUBTRACT, FUNC_REVERSE_SUBTRACT for EXT_blend_subtract). 
But if all you care is that glBlendEquation is available, you should 
probably detect ogl 1.4, and EXT_blend_subtract (some cards only support 
EXT_blend_subtract but not EXT_blend_minmax), but really for correctness 
EXT_blend_minmax and ARB_imaging should be checked too.


Roland
(not subscribed to wine-devel - include me in cc for answers)

Re: Governance revisited

[James Hawkins]

On 9/25/06, jimtabor <[EMAIL PROTECTED]> wrote:


Every Wine developer needs to read this,
http://www.codeweavers.com/services/ and
http://www.codeweavers.com/services/wine .



I'm a Wine developer, and I don't work for codeweavers.  Why should I read that?


It is your job to provide support for this product, I spend money and I
need help, where do
I go?



It is not my job to provide support for this product.  Even if you're
referring to Dmitry and everyone else that works at Codeweavers,
you're still wrong.  This is the wine-devel mailing list, and has
nothing to do with Codeweavers.  You confuse Crossover Office and Wine
as being the same product/project.  Just because they work at
Codeweavers, can they not also work on Wine and not have affiliation
with Codeweavers?  Of course they can, as can anyone else who has a
real job outside of Wine.


Are you going to piss me off by telling me to shut up and put up with
the poor support from
this mailing list?



If you want support, head to wine-users or buy support for *Crossover
Office* from Codeweavers.


This project needs a course in technical sales support. Good idea for
the next WineConf!



What are we selling and who are we selling it to?  I thought this was
a FOSS project.


Remember you represent CodeWeavers, start acting like it.


First, he doesn't represent Codeweavers on the wine-devel mailing
list.  Second, there's nothing unprofessional about his actions.

--
James Hawkins

Re: Governance revisited

[Troy Rollo]

On Monday 25 September 2006 23:05, Robert Lunnon wrote:
> On Saturday 23 September 2006 16:42, Mike McCormack wrote:
> > Since you know better, how about maintaining your own Wine tree and
> > showing us how it's done?
>
> Self evidently thats what I have to do until some core functionality
> patches find their way into WineHQ wine. It's not particularly hard, but it
> is time consuming to manage merge conflicts.

Actually, you're not, at least not in the sense that Mike is suggesting. On 
the other hand Mike's suggestion is a bit of a red herring since the effort 
involved in maintaining a second tree with multiple contributors *and* 
keeping that in sync with WineHQ is significant in terms of management of 
merge conflicts. When the changes on the branch are all your own you will 
presumably know (or be in a position to easily figure out) the correct 
resolution to each conflict, but with lots of contributions from lots of 
people, this job is significantly harder and more time consuming.

If there were such an alternative tree that had better patch management I 
would switch in a second, but if there were a significant number of 
contributors it could easily take a full time person to just manage merge 
conflicts. At this stage I don't know if there's enough commercial interest 
in such a tree to pay for that (although if there are people who are lurking 
who would be interested, let me know off-list).

One alternative is a set of cascading trees in which each participant 
maintains their own tree that is WineHQ plus their own changes, updated to 
some agreed WineHQ commit at the same time each week, with these trees then 
merged into a common tree. That might make it merge conflict management 
easier, but would also result in some lag between updates to Wine and updates 
to the merged tree.

-- 
Troy Rollo - [EMAIL PROTECTED]

Re: Governance revisited

[jimtabor]

Hi,
Dmitry Timoshkov wrote:
>
>
> How many projects have you ever participated in? Every developers'
> mailing list
> of an open source I personally participated in *doesn't guarantee* not
> only patch
> acceptance, but even a reply with explanations why the patch has been
> silently
> dropped, and it doesn't matter how many maintainers a project has. Why
> do you
> request that from Wine, and particularly from Alexandre?
>
> Alexandre is not a robot, he is a human. Please take that into account.
Sounds like he need more help.

>
> It's a metter of the fact, that if you can't cope with other people's
> requirements,
> you can't work in a team.
>

Every Wine developer needs to read this, 
http://www.codeweavers.com/services/ and

http://www.codeweavers.com/services/wine .

It is your job to provide support for this product, I spend money and I 
need help, where do

I go?

Are you going to piss me off by telling me to shut up and put up with 
the poor support from

this mailing list?

This project needs a course in technical sales support. Good idea for 
the next WineConf!


Remember you represent CodeWeavers, start acting like it.
8^D,
James

Re: Tips for vim users

[Troy Rollo]

On Monday 25 September 2006 19:47, n0dalus wrote:
> At the bottom of my ~/.vimrc (create it if it doesn't exist):
> if !exists("loaded_vimrc_autocmd")
> let loaded_vimrc_autocmd=1
> autocmd BufNewFile,BufRead /data/wine/* set expandtab tabstop=8
> softtabstop=4
> endif

You might want to add "shiftwidth=4" so autoindent works correctly.

-- 
Troy Rollo - [EMAIL PROTECTED]

Re: Governance revisited (Wineconf report)

[Troy Rollo]

On Tuesday 26 September 2006 00:16, Jeremy White wrote:

> Hmm.  Now I'm worried; I've long thought this would be a Good Idea (TM),
> and yet if you look at the 'live' project site (presumably the project
> this was built for):
>   http://patchwork.ozlabs.org/linuxppc64/
>
> It's pretty clear that it's not getting any use - it's just a mirror
> of the mailing list.

Are you sure about that? Scroll down and take a look at some of the "rejected" 
or "changes requested" ones. First you have a status for each patch. You also 
have a record of the discussion for each patch. On the other hand the most 
recent patch listed there is from March so perhaps they have stopped using 
it.

> So clearly the folks on the Linux PPC 64 project didn't feel it was
> worth investing much energy into.

Wouldn't it be better to ask them than to speculate? (query sent)

It may well be that the PPC64 project was merged into the PPC one, which is 
seemingly more up to date: 

-- 
Troy Rollo - [EMAIL PROTECTED]

Re: shlwapi: Resupply array sizes stripped by function interface

[Andrew Talbot]

Dan Kegel wrote:

> BTW the way you define the new size, as a magic constant, seems
> bad.  Can you use 4 * sizeof(WCHAR), or whatever, instead of 8?
> And even then, the '4' seems almost as bad.
> - Dan

Yes, I did feel uneasy about using a magic constant, I must admit. Another
way to handle it would be to call GetLocaleInfoW() twice for each buffer.
The first time with its lpLCData parameter equal to NULL and its cchData
parameter equal to zero, which should return the number of characters
required for the buffer. The second time to then retrieve the required
locale information. I had originally decided against this, because I felt
that it might be over-engineering, but how does that sound to you?

Also, if you would like to suggest a clearer changelog line, I would be very
happy to use it.

Thanks,

-- Andy.

Re: shlwapi: Resupply array sizes stripped by function interface

[Dan Kegel]

Andrew Talbot wrote:

>A formal parameter declared as an array is treated as a pointer; any size
>specifier is ignored. So here, sizeof decimal_buffer, for example, would
>equate to the size of a pointer to WCHAR, not to that of an array of eight
>WCHARs.

Why are you doing this?

Are you asking why I am doing lightweight static code checking, or why I am
submitting this particular patch?


The latter.   I was clumsily trying to say "your changeset description
isn't clear enough".   If you had said "shlwapi: fix thinko in sizeof(array)"
I might have woken up out of my stupor enough to understand the change.

BTW the way you define the new size, as a magic constant, seems
bad.  Can you use 4 * sizeof(WCHAR), or whatever, instead of 8?
And even then, the '4' seems almost as bad.
- Dan

re: shlwapi: Resupply array sizes stripped by function interface

[Andrew Talbot]

Dan Kegel wrote:

> Andrew Talbot wrote:
>>A formal parameter declared as an array is treated as a pointer; any size
>>specifier is ignored. So here, sizeof decimal_buffer, for example, would
>>equate to the size of a pointer to WCHAR, not to that of an array of eight
>>WCHARs.
> 
> Why are you doing this?
> - Dan

Hi Dan,

Are you asking why I am doing lightweight static code checking, or why I am
submitting this particular patch?

-- Andy.

Re: [RPCRT4] support for RPC TCP servers

[Robert Shearman]

Jakob Eriksson wrote:

Jan Zerebecki wrote:

On Fri, Sep 22, 2006 at 12:04:40PM +0100, Robert Shearman wrote:
 
I appreciate your attempt at solving this hard problem, but I don't 
believe this is the right approach. Using winsock2 instead of Unix 
sockets adds overhead in terms of wineserver calls and extra 
processing time to mangle arguments, which we shouldn't need.



But shouldn't we have the possibility to use winsock so a build
of our RPCRT4 is possible for native (and e.g. ros)?
  




Of course. In that case, the fix to add inet_ntop can go in 
include/wine/port.h. Then if someone wants to patch rpcrt4 to 
conditionally include winsock2.h instead of the Unix net headers and 
call WSAStartup that would be fine.



Exactly my thoughts too, but I didn't dare voice them.


Why is that?

--
Rob Shearman

Re: [RPCRT4] support for RPC TCP servers

[Robert Shearman]

Damjan Jovanovic wrote:

On 9/22/06, Robert Shearman <[EMAIL PROTECTED]> wrote:

Using WSAEVENTs is an interesting approach, but I'd rather see Unix
sockets being used with a thread that select's on the socket and sets a
Win32 event instead. Also, I think this amount of nesting is confusing
and could be avoided.


Are you working on that approach, or am I free to try it?


No, I am not working on that so you are free to try it. (You would be 
free to try it anyway, since your implementation might be better than an 
implementation I was working on.)





>
>  static int rpcrt4_conn_tcp_read(RpcConnection *Connection,
>  void *buffer, unsigned int count)
>  {
>RpcConnection_tcp *tcpc = (RpcConnection_tcp *) Connection;
> -  int r = recv(tcpc->sock, buffer, count, MSG_WAITALL);
> -  TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, r);
> -  return r;
> +  int rtotal = 0;
> +  int r = 0;
> +  do
> +  {
> +r = recv(tcpc->sock, buffer, count, 0);
> +if (r > 0)
> +  rtotal += r;
> +else
> +  break;
> +  } while (rtotal < count);
> +  if (r < 0)
> +rtotal = r;
> +  TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, rtotal);
> +  return rtotal;
>  }
>

Hmmm. Is the MSG_WAITALL flag not supported in winsock? I think that
should be fixed there.


It isn't supported in the native winsock either. You think too highly
of winsock - remeber it was made by Microsoft ;-).


Both MSDN and dlls/ws2_32/socket.c suggest that it is supported, 
although only in non-blocking mode. Is that the problem?





>
>  static int rpcrt4_conn_tcp_write(RpcConnection *Connection,
>   const void *buffer, unsigned int 
count)

>  {
>RpcConnection_tcp *tcpc = (RpcConnection_tcp *) Connection;
> -  int r = write(tcpc->sock, buffer, count);
> +  int r = send(tcpc->sock, buffer, count, 0);
>TRACE("%d %p %u -> %d\n", tcpc->sock, buffer, count, r);
>return r;
>  }
>

This is a good change. Please submit this as a separate fix.


But if we use UNIX sockets, it shouldn't matter?


Correct. This won't make any difference either way, so we should use send.

--
Rob Shearman

Re: kernel32: Remove unwanted null terminator

[Andrew Talbot]

Alexandre Julliard wrote:

> Andrew Talbot <[EMAIL PROTECTED]> writes:
> 
>> Changelog:
>> kernel32: Remove unwanted null terminator.
> 
> There's no null terminator since the array size is specified
> explicitly.
> 
Ah, that's interesting! I see, from K&R, that "if [the array's] size is
fixed, the number of characters in the string, not counting the terminating
null character, must not exceed the size of the array." I had wrongly
assumed that the null character had to be counted in, too.

We live and learn!

Thanks,

-- Andy.

re: shlwapi: Resupply array sizes stripped by function interface

[Dan Kegel]

Andrew Talbot wrote:

A formal parameter declared as an array is treated as a pointer; any size
specifier is ignored. So here, sizeof decimal_buffer, for example, would
equate to the size of a pointer to WCHAR, not to that of an array of eight
WCHARs.


Why are you doing this?
- Dan

Re: kernel32: Remove unwanted null terminator

[Alexandre Julliard]

Andrew Talbot <[EMAIL PROTECTED]> writes:

> Changelog:
> kernel32: Remove unwanted null terminator.

There's no null terminator since the array size is specified
explicitly.

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: dmime: Dangling references fix

[Alexandre Julliard]

Andrew Talbot <[EMAIL PROTECTED]> writes:

> Changelog:
> dmime: Dangling references fix.

The right way is to use wine_dbg_sprintf("%s") to allocate a copy of
the buffer to return.

-- 
Alexandre Julliard
[EMAIL PROTECTED]

Re: [RPCRT4] support for RPC TCP servers

[Jakob Eriksson]

Jan Zerebecki wrote:

On Fri, Sep 22, 2006 at 12:04:40PM +0100, Robert Shearman wrote:
  
I appreciate your attempt at solving this hard problem, but I don't 
believe this is the right approach. Using winsock2 instead of Unix 
sockets adds overhead in terms of wineserver calls and extra processing 
time to mangle arguments, which we shouldn't need.



But shouldn't we have the possibility to use winsock so a build
of our RPCRT4 is possible for native (and e.g. ros)?
  


Exactly my thoughts too, but I didn't dare voice them.

regards,
Jakob

Re: Governance revisited (Wineconf report)

[n0dalus]

On 9/25/06, Jeremy White <[EMAIL PROTECTED]> wrote:


Hmm.  Now I'm worried; I've long thought this would be a Good Idea (TM),
and yet if you look at the 'live' project site (presumably the project
this was built for):
  http://patchwork.ozlabs.org/linuxppc64/

It's pretty clear that it's not getting any use - it's just a mirror
of the mailing list.



I think a good system would still be useful even if no developers or
maintainers ended up using it. At the least, it could provide a nice
interface for people to find old patches easily. Patchwork seems ok,
but has no real features that the mailing list combined with a decent
email client doesn't have. A system such as described by Ge and I
would allow anyone who was interested to combine, group and watch
patches, which gives some incentive to use it.

It doesn't even need to have an emacs interface. Alexandre could
continue with his current approach and the system would know whether
or not a patch has been accepted by watching the wine-cvs list.

n0dalus.

Re: Wine translations statistics

[Brian Vincent]

On 9/25/06, Mikołaj Zalewski <[EMAIL PROTECTED]> wrote:

  Yes, I could try to do it. However I would need to know where could I
find some winehq.org pages source codes that could be used as an
example, how to send my code (also through wine-patches?) and how to
update the data files for the pages (e.g. I could send my scripts to be
run on winehq or do it on my server and upload the results to winehq?).


It'd probably almost be easier to send the scripts to Newman and let him
build the templates for WineHQ.

If you were to create static HTML from your scripts, they should live
in the lostwages CVS in templates/en or some such:

http://cvs.winehq.org/cvsweb/lostwages/

$ export CVSROOT=:pserver:[EMAIL PROTECTED]:/home/wine
$ cvs login
$ cvs -z 3 checkout lostwages

-Brian

Re: Wine translations statistics

[Mikołaj Zalewski]

Nice one! I'll see if I can update some of the German resources.

One thing I noticed is that the message table in kernel32 is treated as
one resource in the statistics, although it contains quite a number of
strings itself. Maybe wmc can be augmented with some
"--verify-translation" equivalent as well...
 

 Yes, currently every resource is counted as one (also a string table 
that could have up to 16 strings or a menu with many items). Maybe if 
someone will start translating the kernel32 message table I'll look into it.
 As of the German translations I've found that in many resources there 
is LANG_GERMAN, SUBLANG_DEFAULT. So when starting e.g.:

LANG=de_AT winecfg
 the translation is not used. Wouldn't LANG_GERMAN, SUBLANG_NEUTRAL be 
better? (however I don't know if locales like de_AT are set up by Linux 
distributions)


Mikolaj Zalewski

Re: wined3d: fix typo in ResourceReleased

[Stefan Dösinger]

Hi,
> if (This->stateBlock != NULL ) {
> if ((IWineD3DResource *)This->stateBlock->streamSource[streamNumber] == 
resource) {
>  TRACE("Vertex buffer released whlst bound to a state block 
> stream %d\n", streamNumber);
>  TRACE("Vertex buffer released while bound to a state block  stream %d\n", 
streamNumber);
>  This->stateBlock->streamSource[streamNumber] = 0;
>  } 
> }
This is not your code, but this is wrong, even if the msdn says otherwise. 
Once I had a hacky test for testing this stuff. What my test did was:

1) Create a Vertex buffer
2) check device refcount: increased
3) Bind to a stream
4) check the vb refcount: unchanged(still 1)
5) release the vb(release returns 0)
6) check the device refcount: decreased
7) GetStreamSource: returns old vertex buffer
8) Check device refcount: increased
9) check vb refcount: 1

It seems that the stream source is not uset if the buffer is released. And it 
seems that ms implements holding the reference to the device in 
VertexBuffer::AddRef

if(oldref == 0) IDirect3DDevice9_AddRef(This->device)

or something like that, simmilar to our release. CreateVertexBuffer seems to 
init the ref to 0 and call VertexBuffer::AddRef.

To be sure I did tested the following too:
1) Create VB
2) Check device refcount: increased
3) Release vb. Device refcount decremented
4) AddRef the just destroyed vb: Device refcount increased

I didn't submit the test because it doesn't contain anything really new, and 
the GetStreamSource which returns the released buffer works just by chance.

Any ideas to that? I agreed with Vitaly that this isn't crucial behavior as 
any app depending on that would randomly break on windows.

Or is there some COM magic behind this, which keeps objects from beeing 
destroyed?

Stefan


pgp7tgoWUCkoD.pgp
Description: PGP signature

Re: Governance revisited

[Dmitry Timoshkov]

"Troy Rollo" <[EMAIL PROTECTED]> wrote:

If I say I've been coding since I was 14 (in those days home computers had 
less than 1% penetration in Australia), in assembly language since shortly 
after that and raw machine code not long after, having memorised the 
instruction set, then was widely recognised as the most capable Comp Sci 
student at the top university for Computer Science in the state, and that I 
only employ people who are proven geniuses, would it make a difference?


Very nice picture of a man with overestimated personal evaluation.

[skipped]


This is
even more difficult when you have to guess Alexandre's ideas about how
you should properly solve the problem :)


Actually, this is probably 90%+ of the problem. If patch submission weren't a 
black hole in which it either gets through or you have to go begging for 
feedback like an errant schoolboy, you wouldn't see nearly the volume of 
complaints you do.


Worse are the times when you spend considerable time reworking a patch to his 
specifications and he still won't let it in. One of my staff had this 
problem, and the answer from Alexandre was that he wasn't going to let 
*anything* in covering that area no matter how it was implemented until it 
had been proven in the field (effectively forcing a branch). That's pretty 
soul-destroying stuff. That staff member resigned a short time later, and 
while he gave other reasons his frustration with dealing with Alexandre had 
been showing, and his whole job revolved around improving Wine.


How many projects have you ever participated in? Every developers' mailing list
of an open source I personally participated in *doesn't guarantee* not only 
patch
acceptance, but even a reply with explanations why the patch has been silently
dropped, and it doesn't matter how many maintainers a project has. Why do you
request that from Wine, and particularly from Alexandre?

Alexandre is not a robot, he is a human. Please take that into account.

It's a metter of the fact, that if you can't cope with other people's 
requirements,
you can't work in a team.

--
Dmitry.

Re: Wine translations statistics

[Mikołaj Zalewski]

To check what needs to be translated I have played a bit with wrc 
--verify-translation and made some HTML from it's results. As this
might interest other translators I've put the statistics at 
http://pf128.krakow.sdi.tpnet.pl/wine-transl/ .
   



Very nice! It would be cool if we could integrate this on winehq.org.
Care to try that?
 

 Yes, I could try to do it. However I would need to know where could I 
find some winehq.org pages source codes that could be used as an 
example, how to send my code (also through wine-patches?) and how to 
update the data files for the pages (e.g. I could send my scripts to be 
run on winehq or do it on my server and upload the results to winehq?).


Mikolaj Zalewski

Re: Wine translations statistics

[Frank Richter]

On 25.09.2006 13:29, Mikołaj Zalewski wrote:
> To check what needs to be translated I have played a bit with wrc
> --verify-translation and made some HTML from it's results. As this might
> interest other translators I've put the statistics at
> http://pf128.krakow.sdi.tpnet.pl/wine-transl/ .

Nice one! I'll see if I can update some of the German resources.

One thing I noticed is that the message table in kernel32 is treated as
one resource in the statistics, although it contains quite a number of
strings itself. Maybe wmc can be augmented with some
"--verify-translation" equivalent as well...

-f.r.

Re: Governance revisited

[Dmitry Timoshkov]

"Dimi Paun" <[EMAIL PROTECTED]> wrote:


In fact, I must say that the most fun I had with Wine was when Alexandre
let me run with listview a few year back. He clearly committed patches
that weren't perfect, but I appreciated that because that's how I work:
I like to do several iterations, maybe redo the code several times, but
commit the intermediate steps.


And Alexandre explained that as well :-) If he sees that a person really
grasps and understands the code, he reviews his patches much more freely,
and allows some sloppiness in his code, hoping that it improves with time.

--
Dmitry.

Re: Governance revisited (Wineconf report)

[Jeremy White]

> maybe it is worth looking at patchwork?
> 
> ---
> PatchWork is a web-based patch tracking system designed to facilitate the 
> contribution and management of contributions to an open-source project.
> Patches that have been sent to a mailing list are 'caught' by the system,
> and appear on a web page. Any comments posted that reference the patch are
> appended to the patch page too. The project's maintainer can then scan
> through the list of patches, marking each with a certain state, such as 
> Accepted, Rejected or Under Review. Old patches can be sent to the archive
> or deleted.
> -
> http://ozlabs.org/~jk/projects/patchwork/
> 
> I have never used it myself though, so no idea if it does everything you want.

Hmm.  Now I'm worried; I've long thought this would be a Good Idea (TM),
and yet if you look at the 'live' project site (presumably the project
this was built for):
  http://patchwork.ozlabs.org/linuxppc64/

It's pretty clear that it's not getting any use - it's just a mirror
of the mailing list.

So clearly the folks on the Linux PPC 64 project didn't feel it was
worth investing much energy into.

Also, it might be interesting to compare how the Linux kernel
does things; presumably they are a successful model.

My sense was that it was all pretty ad-hoc, and as bad, or much
worse, than Wine when it came to patches going into the void.
(I'm batting .500 with patches to the kernel; one took me 2 years
and a personal plea to Alan Cox to get in, the other is still not
in, despite the sub system maintainer agreeing that it was good
[after many repeated pleas]).

Has that changed?  I presume that this same thread has come up over there -
did a consensus ever develop?  (Forgive me, but I don't follow LKML,
I'm hoping someone braver than I might know).

Cheers,

Jeremy

Re: Wine translations statistics

[Dimi Paun]

On Mon, 2006-09-25 at 13:29 +0200, Mikołaj Zalewski wrote:
> To check what needs to be translated I have played a bit with wrc 
> --verify-translation and made some HTML from it's results. As this
> might interest other translators I've put the statistics at 
> http://pf128.krakow.sdi.tpnet.pl/wine-transl/ .

Very nice! It would be cool if we could integrate this on winehq.org.
Care to try that?

-- 
Dimi Paun <[EMAIL PROTECTED]>
Lattica, Inc.

Re: Governance revisited (Wineconf report)

[Peter Beutner]

Hi

Ge van Geldorp wrote:
> 
> If there is genuine interest to make this work I could put up a few mock
> webpages to get a better idea of how it would work.
> 

maybe it is worth looking at patchwork?

---
PatchWork is a web-based patch tracking system designed to facilitate the 
contribution and management of contributions to an open-source project.
Patches that have been sent to a mailing list are 'caught' by the system,
and appear on a web page. Any comments posted that reference the patch are
appended to the patch page too. The project's maintainer can then scan
through the list of patches, marking each with a certain state, such as 
Accepted, Rejected or Under Review. Old patches can be sent to the archive
or deleted.
-
http://ozlabs.org/~jk/projects/patchwork/

I have never used it myself though, so no idea if it does everything you want.

Re: Governance revisited

[Dimi Paun]

On Mon, 2006-09-25 at 19:47 +0900, Dmitry Timoshkov wrote:
> Dimi, I thought you were aware of it, and Alexandre at least at
> previous WineConf stated that he accepts dubious code in cases, when
> he sees that nobody works on some component: that components were
> OLE/COM, DDraw/D3D, BiDi at some point.

Yes, you are correct. I was trying to make a point, and I couldn't
let reality mess with that :)

In fact, I must say that the most fun I had with Wine was when Alexandre
let me run with listview a few year back. He clearly committed patches
that weren't perfect, but I appreciated that because that's how I work:
I like to do several iterations, maybe redo the code several times, but
commit the intermediate steps.

If I would have had to refine each patch more, I would have given up
working on it, since it wouldn't have been nearly as fun for me.

Truth of the matter is that in the meantime listview broke, and there
was a dip in quality. However, by the time I was done, I think Wine
was in better shape than when I started. For me, that worked.

Unfortunately, that doesn't say much. Whom, when, and where you let
people play is a black art, and there can not be clear policy about
it. In fact, clear policy in these matters would defeat the purpose,
as it would take that 'play' aspect out of it.

-- 
Dimi Paun <[EMAIL PROTECTED]>
Lattica, Inc.

Re: Wine translations statistics

[Tom Wickline]

On 9/25/06, Dimi Paun <[EMAIL PROTECTED]> wrote:

On Mon, 2006-09-25 at 13:29 +0200, Mikołaj Zalewski wrote:
> To check what needs to be translated I have played a bit with wrc
> --verify-translation and made some HTML from it's results. As this
> might interest other translators I've put the statistics at
> http://pf128.krakow.sdi.tpnet.pl/wine-transl/ .

Very nice! It would be cool if we could integrate this on winehq.org.
Care to try that?


Yes very cool indeed!
something like the wineapi_stats would be rather nice.

http://www.winehq.org/site/winapi_stats

Tom



--
Dimi Paun <[EMAIL PROTECTED]>
Lattica, Inc.

Re: Governance revisited

[Robert Lunnon]

On Monday 25 September 2006 20:08, Ge van Geldorp wrote:
> > From: Steven Edwards <[EMAIL PROTECTED]>
> >
> > Which is why we want to have the ambassadors project to help
> > new people in to wine. The thinking goes that if we have some
> > people to help hold the hands of new developers and the
> > developers that are defacto maintainers of a certain section
> > of code will respond to patches as they seem them, this will
> > free julliard from having to answer every single patch with a
> > reply.
>
> You can have ambassadors and subsystem maintainers all you want, but in the
> end it's still going to be Alexandre who decides if a patch goes in. That
> means the end-responsibility of informing developers why a patch was
> rejected needs to be with Alexandre. If an ambassador or subsystem
> maintainer already explained it, fine, no need to create double work for
> Alexandre, but if noone responded I'd still expect Alexandre to send a
> notification.
>
> Just for the record, my own policy on patch submission (and I really hope
> to get back to working on Wine and submitting patches Real Soon Now :-)) is
> to submit a patch once. If I get feedback I'll try to improve and resubmit,
> but if it goes the black hole route I'm not going to beg for an
> explanation. If the Wine community can't be bothered to provide feedback I
> can't be bothered to resubmit. After all, I've already scratched my itch,
> the bug is already fixed in my tree, it's the communities loss, not mine.
>

This mirrors my policy, I used to care - now I don't - That is bad, Wine needs 
developers who care.

(Patently I do care enough to start this thread)
Also the ambassador program doesn't help to improve the process , it serves to 
perpetuate it.

Bob





 
> Ge van Geldorp

Re: Governance revisited (Wineconf report)

[n0dalus]

On 9/25/06, Ge van Geldorp <[EMAIL PROTECTED]> wrote:


If there is genuine interest to make this work I could put up a few mock
webpages to get a better idea of how it would work.



See also my similar post regarding a patch system:
http://www.winehq.org/pipermail/wine-devel/2006-September/051052.html

n0dalus.

Re: Governance revisited

[Robert Lunnon]

On Saturday 23 September 2006 16:42, Mike McCormack wrote:
> > The current process is crippling this project, limiting the developer
> > base and reducing community value. Without some healthy dissent it will
> > never change and get better.  I am a friend of change, a true believer in
> > the process of continuous improvement. I believe one day, the WIne
> > project will value my contribution - even in dissent.
>
> We value your contribution, however it's even more valuable to have
> developers that listen to feedback and fix their broken patches rather
> than just complaining loudly.

Thats not helpful, I'm trying to engage in a discussion on governance, I've 
long since given up on trying to argue with the current system, If a patch is 
rejected it goes to my local tree.

>
> Since you know better, how about maintaining your own Wine tree and
> showing us how it's done?
>
> Mike

Self evidently thats what I have to do until some core functionality patches 
find their way into WineHQ wine. It's not particularly hard, but it is time 
consuming to manage merge conflicts.

Re: Wine translations statistics

[Jonathan Ernst]

Le lundi 25 septembre 2006 à 13:29 +0200, Mikołaj Zalewski a écrit :
> To check what needs to be translated I have played a bit with wrc 
> --verify-translation and made some HTML from it's results. As this might 
> interest other translators I've put the statistics at 
> http://pf128.krakow.sdi.tpnet.pl/wine-transl/ .
> 
> Mikolaj Zalewski
> 
> 
> 

Thanks that is very useful.

I sent some new French translations to wine-patches.

Jonathan


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Governance revisited

[Robert Lunnon]

On Sunday 24 September 2006 01:06, Rolf Kalbermatter wrote:
> Jim White wrote:
> > CodeWeavers Wine version is full of patches that Alexandre won't accept
> > for WineHQ. Obvious proof that the Alexandre's policy isn't the only
> > way to make a Wine that people value. In fact it proves that the
> > WineHQ's patch process is not good enough to make Wine that people
> > will pay for, while CodeWeavers' is.
>
> And that is wrong? Wine being Open Source that everybody can download I'm
> not sure how you would get many people to pay for it. Packaging alone won't
> be a good business model because there are many Linux distributors who will
> and do that too for no additional cost.
>
> > Many more leave than stay.  And your rudeness just helps that to happen.
> > In case you didn't notice, your entire post was signal free.  If Mike
> > is trolling, you've been hooked.
>
> I agree with you that Vitaly's post wat unnecessarily rude and harsh,
> especially considering that Bob did submit a bunch of patches no matter
> if they were accepted into Wine or not.
>
> Rolf Kalbermatter

Actually, most patches *are* accepted - but I keep labouring, this isn't the 
point, I am promoting the concept that Wine should be for the users and that 
the patch acceptance policy and behaviour management should support a user 
(Customer) focus and need to be transparent. 


Bob

Re: Governance revisited (Wineconf report)

[Ge van Geldorp]

> From: Kai Blin
>
> Now, getting back to the patch submission process, you're talking about a 
> patch management system. How would that look like, in your opinion. We
were 
> discussing a couple of ideas, but in the end figured that most of those
would 
> slow down the submission speed of patches that are accepted.
>
> Our idea was to have patches be recieved by the subsytem maintainers, and 
> Alexandre would only apply patches he got from those guys. We voted that
one 
> down.
>
> Now I would be interested in your idea for such a system. I figure that 
> writing an emacs frontend won't be too troublesome if it's reasonably 
> designed, so let's ignore that for now.

A patch management system isn't exactly a new idea. It came up last year,
during the same type of discussion we're having now (and it will probably
come up next year when we have the same discussion again). See e.g.
http://www.winehq.org/pipermail/wine-devel/2005-September/039837.html and
note this sentence: "However, it became clear that the requirements were
fairly substantial (the tight emacs integration became our first clue :-/),
and that project got back burnered."

The users of such a patch management system would fall into 3 categories:
Developers/patch submitters, subsystem maintainers and Alexandre. I can take
a guess at what subsystem maintainers and Alexandre would want from such a
system, but of course I can only really speak as a patch submitter.
My primary requirements would be to be able to:
- Submit a patch
- Specify a subsystem
- Keep track of its progress
- Resubmit after receiving feedback
- Get an overview of patches in the queue
- Apply a queued patch to my working copy
- Provide feedback to others
- Withdraw a patch
In addition to the patch submitter requirements, subsystem maintainers would
probably like to be able to:
- Get an overview of patches relevant to their subsystem
- Recommend a patch for inclusion
In addition to all of the above, I guess Alexandre would need to be able to:
- Get an overview of recommended patches
- Commit a patch
- Reject a patch
- All from within emacs

Moving on to implementation, I see a set of database tables giving a patch
the following attributes:
- Submitter
- Short description
- Status (Queued, Waiting for developer, Recommended, Withdrawn, Committed,
Rejected)
- Subsystem
- Patch text (multiple versions, to allow resubmits and still keep a
history)
- Comments

Some status changes are restricted (e.g. only a subsystem maintainer would
be able to recommend a patch). Everyone would be able to submit a patch,
which would initially have Queued status. When feedback is provided, the
feedback provider (anyone) could change the status to Waiting for developer.
If a patch is in "Waiting for developer" status too long (say a month) it
could be automatically rejected. When "Waiting", the submitter could provide
a new version or respond with a comment, setting the status back to Queued
again. Or he could decide to Withdraw the patch. When a patch makes it into
the tree it will gain the most holy of all statuses, Committed. I envision
manually Rejecting a patch to be a pretty rare case, normally feedback would
be provided and the Waiting status would be set. Uncommittable patches would
then exit the system via the automatic clean up (in "Waiting" too long) or
via a Withdraw.

The heart of the system would be a couple of web pages. However, not
everyone likes web pages and the current system with mailing lists does have
its strong points too. So, there could be a two-way gateway between the web
system and the mailing lists. If a patch is submitted via the web, it could
be sent out via wine-patches too. If a patch comes in via wine-patches, it
could be added to the database automatically (when that doesn't succeed a
notification is sent to the author). Same for comments, they could be fed
from the web page to wine-devel.

If there is genuine interest to make this work I could put up a few mock
webpages to get a better idea of how it would work.

Gé van Geldorp.

Re: Governance revisited

[Robert Lunnon]

On Saturday 23 September 2006 16:36, Dmitry Timoshkov wrote:
> "Jim White" <[EMAIL PROTECTED]> wrote:

> > Steven cited the business at Wineconf of Alexandre never being "proved
> > wrong on a technical matter".  Another straw man.  The part of
> > Alexandre's patch process that is the root of this conflict between Wine
> > development-focused developers vs. Wine user-focused developers is that
> > which consists of style and aesthetic considerations.
>
> No, that's clearly a technical matter, and has nothing to do with user's
> expectations. There is no such a thing as a "wine user-focused developer",
> but there is such a thing as commercial software development. Feel the
> difference.

Let me answer this, as a User-Focused non-commercial developer I feel the 
difference every time I apply my custom patch tree to WineHQ wine to produce 
a solaris binary, thus the argument you give is non sequitur due to the fact 
that self evidently I fit the exact characterisation you assert does not 
exist.



Bob

Re: Governance revisited (Wineconf report)

[Robert Lunnon]

On Sunday 24 September 2006 00:36, Rolf Kalbermatter wrote:
> Robert Lunnon [EMAIL PROTECTED] wrote:
> > On community, the wine project doesn't represent a community in the sense
> > that Wine has an altruistic purpose to provide value to that community -
> > It doesn't do that because the wine developer base doesn't measure
> > important to Wine users and set policy to provide that value. This means
> > Wine isn't a particularly good Product. Wine is a developers play-thing,
> > Crossover is a Product !
>
> Considering that CrossOver does pay the bill for some part and the major
> driving force behind Wine is and has been for a long time Codeweavers, no
> matter if you like it or not, I feel that a Wine with a much more loose
> acceptance policy but without the Codeweavers support it has now would be
> not half as far as it is. It would contain all sorts of hacks and
> workarounds for specific applications but be basically an unmaintainable
> beast and much further from providing a proper basic infrastructure with
> COM/DCOM and MSI support (to name some examples) as it should be done
> rather than as it might just barely work for some popular applications.
>
> A project driven mostly by users most likely is focusing on providing fast
> fixes that make a specific application work, while Alexandre is
> specifically trying to make sure that there is a clean (both technically
> and legally) infrastructure on which one can build for years to come. And
> which by coincidence will deliver a very good platform to build CrossOver
> from. It does mean that you can't expect it to immediately deliver support
> for all the apps you and many others might like but on the other hand it
> will mean that once new MS technologies get used more widespread it is much
> easier if not only possible then, to add them and provide faster support
> for newer apps.
>
> For some part it does boil down to "I want to have fun now" vs "I want to
> have a technically sound infrastructure that can stand some time". In that
> sense Wine as is is maybe not a product in the sense of our fast and
> trigger happy marketing world but it is certainly a product in the sense of
> engineering and even more so than CrossOver. But then you pay something for
> CrossOver and not for Wine so maybe that is also why Wine can't and
> shouldn't really be a product in the sense of marketing.
>
> And as with all OpenSource projects, those that provide the most support in
> terms of code submissions, testing and documentation get to say the most
> and I think it has been clear that most of them are quite content if not
> happy with the modus operandi. Of course Alexandre can be a pain sometimes
> but he has been always with a reason as far as I can tell.
>
> Rolf Kalbermatter

You make the implicit assumption that you can't have both functionality and 
technical soundness. I did not suggest a free-for-all, I suggested that a 
managed objective be established and that "Hacks" that are necessary for 
functionality and are sufficiently limited in scope can be acceptable if they 
meet a need of the community.

Secondly, I am starting to get rather annoyed that I am being portrayed as 
anti Alexandre. This is not the case, Alexandre does a pretty good job given 
the governance model, but the model itself has severe deficiencies and is not 
community focused.

Bob

Last update to git 5 days ago?

[Paul Vriens]

Hi,

is Alexandre on a holiday again? Or is this to recuperate from
WineConf? 

Cheers,

Paul

Re: Governance revisited (Wineconf report)

[Robert Lunnon]

On Monday 25 September 2006 04:36, Robert Shearman wrote:
> Robert Lunnon wrote:
> > 2. Adapt the patch acceptance process to create a right of appeal where a
> > patch can be proven to be within the Patch Acceptance policy. Appeal
> > should be independent of and binding on Alexandre - this eliminates
> > one-to-one arguments about patch acceptability while still providing good
> > excellent control.  It will also have the effect of reducing Alexandres
> > workload.
>
> I think this process would be completely redundant, so can you give an
> example of the patches that would meet the "Patch Acceptance policy" but
> have been rejected by Alexandre?

I could (If there were a patch acceptance policy) but it'd be pointless at 
this point.
>
> BTW, you already have a right to appeal - it's a message to wine-devel
> with a well-reasoned argument.

Ah yes, but is it independent... There is a single acceptance channel, this is 
poor system design.

Bob

Wine translations statistics

[Mikołaj Zalewski]

To check what needs to be translated I have played a bit with wrc 
--verify-translation and made some HTML from it's results. As this might 
interest other translators I've put the statistics at 
http://pf128.krakow.sdi.tpnet.pl/wine-transl/ .


Mikolaj Zalewski

Re: Whither msxml?

[Huw Davies]

On Sat, Sep 23, 2006 at 05:52:51AM -0700, Dan Kegel wrote:
> If anyone has tips on sore spots with Wine's msxml, please
> let me know.

Hi Dan,

There are lots of things that need to be done in msxml3:

Currently we have implemented some of the DOM methods, most of these
are part of the IXMLDOMNode interface (node.c) - you'll still see a
lot of stubs in there.  Most of the additional methods for the
interfaces derived from IXMLDOMNode (see eg IXMLDOMText in text.c)
also need filling out.  Hopefully the infrastructure for DOM is pretty
much laid out however.

There's currently no SAX support, so that could be another area of
fruitful work.

Some of the helper apis like IXMLHTTPRequest would also be fun.

We also don't have a plan for msxml4, so some design decisions
regarding this should be made at some point.

Huw.
-- 
Huw Davies
[EMAIL PROTECTED]

Re: An MSVCRT_fgetc bug

[Chris Robinson]

On Monday 25 September 2006 01:04, Tobias Ringström wrote:
> There's a bug in MSVCRT_fgetc in 0.9.21 (likely introduced in 0.9.19) in
> that it sometimes sign extends the byte read from the file.

Looks like 'char *i;' should be 'unsigned char *i;'.

Re: LOSTWAGES: WWN 292 & 320 updates

[Tom Wickline]

On 9/25/06, Tom Wickline <[EMAIL PROTECTED]> wrote:

On 9/23/06, Mirek <[EMAIL PROTECTED]> wrote:
> >
> > Also Wine reports 64MB of video memory not 16MB
>
> I think there shuld be option in winecfg to set this, because it is not easy 
to
> find how anyone can do that.

http://wiki.winehq.org/UsefulRegistryKeys

Tom



Whoops, I hit "Reply to all" and didn't mean to send a copy to wine-patches.

Tom

Re: Governance revisited

[Dmitry Timoshkov]

"Dimi Paun" <[EMAIL PROTECTED]> wrote:


Bottom line, I don't know. At most I can say that sometimes I wish
Alexandre would be a bit more impulsive, and just let (a selected few)
things in that people want. Maybe this way we generate more excitement,
and the tiny bit of quality drop we pay with would be worth it.


Dimi, I thought you were aware of it, and Alexandre at least at previous
WineConf stated that he accepts dubious code in cases, when he sees that
nobody works on some component: that components were OLE/COM, DDraw/D3D,
BiDi at some point.

--
Dmitry.

Re: LOSTWAGES: WWN 292 & 320 updates

[Tom Wickline]

On 9/23/06, Mirek <[EMAIL PROTECTED]> wrote:

>
> Also Wine reports 64MB of video memory not 16MB

I think there shuld be option in winecfg to set this, because it is not easy to
find how anyone can do that.


http://wiki.winehq.org/UsefulRegistryKeys

Tom

Re: Governance revisited (Wineconf report)

[Kai Blin]

On Sunday 24 September 2006 12:08, Ge van Geldorp wrote:

> Like I said before, I have a lot of respect for Alexandres technical
> abilities. But when I read comments in the Wineconf report about git:
> "Developers might not like it, but Alexandre does so it's a success" (did I
> mention I dislike git also???) and the inability of the Wine community to
> set up a patch management system (so patches won't disappear into the big
> void) because Alexandre refuses to use it if it won't work in Emacs I'm
> starting to wonder if people realise that the developers don't work for
> Alexandre. He's a great Benovelent Dictator on technical issues, but in my
> opinion only a Dictator on patch process management.

While we're going on about personal likes and dislikes, I like git, it saved 
me a lot of work this summer, and the ability to branch whatever I like is 
cool.

Now, getting back to the patch submission process, you're talking about a 
patch management system. How would that look like, in your opinion. We were 
discussing a couple of ideas, but in the end figured that most of those would 
slow down the submission speed of patches that are accepted.

Our idea was to have patches be recieved by the subsytem maintainers, and 
Alexandre would only apply patches he got from those guys. We voted that one 
down.

Now I would be interested in your idea for such a system. I figure that 
writing an emacs frontend won't be too troublesome if it's reasonably 
designed, so let's ignore that for now.

Cheers,
Kai

-- 
Kai Blin, 
WorldForge developerhttp://www.worldforge.org/
Wine developer  http://wiki.winehq.org/KaiBlin/
--
Will code for cotton.


pgpOIh1Warbez.pgp
Description: PGP signature

An MSVCRT_fgetc bug

[Tobias Ringström]

There's a bug in MSVCRT_fgetc in 0.9.21 (likely introduced in 0.9.19) in 
that it sometimes sign extends the byte read from the file. The 
following program illustrates the problem:


   #include 

   int
   main()
   {
   FILE *f = fopen("tmp.bin", "w+");

   fputc(0xe0, f);
   fputc(0xe0, f);
   rewind(f);
   printf("0x%08x\n", fgetc(f));
   printf("0x%08x\n", fgetc(f));
   fclose(f);

   return 0;
   }
 


The output is:

   0x00e0
   0xffe0 (should be 0x00e0 too)
 


The bug is likely this line:

http://source.winehq.org/source/dlls/msvcrt/file.c#L2134

That line is now

   i = file->_ptr++;

but should be

   i = *(unsigned char*)(file->_ptr++);

I don't have a build environment for Wine, and it felt like overkill to 
set one up for this little bug, so I've not been able to verify my 
hypothesis. I hope that's acceptable.


/Tobias

Re: Governance revisited

[Ge van Geldorp]

> From: Steven Edwards <[EMAIL PROTECTED]>
> 
> Which is why we want to have the ambassadors project to help 
> new people in to wine. The thinking goes that if we have some
> people to help hold the hands of new developers and the
> developers that are defacto maintainers of a certain section
> of code will respond to patches as they seem them, this will
> free julliard from having to answer every single patch with a 
> reply.

You can have ambassadors and subsystem maintainers all you want, but in the
end it's still going to be Alexandre who decides if a patch goes in. That
means the end-responsibility of informing developers why a patch was
rejected needs to be with Alexandre. If an ambassador or subsystem
maintainer already explained it, fine, no need to create double work for
Alexandre, but if noone responded I'd still expect Alexandre to send a
notification.

Just for the record, my own policy on patch submission (and I really hope to
get back to working on Wine and submitting patches Real Soon Now :-)) is to
submit a patch once. If I get feedback I'll try to improve and resubmit, but
if it goes the black hole route I'm not going to beg for an explanation. If
the Wine community can't be bothered to provide feedback I can't be bothered
to resubmit. After all, I've already scratched my itch, the bug is already
fixed in my tree, it's the communities loss, not mine.

Ge van Geldorp

Tips for vim users

[n0dalus]

Hi,

Recently I learned a way to have vim automatically change settings
when I'm editing wine source code:

At the bottom of my ~/.vimrc (create it if it doesn't exist):
if !exists("loaded_vimrc_autocmd")
   let loaded_vimrc_autocmd=1
   autocmd BufNewFile,BufRead /data/wine/* set expandtab tabstop=8
softtabstop=4
endif

In my case my wine tree is in /data/wine, so replace this with the
first part of the path to your wine tree. Using the same syntax you
can also put custom settings for other projects you might work on.

This is helpful for me since I usually like to indent using tabs and a
4 space tab width, but now I can edit most of wine's code without
having to worry about fixing my indents all the time.

If anyone is interested, I've also got another Vim tip on the wiki
(from last year), to automate the creation of wide character arrays:
http://wiki.winehq.org/Character_arrays_in_Vim

If any other vim users have tips that help out with wine coding, I'd
love to hear them!

Maybe we can make a page on the wiki for them.

n0dalus.