Mike McCormack wrote:
Ge van Geldorp wrote:
My objective is to improve Wine by maximizing the number of patches of
acceptable quality. In my opinion, this can be done by:
1) assuring no patches get lost
2) assuring an author gets informed about why his patch is not
acceptable in
its current
Ge van Geldorp wrote:
Actually, that's not how I intended things to work. The automatic removal
from the queue would only happen if the patch had a RFC status, i.e. if
action is expected from the patch submitter. If the patch is unopposed and
just waiting in the queue, it should stay there.
It's
> From: Jakob Eriksson [mailto:[EMAIL PROTECTED]
>
> I have been watching this thread with keen interest.
>
> Alexandre does not HAVE to respond to that patch, he can
> silently ignore it just like he can now.
>
> The only difference with Patchwork would be that after a
> certain time with no
Hello Mike,
> From: Mike McCormack [mailto:[EMAIL PROTECTED]
>
> That sounds good, but it's not reasonable to put the
> responsibility on Alexandre, as he has enough work already.
Unless you can read Alexandres mind, he's really the only one who can tell
what he didn't like about a certain pa
Ge van Geldorp wrote:
My objective is to improve Wine by maximizing the number of patches of
acceptable quality. In my opinion, this can be done by:
1) assuring no patches get lost
2) assuring an author gets informed about why his patch is not acceptable in
its current form so he can improve it
On Thursday 28 September 2006 05:49, Mike McCormack wrote:
> Seems like that is a system that doesn't scale well at all, as it
> requires Alexandre to specifically respond to each and every patch.
He still has to take an action to review each patch now, and presumably some
action to remove it fr
Ge van Geldorp gse.nl> writes:
>
> > From: Vitaliy Margolen kievinfo.com>
> >
> > So in a sense you will require some one to respond for any
> > incoming e-mail to wine-patches. And if no one does,
> > Alexandre don't get to see the status?
>
> Not sure I understand what you mean. If no-one
> From: Vitaliy Margolen <[EMAIL PROTECTED]>
>
> So in a sense you will require some one to respond for any
> incoming e-mail to wine-patches. And if no one does,
> Alexandre don't get to see the status?
Not sure I understand what you mean. If no-one responds to the patch on
wine-devel the patc
Ge van Geldorp wrote:
>> From: Mike McCormack [mailto:[EMAIL PROTECTED]
>>
>> Seems like that is a system that doesn't scale well at all,
>> as it requires Alexandre to specifically respond to each and
>> every patch.
>
> No, it doesn't require that. It requires *someone* to respond, that could
On Thursday 28 September 2006 05:49, Mike McCormack wrote:
> Seems like that is a system that doesn't scale well at all, as it
> requires Alexandre to specifically respond to each and every patch.
He still has to take an action to review each patch now, and presumably some
action to remove it fr
> From: Mike McCormack [mailto:[EMAIL PROTECTED]
>
> Seems like that is a system that doesn't scale well at all,
> as it requires Alexandre to specifically respond to each and
> every patch.
No, it doesn't require that. It requires *someone* to respond, that could be
a fellow developer on wine
On 9/27/06, Mike McCormack <[EMAIL PROTECTED]> wrote:
Responding to each and every patch seems like it would be a waste of
Alexandre's time. We should encourage more people to participate in the
patch review process, so that we have more reviewers and a more scalable
process.
+1
--
James Ha
Ge van Geldorp wrote:
It would make sure the author always receives some kind of feedback (either
from the bot, other developers or yourself) and would make sure patches
don't get lost (patches are automatically entered into the system and only
leave the system when the author withdraws them or
> From: Alexandre Julliard <[EMAIL PROTECTED]>
>
> If you expect
> anything to happen, you'll need to make much more concrete
> suggestions, and provide examples to make us understand how
> what you are suggesting would work in practice
Fair enough. Some disclaimers upfront: I'm basically thin
On Tuesday 26 September 2006 22:09, Alexandre Julliard wrote:
> Robert Lunnon <[EMAIL PROTECTED]> writes:
> > Well thats at least a reasoned response, even if I don't agree with the
> > reasoning. But again you simply miss the point. I don't care that
> > Alexandre doesn't move my patches (because
On Tuesday 26 September 2006 22:55, Jeremy White wrote:
> 1. We can write a utility that lets us compare a winehq commit
> message to a wine-patches email and see if there is a 'match'.
> 100% isn't required, but some nice non zero number is.
>
> A key requirement is t
Accepted patches will appear in the wine-cvs mailing list.
Patches with obvious problems may receive a response on wine-devel.
Some patches may not receive any response. In this case, your patch
maybe considered 'Not Obviously Correct', and you can:
* check the patch over yourself, and thin
I didn't respond to Alexandre's point earlier, but wanted to now:
> To the private email issues, Alexandre replied:
>
> There are a fair number of such cases, yes. Not so much the bad
> patches but the corrupted/mangled/doesn't apply patches; I don't want
> to fill wine-devel with "this patch is
Robert Lunnon <[EMAIL PROTECTED]> writes:
> Well thats at least a reasoned response, even if I don't agree with the
> reasoning. But again you simply miss the point. I don't care that Alexandre
> doesn't move my patches (because its not true that he doesn't) and since I
> now have a patch mana
Troy Rollo wrote:
> 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.
On Tuesday 26 September 2006 19:35, 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 particul
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.
It's v
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 sayin
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 syste
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 spen
"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
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 a
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, a
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
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
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
> patch
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, an
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
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 gett
"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 re
"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 re
> 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
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
c
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
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
>
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/05105
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
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
>
> 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
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
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 dev
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 elimin
"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 wo
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
> 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
On Monday 25 September 2006 15:27, Steven Edwards wrote:
> Which is why we want to have the ambassadors project to help new people in
> to wine. ... if... the developers that are defacto maintainers of
> a certain section of code will respond to patches as they seem them...
> the experts in that ar
-- Forwarded message --From: Steven Edwards <[EMAIL PROTECTED]>Date: Sep 25, 2006 1:27 AM
Subject: Re: Governance revisitedTo: Troy Rollo <[EMAIL PROTECTED]>On 9/25/06,
Troy Rollo <[EMAIL PROTECTED]> wrote:
The present system turns people off even before you've had time to learnwh
On Monday 25 September 2006 13:16, Dimi Paun wrote:
> On Sun, 2006-09-24 at 12:36 +0900, Dmitry Timoshkov wrote:
> > Everyone who complaints about "problems" with patch acceptance policy
> > seem to claim that, but my impression is that complaints are going
> > from technically incompetent people,
On Sun, 2006-09-24 at 12:36 +0900, Dmitry Timoshkov wrote:
> Everyone who complaints about "problems" with patch acceptance policy
> seem to claim that, but my impression is that complaints are going
> from technically incompetent people, who just "feels" that the process
> can be improved, but can
On Saturday 23 September 2006 19:24, Kai Blin wrote:
> On WineConf, we decided against this. That would still slow down the
> overall patch submission speed. Consider you have a patch that's just fine,
> but before you sent that, I sent in ten patches with C++ style comments.
> Alexandre would now
On Saturday 23 September 2006 11:39, Steven Edwards wrote:
> As it stands right now the only reason technically
> good patches have been rejected is due to concerns over reverse engineering
> in another project.
I don't see the difference between rejection and "I won't put this in yet
because I
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 prov
Jim White wrote:
The whole "quality" and "hack" language is a red herring. To see that
it is selective and subjective, just look at the code, try xrender.c for
example.
The difference is that presumably the person who submitted that code
demonstrated that they understood the problem that t
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
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 se
On Saturday 23 September 2006 18:10, Hiji wrote:
> I think Bob, Jim and co. were very diplomatic in their recommendations, and
> I firmly believe that they symbolize the opinions of a much larger group of
> people. I don't think they've overstepped their boundaries at all, have
> "complained" or r
From: Kai Blin <[EMAIL PROTECTED]>
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 s
Scott Ritchie wrote:
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
Andreas Mohr wrote:
> Hi,
>
> On Wed, Sep 20, 2006 at 08:52:45PM -0600, Vitaliy Margolen wrote:
>> Dr J A Gow wrote:
>>> How to capture these 'lost' contributions is a difficult issue. Maybe a
>>> centralized repository for patches could be maintained separate from the
>>> main
>>> Wine tree and
Vitaliy Margolen wrote:
The next question is how long does someone wait till resorting to
Bugzilla. Depending on the criteria it could generate a fair bit of
-several days :)
As in if some one wants to fix something, they should either provide a
test (best choice) or open bug and describ
"Hiji" <[EMAIL PROTECTED]> wrote:
- 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
> From: Kai Blin <[EMAIL PROTECTED]>
>
> 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
- 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 pr
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 do
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 p
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 dif
"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 ac
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 w
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 peo
On 9/23/06, Robert Lunnon <[EMAIL PROTECTED]> wrote:
1. Publish the patch acceptance policy - Make sure this is the acceptance
policy and not the patch acceptance process. The Patch acceptance policy
should be developed by community process and be subject to change (and change
control). Perhaps
Hi Jim,On 9/22/06, Jim White <[EMAIL PROTECTED]> wrote:
Steven cited the business at Wineconf of Alexandre never being "provedwrong on a technical matter". Another straw man. The part ofAlexandre's patch process that is the root of this conflict between Wine
development-focused developers vs. Win
Vitaliy Margolen wrote:
> Robert Lunnon wrote:
>
>>>Getting feedback isn't always easy, so listen when you get it.
>>>
>>>If you don't want to go to the effort required to get your patches into
>>>Alexandre's tree, they're not going to get in themselves.
>>>
>>>Mike
>>
>>Rubbish,
>> The curr
Hello Robert,I am an employee of CodeWeavers and one of the former project coordinators of the ReactOS Project though my views do not represent either the position of my employer or the ReactOS Project of which I am no longer actively affiliated.
This thread was part of the reason I wanted to chair
Robert Lunnon wrote:
>> Getting feedback isn't always easy, so listen when you get it.
>>
>> If you don't want to go to the effort required to get your patches into
>> Alexandre's tree, they're not going to get in themselves.
>>
>> Mike
>
> Rubbish,
> The current process is crippling this pr
Jeff Latimer wrote:
>> And exactly this information should probably be stated in the
>> wine-patches subscription welcome mail.
>>
>> "If for some reason the Wine patches you submit fail to get applied,
>> then we'd appreciate you taking the effort of submitting your current
>> patch
>> as a new it
On Thursday 21 September 2006 07:09, Dr J A Gow wrote:
> After having followed this thread for some time, I feel that there is an
> aspect that is often missed in the debate.
>
> As I see it, it would appear that Wine contributors fall into essentially
> two camps. There are those who develop Wine
On Thursday 21 September 2006 04:25, Mike McCormack wrote:
> Robert Lunnon wrote:
> > Which you are entitled to, but my opinion happens to differ. Whether the
> > wine core source has all the patches, (Which it doesn't - many, but not
> > all) isn't relevant, it's the process that they go through
On Thursday 21 September 2006 03:48, Jeremy White wrote:
> >>Wine works fine as-is in my opinion ;)
> >
> > Which you are entitled to, but my opinion happens to differ. Whether the
> > wine core source has all the patches, (Which it doesn't - many, but not
> > all) isn't relevant, it's the process
Andreas Mohr wrote:
Why reinvent the wheel? If such people can spend their time chasing down the
problem
and developing a fix for it, they sure can open a bug in bugzilla, describe
theproblem
and attach a patch they made. How more simple can it be?
No patches lost, no extra places to look for
Andreas Mohr wrote:
> And exactly this information should probably be stated in the wine-patches
> subscription welcome mail.
>
> "If for some reason the Wine patches you submit fail to get applied,
> then we'd appreciate you taking the effort of submitting your current patch
> as a new item at b
Hi,
On Wed, Sep 20, 2006 at 08:52:45PM -0600, Vitaliy Margolen wrote:
> Dr J A Gow wrote:
> > How to capture these 'lost' contributions is a difficult issue. Maybe a
> > centralized repository for patches could be maintained separate from the
> > main
> > Wine tree and with a very loose method of
Dr J A Gow wrote:
> How to capture these 'lost' contributions is a difficult issue. Maybe a
> centralized repository for patches could be maintained separate from the main
> Wine tree and with a very loose method of acceptance (maybe just ensure that
> it
> is clearly indicated what the patch is f
After having followed this thread for some time, I feel that there is an aspect
that is often missed in the debate.
As I see it, it would appear that Wine contributors fall into essentially two
camps. There are those who develop Wine for Wine's sake. This category includes
the core developers, and
On 9/20/06, Vijay Kiran Kamuju <[EMAIL PROTECTED]> wrote:
Some kinda patch management system would help. I think like bugzilla.
It'd better have an emacs interface ;)
-Brian
Some kinda patch management system would help. I think like bugzilla.
On 9/20/06, Jeremy White <[EMAIL PROTECTED]> wrote:
>>Wine works fine as-is in my opinion ;)
>
>
> Which you are entitled to, but my opinion happens to differ. Whether the wine
> core source has all the patches, (Which it doe
Robert Lunnon wrote:
Which you are entitled to, but my opinion happens to differ. Whether the wine
core source has all the patches, (Which it doesn't - many, but not all) isn't
relevant, it's the process that they go through that I believe could improve.
The way to get your changes in is no
>>Wine works fine as-is in my opinion ;)
>
>
> Which you are entitled to, but my opinion happens to differ. Whether the
> wine
> core source has all the patches, (Which it doesn't - many, but not all) isn't
> relevant, it's the process that they go through that I believe could improve.
For t
On Sunday 17 September 2006 21:48, Marcus Meissner wrote:
> On Sun, Sep 17, 2006 at 08:09:24AM +1000, Robert Lunnon wrote:
> > I note the recent flamefest, where some of this list seared yet another
> > contributor (Roland Kaeser)
> >
> > Since this particular very old, very shrivelled chestnut. is
On Sun, Sep 17, 2006 at 08:09:24AM +1000, Robert Lunnon wrote:
> I note the recent flamefest, where some of this list seared yet another
> contributor (Roland Kaeser)
>
> Since this particular very old, very shrivelled chestnut. is one of my
> personal favourites (thanks to Colin Wright for the
On Sunday 17 September 2006 00:09, you wrote:
> I note the recent flamefest, where some of this list seared yet another
> contributor (Roland Kaeser)
You might have noticed that none of the core contributers commented on this,
because they're all at WineConf right now. Just chill, I think there'l
I note the recent flamefest, where some of this list seared yet another
contributor (Roland Kaeser)
Since this particular very old, very shrivelled chestnut. is one of my
personal favourites (thanks to Colin Wright for the chestnut thing...). I'd
like to repeat my observations about this. Feel
96 matches
Mail list logo
