Steven Edwards wrote:
What you and others are asking for is the right to add broken hacks for
the sake of user experience.
...
I didn't ask for anything and I said I don't think WineHQ is even able
to change this process.
Misconstruing the words, intent, and plain meaning expressed by
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
Jim White [EMAIL PROTECTED] wrote:
Your efforts don't add value to it either. All you trying to do, is
create another poor quality software that whole world just can't get rid of.
If you so much like to have bad quality patches, why don't you start
your own repository, and grant patch
On Sat, 2006-09-23 at 15:26 +0930, n0dalus wrote:
A good patch handling system might:
- Watch the wine-patches list, automatically adding patches and
comments (replies)
- Provide a way to categorise/tag patches
- Have a way of creating patch sets, which can be downloaded as a
single diff
.. another small update, now tries to create the buffer size as close as
possible to what the app requested.
The whole patch is available at the same URL, I also created a patch of
only ./dlls/winmm/winealsa/audio.c to make it easier to read the patch,
the patch is here:
On Saturday 23 September 2006 10:32, Scott Ritchie wrote:
Frankly, all we really need is for Alexandre to write a 10-second reply
to wine-devel for each patch he rejects.
On WineConf, we decided against this. That would still slow down the overall
patch submission speed. Consider you have a
On Sat, 2006-09-23 at 11:24 +0200, Kai Blin wrote:
On Saturday 23 September 2006 10:32, Scott Ritchie wrote:
Frankly, all we really need is for Alexandre to write a 10-second reply
to wine-devel for each patch he rejects.
On WineConf, we decided against this. That would still slow down the
Sebastian Reichelt [EMAIL PROTECTED] wrote:
+if (winpos-flags SWP_FRAMECHANGED)
+{
+DWORD style = GetWindowLongW( winpos-hwnd, GWL_STYLE );
+X11DRV_set_iconic_state( winpos-hwnd );
+if (style WS_MINIMIZE)
+return TRUE;
+}
+
if
Bugzilla currently lacks categories for several important
parts of wine. This is natural - nothing's perfect.
Rather than fix this all at one go, let's just add categories
as we find we need them.
I propose adding categories for msxml and setupapi now.
Here are bugzilla queries that find quite
For the past two years, I've helped UCLA's cs130 by pointing
them at an area of Wine that needs improvement
and helping them get patches submitted.
For Winter 2007, I'm considering having them focus on msxml3.
So I'm starting to look at bugzilla (see my previous message)
and dig up demo apps and
I propose adding categories for msxml and setupapi now.
Here are bugzilla queries that find quite a few bugs that
are candidates for moving into those categories:
Good idea. In case someone is going to add these catagories, please also add
catagories for comctl32 and msvcrt. Regards
Tomas Carnecky wrote:
.. another small update, now tries to create the buffer size as close
as possible to what the app requested.
The whole patch is available at the same URL, I also created a patch
of only ./dlls/winmm/winealsa/audio.c to make it easier to read the
patch, the patch is here:
- Original Message
From: Mike McCormack [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: wine-devel@winehq.org; Marcus Meissner [EMAIL PROTECTED]
Sent: Friday, September 22, 2006 11:42:36 PM
Subject: Re: Governance revisited
The current process is crippling this project, limiting the
13 matches
Mail list logo
